14.07.2025
第5章：なぜソフトウェアの欠陥は後を絶たないのか
OEMのQA失敗の背後にある核心的な問題
何百万台ものリコール車、高額な集団訴訟、そしてますます大きくなる顧客からの苦情。
自動車メーカーもこの問題に目をつぶっているわけではない。ソフトウェアチームに投資し、他業界の著名な専門家を雇い、社内のQAプラットフォームを立ち上げている。しかし、その努力にもかかわらず、インフォテインメントのバグ、統合の問題、システムクラッシュが量産車に搭載され続けている。
その理由はいくつかある。
OEMが積極的でなく消極的なままである。
OEMの大半は、ソフトウェアの品質に関して、いまだに消火活動的な考え方で動いている。品質分析が始まるのは、多くの場合、製品がすでに問題を抱えた後である。最終テスト中、開発サイクルの最終段階、さらに悪いことに、顧客の手元で問題が表面化してからである。
この消極的なアプローチは、次のような事態を招く：
- 修正にコストとリスクがかかる、後期段階のバグ発見。
- 現場からの苦情をトリアージするために結成された、その場限りのタスクフォース。
- 断片的な検証で、長期的な安定性や稀な問題パターンに関する洞察が限定される。
最近のブログ記事で述べたように、代わりに必要なのはプロアクティブな品質戦略である。つまり、問題の発見を開発ライフサイクルの終盤だけでなく、全体を通して組み込むということだ。つまり、リアルタイムの挙動分析、AIによる欠陥検出、そして車両が路上を走る前の強固な統合テストを活用することだ。
残念ながら、ほとんどのOEMのQAチームは、このシフトに対応していない。彼らは、ウォーターフォール時代のプロセス、実世界をあまりにシミュレートしていないテストベンチ、テレマティクス、クラスタ、ADASから切り離されたサイロにインフォテインメント検証が置かれている組織構造に依存している。
100%の機能性は長期的な安定性を意味しない
OEMは、ソフトウェアの欠陥が表面化するまでに、数週間から数カ月の連続使用を要することを過小評価している場合があまりにも多い。従来の品質保証手法では、このような時間のかかる問題を発見することはできません：
- 自動化された機能テストは、機能がテスト中に一度だけ動作するかどうかをチェックするが、長期的にどのように動作するかについては何も語らない。
- 手作業によるテストは大規模なチームを必要とするが、テストウィンドウは通常、長期的な安定性の問題を明らかにするには短すぎる。また、人間が主導するプロセスであるため、重大な問題が抜け落ちる可能性もある。
- かつては機械的な耐久性をテストするために設計された路上走行試験が、現在ではソフトウェアのテストにも使用されている。しかし、このような試験は、隠れたソフトウェアの欠陥を捕捉するのに十分な期間実施されなかったり、エンジニアが問題を理解するのに役立つ十分なデータが収集されなかったりすることが多い。
これらの方法に共通する問題は何か？機能が動作しなくなった」「システムがクラッシュした」など、何かがうまくいかなかったことを示すことはあっても、その理由を示すことはほとんどない。インフォテインメントがクラッシュした」という曖昧なフィールドレポートでは、エンジニアが根本的な原因を突き止めることはおろか、解決することもできない。
「それはティア1の問題だ」というのは、危険なほど時代遅れの考え方だ。
私たちはいまだにこの言葉を頻繁に耳にする。これは、OEMがティア1サプライヤーからサブシステムをブラックボックスとして調達していた伝統的な開発モデルの名残である。
このようなモデルは、インフォ テインメントのような複雑でソフトウェア集約的な領域では単純に機能しない。OEMもティア1も、Android Automotive OSのようなシステムはまだ比較的新しく、どちらにも深い専門知識がない。
その結果OEMはしばしば厳格な品質要件を実施できず、Tier 1は堅牢なQAが期待されていなかったため、テスト不足のソフトウェアを提供することになる。書類上、ティア1は契約上の責任を負うことになるかもしれないが、現実の世界でインフォテインメント・システムが故障した場合、打撃を受けるのはOEMのブランドである。顧客は目に見えないサプライヤーを責めるのではなく、ハンドルに書かれた名前を責めるのだ。
自社製ツールではギャップを埋められない
多くのOEMは、効果的なQAシステムを自社で構築するための専門知識が不足している。
第4章で取り上げたGMのケースは、その顕著な例である。最先端のAIを駆使した社内品質プラットフォームがあると公言しているにもかかわらず、同社はインフォテインメントの不具合リストを長く、そして増え続けている。先進的な社内QAの約束と、未解決の現場問題の現実との間の断絶は、ツールがどんなに賢くても、それだけでは十分でないことを示唆している。
それはなぜか？
- ソフトウェアの品質は、一般的なエンジニアリングの問題ではなく、製品に特化した深い専門知識が要求される。
- 社内チームには、ベンダーが提供するコードと社内のコンポーネントを横断して根本原因を診断するのに必要な、部門横断的な可視性が欠けていることが多い。アンドロイドだけでも、OEMではなくグーグルが開発した非常に複雑なソフトウェアシステムであり、その内部構造に関する理解は限られている。
- インフォテインメント・システムの場合、実世界の複雑な挙動をモデル化するのは、その分野に特化した知識がなければ難しい。
OEMは第一に自動車会社であり、第二にソフトウェア会社である。ソフトウェアファーストの組織への転換を図る企業もあるが、世界クラスのQA機能をゼロから構築するのは何年もかかる道のりであり、顧客の期待は待ってはくれない。
要点
大規模な投資と意識の高まりにもかかわらず、インフォテインメント・ソフトウェアの問題は顧客に届き続けている。本章では、そのシステム的な理由を概説した：
- 品質保証が依然として消極的である。多くのOEMは、不具合がすでに現場に届いてから本格的なQAに着手しているため、パッチや高コストの修正が急がれる。
- 従来のテストは長期的な問題を見逃す。機能テストや手動テストでは、短期的なパフォーマンスしか検証しないことが多く、実際に使用される数週間にわたってシステムがどのように動作するかは検証されない。
- OEMとティア1の力学がずれている。インフォテインメント・システムは、深いコラボレーションと責任分担を必要とするが、ティア1の関係のほとんどは、まだ2005年のように動いている。
- ドメインの専門知識が不足している。OEMの社内QAツールは、Android Automotive OSのような複雑なインフォテインメント・システムに対応できないことが多い。
このような構造的な問題が解決されない限り、OEMは欠陥の見逃しや解決の遅れ、風評被害などに悩まされ続けることになる。
本シリーズの最終章では、 これまでに学んだ最も重要な教訓をまとめ、OEMがソフトウェア品質を今後の競争優位につなげる方法を探る。
このシリーズの他の記事: