ISO26262 Part.8 支援（管理プロセス）：自動車分野の機能安全規格「ISO26262」とは何か？（3）（2/2 ページ）

自動車分野向けの機能安全規格「ISO26262」。今回は、システム、ハードウェア／ソフトウェアに関係する「ISO26262 Part.8 支援」の管理プロセスについて解説する。

[河野喜一（NEC コンサルティング事業部），＠IT MONOist]

構成管理

　ISO26262の「構成管理」では、ISO9001やTS16949をベースに、ISO12207のソフトウェア構成管理プロセスを採用することとなっています。日本では、あまりISO12207に準拠した開発を見掛けませんが、Automotive SPICEやCMMIの構成管理プロセスに準拠している場合は適用しやすいプロセスとなります。

　また、構成管理というと、何を管理するのか分かりにくいかもしれませんが、作業工程ごとの成果物を管理する“成果物管理”と呼ぶと分かりやすいことがあります。構成管理プロセスでは、作業工程ごとに作成する全ての成果物に対して、「成果物のバージョン」「部品としての成果物セット」「製品としての成果物セット」の管理を行うのが基本となります。

　成果物セットにベースラインを設定して、成果物セットのバージョンを管理します。このベースラインが設定された成果物セットを、次の工程の作業者や協力会社に渡すことによって次の工程が開始されます。

図1　北米向けと日本向けのソースコードベースライン例

　この成果物セットをきちんと管理していない場合、不正なファイルを参照することによる開発ミス、不正なファイルが混入することによるコンパイルエラー、テスト工程での不具合につながることがあり、開発規模が大きくなるほど開発工数への影響が大きくなります。

　構成管理プロセスは、開発プロセスはもちろんのこと、要求管理や変更管理プロセスを実施する前提条件になりますので、構成管理を実施することは、全てのプロセスの中でも優先度が高くなります。しかし、その半面、構成管理環境に故障が発生すると全ての作業が停止してしまうため、構成管理環境への高い信頼性が要求されます。

変更管理

　ISO26262の「変更管理」では、変更要求が発生したときのプロセスフローと、各プロセスでどのようなことをするのかという要求が定義されています。

　変更管理で重要なのは、変更箇所に関する影響分析を実施して、影響箇所に対する修正有無を確認することと、どのバージョンでリリースするかを明確にすることです。つまり、構成管理と要求管理（成果物間のトレーサビリティ）プロセスがきちんとできている必要があります。

　この変更管理プロセスが実施されていないと、バグ修正時に関連する箇所の修正モレや関連する要求を満たせなくなるという不具合のモグラたたきが始まってしまいますし、リリースする予定がない不要な機能をリリースして不具合を誘発してしまうことにもなりかねません。さらに、開発者への不具合対応指示がたまりやすくなることで、開発者への負荷増加による開発効率低下にもつながります。

　また、要求の管理項目に「作業実績」がある場合には、変更要求に対する工数の見積もり精度が上がり、変更要求を受け付けるかどうかの判断に使うこともできます。

図2　変更管理時、要求管理項目を利用した作業見積もり

　さらに、実際の開発においては、過去との差分開発を行うことが多いのですが、構成管理と要求管理プロセスが実施されておらず、過去の成果物（主にソースコード）を修正すると、どこに・どのような影響を与えるかが分からず、修正することができないという問題も発生します。

　このような状況になってしまうと、一度全体を作り直さない限り、過去の成果物を修正できなくなってしまいますので、開発している製品が一度限りの製品なのか、将来拡張されるものなのかを判断して、構成管理、要求管理、変更管理プロセスの実施度合いを決める必要があります。

図3　構成管理をベースにした変更管理と要求管理

開発支援ツールなしでは、管理プロセスを実現できない!!

　ISO26262の支援（管理プロセス）では、構成管理ツールや変更管理ツールだけでなく、場合によっては要求管理ツールも必要となるなど、開発環境を整備しないことには管理プロセスの実現が難しくなります。

　また、（日本のソフトウェア開発でありがちですが、）短期間開発のためにドキュメント作成を省略してしまい、ソースコードだけが成果物として存在する場合、構成管理や変更管理で管理されるのはソースコードのみとなってしまいますので、管理対象をソースコードだけでなく、ドキュメントまで広げることも重要となってきます。その上で、ドキュメント間のトレーサビリティを確立するために要求管理ツールを適用していくことになります。

　これらの管理ツールを導入するためには、初期投資や開発者による習熟が必要になります。初期投資に関しては、開発効率と品質向上という効果で回収を見込むことができますし、構成管理ツールや変更管理ツールのようにモデリングツールやコーディングツールなどの開発環境に統合されてバックグラウンドで動作するようなツールですと、開発者が意識せずに使うこともできます。

　この際、現状プロセスや開発者のスキルに合った管理ツールを導入していくことも重要なポイントになります。

　例えば、最初から高機能な管理ツールを導入しても、開発プロセスや開発者のスキルが追い付いておらず、機能を使い切ることができなかったり、低機能な管理ツールを導入しても、開発者のスキルが高い場合には機能不足だったりすることがあります。また、低機能なツールから高機能な管理ツールへ移行することが困難だったりする場合もあります。

　これだけではなく、ISO26262では、製造や生産部門も関わってくるため、PLM（Product Lifecycle Management）との連携機能も注目されてきています。

---

　次回は、ISO26262 Part.8 支援の続きとして、「検証・認定系」について取り上げ、使用するツールの事前認定などのお話を紹介したいと思います。ご期待ください！ （次回に続く）

筆者紹介

河野喜一（こうのよしかず）
NEC コンサルティング事業部
（http://www.nec.co.jp/service/consult/vision/softconsul/safety_05.html）
産業機器開発、通信機器開発、ALMベンダー、組み込みコンサルを経て、現職。専門分野は、開発者の視点による開発プロセス改革（管理面、開発面）、規格適用コンサル。現在、組み込み開発の開発プロセス改革、ISO26262適用コンサルに従事。