　Automotive SPICEで示されているプロセスは、プロジェクト進行上の開発フェーズそのものではありませんが（故意か否かはさておき）、両者を同一視してしまうことによって、「インテグレーション活動／作業」を過小評価し、個人の努力に帰結させてしまうような発言につながるという構図があるのではないでしょうか（先の表1および図3）。

　インテグレーション以外の場面でも、例えば、完成車メーカーからECUの見積もり依頼（RFQ）が出てきたとき、実現の見通しも何もなく見積もりできるわけではありません。

　そこでは、完成度はともかく、ラフなレベルの要件定義やアーキ設計と、活動計画立案が行われているはずなのです（図4）。

図3　「開発フェーズ」と「活動内容」［クリックで拡大］

図4　「プロジェクトフェーズ」と「活動内容」［クリックで拡大］

　用語／ラベルによって、本来の姿がゆがめられた形で認知されてしまうことには注意が必要です。

　なお、インテグレーションという開発フェーズで、例えば以下のような「手直し／つじつま合わせ」を、インテグレーターが行うこともあるかと思います。

インタフェース不整合の解決（合わせ込み）
アーキテクチャ上、不足する要素の追加
インテグレーション対象に対する手直し

　ここで疑問が生じてきませんか？　ここで示した「手直し／つじつま合わせ」を、なぜインテグレーターが行わなければならないのでしょうか。

「インテグレーター」の位置付け、本当にそれでいいの？

　先に示した「手直し／つじつま合わせ」は、「アーキテクチャ設計」や「詳細設計／実装」という開発フェーズでの成果物に関わるものです。

インタフェース不整合の解決（合わせこみ）
アーキテクチャ上、不足する要素の追加
インテグレーション対象に対する手直し ※アーキ設計の不備で、詳細設計／実装されたものの不備に対する修正／変更が必要

　いずれも、両フェーズで不備があれば、発生してしまう可能性があるものです。

　それらの義務のやり残しに対して、後始末・つじつま合わせ・尻拭いを強いられるインテグレーターは、実は「影の要件エンジニア／アーキテクト（仕上げ役）」なのではないでしょうか。

　では、インテグレーションに先立つフェーズで解消できないのでしょうか。

　もちろん、100％完璧に仕上げられるわけではありません。

　でも、「どこまで仕上げようとするのか」という目標をどこに置くのかによって、インテグレーション段階の活動が「つらく泥臭い、つじつま合わせ／尻拭い的な作業だらけ」になるのか、「くっつけて、検証方法を考えて、検証を行うだけ」で済むのかが大きく左右されてしまうのです。果たして、本当にそれでいいのでしょうか。

　それだけではありません。前のフェーズでの「仕上げ」の程度によっては、以下のようなリスクへの対処が、インテグレーション段階に押し付けられる形になりかねないのです。

要件定義：要件自体の実現可能性リスク（そもそも、要件を実現するすべが存在しない、要求間の競合が解決されていない）
アーキテクチャ設計：アーキテクチャの実現可能性リスク（そのアーキテクチャ設計では要件を満たせない、要件達成阻害要因への対処が存在しない、そのアーキテクチャ設計で小分けにされた要素を実現／実装するすべが存在しない、小分けにしたことに起因して生じる各種制約が見落とされる）^※5）

　さらには、前のフェーズでのやり残しのような「リスク」が、インテグレーターに対して十分に伝達されているとは限りません。

　そもそも「要件実現のために必要なこと」（成功シナリオ）が特定されていないのであれば、実現可能性の説明は不可能なうえ、リスク伝達（リスクコミュニケーションの一部）もせいぜい「前のフェーズで気付いたものだけを伝える」という程度にとどまってしまいます。

　これでは、インテグレーターは「全てを疑ってかかる」という、到底不可能なことをやらなければならなくなってしまうでしょうし、「不可能なこと」を「期限内にやれ」と言われ、かつ、それが実現できないことを報告し相談したとしても「インテグレーターなんだから、自力で対処を」と突っぱねられたら、インテグレーターは実質的に孤立してしまいます。組織の一貫性に不可欠の、インテグレーターから組織への有益なフィードバックが得られなくなるような分断が生じるだけではなく、場合によっては不正も引き起こしてしまいかねません。これは、「合理的に予測可能な、構造起因リスク（reasonably foreseeable structural causal risk）」であるといえるでしょう。^※6）

　さらに、リスクというと、すぐに「プロジェクト失敗のリスクなんて当たり前」「確率の話でしょ？　まさか必ず失敗するわけじゃあるまいし」と返してくる人は大変多いと感じています。

　ただ、こんな構図は、そもそも「条件に合致してしまったら、失敗が運命付けられたもの」という決定論的リスクです。^※7）

　なお、前者（つらく泥臭い、つじつま合わせ／尻拭い的な作業だらけ）であった場合、「自分で手直し」したところを「自分で検証する」という構図になりかねないことも併せて指摘しておきます。

　この「自分の成果に対する検証」の証拠能力は、低いと考えるべきでしょう。ISO 26262-8:2018 clause 9.4.3.2でも、「異なる人物により実施されるべき」としています。^※8）

※5）小分けにしたことに起因して生じる各種制約の見落しは、上位要件とその実現アーキテクチャに対するアーキテクチャ分析なしには防げません。　特に「変化点管理しているから問題ない」という主張は要注意です。なぜなら、「小分けにしたことにより付加されるリスク」は、変化点自体ではなく、変化したものとそれ以外との関係にも現れるからです。だからこそ、上位要件定義とそれに基づく上位アーキテクチャ設計でのアーキテクチャ分析が必要なのです。異なる出自を持つ要素の統合（ボトムアップ型の統合）では、要素間に「出自の違い」（前提の違いなど）という競合要因が本質的に存在するのです。「従来は問題なく解決できたから、これからも大丈夫」という使い古された主張は、今や「愚者の主張の典型」というレッテルを貼られる対象です。加えて、ソフトウェア規模・複雑さの増大は、「変化点だけ見ておけば、あとはパッチで済むという時代」をいつか終わらせる、ということは強く申し上げます。なお、対象が何であれ、小分けにしたら生じる制約の類型など、すでに整理したものがございます。ご興味がある方はビジネスベースでご相談ください。

※6）その当事者が、不当に押し付けられた無理から逃れるために、本人が何も得をしない不正（手抜きなど）を行いかねない構図と言えないでしょうか？　その構図、つまり無理の不当な押しつけがなければそんな不正を働く必然性はない（＝決定論的に解決が可能である）にもかかわらず、その不正に手を染めるかどうかが、本人の倫理観などに委ねられる。果たしてそれはフェアでしょうか？　外野から「そんな無理の不当な押し付けに対しては、対抗できて当然」と言い放つことは簡単ですが、それを言われ抵抗／対抗を求められる側になったとしたら、皆さんどうですか？

※7）2026年7月4日に開催された長岡技術科学大学安全安心社会研究センターの特別講演会では、安全分野で多大な功績を残された同大学名誉教授の杉本旭氏との議論の機会をいただいたのですが、リスクという言葉に関して「いきなり確率で片付けようとするな」と繰り返しおっしゃっていたのが強く印象に残っています。私は、※6）でも書いた「いきなり倫理観で片付けようとするな」という言葉を、「確率論で～」の派生として位置付けたいと思います。

※8）例えば、自身では気付けない勘違いや違反（故意か否かによらない）に対する手当として、「他者の目」が必要になる場合があります（図5）。なお、自分で作ったものを全く検証せずに、検証担当に引き渡すべきだと言っているのではありませんので、誤解なさらぬようお願いいたします。