　チャブラ氏は冒頭、「ISO 26262に対応する方法としてはいろいろなアプローチがある。Automotive SPICE（以下、A-SPICE）もその1つである」と前置きし、事例を交えながらISO 26262とA-SPICEの統合的なアプローチについて紹介した。第三者認証機関であるDNVは、「ISO 26262とA-SPICEは共通点が多い」（チャブラ氏）ことを踏まえて、ISO 26262とA-SPICEの統合アプローチを提案している。

DNVビジネス・アシュアランス・ジャパンのランジー・チャブラ氏

　A-SPICEは、車載ソフトウェアの品質改善を目的に欧州の自動車メーカーが規定したプロセスモデルである。ソフトウェア開発プロセスを評価するためのフレームワークISO/IEC 15504など国際的な規格に適合しているが、A-SPICEそのものは規格ではない。ISO 26262に準拠した車載ソフトウェア開発プロセスを構築する上で、A-SPICEは有用だと言われているものの、必ずしも利用しなければいないわけではない。

　一方、ISO 26262は、一般産業機器向けの機能安全規格IEC 61508をベースに策定された国際規格である。IEC 61508だけでなく、品質マネジメントの規格ISO/TS 16949やISO/IEC 15504、そしてA-SPICEも参照している。ISO 26262とA-SPICEに共通点があり、ISO 26262への準拠にA-SPICEが有用なのはこのためだ。しかし、ISO 26262は、開発の企画段階から、生産、サービス、廃棄に至るまで、自動車の製品開発ライフサイクル全体をカバーするように、全10パートで構成されている。A-SPICEでISO 26262の全てを網羅できるわけではない。

　チャブラ氏は、「A-SPICEは、車載ソフトウェア開発プロセスについて、現在どこまでの能力レベルを有しているかを示す『レベルコンセプト』が設けられている。このため、活動成果を評価しやすい。一方、ISO 26262にはレベルコンセプトはなく、現在どういった段階まで規格への準拠を進められているのかが分かりにくい。『開始地点』や『終了地点』が分かりづらいのだ」と説明する。

　そこでDNVは、ISO 26262とA-SPICEを統合して実装するアプローチを提案している。このアプローチは「IMPROVE」と呼ばれている。「Identify（特定する）」、「exaMine（調査する）」、「Provide（提供する）」、「Resolve（解決する）」、「Observe（観察する）」、「Verify（検証する）」、「Evaluate（評価する）」という7つの英単語から名付けたものだ。またチャブラ氏は、このIMPROVEについて、ABC社という架空の企業に適用した事例を紹介した。ちなみに、このABC社は、1年前の2010年にA-SPICEのレベル2を取得した後、A-SPICEに基づくプロセス改善活動を1年間実施していなかったところに、顧客からISO 26262への準拠とA-SPICE対応が求められたという設定になっている。

ISO 26262とA-SPICEを統合して実装するDNVのアプローチ「IMPROVE」（クリックで拡大）出典：DNVビジネス・アシュアランス・ジャパン

　チャブラ氏は講演の中で、「ISO 26262に準拠するための活動を開始するに当たって、まず課題を明確にすることが重要だ」と語った。ここでいう課題とは、「どこから始めるか」、「どのように始めるか」、「どう改善するか」、「統合評価をどうするか」などである。また、「企業として目指す方向を明確にするための安全方針を作成し、経営陣からコミットメントを得ることが必要だ」とも述べた。そして、「ISO 26262のパートごとに成果物を明確にし、その進捗状況を常にチェックするのが効果的である。しかも、安全文化を確立するには改善活動の継続も重要になる」と締めくくった。

中間管理職が率先して動ける環境づくりが大切

ガイオ・テクノロジーの貝瀬康利氏

　続いて、ガイオ・テクノロジーのプロジェクトマネージャ/コンサルタントの貝瀬康利氏が「車載システム開発の最新動向と効果的なソフトプロセス改善の勘所」というテーマで講演した。

　貝瀬氏はまず、車載システム開発に押し寄せる新たな波として、3つの危険性を挙げた。「スマートフォンやタブレット端末を経由した攻撃」、「高機能化に伴う基本制御機能（走る、止まる、曲がる）への攻撃」、「オープン化による通信網を使った攻撃」である。これらの攻撃で、悪質なソフトウェアが外部から侵入し、「ブレーキ制御システム」や「タイヤ空気圧監視システム」などに不具合を発生させる可能性もありうるという。これらの問題を回避するためにも、セキュリティ対策の強化が一段と重要になると指摘した。貝瀬氏は、「課題が表面化してから対策するのでは遅い。継続的にプロセス改善を実施していくことが大切である」と話す。

車載システム開発に押し寄せる新たな波（クリックで拡大）出典：ガイオ・テクノロジー

　貝瀬氏によれば、プロセス改善の進め方として、大きく「課題ベース」と「モデルベース」の2種類のアプローチがあるという。今回の講演では、改善の効果が即体感できる課題ベースの品質改善について紹介した。ここで重要となるのが「トップダウンとボトムアップのバランス調整」という。貝瀬氏は、「改善活動に取り組む際、日本では現場の影響力が強いが、機能安全活動では経営層と目標を共有しておくことが大切だ」と強調する。プロセス改善の流れとしては、「アセスメント～活動開始」工程で目標などを明確にした後、「改善活動」、「改善提案」、「施策実施」などを行い、成果をフィードバックして改善活動を繰り返し実行していくことになる。

プロセス改善の流れ（クリックで拡大）出典：ガイオ・テクノロジー

　改善活動を始めるに当たり、まず行うべきこととして貝瀬氏が強調したのは「現状の課題整理」と「改善活動を推進していくための体制構築」である。講演では「品質改善」のケースを紹介した。まず、現状調査として「品質の見える化」を挙げた。工程ごとに「どの部分がどのように弱いか」、「どの部分にどのような欠陥が多いか」などを計測し、より具体的に「見える化」することである。しかも、「現場の細部を理解し、戦略やビジョンを描ける組織の中間管理職が率先して動くことが、改善活動を成功させるカギになる」（貝瀬氏）という。

　次のステップでは「原因分析」を行う。システムの不具合や事故の原因は、多様で複雑な要因が関係している場合が多い。貝瀬氏は、「その場合、レアなケースとして片付けるのではなく、『要因が複雑に絡み合うからこそ、事故やトラブルは起こる』ことを前提として、品質文化や安全文化への取り組みを行うべき」と説明する。また、根本原因を特定するやり方としては、「原因分析は責任追及ではなく、類似したトラブルの再発防止を最優先に掲げ、（根本原因に対して）効果的で歯止めがきく施策」（同氏）が重要になる。これまでのような「なぜなに解析」だけでは品質改善の目的を達成できないこともあるという。

　改善活動を推進するに当たってのポイントとして貝瀬氏は、「マネジメント層のコミットメントと、現場のモチベーションの両方が必要。どちらか片方だけでは活動が形骸化してしまう」と繰り返し述べた。そのためにも、「改善活動の推進には有能な中間管理職を採用し、その上で改善活動を推進していくための『ゆとり』を、中間管理職に与えることが必要である」（同氏）と重ねて強調している。