RAMS[30] Safety Case

2023年6月18日 2023年6月25日

mack0113

RAMSプロセスを用いて、製品またはシステム開発を実施した結果、最後に生成されるものがSafety Caseです。Safety Caseはとても重要なものですが、私の周りでは少し軽視されている気がするので今回はSafety Caseについてい書いてみたいと思います。Safety CaseはRAMS用語ではなく、安全工学やリスク管理の分野で使用される概念です。この Case という英語は沢山の意味があり、また日本人には場合という言葉を思い浮かべます。所謂、Case by Case のような言い回しです。昔、Case by Caseは日本語英語で、Nativeは depends を使うと聞いたことがありますが、実際に英語を使う場では多くの人が、Case by Case を使っていました。

適切な訳はないようなので、Safety Caseという言葉をそのまま使います。あらためて、Safety Caseはなにかというと、

安全工学やリスク管理の分野で使用される概念です。SafetyCaseは、特定のシステムやプロセスの安全性を評価し、証明するために使用されるドキュメントまたはアプローチを指します。SafetyCaseは、システムの設計、運用、保守など、そのライフサイクル全体にわたる安全性に関連する情報をまとめたものです。これには、ハザードの特定と分析、リスク評価、安全要件の定義、安全な運用手順の策定などが含まれます。SafetyCaseは、安全性を確保するための証拠や根拠を提供するために使用されます。これは、関係者（システムの所有者、開発者、監督機関など）に対して、システムが安全であることを示すための文書として機能します。SafetyCaseは、特に航空宇宙、鉄道、原子力、医療機器などの高リスクな産業や分野で広く使用されます。これらの分野では、システムの安全性が非常に重要であり、SafetyCaseは信頼性の証明となります。また、システムまたは製品のライフサイクル全体にわたって継続的に更新され、変更に対応する必要がある場合もあります。

こういうものがSafety Caseだという事です。これをRAMSの認証で考えると、すべて製品またはシステム開発が終了しているのなら、SafetyCaseを認証機関に見てもらえば済む話です。これをXXプランがどうとか、開発手法がどうとかいうのはこれから開発が始まろうとしている場合にのみ意味を持ちます。

認証機関と一緒に開発するとわかりますが、マイルストン毎にOK、NGというように進んでいきます。しかし、アドバイスはできないというスタンスです。これも不思議な気がしています。確かにISAとしての独立性ということからこのような話が出ているのだとは思いますが、アドバイスって本当に独立性から逸脱するのでしょうか？　OK、NGと判断することも言い換えればアドバイスと変わらないと思います。ようは、複数の目を入れて変なバイアスがかからない状態で真摯に開発を進めるという事が求められることであって、アドバイス自体は特に問題ないと私は思っています。因みにこの時点でアドバイスが欲しいというと、ISAの別部隊が出てきて別料金でサポートが始まります。変でしょ？

話を戻しますが、ISAと一緒に開発しているときに、各マイルストーンでOkと言われて次に進む場合、顧客側はここまではISAがOKと言っているので、最終的にもOKだなという認識を持ちます。このような段階を経て最終開発が終わればISAはISAレポートを発行し、晴れてその製品が安全だと第三者に認められることになるわけです。開発時にISAを入れない場合、最終ゴールでSaftey Caseを見てもらうわけですが、ISAは過去を知らないので色々問いただしたあげく、問題点を見つけ出し、これでは認証は出せませんとなるわけです。私がRAMS認証のスキームはおかしいと言っているのは、この部分です。社内ISAがいて、彼が外部ISAと判断基準が変わらないのなら特に問題ないのかもしれません。当然、共通の規格を元にしているわけですから、同じ判断基準になるはずだと思われるかもしれませんが、RAMS規格は曖昧に記述されているので当然判断基準は変わります。私はよく、法律のようなものだよと言っています。それは、同じ法律なのに裁判官によって判例が変わるのは当たり前のことです。それと同じで、RAMS適合性評価も判断基準が複数あって当然だと思います。これも私が主張するスキームの変な部分の一つです。なので、みなが平和になるように、開発時からISAを付けて開発するのだと理解しています。

なので、開発チームが自信をもって製品開発し、その安全性の証拠であるSafety Caseを作っても問題ないという事です。そういう意味でも、Safety Caseは非常に重要なものであり、決して軽視されてはいけないものです。

もう一つ重要なことに、「システムまたは製品のライフサイクル全体にわたって継続的に更新され、変更に対応する必要がある」という事です。つまり、Safety Caseはそのシステムや製品の歴史がすべて記載されていなければなりません。変更部分だけのSafety Caseはあり得ないのです。これは見る側に立てば明らかでしょう。そのシステム・製品の安全性を知りたいのに複数のドキュメント見なくてはいけないというのは不親切です。一方、ドキュメント量は膨大ですから一つのファイルでなければならないことはありませんが、必要なドキュメントに素早くたどり着くことは必要でしょう。事故などがあれば、Safety Caseの提出が求められます。そのためにも、Safety Caseは作成・更新がされていなくてはなりません。

一度作成したSafety Caseをもう一度見てみて、客観的に開発した製品の安全性を証明しきっているかどうかを確認してみることもいいと思います。多分、言いたいことの半分も書いていないのではないでしょうか。これが裁判の証拠になると思うと怖くありませんか？