6-1. フェーズ分割と完了基準

フェーズごとに「いつまでに何が完成しているか」と「完了の判断基準」を決める。完了基準がないフェーズは、終わりのない追加要求を生む。特にソフトウェア開発では「ほぼできている」状態が長く続きがちで、「あとちょっと」が積み重なって大幅な遅延を招く。各フェーズの出口（Exit Criteria）を明文化することが、スケジュール管理の最も重要な一歩だ。

ℹ️ フェーズ構成の例

Phase 0：憲章確定・技術選定・環境構築　→ 完了基準：全ステークホルダーの憲章承認
Phase 1：MVP（最小限の機能で動くもの）　→ 完了基準：定義したコア機能がすべて動作する
Phase 2：拡張機能　→ 完了基準：Phase 1の品質担保 + 拡張機能追加
Phase 3：運用・改善　→ 完了基準：KPIの達成

⚠️ 定義しないと…

「まだ終わっていない」「もう完成のはず」という認識のズレが生まれ続ける。完了基準がないと際限なく改善が求められ、次のフェーズに進めない。

フェーズ目標完了基準（例）リスク
Phase 0準備・合意形成全員が憲章を承認している合意が取れないまま開発に入り、後で根本的な方針変更が必要になる
Phase 1MVPコア機能が動作し、内部テストをパスしている「ほぼできている」状態が続き、リリースが遅れる
Phase 2拡張Phase 1 の品質を維持したまま拡張機能が追加されているPhase 1の品質が担保されないまま拡張が進み、技術的負債が積み上がる
Phase 3運用KPI 目標値に到達しているKPIが未定義のまま「完成した」とみなされ、成果が測定できない

フェーズの完了基準は「測定できる形」で書くことが重要だ。「品質が高い」ではなく「テストカバレッジ80%以上かつ重大バグ0件」のように定量化する。定性的な完了基準は解釈の幅が生まれ、「完了しているか否か」の判断が人によって変わってしまう。

6-2. 優先順位の決定基準

機能の優先度を何で判断するかの基準を定義する。基準がなければ「声の大きい人の意見」が優先されるようになる。プロジェクトが進むにつれて追加要求は必ず増える。その際に「なぜこれを先に作るのか」を説明できる共通の基準があれば、議論をスムーズに進められる。

判断軸内容スコアリング例
ユーザー影響度どれだけ多くのユーザーに影響するか全ユーザー=3点、一部=2点、少数=1点
開発コスト実装にかかる工数・難易度1週間以内=3点、1ヶ月以内=2点、1ヶ月超=1点
依存関係この機能がないと他の機能が作れないかブロッカー=+2点、依存なし=0点
リスク後回しにするとどんな問題が起きるか法的リスク・セキュリティは最優先フラグ

⚠️ 定義しないと…

声の大きい人の意見が優先されるようになり、本来重要な機能が後回しになる。「なぜこれを先に作るのか」の合理的な説明ができなくなる。

✅ シンプルな優先度スコアリング

ユーザー影響度（大/中/小）× 開発コスト（大/中/小）の2軸でマトリクスを作り、「影響大・コスト小」を最優先にするだけでも判断基準として機能する。

代表的な優先度フレームワークには MoSCoW法（Must / Should / Could / Won't）や ICE スコアリング（Impact × Confidence ÷ Effort）がある。どれを使うかよりも「チーム全員が同じ基準で優先度を語れる状態を作る」ことが目的だ。プロジェクト開始時にフレームワークを選定し、全員に共有しておくとよい。

また、「絶対に入れなければならない機能（Must）」と「あれば良い機能（Should/Could）」を分けておくと、スケジュールが圧迫されたときの意思決定が速くなる。リリース直前に「この機能は今回落とすか、延期するか」を判断する際の材料にもなる。

スケジュール計画でよくある失敗パターン

スケジュールは「最初の見積もり」が甘いだけで後工程全体が破綻する。代表的な失敗パターンを知っておくことで精度が上がる。

失敗パターン何が起きるか防止策
バッファを一切積まない「理想スケジュール」を作る最初のタスク遅延が全体に波及し、テストフェーズが丸ごと短縮される工数見積もりにバッファ（20〜30%）を明示的に積み、フェーズ間に予備日を設ける
依存関係を考慮せずにタスクを並べる前工程の完了を待たずに後工程が始まり、手戻りが発生するWBSでタスク間の依存関係（FS/SS）を明記し、クリティカルパスを把握する
マイルストーンの基準を曖昧にする「基本設計完了」の定義が人によって異なり、フェーズを抜け出せない状況が発生するマイルストーンごとに「何が揃ったら完了か」を成果物・承認者・期日でセットで定義する