最初の難関「プロセス実装」にいかにして挑むべきか：中小サプライヤのための実践的ISO26262導入（3）（3/3 ページ）

中小サプライヤを対象に、ISO 26262に取り組む上での実践的な施策について紹介する本連載。第3回は、ISO 26262の導入に当たって最初の難関となる「プロセス実装」について解説する。「テーラリング」や「DIA（開発インタフェース協定）」という、ISO 26262で頻出する用語についても取り上げる。

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

契約上欠かせないプロセス領域（2）

　本連載では、機能安全プロセスを必要とする中小サプライヤを想定した解説が主眼ですので、例外的なものの議論はここまでにして、ISO 26262：Part8の5節「分散開発でのインタフェース」の話に戻したいと思います。

　開発インタフェース協定（DIA）で合意するプロセスが、顧客と契約する上で最低限必要な機能安全プロセスであることは先に述べました。この作業範囲に含まれるのは製品開発のためのプロセス、いわゆるエンジニアリングプロセスだけではありません。製品開発を管理するマネジメントプロセスや、それに関連する支援プロセス、製品の機能安全のための監査やアセスメントといった支援業務も含まれてきます。

　表3は、DIAの主な要求事項から見た機能安全プロセスを整理したものです。この中で「機能安全に必要なプロセス」欄で示したものは、あくまでサンプルですから、もちろんこれとは別構造、別名称のプロセスを作ってもなんら問題はありません。

DIAで合意すべきこと	機能安全に必要なプロセス	関連する規格条項
入力情報	製品開発プロセス。機能仕様書、安全目標、安全要求などの入力となる成果物規定	Part4、Part5、Part6
安全管理者の任命／計画立案	安全管理プロセス。安全管理者任命、安全計画の立案、テーラリング基準など作業開始時の作業や責任・権限に関する規定	Part2：6節
テーラリング結果	製品開発プロセス。安全要求、設計、テスト、安全分析などエンジニアリング関係の作業規定	Part4、Part5、Part6
やりとりする成果物	構成管理・文書管理プロセス。成果物の管理と配布など成果物や文書・記録などの版管理やリリースに関する規定	Part2：6.4.6、Part8：7節、10節
進捗状況の報告／アノマリの報告	安全管理プロセス。進捗管理、問題管理、エスカレーションなどのプロジェクト管理規定	Part2：5節、6節
変更発生時の対応	変更管理プロセス。影響分析、変更時の承認・報告	Part8：8節
機能安全監査の実施	機能安全監査。監査計画、実施要領、監査報告	Part2：6.4.8
機能安全アセスメントの実施	機能安全アセスメント。アセスメント範囲、役割分担（顧客・自社）	Part2：6.4.9、Part4：10節
生産時の対応	生産管理プロセス	Part7
表3　DIAから見た必要な機能安全プロセス

　表3の「関連する規格条項」の欄を見ていただくと分かりますが、この切り口はあくまでDIAから見ただけであり、これで全ての規格要求を満たした機能安全プロセスが実装されるわけではありません。しかしながら、主だったプロセスは、おおむね含まれていますので、これらのプロセスを骨格にして、残った部分を肉付けすればよいのではないかと思います。もし、機能安全プロセスのベースにできるようなプロセス資産が既に存在しているのであれば、それとの対応関係を見ながら、足りないプロセスや作業を明らかにするとよいと思います。

中小サプライヤにとっての機能安全アセスメント

　表3に示したプロセスの中で、中小サプライヤという立場で機能安全プロセスを考えると少々やっかいなのが、機能安全アセスメントでしょうか。機能安全アセスメントは、ISO 26262：Part2に出てくる表2の定義によれば、「アイテム」の機能安全を評価することになっています＊3）。アイテムの構成要素のみを担当する中小サプライヤが、アイテム全体に関わる機能安全についての合否を判定するとは考え難いので、規格要求をそのまま受け入れることは現実的ではないでしょう。通常、安全目標を達成するための安全方策は、アイテムレベルあるいは車載システム全体で考えることで、構成要素単独の視点で安全を評価するのには限界があります。

＊3）対象製品にASIL-CまたはASIL-Dが割り付けられた場合のみ。ASIL-Bの場合は推奨。

　中小サプライヤという立場で現実的にできることは、機能安全アセスメントへの要求全体を担うのではなく、全体の中の一部分のみを担うという考え方であろうと思います。システム全体としての機能安全は評価できないが、担当した製品が要求に従い正しいプロセスで開発されたことをしっかり評価するというアプローチです。例えば、自社の担当範囲内で実施される検証活動の結果や機能安全監査の結果を評価し、「安全要求が確実に展開されているか」、「テストが十分に行われているか」、「未解決の問題が残っていないか」といった項目について客観的な視点で評価するといったことです。客観的な視点での評価は、開発の当事者が思い込みに影響されて気付き難いことを発見する効果的な手段です。

　とはいえ、具体的なやり方や評価観点、対象範囲や評価の深さなどは契約相手方（顧客）との間で調整し、合意する必要があるでしょう。顧客が実施するケースもあります。いずれにしても、この検討には、前回も触れたように、自組織の事情も十分考慮して、少しでも効果の上がる活動を考えるべきでしょう。

補足：DIAについて

　今回は、膨大な規格要求事項から機能安全プロセスを実装するに当たって、DIAを起点に、その切り口から最低限必要なプロセス要素を絞り込むことについて解説しました。

　しかし、現実のビジネスを考えると、このDIA自体もどこまでの範囲で必要なのか分からないといった質問をいただくことがあります。例えば、日本の開発現場でよく見られる、製品開発を委託するのではなく、製品開発に必要な技術サービス（人的なサービス）を提供するケースはどうなるのかといった質問です。他社のソフトウェア技術者が自社に常駐して開発するようなケースのことです。

　DIAは、製品の分散開発を行う場合には、責任もそれぞれ分担しましょうという考え方ですから、成果物責任を負わないこうしたケースでは、DIAを結ぶのは難しいのではないかと思います。当然DIAを結ばないのであれば、責任は分担できない（責任は発注者が負う）ということになりますので、発注する側は相応の作業管理が必要になるでしょう。

---

　次回は、今回に引き続き、「プロセスの実装」について主なPartごとに実装上のポイントを解説してみようと思います。

執筆者プロフィール

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

http://www.dnv.jp/industry/automotive/

ノルウェー・オスロに本拠地を置く認証機関・DNVビジネス・アシュアランスの日本法人で、機能安全規格対応に向けたサービス業務に取り組んでいる。日本国内では、大手自動車メーカーや中堅サプライヤに対してのトレーニング、アセスメントで多くの実績を有している。

ISO26262−自動車向け機能安全規格−

ISO26262の解説記事と最新情報を集約した特集サイト

＞＞トップページはこちらから