　開発インタフェース協定（DIA）で合意するプロセスが、顧客と契約する上で最低限必要な機能安全プロセスであることは先に述べました。この作業範囲に含まれるのは製品開発のためのプロセス、いわゆるエンジニアリングプロセスだけではありません。製品開発を管理するマネジメントプロセスや、それに関連する支援プロセス、製品の機能安全のための監査やアセスメントといった支援業務も含まれてきます。

　表3は、DIAの主な要求事項から見た機能安全プロセスを整理したものです。この中で「機能安全に必要なプロセス」欄で示したものは、あくまでサンプルですから、もちろんこれとは別構造、別名称のプロセスを作ってもなんら問題はありません。


DIAで合意すべきこと	機能安全に必要なプロセス	関連する規格条項
入力情報	製品開発プロセス。機能仕様書、安全目標、安全要求などの入力となる成果物規定	Part4、Part5、Part6
安全管理者の任命／計画立案	安全管理プロセス。安全管理者任命、安全計画の立案、テーラリング基準など作業開始時の作業や責任・権限に関する規定	Part2：6節
テーラリング結果	製品開発プロセス。安全要求、設計、テスト、安全分析などエンジニアリング関係の作業規定	Part4、Part5、Part6
やりとりする成果物	構成管理・文書管理プロセス。成果物の管理と配布など成果物や文書・記録などの版管理やリリースに関する規定	Part2：6.4.6、Part8：7節、10節
進捗状況の報告／アノマリの報告	安全管理プロセス。進捗管理、問題管理、エスカレーションなどのプロジェクト管理規定	Part2：5節、6節
変更発生時の対応	変更管理プロセス。影響分析、変更時の承認・報告	Part8：8節
機能安全監査の実施	機能安全監査。監査計画、実施要領、監査報告	Part2：6.4.8
機能安全アセスメントの実施	機能安全アセスメント。アセスメント範囲、役割分担（顧客・自社）	Part2：6.4.9、Part4：10節
生産時の対応	生産管理プロセス	Part7
表3　DIAから見た必要な機能安全プロセス

　表3の「関連する規格条項」の欄を見ていただくと分かりますが、この切り口はあくまでDIAから見ただけであり、これで全ての規格要求を満たした機能安全プロセスが実装されるわけではありません。しかしながら、主だったプロセスは、おおむね含まれていますので、これらのプロセスを骨格にして、残った部分を肉付けすればよいのではないかと思います。もし、機能安全プロセスのベースにできるようなプロセス資産が既に存在しているのであれば、それとの対応関係を見ながら、足りないプロセスや作業を明らかにするとよいと思います。

中小サプライヤにとっての機能安全アセスメント

　表3に示したプロセスの中で、中小サプライヤという立場で機能安全プロセスを考えると少々やっかいなのが、機能安全アセスメントでしょうか。機能安全アセスメントは、ISO 26262：Part2に出てくる表2の定義によれば、「アイテム」の機能安全を評価することになっています＊3）。アイテムの構成要素のみを担当する中小サプライヤが、アイテム全体に関わる機能安全についての合否を判定するとは考え難いので、規格要求をそのまま受け入れることは現実的ではないでしょう。通常、安全目標を達成するための安全方策は、アイテムレベルあるいは車載システム全体で考えることで、構成要素単独の視点で安全を評価するのには限界があります。

＊3）対象製品にASIL-CまたはASIL-Dが割り付けられた場合のみ。ASIL-Bの場合は推奨。

　中小サプライヤという立場で現実的にできることは、機能安全アセスメントへの要求全体を担うのではなく、全体の中の一部分のみを担うという考え方であろうと思います。システム全体としての機能安全は評価できないが、担当した製品が要求に従い正しいプロセスで開発されたことをしっかり評価するというアプローチです。例えば、自社の担当範囲内で実施される検証活動の結果や機能安全監査の結果を評価し、「安全要求が確実に展開されているか」、「テストが十分に行われているか」、「未解決の問題が残っていないか」といった項目について客観的な視点で評価するといったことです。客観的な視点での評価は、開発の当事者が思い込みに影響されて気付き難いことを発見する効果的な手段です。

　とはいえ、具体的なやり方や評価観点、対象範囲や評価の深さなどは契約相手方（顧客）との間で調整し、合意する必要があるでしょう。顧客が実施するケースもあります。いずれにしても、この検討には、前回も触れたように、自組織の事情も十分考慮して、少しでも効果の上がる活動を考えるべきでしょう。

補足：DIAについて

　今回は、膨大な規格要求事項から機能安全プロセスを実装するに当たって、DIAを起点に、その切り口から最低限必要なプロセス要素を絞り込むことについて解説しました。

　しかし、現実のビジネスを考えると、このDIA自体もどこまでの範囲で必要なのか分からないといった質問をいただくことがあります。例えば、日本の開発現場でよく見られる、製品開発を委託するのではなく、製品開発に必要な技術サービス（人的なサービス）を提供するケースはどうなるのかといった質問です。他社のソフトウェア技術者が自社に常駐して開発するようなケースのことです。

　DIAは、製品の分散開発を行う場合には、責任もそれぞれ分担しましょうという考え方ですから、成果物責任を負わないこうしたケースでは、DIAを結ぶのは難しいのではないかと思います。当然DIAを結ばないのであれば、責任は分担できない（責任は発注者が負う）ということになりますので、発注する側は相応の作業管理が必要になるでしょう。

　次回は、今回に引き続き、「プロセスの実装」について主なPartごとに実装上のポイントを解説してみようと思います。