成熟度モデル

VDLCの導入度合いを4段階に分け、チームがいまどこにいて次に何をすべきかを見積もる基準だ。

成熟度は道具の使用有無ではなく、手順と資産の定着度合いで判定する。コーディングエージェントを毎日使っていても、チーム共用のルールと検証体系がなければ依然として低いレベルであり、逆に道具の使用頻度が低くても、意図文書と計画承認の関門が根づいていれば、そのチームはすでに次のレベルへ入っている。

4レベル表

レベル	名前	特徴	判別信号
1	探索(Exploring)	個人がバイブコーディングを実験中、プロセスなし	プロンプトがセッションごとに揮発、検証は「動けばOK」
2	実践(Practicing)	個人/少数がVDLCサイクルを回す	意図文書の作成が始まる、コンテキストファイルが存在、計画承認の関門を使用
3	資産化(Compounding)	チーム単位でコンテキスト資産を蓄積・再利用	チーム共用のルール/スキル/テンプレート、リスクベースの検証、還流の儀礼が定着
4	標準化(Systematizing)	組織標準が定着、指標で管理	リードタイム・手戻り率を測定、オンボーディングに資産を再利用

レベル別の詳細

L1 — 探索(Exploring)

特徴: 個人がコーディングエージェントで実験しているが、チーム次元のプロセスはない。プロンプトとその結果は各自のチャット画面の中にとどまる。

判別信号: セッションが終わると、そのセッションで合意した内容もともに消える。成果物を信じられるか判断する基準は「とりあえず実行して動けばOK」の水準だ。同じ質問をセッションごとに説明し直す。

次のレベルへ行く鍵: 成果物ではなく出発点を残す — コードを書く前に目的と成功基準を文書一枚で書いてみること。

L2 — 実践(Practicing)

特徴: 個人または少数が六つのステージサイクルを意識的に回す。意図文書を書き、エージェントの計画を検討したうえで実装を進める。

判別信号: 意図文書の作成が始まり、プロジェクトルールファイル(CLAUDE.mdなど)が存在する。計画承認の関門を使うが、この手順はまだ個人の習慣であってチームのルールではない。

次のレベルへ行く鍵: 個人のルールファイルと習慣をチーム共用の資産へ移す — 自分一人が参照していたCLAUDE.mdとチェックリストを、チーム全体が一緒に使い更新するものへ転換すること。

L3 — 資産化(Compounding)

特徴: チーム単位でコンテキスト資産が蓄積され再利用される。検証強度はリスクに応じて変わり、サイクルが終わるたびに学んだことを資産へ反映する還流の儀礼が定着している。

判別信号: チーム共用のルール・スキル・テンプレートが存在し、複数の人が同じものを参照する。リスク等級に応じて検証強度を分ける基準がある。定期的な還流(振り返り、チェックリスト更新)がチームの予定に入っている。

次のレベルへ行く鍵: 定性的に「良くなっている」という感覚を定量指標に変える — リードタイム、手戻り率といった測定指標を実際に測り始めること。

L4 — 標準化(Systematizing)

特徴: VDLCが特定チームの実践ではなく組織の既定値だ。指標で効果を管理し、新規プロジェクトとオンボーディングが既存資産の再利用を前提に始まる。

判別信号: サイクルリードタイム・手戻り率といった指標を定期的に測定し意思決定に使う。オンボーディングの過程で新規参加者が組織標準のコンテキスト資産を再利用する。

標準を維持する鍵: 指標が悪化する信号を放置しない — 標準化は到達した状態ではなく、測定指標で点検し続けながら維持する状態だ。

セルフ診断チェックリスト

六つの原則ごとに3問ずつ、計18問だ。各原則の中で設問は難易度順に配置した — 1番(Q1)はL2(実践)水準で、2番(Q2)はL3(資産化)水準で、3番(Q3)はL4(標準化)水準で自然に「はい」になる設問だ。後のレベル判定はこのQ1/Q2/Q3の系列ごとに別々に集計するので、答えるときに各設問が何番(Q1/Q2/Q3)かを一緒に表示しておくと採点が楽だ。すべて観察可能な事実を問うので、はい/いいえだけで答える。

原則1 — 意図がソースだ

• [ ] Q1. 機能作業を始める前に、目的と成功基準を文書一枚だけでも残す。
• [ ] Q2. チームが共有する意図文書の形式(6-pager、PR-FAQなど)があり、大半の作業に実際に使われる。
• [ ] Q3. 意図文書に書いた成功基準を事後に検討し、次の意図文書の品質基準として反映する。

原則2 — 人間は判断し、AIは実行する

• [ ] Q1. エージェントが提案した実装計画を、コード作成前に人が検討・承認したことがある。
• [ ] Q2. 計画承認の関門が個人の習慣ではなく、チームの文書化された手順として定着している。
• [ ] Q3. 何を作るか・いつデプロイするかについての判断権限と実行委任の範囲が組織次元で明文化され、オンボーディングで扱われる。

原則3 — 速度は検証が決める

• [ ] Q1. エージェントの成果物を、自動化されたテストや静的解析なしにマージすることがほとんどない。
• [ ] Q2. リスク水準に応じて検証強度(自動検証のみ vs 人間レビュー必須)を分ける基準がチームにある。
• [ ] Q3. 検証通過率(一発通過率)のような指標を定期的に測定し、検証体系の改善に使う。

原則4 — コンテキストは資産だ

• [ ] Q1. プロジェクトルールファイル(CLAUDE.mdなど)が存在し、実際に参照される。
• [ ] Q2. チーム共用のコンテキスト資産(スキル、wiki、規約)があり、複数の人が再利用する。
• [ ] Q3. コンテキスト資産の増加・再利用の状況を追跡し、新規プロジェクトが既存資産の再利用を基本に始まる。

原則5 — 小さく回し、頻繁に還流する

• [ ] Q1. 意図-実装-検証の一サイクルが、スプリント単位ではなく一日〜数日単位で回る。
• [ ] Q2. サイクルが終わるたびに学んだことをルール・チェックリスト・wikiへ移す還流の儀礼がチームの予定にある。
• [ ] Q3. 還流の結果が組織指標(リードタイム、手戻り率など)の改善につながるか追跡する。

原則6 — 理解が所有だ

• [ ] Q1. エージェントの成果物を承認する前に、計画や変更内容を自分の言葉で要約して確認する習慣がある。
• [ ] Q2. リスクが高い変更について、承認者が内容を説明できるか確認する手順(説明の問い返し、コードウォークスルーなど)がチームにある。
• [ ] Q3. 理解しないまま通り過ぎた点を還流で償還する学習活動が、組織標準の手順として明文化され、オンボーディングで扱われる。

レベル判定ルール (階層型マッピング)

18問の「はい」の数を単純合算しない。代わりにQ1/Q2/Q3の系列(各6問、原則ごとに一つずつ)を別々に集計し、上の段から順に条件を確認する。

確認順序	条件	条件充足時のレベル
1	Q3系列(3番の設問6個)のうち「はい」3個以上	L4 標準化(Systematizing)
2	(1が未充足の場合) Q2系列(2番の設問6個)のうち「はい」3個以上	L3 資産化(Compounding)
3	(1・2が未充足の場合) Q1系列(1番の設問6個)のうち「はい」3個以上	L2 実践(Practicing)
4	上の三条件すべてが未充足	L1 探索(Exploring)

上から順に確認し、最初に満たす条件のレベルを最終レベルとする(上位の条件を満たせば下位の条件は確認しない)。しきい値を6問中3個に取ったのは、スペックのレベル別判別信号がそれぞれ3個前後の項目(例: L2 = 意図文書・コンテキストファイル・計画承認の関門の3つ)で構成されているためだ — 系列ごとにその信号に対応する設問が一つずつ(6原則 × 1問 = 6問)あるので、そのうち半分(3個以上)が「はい」なら、当該レベルの信号が実際に発現していると見なす。

単純合算方式は、Q1/Q2/Q3が互いに異なる成熟度の信号を代表するという点を無視し、境界で誤判を生む。例えば、スペックのL2判別信号3つに正確に該当する設問だけが「はい」のチームは、合計が3なので合算式ではL1と誤判定されるが、系列型ルールではQ1系列3個以上を充足して正確にL2と判定される。同様に、L2の信号をすべて充足(Q1系列6個)したうえにL3判別信号3つまで備えたチームは、合算式では合計9でL2にとどまるが、系列型ルールではQ2系列3個以上を充足して正確にL3と判定される。

チェックリストは自己評価用であり、チーム全体が各自答えたうえで結果を突き合わせる方式を勧める。答えが大きく分かれる設問があれば、それ自体がチーム内に共有されていない手順があるという信号だ。診断結果に合った次の段階は導入ロードマップで確認する。