　それでは、視点をティア1サプライヤに戻してみます。ティア1サプライヤであるA社は、自身の開発作業ではなくとも、発注者としての管理業務も明示的に実施しなければならないと前回述べました。つまり、丸投げはダメだと言うことです。例えば、発注先のB社による作業が計画通りに進行しているのかを見る進捗管理や、設計中に発生した問題や課題の管理が必要です。

　もしかしたら、B社の設計によって技術安全要求の変更が発生するかもしれません。こうした業務上の調整事項をきちんと管理しておくことは、開発インタフェース協定（DIA）を結んだ双方の組織の責任です。これらの管理作業を具体的にどんな形で実施するのかを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
表2　DIAから見た必要な機能安全プロセス（第4回の表1から再掲）

　また、技術的な側面においてもやるべきことはあります。システム設計を担当したB社が実施した安全論証^注1）は発注元であるA社が確認し、機械部品を含んだ全体システムの目線から見て、十分であるかを評価し、合意すべきでしょう。後ろの工程でまとめて確認するのでも良いのですが、手戻りの影響などを考えると、早め早めに行う方が良いと思います。

注1：安全論証の手段として代表的なのがセーフティケースです。しかし、欧州などでは発注元がセーフティケースの提出を要求する事例も出てきているようです。

　つまり、発注元としては、プロジェクト管理的な側面の業務と技術管理的な側面の業務が必要で、発注先任せというわけには行かないことを理解しておいてください。仮にA社が機械部品中心の会社で、電子部品の技術者が少ない場合であっても、自動車メーカーから見れば直接の契約先となります。説明責任も負うことになりますし、どんな安全コンセプトのもとに開発された製品なのかを把握していなければならないのです。

　次回は、ハードウェア開発、ソフトウェア開発、そしてシステム開発のテストプロセスについて解説します。