
	関連リンク：
⇒	東証ダウン、原因は東証と富士通の連絡ミス
⇒	【特報】東証で大規模システムダウン、プログラム改変が原因

　これに対して、欧米では「CMMI」「SPICE」「ISO」などに基づいて、契約と管理プロセスを実施することによって、受注側の防衛や人的エラーを最低限にする手法がとられています。

　今回は、自動車機能安全規格「ISO26262」で要求される“管理プロセス”について解説していきます。


	関連記事：
⇒	いまさら聞けない機能安全入門

ISO26262の支援（管理プロセス）

　ISO26262の支援（管理プロセス）は、以下、全ての開発工程で実施することが要求されます。

Part.3 構想段階
Part.4 システムレベル
Part.5 ハードウェアレベル
Part.6 ソフトウェアレベル

　また、構成管理や変更管理は上記の開発工程に加えて、「Part.7 生産・運転・サービス」でも実施が要求されます。

　自動車業界では、TS16949によって構成管理や変更管理を実施することが要求されていますが、ISO26262の場合は、より詳細な管理が要求される“ソフトウェアの管理プロセス”であるため、システム担当者やハードウェア担当者は少々戸惑うかもしれません。

ISO26262の分散開発でのI/F

　ISO26262の「分散開発I/F」では、自動車メーカーが部品メーカーに部品開発業務を依頼するとき、または、部品メーカーがさらに協力会社に業務を依頼するときに実施します。これは、自動車の開発に関わる末端の会社までが対象範囲となります。

　このプロセスでは、部品メーカーや協力会社のレベル判定を行い、業務依頼に適した会社を選定することから始まります。会社を選定した後は、要求や問題発生時のエスカレーション方法などを明記した契約書を両社間で締結し、契約に従って開発を実施していくことになります。このプロセスは、業務契約ですので当たり前のプロセスではありますが、米国などのように契約社会でない日本では、意外とできていないプロセスでもあります。

　このプロセスが実行されると、発注側が要求を具体的に決めるため、受注側は仕様変更などを別作業とすることができます。つまり、仕様変更の多発によって一方的にプロジェクトが赤字になるようなケースを防ぐことができるのです。

　日本では、開発の上流工程をうやむやのまま実施し、下流工程や完成後に不具合が発見されることを防止するために、受注側が要求の確認を行う「すりあわせ」という文化が構築されてきました。これに対し、ISO26262では、前述のプロセスが実施されるため、“受注側が要求を確認する手間を省略できる”というメリットがあります。

安全要求定義と管理

　ISO26262の「安全要求定義と管理」では、“安全要求の定義方法”と“安全要求の管理方法”の2つのことが定義されています。

　要求定義時には、要求を階層化することによって要求モレを防止したり、重複している要求をなくしたり、矛盾のある要求を解決したりするという要求定義の基本を実施します。さらに、要求に優先度などの属性を設け、上流と下流の“双方向トレーサビリティ”の管理をするという要求管理の基本が記載されています。

　双方向トレーサビリティは、どの粒度までトレーサビリティを確立するかによって作業量が大幅に変わりますので、最初は成果物（ファイル）単位からトレーサビリティを確立し、徐々にファイルの“章単位””行単位”と拡張していくと効果を得やすくなります。ただし、パラメータなどの値に関しては、行単位や使用している箇所単位でトレーサビリティを確立した方がいい場合もあります。

　なお、日本では、要求定義そのものを省略したり、口頭で指示したりすることによって、要求定義も要求管理も実施されていないことがあります。これに対し、ISO26262では、要求定義を確実に実施し、要求管理も実施する必要があります。その結果、要求に対する作業モレの防止や、過去の製品に関する要求から成果物一式を取り出して“再利用開発”がしやすくなるという効果を得られます。

　要求管理というと“要求だけ”の管理と思われがちですが、トレーサビリティの範囲は要求だけではなく、「設計書」「ソースコード」「テスト結果」なども含まれることに注意してください。