SHINCHI, Takahiro
1. 計画通りに進まないのは当たり前
プロジェクトマネジメントの現場では、「計画通りに進めること」が重視されがちです。
しかし、実際のプロジェクトでは 計画通りに進むことのほうが珍しい というのが現実です。
✅ 要件の変化
✅ 外部環境の変化
✅ 予想外の技術的課題
✅ チームメンバーの異動や体調不良
こうした 「想定外」 はプロジェクトに付き物です。
計画をそのまま維持しようとすると、変化に対応できず、かえってプロジェクトの成功を遠ざけてしまうことになります。
2. 計画を「適応させる」ことがPMの仕事
PMの役割は 「計画を守ること」ではなく、「計画を適応させること」 です。
固定された計画に固執するのではなく、状況に応じて更新し続けることで、
プロジェクトをより良い方向へと導くことができます。
そのために必要なのは、「計画は変化するものだ」という前提を持つこと です。
3. 計画を柔軟に変更するための戦略
計画を柔軟に更新するためには、以下のような工夫が有効です。
1. スコープを細かく区切る
- 計画を「大きなゴール」ではなく「小さなマイルストーン」の集合として考える。
- 一度に全てを完了させようとせず、段階的に進めることで適応しやすくなる。
- 例えば、開発フェーズを「基盤構築」「主要機能開発」「追加機能開発」と分け、それぞれ完了後に状況を再評価したり、段階リリースを提案する。
2. MVP（Minimum Viable Product）を活用する
- 「まず動くものを作る」 ことで、早い段階でフィードバックを得られる。
- 計画を頻繁に見直しながら進めることで、無駄な作業を減らせる。
- ユーザーに価値を届けるまでの時間を短縮できるため、計画変更に対する抵抗も減る。
3. 計画変更を「失敗」と捉えない
- 計画を変えることは「失敗」ではなく、「適応すること」。
- 計画がズレたら、その都度更新するのが 正しいプロジェクトマネジメント である。
4. 具体例：計画を柔軟に更新して成功したケース
あるプロジェクトでは、管理機能を先に作る計画 で進めていました。
しかし、開発が進むにつれて、管理機能の工数がどんどん増大し、プロジェクトが停滞する状況になってしまいました。
そこで方針を転換し、まずMVPとしてフロント機能を優先的にリリースする ことに切り替えました。
結果として得られたメリット
✅ ユーザーに価値を届けるスピードが上がった
✅ 先にフロントをリリースすることで、実際の運用イメージが明確になった
✅ その結果、当初予定していた管理機能の大部分が不要だと判明し、工数を大幅に削減できた
このように、「計画通りに進めること」に固執せず、状況に応じて計画を更新することで、より良い結果を生み出すことができた のです。
5. 計画を柔軟に変えるためには「信頼関係」が不可欠
計画を変更することは、チームやステークホルダーとの信頼関係がなければ難しくなります。
なぜなら、計画変更が 「場当たり的なもの」 に見えると、不信感を生む可能性があるからです。
信頼を築くためのポイント
✅ 計画には常に「前提条件」を明示する
- 「〜という前提において、〜という計画で進めます」とすることで、前提が変化した際の計画変更をスムーズに説明できる。
- 例：「市場環境が変わらない前提でA案を採用。もし競合がBの施策を先に打った場合は、C案に切り替える。」
✅ 計画変更をオープンに共有する
- 計画を変える際、「なぜ変更するのか？」を関係者に明確に説明する。
- 変更の背景が理解されれば、受け入れやすくなる。
✅ プロジェクトのゴール（目的）を明確にする
- 「計画」は手段であり、ゴールではない。目的に対して最適な手段を選ぶ姿勢を示すことで、計画変更への納得感を高める。
このように、計画変更を適切に伝えることで、信頼関係を維持しながら柔軟なプロジェクト運営が可能になります。
6. まとめ
- 計画は変化するものだと前提にする
- PMの役割は「計画を守る」ことではなく、「計画を適応させる」こと
- スコープを細かく区切り、MVPを活用することで、計画の柔軟性を確保する
- 計画変更をスムーズに進めるために「前提条件」を明示し、ステークホルダーとの信頼関係を築く
計画を守ることに固執するのではなく、計画を常に更新しながら前進する ことを意識していきましょう。
7. 読者への問いかけ
- あなたのプロジェクトでは、計画をどれくらいの頻度で見直していますか？
- 計画を適応させるために、どんな工夫をしていますか？
- 固定された計画に固執して、うまくいかなかった経験はありますか？
ぜひ、あなたの考えをコメントで教えてください！