🧱 プロセス間インタフェースが事故を起こす

~~NIP~~

🧭 はじめに

このページでは、A-SPICEにおいて プロセス間インタフェース がなぜこれほど重視されるのかを説明する。

品質問題や手戻り、責任不明確といったトラブルは、 個々のプロセス内部 ではなく、 プロセスとプロセスの「つなぎ目」 で発生することが圧倒的に多い。

A-SPICEがアセスメントで境界を重点的に見るのは、偶然でも形式でもない。

自動車ソフトウェア開発では、

要求を書く人設計する人実装する人テストする人

が必ずしも同一ではない。むしろ 違う人・違う組織であることが前提 である。

OEM / Tier1 / Tier2 にまたがる分業では、インタフェースがそのまま契約境界になる

このとき、問題が起きやすいのは「誰が悪いか」ではなく「誰の仕事でもない領域」である。

A-SPICE上では、

要求分析アーキテクチャ設計詳細設計実装テスト

は直列に並ぶ。しかし、責任や判断は 自然に引き継がれるわけではない。

「前工程が悪い」「後工程が確認しなかった」は、最も典型的な事故パターン

A-SPICEは、この断絶を前提に プロセス間に明示的なインタフェースを要求する。

A-SPICEにおけるインタフェースとは、

入力と出力受け渡し条件判断根拠レビュー観点

を含む 責務の接点 である。

単なる成果物の受け渡しではない。

「ドキュメントを渡した＝引き継いだ」ではない

事故が起きる典型的な瞬間は次のような場面である。

要求が曖昧だが、とりあえず設計に入る設計の前提が共有されないまま実装が進むテストで失敗が出るが、設計に戻れない変更理由が分からないまま修正が重なる

これらはすべて、 プロセス間で「説明責任」が消えた状態 である。

アセッサーの質問は、しばしば次のような形を取る。

「この要求は、どの判断でこうなったのですか」「設計への入力は何でしたか」「このテストケースは何を検証していますか」

これらは成果物の有無を聞いているのではない。 プロセス間の思考が接続されているか を見ている。

説明が自然につながる現場は、ドキュメント量が多くなくても評価が高い

よくある誤解として、

インタフェース対策＝帳票追加トレーサビリティ＝ツール導入レビュー＝チェックリスト消化

と考えてしまうケースがある。

形式を増やしても、思考が接続されなければ事故は減らない

A-SPICEが求めているのは、 「なぜそう判断したか」を後から説明できる状態 である。

プロセス間インタフェースは、 品質事故が最も起きやすい場所 であり、 A-SPICEはそこを最優先で守ろうとしている。

プロセス内部をどれだけ磨いても、境界が壊れていれば品質は成立しない。

A-SPICEが「横断構造」を重視する理由は、この一点に集約される。