PM初心者が最初に身につけるべきスケジュール管理の基本

「スケジュール通りに進んだプロジェクトはほとんどない」という話を聞いたことがあるかもしれません。これは誇張ではなく、多くのPMが実感していることです。問題は、遅延が「頑張りが足りないから」ではなく、ほぼ必ず設計の段階のミスから来るという点です。

なぜプロジェクトは遅れるのか

よくある原因を並べると、タスクの抜け漏れ・依存関係の考慮不足・バッファなし・進捗の見えない化——この4つがほぼすべてのケースを説明できます。

遅延の原因	具体的な症状	根本対策
タスクの抜け漏れ	終盤に「これ誰がやるの？」が発生	WBSで全タスクを洗い出す
依存関係の無視	Aが終わらないとBが着手できないのに並列扱い	クリティカルパスを把握する
バッファなし	1つ遅れると全体が連鎖遅延	工程ごとに余裕日数を設ける
進捗の不可視化	問題が深刻化してから発覚する	週次で進捗を数値化して確認する

なかでも見落とされがちなのが「依存関係の無視」です。計画上は並行作業になっているが、実は片方が終わらないと着手できない——こういうタスクを見つけるために使うのがクリティカルパスの考え方です。

WBSとは：「何をするか」を全部書き出す作業

WBS（Work Breakdown Structure）という言葉は難しく聞こえますが、やることは単純です。プロジェクトで発生するすべての作業を書き出して、1〜3日で終わる粒度まで分解する。 それだけです。

3ステップで作る

ステップ1：成果物を起点にする

「何を作るか」からタスクを逆算します。「資料作成」ではなく「経営層向け要件定義書の作成」のように、成果物が具体的に見えるレベルまで落とし込みます。

ステップ2：1〜3日で完了できる粒度に分解する

「システム開発」のような大きな塊はそのままにしない。「ログイン機能の実装」「ログイン機能のテスト」「テスト結果の修正」のように分解することで、進捗が数値で見えるようになります。

ステップ3：依存関係を整理してクリティカルパスを把握する

例：クリティカルパスのイメージ

要件定義 → 設計 → 開発 → テスト → リリース
  ↑このどれか1つが遅れると、後続がすべて連鎖する

クリティカルパス上のタスクには特に注意を払います。逆に言えば、それ以外のタスクは多少前後しても全体への影響は限定的です。

ガントチャートは「作ること」が目的ではない

WBSが完成したら、ガントチャートに落とし込みます。ツールはExcelでもNotionでもJiraでも何でも構いません。ガントチャートで本当に見たいのは「各タスクの開始日・終了日」ではなく、「1つが遅れたとき、どこまで影響するか」の連鎖図です。

ガントチャートで確認すること	なぜ必要か
各タスクの開始日・終了日	誰が・いつまでに何をすべきかを全員が共有できる
並行作業の可否	リソースの二重割り当てを防げる
マイルストーン	「ここまでに終わらないと次に進めない」節目を可視化する
遅延の連鎖	1つ遅れたとき、どこまで影響するかをすぐ確認できる

AIを使ってWBSを作る

プロジェクト概要をChatGPTに渡すと、WBSの叩き台がすぐに完成します。ゼロから考えるよりも、AIが出した叩き台に「抜けているタスクはないか」と問い直す方が、漏れを防ぎやすいです。

プロンプト例

以下のプロジェクトのWBSを作成してください。
・フェーズごとにタスクを分解する（3〜4フェーズ）
・各タスクに目安工数（人日）と担当者欄（空白）を追加
・1タスクは1〜3人日の粒度にする
・依存関係があるタスクにはコメントを付ける

【プロジェクト概要】
新しい社内向け勤怠管理システムの導入（クラウドツール）
期間：2ヶ月 / チーム：PM1名・担当者2名・情報システム部（協力）

出力サンプル

フェーズ1：要件定義・選定（2週間）
├── 現状の勤怠管理フローのヒアリング   2人日  担当：    ※フェーズ1の起点
├── ツール候補のリストアップ・比較      1人日  担当：    ※ヒアリング完了後
├── 情報システム部とのセキュリティ確認  1人日  担当：
├── ツール選定・決裁申請               1人日  担当：    ※比較完了後
└── ベンダーとの契約手続き             2人日  担当：    ※決裁後

フェーズ2：設定・構築（3週間）
├── アカウント・権限設定               1人日  担当：    ※契約完了後
├── 勤怠ルールのシステム設定           3人日  担当：
├── 既存データの移行・変換             2人日  担当：
└── 動作テスト・修正                   2人日  担当：

フェーズ3：展開・教育（2週間）
├── 操作マニュアル作成                 2人日  担当：
├── 管理者向け説明会                   1人日  担当：
└── 全社員向けアナウンス・Q&A対応      1人日  担当：

フェーズ4：運用安定化（1週間）
├── 初月の利用状況確認・問い合わせ対応 2人日  担当：
└── 振り返り・課題整理                 1人日  担当：

遅延が発生したときの対処をAIで考える

スケジュールが遅れたとき、PMに求められるのは「どう挽回するか」の選択肢を素早く並べることです。冷静に考えたいが時間がない——そういう局面でAIは特に役に立ちます。

プロンプト例

以下の状況で、スケジュールを1週間短縮するための対策案を3〜5個挙げてください。
メリット・デメリットも一緒に記載してください。

【状況】
・プロジェクト残り3週間の時点で1週間の遅延が発生
・原因：テスト工程でバグが予想より多く発生
・チーム構成：PM1名・エンジニア2名・テスター1名
・リリース日はビジネス上変更不可

出力サンプル

【対策案1】テスターを1名追加アサインする
メリット：テスト工程を短縮できる。根本的な工数問題を解決
デメリット：コストが増加。新メンバーへの引き継ぎ工数が発生

【対策案2】バグの優先度を絞り、軽微なバグはリリース後対応とする
メリット：テスト対象を減らすことで期間内完了の可能性が高まる
デメリット：リリース後の品質リスクがある。ステークホルダーの合意が必要

【対策案3】エンジニアがテストを並行して担当する
メリット：追加コストなしで工数を確保できる
デメリット：開発と品質確認の兼務はミスが起きやすい。負荷増大

【対策案4】リリース範囲を絞り、一部機能を第2弾に回す
メリット：コアな機能に集中してリリース品質を確保できる
デメリット：ステークホルダーへの説明と合意形成が必要

【推奨】まず対策2・4でスコープを見直し、それでも足りなければ対策1を検討

スケジュール管理でPMがやるべき3つのこと

スケジュール管理の本質は「作って終わり」ではありません。毎週更新して、ずれを早期に発見し続けることです。

プロジェクト開始時にやることは、AIでWBSの叩き台を作り、メンバーと一緒に抜け漏れを確認すること。この時間を惜しむと、後半に「誰がやるの？」が必ず出てきます。

毎週やることは、実績と計画の比較です。1日でもずれがあれば、その場で原因を特定します。「今週はちょっと遅れたけど来週挽回できる」という判断を繰り返すと、挽回できないまま終盤を迎えます。

遅延が発生したときは、慌てずAIで挽回策の選択肢を出してから、ステークホルダーに早期報告します。「問題が発生しました、対策はこれです」と同時に伝えられると、信頼は下がりません。