推進組織立ち上げの着実な「準備」がISO26262対応活動の形骸化を防ぐ：中小サプライヤのための実践的ISO26262導入（2）（1/3 ページ）

中小サプライヤを対象に、ISO 26262に取り組む上での実践的な施策について紹介する本連載。第2回は、機能安全対応の推進役が決まった後の「準備」について解説する。

[DNVビジネス・アシュアランス・ジャパン機能安全部チーム，MONOist]

　前回は、自動車向け機能安全規格であるISO 26262対応に向けた活動を始める前に理解しておくべき「リスク」や、規格の対象範囲、推進役の決定などについて説明しました。

　今回は、機能安全対応の推進役が決まった後の「準備」作業について解説したいと思います。

ISO 26262対応に向けた一般的な流れ（クリックで拡大）

推進組織の立ち上げ

　推進役が決まれば、その担当者はいよいよ本格的に社内の機能安全対応活動を開始します。このとき、主に管理層の方に注意してほしいことが幾つかあります。

推進者への権限付与

　まず、推進役の位置付け、権限を明確にし、社内に知らしめることです。ISO 26262のPart2（機能安全の管理）には「5.4.2 安全文化」という項目があり、その中に「5.4.2.8 組織は安全活動を実行又は支援する人がそれら責務を果たすのに十分な権限が与えられていることを保証しなければならない」という要求があります。

　ISO 26262が製品開発ライフサイクル全体を網羅した大規模な規格であることは前回も述べました。このため、機能安全の推進役は、多くの組織や部署、担当者との交渉・調整が必要になります。この際、推進役の社内における位置付けや権限が曖昧な状態では各部署との調整が難航し、効果的な対応策を打てなくなるおそれがあります。最悪、開発現場との衝突、意識の乖離（かいり）が起こり、結果として現状を鑑みない形骸化した活動になってしまいかねません。

　一般的に推進役は、規格を理解し、要求内容を社内プロセスに落とし込むという、どちらかと言えば技術的な活動が中心であるように思われがちです。しかし現実には、社内各部署との調整、部署間の要望の取りまとめといった調整業務に多くの時間や労力を費やすことになります。

　こうした負担を少しでも減らすためにも、推進役の「権限」を明確にし、その後ろ盾に経営層の支援があることを明確に打ち出してあげる^＊1）必要があります。

　同時に、各関連部署の窓口や意思決定者が誰なのかといったインタフェースを明確にする必要もあります。これが推進役の孤立化を防ぎ、機能安全活動を効果的かつ円滑に進めるための助けになるはずです。推進役の人が精力的に動けるか否かは、この活動の成否にかかっていることを理解してください。

＊1）機能安全活動のキックオフ会議などで全社的に公知するのが一般的なようです。

推進のためのリソース確保

　次に、必要なリソース、特に人的なリソースを推進組織に割り当てることです。推進に必要な権限が付与されたとしても、それを遂行するためのリソースがなければ意味がありません。こちらについても、ISO 26262のPart2（機能安全の管理）、「5.4.2 安全文化」中に「5.4.2.6 組織は機能安全達成に必要なリソースを提供しなければならない」という要求があります。

　ここでいうリソースには、人的リソースだけでなく、開発支援ツールなども含まれています。とはいえ、実際に最も難航するのが人的リソースの確保ではないでしょうか。国内企業では、機能安全活動は外圧（欧米からの）によってもたらされた「余計な作業」であって、「本業ではない」と認識されてしまうことがよくあります。当然、「本業ではない」とされると「必要なリソース」を確保するのは難しくなります。しかし、機能安全活動は安全に関連する製品においては、決して余計な作業ではなく製品開発プロセスそのものです。確かに、「確証方策（Confirmation Measure）」^＊2）などの耳慣れない作業要求が追加されていますが、これらは先行する他分野から得た知見が反映された結果であり、安全な製品作りのためのノウハウ（手法）と捉えて前向きに取り組むべきでしょう。まずは、「余計な作業」であるという認識を粘り強く取り除くことが大前提となります。

＊2）安全に対して影響を与える可能性のあるコストや納期からのプレッシャーを受けない、客観的な視点でチェックする（安全を確認する）という考え方や、切り口を複数（成果物観点、プロセス観点）持ってチェックするという考え方は、セーフティクリティカルシステムの世界では定着した考え方です。

　とはいえ、仮に「余計な作業」という認識を取り除いたとしても、機能安全活動に必要かつ十分な人的リソースを確保することはかなり難しいのが現実でしょう。活動の取りまとめ、意思決定などの重要な業務は社員が行い、場合によっては、それ以外の業務に外部リソースを活用するのも選択肢の1つかもしれません。

　推進組織の立ち上げから、機能安全を適用した製品開発を開始するまでの作業で、量的にも質的にも大きな負担となるのが、機能安全に対応したプロセスの構築です。この作業に外部リソースを活用する例は比較的多いようです。確かに、プロセスを作るという作業は、規格を理解した専門家が対応した方が効率面で有利なのは確かです。しかし、完全に丸投げしてしまうと、構築されたプロセスが開発現場の現実と懸け離れてしまい、たとえ規格に適合した立派なものであっても、なかなか現場にはなじみません。「仏作って魂入れず」というところでしょうか。

　こうした事態を避けるためにも、外部リソースを活用する際には、理想と現実（社内事情）を理解する社内経験者の深い関与が前提になることに注意しなければなりません。