🧱 A-SPICEのプロセスカテゴリ分解の思想
🧭 はじめに
このページでは、A-SPICEが採用している SYS / SWE / SUP / MAN / ORG というプロセスカテゴリ分解について、 「何が定義されているか」ではなく、なぜこの分け方になっているのか を説明する。
A-SPICEを学び始めた多くの人が最初に感じる違和感は、 「開発プロセスより、周辺プロセスの数が多い」 「品質規格なのに、技術そのものの話が少ない」 という点にある。
この違和感の正体こそが、A-SPICEの思想そのものである。
🌍 背景・前提
🚗 自動車ソフトウェア開発の現実
自動車ソフトウェアは、以下の前提条件の上に成り立っている。
- 長期供給（10年〜20年）
- 多社分業（OEM / Tier1 / Tier2 …）
- 人の入れ替わりが前提
- 法規・安全・品質規格との重畳
この世界では、 「優秀な個人が頑張る」 というモデルは成立しない。
短期間で完結するWebサービス開発とは、前提条件が根本的に異なる
🧩 A-SPICEの構造・思想
🏗️ プロセスを「役割」で分けている
A-SPICEのカテゴリ分解は、作業内容ではなく 役割と責務 に基づいている。
- SYS / SWE：何を作るか、どう作るか
- SUP：壊さずに回すための支え
- MAN：計画し、予測し、判断する
- ORG：プロジェクトを成立させる土台
ここで重要なのは、 品質は「開発プロセス単体」では作れない という前提が最初から置かれている点である。
🧠 「開発以外」が多い理由
品質問題の多くは、実装技術そのものよりも、
- 要求の伝達ミス
- 変更管理の破綻
- 判断遅延
- 責任の所在不明
といった 横断領域 で発生する。
実装が原因に見える不具合の多くは、実は上流や管理の問題である
A-SPICEは、この現実を前提に 「事故が起きやすい場所」にプロセスを割り当てている。
🛠️ 実務上の意味
📌 なぜ「SUPが多すぎる」と感じるのか
多くの現場では、SUP系プロセスが
- 雑務
- 形式作業
- QAの自己満足
として扱われがちである。
しかし実際には、SUPは 「人が変わっても、会社が変わっても、同じ判断ができる状態」を作るための装置 である。
SUPが機能している現場では、属人トラブルが起きにくい
🧱 プロセス分割の本質
A-SPICEのカテゴリ分解は、
- 部署分割でもなく
- 組織図の反映でもなく
- 規格の都合でもない
「失敗の再現性を潰すための構造設計」 である。
プロセスを「担当部署」で理解すると、A-SPICEは必ず形骸化する
🧾 まとめ
🎯 このページで伝えたい一点
A-SPICEのプロセスカテゴリ分解は、 「品質はどこで壊れるか」を知り尽くした結果の構造 である。
開発プロセスだけを見ている限り、 A-SPICEの本質は決して理解できない。
次のページでは、この分割構造の 境界 で何が起き、 なぜそこがアセスメントで重点的に見られるのかを扱う。