プロセスの定義と遵守

トップダウンのアプローチになる

他者に対して、安全面を十分に考慮して開発したことを示したり、その組織が「機能安全」を考慮した開発を行える能力があることを示したりするためには、その根拠を論理的に説明できる必要があります。そのため、「ISO26262」 でも上流工程で決めた安全要求を設計、実装まで落としていくというトップダウンでの開発方法が規定されています。

一方、開発現場では、具体的な仕様を検討する中で安全機能を検討していくようなすり合わせ型の開発が行われている場合が多く、上流工程の成果物を作成できていないために、安全性の根拠を十分に示せないことが懸念されます。

組織に合った開発プロセスを定義する

「ISO26262」では、Part4 からPart6 でシステム開発、ハードウェア開発、ソフトウェア開発で実施すべきことが規定されており、Part8で構成管理や変更管理、検証といった支援系のプロセスに関することが規定されています。

しかし、ただ規格に規定された内容に合わせてプロセスを定義すればよいわけではなく、そのプロセスに従うことで開発がより良くなることが大事です。

また、「ISO26262」に従うために既存の開発方法を大きく変えてしまいたくなるかもしれませんが、それでは開発が回らなくなってしまうため、既存の開発方法で良い部分はそのまま流用し、不足している点や改善の必要な作業を検討することが賢明です。

プロセスに従った開発を行うには

開発プロセスは開発者が行うべき作業の手順を表したものですので、自分が行うべき作業をどのように行うかを理解するためにも開発者自身で考えるべきです。自分で決めた開発プロセスなら、その作業の意図や目的を理解しているため、そのプロセスに問題点があることが分かれば継続的に改善することができ、形骸化しにくくなります。

また、プロセス検討の専任チームが開発組織の標準プロセスを定義する場合であってでも、対象のプロジェクトに合うように標準プロセスを修正（テーラリング）するのは作業を担当する開発者自身が行う方が、プロセスに対する理解が深まり、プロセスに沿った開発も行いやすくなります。

機能安全 関連コラム

「機能安全」対応支援に関する記事を見る

他のソリューションを見る

最新コラム