自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善の話を聞いてきた。
自動車業界の裏話もたくさん聞けて、すごく有意義だった。

【参考】
【ハイブリッド開催】品質・効率・安全を同時に実現する統合開発プロセスの最新アプローチ （第75回 SEA関西プロセス分科会） | Peatix

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

図解カーエレクトロニクス 下 要素技術編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] エンジニアリングセット | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] 管理支援 | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

ISO26262 2nd実践ガイドブック［エンジニアリングセット］ | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

詳解 車載ネットワーク -CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために- | 藤澤行雄, 品川雅臣, 高島 光, 村上 倫, 石本裕介 |本 | 通販 | Amazon

システムズエンジニアリングに基づく製品開発の実践的アプローチ | 後町智子, 土屋浩幸, 鈴木　研 |本 | 通販 | Amazon

【1】聞いた講演のストーリーはこんな感じ。
自動車業界では、従来のISO9001系列の規格だけでなく、A-SPICE・機能安全・サイバーセキュリティの規格が次々に導入された。
本来のハード設計、組み込みソフトウェア開発だけでなく、その開発プロセスがこれらの規格に準拠していることが求められる。
そのために、監査のドキュメントが多くて開発現場の負荷が高く疲労している問題が出ている。

そこで、A-SPICE・機能安全・サイバーセキュリティの規格で定義されるプロセス領域や各プロセスを整理統合したプロセスを作ることで、1つの監査資料で複数のアセスメントに対応できるようにしたり、整理統合したプロセスの順番に実施すれば、複数のアセスメントのレビューをスムーズに進められるように対応した、という流れ。

【2】僕としては、それぞれの規格に対する考え方を聞いて面白かった。

まず、A-SPICEは元々、CMMIから派生したSPICEというプロセスモデルがあり、これを自動車業界向けに特化したAutomotive-SPICEが作られた。
元々、CMMIの目的は組織の成熟度を上げるために成熟度モデルに従ってプロセス改善しましょう、という考え方だった。
しかし、A-SPICEはPJごとのアセスメントに行うために、他のPJではA-SPICEが当てはまらないケースが多くなる。
すると、A-SPICEに準拠しないPJにアサインされたメンバーはプロセス改善する目的も意欲もないので、目的が失われてしまい、組織のソフトウェア開発能力が上がらないという結果に陥りがち。
つまり、A-SPICEという規格を通すだけに頑張る、という環境に陥りがち。

そもそも、A-SPICEは欧州の自動車メーカー、特にOEMメーカーが生み出した規格であり、A-SPICEはサプライヤに対する品質要求を定めて、サプライヤのふるい落としに使う。
部品メーカー、つまりサプライヤはプロセス改善に躍起になっているのが実情らしい。

聞いた話では、たとえば、OEMメーカーは、試作車の段階で4社のサプライヤから同じ部品を採用し、各段階でサプライヤを3社、2社と1社ずつふるい落とし、最後の量産工程で初めて1社に決定する。
つまり、サプライヤは試作段階では投資フェーズであり、量産工程で初めて投資を回収するわけだ。

サプライヤはA-SPICEに準拠するように対応するわけだが、A-SPICEを満たさない部品を納入した場合、サプライヤは罰金を支払う契約になるらしい。
つまり、サプライヤは納入して代金をもらうはずなのに、逆に罰金まで支払ってでも、量産工程に採用されるために対応し続ける時もあるらしい。
それぐらい、OEMメーカーに部品を採用されるのは利益があることなのだろう。
そんなA-SPICE規格の内情を聞くと、かなりしんどいプロセスだなと思う。

【3】機能安全の規格は原子力発電所やプラント工場が対象らしく、民生品向けでは自動車が初めてらしい。
機能安全のよくある例は、踏切だ。
たとえば、踏切を安全に動作させるために、バーを付けたり、センサーを付けたり、音を鳴らしたり、点灯させたりする。
そういう機能を付加して、安全を保証するわけだ。

また、危険な状態になったら、安全な状態へ移す機能をつける場合もある。
いわゆるフェイルセーフ。

さらに、試作工程の設計だけでなく、量産工程でも機能安全を検討する。
たとえば、故障率も調べて、許容率よりも超えて故障したら、設計工程から機能安全を考えて作り直す必要も出てくる。
つまり、故障や誤操作を想定しながら、設計工程で機能安全の設計を考える必要があるわけだ。

機能安全の規格もかなり複雑かつ膨大な印象。
機能安全という品質特性は、全ての機能に横断的に関わるだろうから、特有の設計手法が必要だろうと思う。

【4】車載サイバーセキュリティの規格も機能安全と並ぶ、安全性確保のもう一つの柱。

車載サイバーセキュリティの規格が生まれたきっかけとしては、ジープクライシス（Jeep Hack/Crisis）があったらしい。
具体的には、2015年頃の米国で、2人のセキュリティ研究者が走行中のジープを遠隔でハッキングし、運転席のドライバーが操作できない状態で速度を落としたり、ブレーキを無効化したりできることをデモで証明したらしい。
つまり、コネクテッドカーに対するサイバー攻撃の脆弱性が実証・公表されたわけだ。
これにより、ジープの所有者から訴訟が起き、リコールや損害賠償に発展したらしい。
そこで、自動車メーカーは躍起になって規格を作って対応しようとしているわけだ。

【5】では、これらの規格に自動車メーカーはどのように対応しているのか？

基本は、ECUごとに、A-SPICE、機能安全、サイバーセキュリティの規格を当てはめる。
一般に、自動車のECUは100個近くあるらしいので、100個のA-SPICE、機能安全、サイバーセキュリティのドキュメントを全部作っている。
つまり、ECUごとに監査用ドキュメントが異なり、それぞれのアセスメントの観点も違うので、ECU100個　ｘ　3規格＝300個の書類を作る必要がある。
開発者の観点では、同一のECUというハードとソフトに対し、似たような、しかし違う観点の監査用ドキュメントを作らないといけない。
実際の現場を見ると、ハードにソフトを組み込んだ開発とテストだけで精一杯なので、後付けで監査ドキュメントを作っているようだった。
つまり、プロセス改善の目的や動機もなく、ただアセスメントを通すために資料作成している感じだった。

【6】最後の質問では、プロセス改善のコンサルの拠り所、肝は何か？という質問があった。
回答は2つあった。

1つ目は、現場の開発プロセスと規格のマッチング。
サプライヤの現場にはそもそも、開発プロセスという概念がなく、定義された工程がない場合がある。
すると、A-SPICEに応じたソフトウェア開発やハードウェア開発、ハードとソフトを統合した開発プロセスを最初から導入して、現場で初めて実践する必要がある。
あるいは、サプライヤに独自の開発プロセスがあったとしても、A-SPICEに合わせたハード・ソフトの開発プロセスに定義し直す必要がある。
どちらにせよ、規格に対応するだけで精一杯ではないかと想像する。

2つ目は、規格を現場に浸透させること。
アセスメントを依頼する人は管理者、企画部門になるが、監査ドキュメントを作るのは現場のソフト開発者やハード設計者になる。
現場の人には、規格に準拠する動機やインセンティブがない。
現場の人に、いかに、規格に即することが重要なのか、を浸透させる事が大事なわけだ。
しかし、A-SPICEはプロジェクト単位、ECU単位になるので、別PJになれば俺は関係ない、という立場になりやすい。

そういう葛藤を聞いて面白いなと思った。