インテグレーション地獄からの脱却：構造問題と「インテグレーター人権宣言」：AUTOSARを使いこなす（41）（2/4 ページ）
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第41回は、AUTOSARにとどまらず「インテグレーション地獄」が繰り返される構造問題を分析するとともに、筆者が訴える「インテグレーター人権宣言」を通してインテグレーターの位置付けについて考察する。
建前の上での「インテグレーション」
自動車業界ではおなじみのAutomotive SPICEにも「インテグレーション」という言葉は登場します。
Automotive SPICEのVer. 4.0では、以下の2つのプロセスとして登場します。
- SYS.4 システムインテグレーションおよびインテグレーション検証（System Integration and Integration Verification）
- SWE.5 ソフトウェアコンポーネント検証およびインテグレーション検証（Software Component Verification and Integration Verification）
そこで示されている基本プラクティス（Base Practice）の内容を見てみましょう。
- インテグレーションの検証手段の仕様化（SYS.4.BP1／SWE.5.BP1＋SWE.5.BP2）
- 検証手段の選定（SYS.4.BP2／SWE.5.BP3）
- インテグレーション対象の要素のインテグレーションおよびインテグレーション検証の実施（SYS.4.BP3／SWE.5.BP4＋SWE.5.BP5）
- 一貫性の確保および双方向トレーサビリティーの確立（SYS.4.BP4／SWE.5.BP6）
- 結果の要約および伝達（SYS.4.BP5／SWE.5.BP7）
中心になるのは、「インテグレーション対象の要素のインテグレーションおよびインテグレーション検証の実施」であり、その部分の記述は以下の通りです。
- 仕様化されたインテグレーション対象の要素間のインタフェースおよび相互作用に従い、かつ定義された順序および前提条件に従って、インテグレーション対象全体が完全にインテグレーションされるまで要素をインテグレーションする。選定されたインテグレーションの検証手段を実施する。合否ステータスを含む検証結果および対応する検証測定データを記録する
さて、インテグレーションに関わっておいでの皆さん、「あれ？ こんなことしかやらないの？」と思いませんか。
そして、その「あれ？」という感覚を言語化すると、以下のような内容ではないでしょうか。
- 1）一般的なプロジェクトでの「インテグレーション段階の活動／作業」に含まれる、以下のような作業はどこに行ってしまったのでしょうか？※3）
- a）Configurableなソフトウェアの選定／採否決定 ※（Re）Use or Make判断 ※通常は、プロジェクト着手前（計画／企画段階）に実施
- b）インテグレーション活動の計画（活動フェーズ定義、活動概要策定、資源確保など）
- c）開発環境の構築／能力認定 ※ワークフローをインテグレートし、可能な限り自動化
- d）インテグレーションでの「つなぐ」方法／手順の検討 ※試行錯誤的になりやすい
- 初期化関数や周期関数などの、call位置／vector table登録位置の決定
- インタフェースの接続／合わせ込み（既存要素のI/F不整合の解消）
- 処理のスケジューリング、排他区間の実現方法の検討と設定
- HWリソースへのアクセスの割り当てなど
- e）インテグレーション対象の要素に対する受け入れ検証と手直し
- f）Configurableなソフトウェアのパラメータの設定、コード生成と検証 ※Classic Platform（CP）ではBSW／RTE（Runtime Environment）の、インタフェースの切り替えおよびふるまいの切り替えのためのパラメータが存在
- g）各種プロジェクト固有単体ソフトウェアコードの設計／実装 ※時にアーキ分割（例：boot、application、hook、callout、callback、indication、notificationの単体）
- h）ビルド対象を集め、ビルド（Build）
- i）インテグレーション目的／ゴール（Integration Goals）の特定（論証シナリオ構築） ※「インテグレーションでの検証内容／合格条件は何？」と後から悩む段階
- j）テスト（Test）の計画、仕様書作成、実施と結果の文書化
- 2）そもそも、「インテグレーションでの検証内容／合格条件とは何？」（インテグレーション目的／ゴール：Integration Goals）
その答えが、「インテグレーション」そのものを見ているだけで得られないのであれば、その周囲にあるものとの関係性も含めて、俯瞰的に観察するべきでしょう。
※3）網羅的なサブフェーズ名ではなく、あくまで代表的な活動の例とお考えください。
「インテグレーション」の周囲にあるものを含めて俯瞰する
その周囲にあるものとの関係性も含めて、俯瞰的に観察するとは言っても、ただ漫然と「周りにあるもの」を含めて眺めたところで、見えてくるものはないかもしれません。
ですから、「インテグレーションを完了する」という言葉を起点に、言い換えを試みました。
- 起点：（各種構成要素の）インテグレーションを完了する
- 調達／再利用したものと、新作したものの統合／結合／インテグレーション
- ECU HWや、他のSW構成要素との統合／結合／インテグレーション
- 上位システムへの、下位システム（Subsystem）のインテグレーション（車両へのECUの統合など）
- 言い換え：「インテグレーション対象のアーキ設計を、（各種構成要素を用いて）実現する」
- さらに言い換え: 「インテグレーション／アーキ設計対象の要件を、（各種構成要素を用いて）実現する」
では、おなじみの開発の流れを要約すると、こんなところでしょうか（図2）。
- プロセス構築や計画／筋道を立てる部分の領域
- 要件定義の領域
- アーキテクチャ設計の領域 ※要件の実現戦略の一形態で、実現シナリオを小分けにする
- 詳細設計／単体の実装と検証の領域 ※小分けにされたものを形にする
- いわゆる「インテグレーション」の領域 ※小分けにされ形になったものをくっつける
- インテグレーション（あるいは統合／結合）の領域 ※くっつける部分（あえて検証部分とは分けています）
- インテグレーション検証の領域 ※あえてくっつける部分とは分けています
- 妥当性確認の領域 ※今回は省略
- 変更対応の領域 ※再利用、手直し
上記の文脈に、「インテグレーション」で実際に何かを行う活動を照らし合わせてみると、以下のようなことが見えてきます（表1）。
Automotive SPICEでの「プロセス」と、実際にインテグレーションという活動フェーズで行われることの間には、大差がある
これは何も新しいことではありません。
しかし、意外とこのことに対する理解は得られていないようにも思います。※4）
もちろん、Automotive SPICEは「AUTOSARを用いた場合に固有の内容」には直接触れていませんが、これは、AUTOSARに限ったことではないことは、皆さんもすぐにご理解いただけることと思います。
※4）Automotive SPICEで示されているプロセスは、プロジェクト進行上の開発フェーズそのものではありません。 先日、一般社団法人である日本SPICEネットワーク 代表理事の萩原一彦氏とインテグレーション談議で盛り上がった時にも、このよくある誤解が話題になりました。Automotive SPICEの公開されているPDFだけを軽くご覧になっただけでは、気付きにくいかもしれません。違和感もおありでしょう。ちなみに私自身も、長らく「プロセスと活動フェーズは別」という解釈で本当によいのか、自信が持てずにいましたが、2016年の、Automotive SPICEのProvisional Assessor資格を得るための研修の中での、講師からの説明でようやく確信が持てたという次第です。今年（2026年）で、そこからもう10年が経過しましたが、よく考えると、Automotive SPICEとのなれそめ（2004年）から12年もモヤモヤ／違和感を抱えたままだった、ということに、自分自身でも驚きます。
Copyright © ITmedia, Inc. All Rights Reserved.