　ベースにするプロセスとは、機能安全活動を追加定義する場合の基になるプロセスのことで、既に多くの企業で導入されている品質マネジメントプロセス^＊3）を基にする例も多いようです。品質・信頼性関連の業務に携わってきた人ならばなじみのあるプロセスでしょうし、機能安全規格の前提としても「品質管理システム」があるので、基にするプロセスとして適しています。ただし、これらの規格は組織に向けられたマネジメント規格であるため、ISO 26262のPart2（機能安全の管理）やPart8（支援プロセス）などの管理系プロセスとの相性は良いのですが、Part4（システム）、Part5（ハードウェア）、Part6（ソフトウェア）などのエンジニアリング系プロセスについては、相応の工夫が必要になるでしょう。

＊3）ISO9001やTS16949などの規格に対応したマネジメントプロセスのこと。

　一方、ソフトウェア開発を重視してきた企業では、CMU/SEI^＊4）のCMMI（Capability Maturity Model Integration）や、欧州の自動車産業が推進しているAutomotive SPICEなどに対応したプロセスを運用しているケースも多く、これらのプロセス資産を基にする例も多いようです。欧州では、以前からソフトウェアへの取り組みに積極的だったRobert BoschがCMMIベースのプロセスで、Automotive SPICEの推進・普及に熱心なContinentalなどはAutomotive SPICEベースのプロセスでといったように、これまでの活動資産や経験をいかに生かすかという観点でもプロセス構築戦略が決められているようです。

＊4）Carnegie Mellon University ｜ Software Engineering Institute

　特に、Automotive SPICEは欧州では広く普及しており、ISO 26262と重複する要求（表1）も多く、機能安全に取り組む際のベースプロセスとしては最適かもしれません。この点に着目し、Automotive SPICEに対して機能安全拡張を施した、統合SPICEを策定する動きも活発化^＊5）しています。

＊5）代表的なのがSS7740というスウェーデン規格である。Automotive SPICEの不足分をISO26262の要求を追加した統合版SPICEになっています。国内においても、日本SPICEネットワークの有志メンバーによって、機能安全拡張の検討が進められています。

表1　ISO 26262とAutomotive SPICEの関係（クリックで拡大）

（2）機能安全活動の役割分担

　ISO 26262には、「安全管理者」と呼ばれる製品開発における機能安全活動に対して責任を持つ役割があります。業務内容としてはプロジェクトマネジメントに近いため、プロジェクト管理者が安全管理者を兼務することもできます。しかし、直接的にコスト削減や納期順守の圧力を受けるプロジェクト管理者が、安全を最優先する責任を持たなければならない安全管理者の業務を兼務することによる弊害は十分に考慮されるべきでしょう。

安全管理者の法的責任

　毎年欧州でVDA QMCが主催しているVDA Automotive SYS Conferenceという国際会議があります。昨年（2012年）もドイツのベルリンで開催され、機能安全の話題も数多く取り上げられています。この会議の中で、法律家を招いたワークショップが行われ、法的な側面から見た「安全管理者」の責任についての活発な議論が行われていました。過去の判例を基にした議論ですから一概に安全管理者の責任がどこまで及ぶのかを定義するのは難しいのですが、いずれにしろ、もし開発した製品に安全上の欠陥が見つかり、その問題が法廷に持ち込まれる事態になれば、何らかの形で安全管理者が巻き込まれることは避けられないようです。

　機能安全活動は、安全管理者以外にも「確証レビュー」を実施する「レビューワー」、「機能安全監査」を実施する「監査人」、「機能安全アセスメント」を実施する「アセッサー」といった、確証方策と呼ばれる製品開発の各段階で重要な業務を担う専門家が必要になります。

　安全管理者の責務は、安全面の責任を担うという点を除けばこれまでのプロジェクト管理業務に近い責務であることは先に述べました。

　一方、確証レビューや機能安全監査、機能安全アセスメント（表2）といった新しい責務については、どんな経験を積んだ人がふさわしいのか、どんな能力が必要なのか、今後どんな技術を身に付けるべきかなどなど、多くの組織が悩んでいる課題です。この点は、次に述べる組織構造の課題と合わせて、規格要求の狙いを十分に理解した上で慎重に検討すべきでしょう。