🛠️ SUPプロセスは雑務ではない
🧭 はじめに
このページでは、A-SPICEにおけるSUP（Support）プロセスが、なぜ「雑務」や「付随作業」ではなく、開発品質そのものを成立させる中核構造として位置づけられているのかを説明する。 多くの現場で軽視されがちなSUPが、なぜA-SPICEの中で独立したプロセス群として定義されているのか。その設計思想を理解することが目的である。
🏭 背景・前提
自動車ソフトウェア開発では、次の前提が常に存在する。
- 長期間にわたる開発・保守
- 人の入れ替わりが前提の組織構造
- 複数組織・複数拠点にまたがる分業
- 要求・設計・実装・テストが並行して進む現実
この環境では、「正しく作ったか」以前に、 「何を、いつ、誰が、どの状態で扱っていたのか」 が分からなくなること自体が、重大なリスクになる。
SUPは、この前提条件に対する構造的な回答である。
🧱 A-SPICEにおけるSUPの構造と思想
🔧 SUPは「作業を支援する」プロセスではない
SUP（構成管理、品質保証、問題解決など）は、しばしば以下のように誤解される。
- 書類を整える人たち
- ルールを押し付けるだけの部署
- 開発が終わった後にチェックする役割
しかしA-SPICEにおいてSUPは、 「開発活動が意味を持つ状態を維持するための前提条件」 を保証するプロセスである。
SUPは成果物の品質を直接上げるプロセスではないが、品質が成立する土台を作る役割を担っている。
🧩 構成管理が壊れると何が起きるか
構成管理（CM）はSUPの代表例だが、軽視された場合に起きる問題は極めて致命的である。
- 修正したはずのコードが別ブランチに存在しない
- テスト対象とリリース対象が一致しない
- 「どの要求に対する修正か」が追えない
これは単なる手続きミスではなく、 検証そのものが無意味になる 状態を生む。
構成管理が破綻した状態では、どれだけテストをしても、その結果が何を保証しているのか説明できない。
🔍 問題解決プロセスの本当の狙い
問題解決（SUP.9 など）は、 「不具合を修正するためのプロセス」ではない。
A-SPICEが見ているのは、 問題が組織として再発防止可能な形で扱われているか という点である。
- なぜ起きたのか
- なぜ防げなかったのか
- 次に同じ構造が現れたらどう検知するのか
ここが整理されていない組織では、 不具合は常に個人の頑張りで消され続ける。
問題解決を「是正処置の記録作成」と誤解すると、SUPは単なる帳尻合わせになる。
⚖️ 実務上の意味と誤解されやすい点
😖 なぜSUPは嫌われ役になりやすいのか
SUPは、開発速度を直接上げない。 むしろ「止める」「戻す」「確認する」役割を持つ。
そのため現場では、
- 開発の邪魔をする
- 手戻りを増やす
- 納期を遅らせる存在
と見られがちである。
しかしこれは、 「見えていないリスクを先に顕在化させている」 だけである。
SUPが機能している組織では、後工程での炎上が明確に減る。
🧠 A-SPICEがSUPを独立させている理由
A-SPICEがSUPを「開発プロセスの一部」とせず、 独立したカテゴリとして定義しているのは、
品質は個々の工程ではなく、工程をまたぐ構造で壊れる という前提に立っているからである。
SUPは、 「境界」「引き継ぎ」「時間差」 といった、事故が最も起きやすい場所を見ている。
🧾 まとめ（このページで伝えたい一点）
SUPプロセスは雑務ではない。 それは、
開発行為が意味を持ち続けるための前提条件を管理するプロセス である。
SUPを軽視している組織は、 「うまくいっている間は速いが、壊れた瞬間に立て直せない」。
A-SPICEがSUPを中核に据えている理由は、 品質とは結果ではなく、構造の性質だからである。