準備の定義（DoR）

状況: 従業員200名のSaaS企業のモバイルアプリチーム。スプリント中に「仕様がわからない」で作業が止まるケースが月平均6回発生していた。

チームが合意したDoR:

1. ユーザーストーリーが「〇〇として、△△したい。なぜなら□□だから」の形式で書かれている
2. 受け入れ条件が3つ以上定義されている
3. UIデザイン（Figma）がレビュー済み
4. ストーリーポイントの見積もりが完了（チーム合意）
5. 外部API連携がある場合、API仕様が確定している

運用例: スプリントプランニングで「ユーザープロフィール編集機能」を検討。DoRをチェックしたところ、項目5のAPI仕様が未確定だったため、次スプリントに延期。代わりにDoRを満たしている別のアイテムを採用。

DoRを導入したことで「始められない」が激減し、スプリント完了率が68%から92%に改善。ベロシティも安定した。

状況: 従業員30名のWeb制作会社。クライアントからの要件が曖昧なままスプリントに入ることが多く、手戻りが全作業の25%を占めていた。

DoRの工夫:

• 通常のDoR項目に加え、「クライアント承認済みワイヤーフレームがある」を追加
• 受け入れ条件はクライアントとチームの双方で合意したものだけ有効
• DoR未達アイテムは「ステータス: 要確認」としてバックログに差し戻し

結果:

この取り組みが示すように、受託開発では「クライアント承認」をDoRに含めることで、手戻り率を25%から7%に削減でき、納期遵守率も大幅に改善した。

状況: 人口15万人の市役所の基幹システム刷新。ベンダー3社・庁内担当者12名の大規模プロジェクト。要件の認識ずれにより、3ヶ月で4回の仕様変更会議が発生していた。

DoRの設計:

1. 業務フロー図が現行・新規ともに作成済み
2. 関係部署の課長以上の承認が書面で取得済み
3. テストデータが準備されている
4. セキュリティ要件が情報政策課のレビューを通過済み
5. ベンダーの見積もり（工数・費用）が確定済み

運用: 月2回のリファインメントで次期開発対象をDoRチェック。「住民税計算ロジックの変更」はDoR項目2（関係部署承認）が未達のため、税務課長の承認を先に取得するアクションを設定。

行政プロジェクトでは「関係部署の書面承認」をDoRに組み込むことで、後からのひっくり返しを防ぎ、手戻り工数を**85%**削減できた。