📊 Capability Levelとは何か（成熟度ではない）

~~NIP~~

🧭 はじめに

このページでは、A-SPICEにおける Capability Level（CL） とは何かを整理する。特に重要なのは、CLを 「成熟度」や「レベルの高さ」だと誤解しないこと である。 CLは「良し悪し」や「強さ」を測る尺度ではなく、プロセスがどの程度“制御可能な状態に置かれているか” を見るための軸である。

🏗️ 背景・前提：なぜCapability Levelという概念が必要なのか

自動車ソフトウェア開発は、以下の前提条件を強く持つ。

長期間にわたる開発・保守組織や担当者の入れ替わりが常態外部監査・説明責任が避けられない安全・品質・法規への間接的影響が大きい

この世界では、「優秀な人が頑張った」や「今回はうまくいった」は、再現性のある保証にならない。 A-SPICEはここに対して、人の能力ではなく、プロセスの状態 を評価対象として切り出した。

Capability Levelは成果の良し悪しを測る指標ではない。
再現可能なやり方として成立しているかを見るための物差しである。

🧩 A-SPICEにおけるCLの正体

Capability Levelは、各プロセスについて次の問いに答えるための構造である。

「このプロセスは、組織としてどこまで意図的にコントロールされているか？」

ここで重要なのは、「できているか」ではなく「制御されているか」 という視点である。

たまたまできた → 制御されていない個人の力量で成立 → 組織としては不安定状況に応じて説明・再現できる → 制御されている

CLは、この「制御の深さ」を段階的に切り分けた概念であり、 能力の高さや完成度を示すランク表ではない。

📉 成熟度モデルとの決定的な違い

CLはしばしば「成熟度モデル」と混同されるが、思想はかなり異なる。

観点一般的な成熟度モデル A-SPICEのCapability Level 評価対象組織全体プロセス単位含意高いほど良い高低に価値判断なし見ているもの成長段階制御・統制の状態ゴール感最上位を目指す必要十分を見極める

CLを「上げるもの」だと考え始めると、
本来不要な管理や形式化が増え、現場負荷だけが上がる。

A-SPICEは「CL5を目指せ」とは一切言っていない。 そのプロセスにとって、どのレベルの制御が妥当か を問うだけである。

🧠 「どれだけ管理・統制されているか」という視点

CLは、次のような問いに集約できる。

判断基準は説明できるか責任の所在は明確か状況が変わっても破綻しないか他のプロジェクトでも同様に回せるか

これらはすべて、成果物そのものではなく、プロセスの内側 を見ている。

CLを正しく理解すると、「なぜこの管理が必要なのか」が説明できるようになる。
結果として、形骸化したプロセス改善を避けやすくなる。

🚧 実務で起きがちな誤解

現場でよくあるズレは次の通り。

CL＝ドキュメント量だと思っている CL＝プロジェクトの格付けだと思っている CLが高い＝品質が高いと短絡する全プロセスで同じCLを求めようとする

Capability Levelを評価の点数として扱うと、
現場は防衛的になり、実態が見えなくなる。

CLは比較や序列のための道具ではない。 「今のやり方は、どこまで説明責任を果たせる状態か」 を確認するためのレンズである。

🧾 まとめ：このページで伝えたい一点

Capability Levelとは、成熟度でも格付けでもない。 プロセスが、組織としてどこまで意図的に制御されているかを見るための構造である。

この前提を外さないことが、次のページで扱う CL1 / CL2 / CL3 の違い を正しく理解するための土台になる。