フェーズ分割

大規模なプロジェクトを一度にすべて作るのではなく、複数のフェーズ（段階）に分けて納品・公開していく進め方（Phasing / フェージング）。

初期フェーズで「MVP（Minimum Viable Product：実用最小限の機能・プロダクト）」をいち早く公開し、後続のフェーズで機能追加や改善を行っていく流れが代表的。Web リニューアルや新規サービス立ち上げで多用される。

最大の狙いは、「全部を最初に揃える」というリスクの高い手法をやめ、初期費用と開発期間を抑えつつ、実際のユーザー運用から得たデータ（学習）を次の段階に反映させることである。

MVP の概念と表裏一体であり、無茶な要望が出た際の「スコープ調整（それはフェーズ 2 に回しましょう、と抑える）」の強力な打ち手にもなる。

※各フェーズの移行前には必ず「学習レビュー」を挟み、GA4 等の運用データを見て次のスコープを確定させる。「要件はデータ次第で変わる」という前提を事前に関係者と握っておくことが鍵となる。

全てが確定していない「フル仕様」で最初から見積を取るのは非現実的である。

実務では、業者からは「フェーズ 1 の確定見積＋フェーズ 2 候補の概算見積」で取得する。契約・支払いもフェーズごとに区切り、コミットメントを段階化してリスクを分散する。

後続予算の未確保（最悪のパターン）：フェーズ 1 の予算だけ稟議を通し、後からフェーズ 2 の予算を申請して経営層に「また金がかかるのか」と却下され、フェーズ 1 の不完全な状態でプロジェクトが頓挫する。（※対策：必ず「全体の概算総額」で初期に稟議を通しておくこと）。
スケジュール分割との混同：単に納期を分けただけで、「運用データを見て要件を変える」という柔軟性がない。
燃え尽き症候群：フェーズ 1 の公開（リリース）だけで「完成した」と思い込み、燃え尽きて運用や改善に入らない。
見積の膨張：フェーズ 1 の見積だけを出して進行し、後続フェーズになった途端に業者のフル仕様見積が法外に膨張して身動きが取れなくなる。
契約の曖昧化：フェーズ間の契約継続を口頭ベースで済ませてしまい、延長分の契約書や瑕疵担保責任の範囲が不明確になりトラブル化する。
移行基準の欠如：フェーズ 2 へ移行するための基準（KPI 達成など）が曖昧で、なんとなく自然消滅する。

言葉をよく利用する人

大型リニューアルの見積を業者と詰める場面

Web担当者
一度に全機能だと予算がオーバーしてしまうので、フェーズ分割で組み直してもらえますか。まずMVPの範囲と、フェーズ2の候補という形で見積をいただきたいです。
業者ディレクター
承知しました。フェーズ1のMVPは主要6ページと問い合わせまで、フェーズ2の候補は採用ページと事例データベース、メルマガ機能あたりで。フェーズ2に進む判断のタイミングも提案に入れておきます。
Web担当者
助かります。フェーズ2の予算も後で揉めないよう、最初から見える形にしておきたいです。

フェーズ2に着手するか判断の基準が曖昧になった場面

プロデューサー
フェーズ1の公開から半年経つけど、フェーズ分割の2期目ってどうするんだっけ。
Web担当者
運用データを見て決めましょう。リード数がKPIを達成していれば採用ページを先に、未達ならまずフォーム改善を先に、という基準で意思決定マップに乗せます。それを経営会議に出して判断してもらいます。
プロデューサー
なんとなくで進めずに、基準で決められるのはいいね。