（この記事はもともとForbes.comに掲載されたものです）

車両のライフサイクルの各段階は、それぞれ異なるソフトウェア上で動作します。開発チームはシミュレーションプラットフォームを使用し、テストチームはデータロガーと検証スイートを使用します。製造チームは専用システムで最終検査を実施し、アフターサービスチームはまた別の診断ツールセットを使用します。各チームは、それぞれの領域に最適なツールを個別に選択します。

問題は、各段階の内部ではなく、段階間や段階をまたぐ部分で何が起きるかという点にあります。従来の車両ライフサイクルをリレーレースに例えてみましょう。開発段階からテスト段階へ、テスト段階から生産段階へ、生産段階からサービス段階へとバトンが渡されます。バトンが渡されるたびに、知識を再構成したり、一から作り直したりしなければなりません。多くの場合、事態はそれ以上に深刻で、各段階のツール間で知識や知見が共有されることはありません。その結果、バトンが渡されるたびに増大する3つのコストが発生します：

  1. システム保守にかかるオーバーヘッドは、チェーンにツールが1つ追加されるごとに、ライセンスの取得、統合、パッチ適用、サポートが必要なシステムが1つ増えるため、倍増してしまう。
  2. 新入社員や部門横断チームは、関わる各段階ごとに異なるツールを習得しなければならないため、研修にかかる負担が増大している。
  3. 何よりも重要なのは、知識の連続性が断たれてしまうことです。エンジニアが機能を開発した際の背景情報は、6か月後に現場でそのトラブルシューティングを行う担当者には、そのままではうまく伝わらないのです。

これは、どのチーム単体の失敗でもありません。設計、開発、テスト、生産、サポートを、1つの連続したプロセスではなく、5つの別々のワークフローとして扱うことによる構造的なコストなのです。OEM企業にとって、そのコストは各段階で余分な時間が加わるという形で現れます。つまり、開発の遅延、テストの遅延、不具合調査の遅延に加え、作業の重複や、チーム間で引き継がれる際に失われる組織的知見といった問題が生じるのです。

かつて統一が非現実的だった理由

ソフトウェアの歴史の大部分において、これらのツールを統合することは現実的ではありませんでした。ソフトウェアは特定の目的のために作られています。テストツールは、定義された一連の条件下でシステムが期待どおりに動作することを検証するために設計されており、診断ツールは、問題が発生した際にその根本原因を特定するために作られています。一方のツールをもう一方の役割に流用するには、コードの大部分を書き直す必要があります。エンジニアがボタンの位置を変更したり、ワークフローを変更したりしたい場合、それには開発サイクルが必要となります。

AI この状況に変化の兆しが見え始めています。というのも、これらの段階にわたるエージェント型AI ソリューションは、ますます同じ基盤を共有するようになってきているからです。テストツールの基盤となっている大規模言語モデル（LLM）は、根本的には、現場の診断ツールの基盤となっているモデルと同じものです。リリース前の検証テストケースの分析であれ、販売後の顧客の問題のトラブルシューティングであれ、推論を行うAI は同じです。異なるのは、その周囲の文脈だけなのです。

組織は、ドメインごとに個別のシステムを構築するのではなく、開発、テスト、運用にわたり同じ基盤となるインテリジェンスを拡張することで、毎回ゼロから始めることなく、各チームの状況に合わせて適応させることができます。これが、Sonatus Fastlane™ Platform、 という、ライフサイクルの各段階間で車両データや知見を次へと引き継ぐクローズドループ型のAI プラットフォームの根底にある考え方です。これは、業界がこれまで持っていたものとは本質的に異なる出発点ですが、多くの組織がまだその実践の初期段階にあるのが現状です。

より大変な作業は組織的なものなのです

この兆候は業界全体で見られ始めており、たとえ現在、各組織がこれらの取り組みのうち1つか2つしか行っていない場合でも同様です：​

  • フィールドでの不具合を、車載のAI などを活用して、より直接的に無線アップデートサイクルに組み込み、Sonatus Fastlane™ Edge 、問題の発生から修正プログラムの展開に至るまでのプロセスを円滑に完結させるのに役立ちます。
  • サービスデスクの知見を、次期モデルの設計およびテスト基準に反映させること。こうした場面で、 Fastlane™ Insight のようなツールが、診断結果をエンジニアリングチームにとって実用的な知見へと変換できるのです
  • 製造現場の異常データを活用して、サプライヤー間の部品品質を比較する。
  • AI が提供する車両コンテキスト情報を活用し、開発段階の検証データを車両に引き継ぐことで、サービス開始初日の診断を迅速化できるかどうかを検討する。Sonatus Fastlane™ Collector。

これらの課題はいずれも、まだどこにおいても完全に解決されているわけではありませんが、ツールの引き継ぎのたびにリセットされるという状況がなくなれば、業界がどのような方向へ向かうのかを示唆しています。​

これは単にソフトウェアを乗り換えるだけの問題でもありません。ライフサイクルの各段階にわたってツールを統一するということは、通常、長年にわたり独立して運営されてきたチーム間で、責任の所在、予算、プロセスを統一することを意味します。これにより、技術的な課題と同様に、変更管理上の課題も生じます。これを単なるツールの選定問題として扱う組織は、組織面での対応の方がはるかに困難であることに気づくことになるでしょう。

統一戦略の構築

私の経験上、この種の組織変革には、いくつかの基本的な原則が当てはまる傾向があります：

  • 統合を全社的な戦略として採用する。データ、知識、およびAI の統合は、単一のチームが担当するプロジェクトではなく、経営陣からの指示として進められなければならない。
  • プロセスの各段階において、推進役を指名します。この取り組みには、開発、テスト、製造、サービスの各部門に、その推進役が配置されている必要があります。
  • 共有コンテキストに含めるべきものを特定します。 すべてのデータ、知識、成果物が各段階間でやり取りされる必要はありませんが 、適切なシグナルはやり取りされる必要があります。
  • まずは1つまたは2つのユースケースについて、AI ソリューションを導入してください。 一度に全面的に展開するのではなく、ライフサイクル全体を通じて双方向の知識の流れを具体的に活用できるユースケースを選んでください。
  • 初期の実装は出発点として捉えましょう。 そこから学び 、反復を重ね、発展させていきましょう。

なぜこれを先延ばしにしてはいけないのか

こうしたツールへの対応を求める圧力は高まりつつある。車両がますますソフトウェア主導型になり、イテレーションのペースが加速するにつれ、サイロ化されたツールのコストは増大している。段階ごとに専用のツールが1つ増えるごとに、組織の知見が閉じ込められるポイントが1つ増え、維持管理すべき統合ポイントが1つ増え、問題の発見から修正の実施までの間に遅延が生じるポイントも1つ増えることになる。

そのギャップを埋めるのは、すべての段階で同じツール――あるいは少なくとも同じ基盤となるインテリジェンス――を活用することです。設計、開発、テスト、本番運用、サポートを、5つの独立した機能ではなく、1つの連続したシステムとして扱うことに成功した企業は、構造的な競争優位性を獲得できるでしょう：​

  • ある段階での知見が次の段階に素早く伝わるため、問題を早期に発見できる。
  • データやコンテキストが引き継がれるため、実機テスト車両の台数や重複する検証作業を削減できます。
  • 現実世界の信号と実装されたソリューションとの間の距離を縮める。