手順が精緻で、失敗から素早く改訂できる開発手法でも、それだけで安定運用できる成熟した手法とは限らない。設計の網羅性と、実運用で再現性が確認された範囲を別々に評価する。

2つの評価軸

設計成熟度では、変更リスクに応じた工程分岐、役割と責任の境界、検証証跡、失敗時の扱い、フィードバックループ、重要規則の機械強制を見る。ここが高ければ、手法は問題を診断して改善できる構造を持つ。

実証成熟度では、各工程分岐の利用件数、レビュー前後の品質漏れ、手順逸脱率、レビュー巡回数、所要時間や生成コスト、検証の実施率、改訂後の再発率を見る。ここが低いなら、設計が良くても判定は「有望だが安定化途上」に留める。

判断上の注意

• 摩擦を多数発見して短期間で修正できた事実は、学習能力の証拠であって安定性の証拠ではない。直近の変更頻度が高い時期は、改善速度と同時に仕様の揺れも大きい。
• 品質漏れがゼロでも、対象工程の利用実績が少なければ安全性を裏づけない。検証失敗ゼロも、検証実施ゼロなら証拠にならない。
• 全体平均だけでなく、低リスク・中リスク・高リスクなど工程分岐ごとに母数を持つ。一つの重い工程だけの実績から、軽量経路の安全性や速度を推定しない。
• 改訂件数やルール数を成果指標にしない。利用者が守れたか、品質と時間が改善したかを成果にする。

運用方法

設計指標と実証指標を同じダッシュボードで混ぜず、前者を「能力」、後者を「確認済み範囲」として並記する。改訂前後はバージョンまたは期間のコホートで比較し、逸脱やレビュー指摘が減ったかを確認する。安定版と判断する条件は、各工程に十分な利用例があり、直近の改訂後に同型再発がなく、品質・時間・検証実施率が事前に決めた許容範囲へ収まることとする。

この分離により、精緻な文書を成熟と誤認することも、改善中の手法を未熟として一括否定することも避けられる。