初めてスケジュールを引いたとき、担当者に「何日かかりますか？」と聞いて回り、その回答を並べたら完成——という作り方をしてしまうことがあります。これは手順として間違っていませんが、重大なものが抜けています。
「担当者の作業を並べただけ」のスケジュールは、作った翌週から崩れ始めることが多いです。
初めてのスケジュールが崩れやすい理由
担当者の作業見積もりは、通常「問題なく作業だけが進んだ場合の時間」です。その見積もりを順番に並べても、実際のプロジェクトにはそれ以外の時間がたくさんあります。
- レビューと修正の時間
- 顧客・上司の確認を待つ時間
- 想定外の問題が起きたときの手戻り
- 依存関係：Aさんの成果物が来ないとBさんが動けない
これらが入っていないスケジュールは、最初の遅れが出た時点で連鎖的に崩れます。
落とし穴1：作業だけ並べる
設計3日、開発5日、テスト2日——と作業を並べるだけでは、誰がどのタイミングで何をレビューするかが見えません。
作業の後には必ずレビューとフィードバック反映の時間を入れる習慣を持ちましょう。特に「顧客レビュー」が入る場合は、顧客が資料を確認して意見を返してくれるまでの時間も計画に含める必要があります。
落とし穴2：確認待ちを入れない
実際のプロジェクトでは「顧客の承認待ち」「上司のレビュー待ち」「外部ベンダーからの回答待ち」などで作業が止まることがよくあります。
これらの確認待ち時間をスケジュールに入れていないと、「担当者は終わっているのに、確認が来ない」という状態が生まれ、計画が実態と合わなくなります。
顧客確認が必要なフェーズには「提出後〇営業日以内に返答をいただく想定」という記載を入れ、スケジュールに反映させましょう。
落とし穴3：レビューと手戻りを入れない
設計書や成果物は、一度レビューを受ければ必ず修正が発生します。「完璧なものを最初から提出できる」という前提でスケジュールを組むのは現実的ではありません。
レビュー→修正→再レビューというサイクルを1フェーズに1〜2回は想定して、その時間を積んでおきましょう。特にプロジェクト初期の設計フェーズは手戻りが多い傾向があります。
落とし穴4：依存関係を見落とす
「A担当者の設計が完了したら、B担当者の開発が始められる」という依存関係が複数あるプロジェクトでは、ひとつの遅延が後続タスクを全て遅らせます。
スケジュールを作るとき、「このタスクは何が完了してから始められるか」を担当者ごとに確認しましょう。依存関係が整理されていると、遅延が発生したときに「どこを回復させれば全体に影響しないか」が見えやすくなります。
最初に作るスケジュールの確認観点
スケジュールを作ったら、以下の観点で見直してください。
- レビューと修正の時間は入っているか
- 顧客・上司の確認待ち時間は入っているか
- 手戻りを想定したバッファはあるか
- 依存関係が見えているか（Aが終わらないとBが始まらない箇所）
- 休日・祝日・担当者の休暇が考慮されているか
完璧なスケジュールを最初から作ることは難しいですが、この5点を確認するだけで「壊れにくいスケジュール」に近づきます。
まとめ
初めてスケジュールを引くときの落とし穴を4つ整理しました。
- 落とし穴1：作業だけ並べる（レビュー時間がない）
- 落とし穴2：確認待ちを入れない（承認・回答待ちがゼロ前提）
- 落とし穴3：手戻りを入れない（修正ゼロ前提）
- 落とし穴4：依存関係を見落とす（並列・直列の連鎖が見えない）
「作業見積もりを並べるだけ」から「実態に近いスケジュール」に変えるための第一歩として、この4つを意識してみてください。
チームから工数を確認するときの一言例
スケジュールを引くにはメンバーの見積もりが必要ですが、聞きにくい場合は以下のような確認の仕方が使いやすいです。
- 「A機能の実装、今の状況だと何日くらいかかりそうですか？レビュー・修正含めた目安でいいです」
- 「作業に入る前に確認したいのですが、前提として○○の仕様は確定しているという認識で大丈夫ですか？」
- 「先行する作業の完了を待ってから始める必要がある作業があれば教えてください」
「何日かかりますか？」の一言より、「何を含めた見積もりか」を伝えて聞くと、返ってくる数字がスケジュールに使いやすくなります。
スケジュール管理の実務スキルを学びたい方はこちらもどうぞ。