「プロセス実装」のポイント（その1）：機能安全管理プロセス：中小サプライヤのための実践的ISO26262導入（4）（3/4 ページ）

中小サプライヤを対象に、ISO 26262に取り組む上での実践的な施策について紹介する本連載。第4回は、第3回で基礎を解説した「プロセス実装」のうち、Part2の機能安全管理プロセスについて掘り下げる。Part4〜6のエンジニアリングプロセスについても、ティア1サプライヤの取るべき対策を紹介しよう。

[DNVビジネス・アシュアランス・ジャパン機能安全部チーム，MONOist]

プロジェクトレベルの機能安全管理

　次に、プロジェクトレベルの機能安全管理について掘り下げてみます。ここで要求されていることの大半は、基本的にプロジェクトマネジメントの世界で従来から提案されている内容と変わりません。つまり、プロジェクトを成功に導くための管理手法のことで、計画立案、進捗管理、問題解決などで構成されます。この辺りは、難しく考えずに現行の管理ルールをベースに考えればよいはずです。

　ISO 26262では、こうした伝統的なマネジメント要求に加えて、安全関連特有の要求が追加されています。代表的なものが次の2つです。

• セーフティケース
• 確証方策

　まずセーフティケースですが、この定義は、

“開発中の安全活動の作業成果物を編纂（へんさん）した証拠により、アイテムに対する安全要求が完結しており、かつ満たされていることの論証”

となっています。

　非常に定義が難解なので、その解釈で議論になることが多い要求です。現実的な対応に苦慮している人も多いのではないかと思います。典型的なのが、セーフティケースを「作業成果物一式のことである」という解釈と、「セーフティケース」と呼ばれるドキュメントを開発中に作成される作業成果物とは別に作らなければならないという解釈、どちらが正しいのか、あるいは自動車分野にとって現実的な落としどころはどこなのかという議論です。

　前者の解釈では、開発で作成された作業成果物群自体が、安全要求を満たしたことの論証になるので、作業成果物一式をまとめておけばよいとも言えます。安全要求が具体的な設計となり、これを基に実装され、テストされる。こうした一連の作業の証拠（作業成果物）が、安全要求を完結したことの証明である。従って、このセーフティケースの要求を満たすために余計な作業は必要ないという結論になります。

　一方、後者の解釈は、セーフティケースの定義で“作業成果物を編纂した証拠により”とあるので、作業成果物一式を材料にして、安全を論証するための証拠を別途作らなければなりません。従って、このセーフティケースの要求を満たすためには、新たな作業が必要になるわけです。

　ちなみに、航空や鉄道などの分野では、後者の解釈が一般的です。しかし、コスト制約や開発期間、ハザードレベル（主にSeverity）などが異なる自動車分野でも同じ解釈が成り立つのかという議論は、ビジネス面を考慮すれば当然と思います。

　いずれにしても、この要求は相手のいる話ですから、誰に対して論証するのかという点に立ち返る必要があると思います。その相手とは、間違いなく納入先となる顧客であり、その顧客が納得する形で提示すべきというのがこの要求の本質ではないでしょうか。決して規格（の解釈）が相手ではないということです。

　つまり、規格の解釈がこうだからこの程度でよいというものではありません。この製品が安全なのかを判断しなければならない人が、「セーフティケース」を見て判断できるものなのか、それは開発者として現実に提供可能なのかという議論であるべきです。