　ISO 26262の全体像を眺めてみると、大変に膨大な規格であることをあらためて認識するとともに、自分の担当部分（例：Part6のソフトウェア開発）だけを理解して、取り組めばよいのではないかと考えたくなります。しかしこの規格は、規格文書の各Partを読んだだけではベースにある考え方、思想を理解し難いというのが悩ましいところです。全てのPartの具体的な要求事項まで理解し、検討する必要はないと思いますが、少なくとも実際の担当業務を遂行する前段階で、どのように安全活動が進められているのかくらいは理解しておきたいところです。

　例えば、ティア2サプライヤにとって、「Part3：コンセプトフェーズ」は自動車メーカーや大手ティア1サプライヤの担当なので、実際に作業を実施する必要はないというのは事実でしょう。とはいえ、上流工程でどのように安全要求が検討され、それらがどのような形で自分たちに割り当てられたのかを理解した上で開発業務に取り組むのと、そうでないのとでは、安全活動上で大きな違いが出てくると思われます。安全上の見落としを発見する（例：下流工程で新たに発見したハザードなど）、適切な設計解を導き出す、あるいは選択するといったことは、全体の流れや思想を理解してこそ得られる効果です。

　現実の業務において、上流工程の源泉となるような機能安全関連ドキュメント（例：H＆R（Hazard Analysis＆Risk Assessment）の結果や機能安全コンセプト）の入手は難しいとは思いますが、最低限ISO 26262が求めていることは理解しておくべきでしょう。

　このような考え方は、宇宙分野でも取り入れられています。下流工程として位置づけられるソフトウェア設計工程でのミスを減らすため、最上流である人工衛星の運用や利用に関わる要求をソフトウェア技術者も参照できるようにして、ソフトウェア設計のためのインプットとする試みがあります。実際には、ソフトウェア技術者が人工衛星の運用に関わる専門知識を有しているわけではないので、全ての要求は理解できませんが、部分的ながら理解していたことによって未然に防がれた設計ミスもあるようです。

推進役の決定

　ISO 26262対応のために自社が取り組まなければならない範囲が決まると、そのための活動を進める上で、誰が旗を振り、どのような社内活動として実施するのかを決めなければなりません。分かりやすい例で説明すると、推進役を技術部門がやるのか、管理部門（例えば品質管理部）がやるのか、ということです。

　また、ISO 26262の要求の大半はプロセス要求です。従って、安全に関わる設計・開発業務のプロセスを定め、それを順守しながら製品開発を進めなければなりません。この場合、まったく新しくプロセスを定めるのか、それとも元となる既存プロセス（例：品質管理システム）に対して変更を加えていくのか、という点もISO 26262対応の推進役を決める上での重要なファクターとなります。

　筆者の経験から判断すると、品質管理部門が主導するパターンと、設計・開発部門が主導して品質管理部門が支援するパターンが多いようです。表2では、品質管理部門と設計・開発部門が、それぞれ得意もしくは不得意とする業務内容について、大まかに比較してみました。実際には、企業固有の特徴があるでしょうから、必ずしもこの通りではないかもしれません。


業務内容	品質管理部門	設計・開発部門
プロセスを定める・整備する	○	×
具体的な手順や要領を作成する	×	○
経営層のコミットメント	○	×
プロセスの定着化	○	×
プロセスの運用・推進	×	○
表2　品質管理部門と設計・開発部門の得意・不得意