🧭 A-SPICEは何を保証し、何を保証しないのか
📝 はじめに
このページでは、A-SPICE（Automotive SPICE）が何を保証する規格で、何を意図的に保証しない規格なのかを整理する。 A-SPICEはしばしば「品質規格」「合格すれば安全になるもの」「通過点としての儀式」と誤解されるが、これらはいずれも本質から外れている。 ここではまずスコープを明確にし、その上でA-SPICEという枠組みが持つ思想を構造的に理解することを目的とする。
🎯 背景：A-SPICEはなぜ誤解されやすいのか
A-SPICEは自動車業界で事実上の共通言語となっている一方、その位置づけは分かりにくい。 理由は単純で、A-SPICEが直接評価している対象が「成果物」でも「技術力」でもないからである。
多くの現場では次のような期待が混在する。
- 「A-SPICEに通れば品質が良いはず」
- 「A-SPICE対応＝安全」
- 「点数が高い＝優秀な開発チーム」
しかし、これらはA-SPICEのスコープ外である。
A-SPICEを成果物の品質評価だと捉えると、以降のすべての理解がズレる。
🧱 A-SPICEが保証するもの：プロセスの成立性
A-SPICEが保証しようとしているのは、「プロセスが成立しているかどうか」 である。 より正確には、次の問いに対する答えを与える。
- その組織は、開発を再現可能な形で行っているか
- 個人に依存せず、説明可能な意思決定が行われているか
- 計画・実行・確認・是正が意図的に管理されているか
ここで重要なのは、「うまくいったか」ではなく「なぜそう判断したかを説明できるか」である。
A-SPICEは結果ではなく思考と構造を評価対象にしている。
🚫 A-SPICEが保証しないもの
一方で、A-SPICEは次のことを明確に保証しない。
❌ 成果物の品質
- バグが少ない
- 壊れにくい
- 性能が高い
これらは結果論であり、A-SPICEの直接評価対象ではない。
❌ 安全性・法規適合
- 機能安全
- セキュリティ
- 法規制への適合
これらは他規格（例：ISO 26262 等）が担う領域であり、A-SPICEはそれらを支える土台に過ぎない。
❌ 開発スピード
- 早く作れる
- コストが下がる
プロセスが整うことで副次的に改善することはあるが、速さそのものを目的にした規格ではない。
「A-SPICE対応すれば安全になる／速くなる」という説明は、規格の趣旨を誤って伝える危険がある。
🧠 なぜ成果物保証をしないのか
A-SPICEが成果物を保証しないのは、それを保証できないことを理解しているからである。
自動車ソフトウェア開発は以下の特徴を持つ。
- 複雑で巨大
- 長期にわたり人が入れ替わる
- サプライチェーンが多段構造
この世界で「良い成果物」を一度作れたことには、ほとんど意味がない。 再現できなければ事故は必ず起きる。
そのためA-SPICEは、成果物そのものではなく、 成果物が生まれるまでの判断と管理の構造を評価する。
「誰がやっても同じ判断に近づく」状態を作れることが、A-SPICEが目指すゴール。
🔍 実務で起きがちな誤解
📄 ドキュメントが多ければ良い？
違う。 ドキュメントは「証拠」であって「目的」ではない。
- 書いてあるが説明できない → 評価されない
- 説明できるが書いていない → 問題になる
重要なのは、なぜそれを決めたかが追えることである。
📊 点数が高ければ優秀？
違う。 Capability Levelは能力の序列ではなく、管理状態の違いを示している。
CLを成績表として扱うと、現場は必ず形骸化する。
📌 まとめ：このページで伝えたい一点
A-SPICEは、
良いものを作ったかを評価する規格ではない。 良いものを作り続けられる構造を持っているかを問う規格である。
何を保証し、何を保証しないのかを正しく理解しない限り、 A-SPICEは「重い儀式」にしかならない。
この前提を押さえた上で、次のページでは なぜ自動車ソフトウェアでは属人化が許されないのかを構造的に掘り下げていく。