　ISO 26262対応に向けた活動を始める前に、まず「リスク」というものについて理解しておかなければなりません。リスクという言葉やリスク管理という考え方は、なかなか日本にはなじまず、日本企業の弱みになっているという議論をよく耳にします。このことは企業レベルに留まりません。福島第一原子力発電所の事故では、「安全神話」という、リスクを全く無視した最悪のケースを目の当りにすることになりました。

　一方、欧米の人々は、「人間はミスを犯す」、「機械は故障する」という前提に立って考えるため、リスクがゼロになる、絶対に安全であるという考え方を持っていません。存在する（ゼロにならない）リスクを明確に識別し、そのリスクの度合いに応じた最適な対策を取ることが製品開発者の責任であるという考え方です。もちろん、その判断経緯を含めた活動結果は第三者にも見える形になっていなければなりません。この考え方の違いに苦労したのが、2009年に発生したトヨタ自動車の米国における集団訴訟問題です^＊1）。

＊1）最終的にはNHTSAとNASAから電子制御の安全性の確証を得ることで決着しています。

　ISO 26262もこうした前提に立っており、意図した機能が故障した場合に、安全を脅かす可能性やその被害度合い^＊2）を評価して、その結果に応じた対策を取ることを要求しています。その対策について、リスクの度合いに応じて整理した結果が、ISO 26262の規格書の中で、安全要求レベルであるASIL（Automotive Safety Integrity Level）のA～Dに分けて分類されているわけです（表1）。

＊2）ISO 26262ではコントローラビリティという概念も加わり，正確には3つの尺度で評価する。

表1　ASILのレベルに合わせて要求される対策の例。ソフトウェアアーキテクチャ設計のための記法とASILレベルを対応させている。

　多くの人は、このASILレベルごとに並べられた要求事項自体に注目し、短期的な視点でどのように対応しようかと考えてしまいがちです。しかし、これらの対策は、抽象的な表現では利用者に理解されないので、現在の技術水準から考え得る最も妥当な対策^＊3）を、できる限り具体的に並べたと理解すべきです。もちろん、技術が進化すればその対策も変わるべきものなのです。

＊3）「state of the art」という言い方が良く使われている。

　ISO 26262を理解する上で最も重要なのは、ASILレベルごとに並べられた対策・手法などではなく、先述したリスクに対する考え方なのです。つまり、「リスクを慎重に識別」して、自分達が実施する対策や開発活動が「識別したリスクを十分に軽減（許容）できるレベルであるかの判断」を、「組織」が常に意識しながら開発を進めるという点につきるのです。これがISO 26262という規格のベースにある考え、思想、精神なのだと思います。

　リスクを意識できていないと、要求されたASILレベルと、ASILレベルが求める対策を遂行することだけが関心事となり、常に納期要求やコスト制約などにさらされる開発現場が、安全活動までおろそかにしてしまうような事態を招きかねません。もちろん、下流工程で新たなハザードが発見される^＊4）こともなく、ましてやISO 262626が目指す健全な「安全文化」^＊5）も醸成されないでしょう。

＊4）ISO 26262のPart9で、新たなハザードを発見した場合の取り扱いが明記されている。

＊5）Part2で安全文化についての要求が明記されている。

ISO26262の全体像

　先述した通り、ISO 26262は、マネジメント、システム開発、ハードウェア開発、ソフトウェア開発、製造に至る製品の設計・開発全般に適用される規格です。本連載は、規格そのものの解説は主な目的ではありませんので、規格文書の各Partの詳細については、MONOistの解説記事を参照してください。


	「ISO26262」の解説記事：
⇒	「ISO26262」の全体像とソフトウェア開発プロセス
⇒	「ISO26262」の管理プロセスと検定プロセスを読み解く
⇒	「機能安全」の導入で何が変わるのか？

　図2は、自動車の開発プロセスにおける、自動車メーカー、ティア1サプライヤ、ティア2サプライヤ、これらサプライヤの下請けとなるハードウェアメーカー、ソフトウェアベンダーそれぞれの担当範囲と、規格文書のPart2～9までの関わりを大まかに示しています。しかし、これはあくまで規格要求内容から見た目安であり、実際には個別の契約^＊6）によって担当や責任の範囲が決められることになろうかと思います。

＊6）Part8の中に「分散開発のインタフェース」として契約に対する要求が明記されている。この契約は一般的にDIAと呼ばれる。