フレームワーク活用ガイドひとことで言うと#
プロジェクトの全タスクを洗い出し、依存関係・所要時間・リソースを考慮しながら時間軸上に最適配置する計画手法。「いつ・誰が・何をするか」を明確にし、プロジェクト全体の見通しを立てる基盤となる。
押さえておきたい用語#
- クリティカルパス（Critical Path）
- プロジェクト全体の最短完了期間を決定する最も長い経路上のタスク連鎖のこと。ここが遅れるとプロジェクト全体が遅れる。
- フロート（Float / Slack）
- タスクが遅延しても全体スケジュールに影響しない余裕時間のこと。フロートが0のタスクがクリティカルパス上にある。
- 依存関係（Dependency）
- タスク間の前後関係のこと。最も一般的なのは「終了→開始（FS: Finish to Start）」。
- 三点見積もり（Three-Point Estimation）
- 楽観値・悲観値・最頻値の3つで見積もり、PERT式で期待値を算出する手法を指す。（楽観 + 4×最頻 + 悲観）÷ 6。
- マイルストーン（Milestone）
- プロジェクトの重要な中間到達点である。進捗確認と意思決定のタイミングとして設定する。
プロジェクトスケジューリングの全体像#
こんな悩みに効く#
- プロジェクトの全体像が見えず、何から手をつけていいかわからない
- タスクの順序や並行作業の判断が属人的になっている
- スケジュールを作っても現実と乖離してすぐ破綻する
基本の使い方#
WBSなどを使い、プロジェクトの全作業を具体的なタスクに分解する。
- 成果物を起点に必要な作業を洗い出す
- 各タスクの所要時間を見積もる（楽観・悲観・最頻の3点見積もりが有効）
- タスクの粒度を揃える（1日〜2週間程度が管理しやすい）
ポイント: 粒度が粗すぎると進捗が見えず、細かすぎると管理コストが膨らむ。「進捗を確認できる最小単位」が目安。
タスク間の前後関係を明確にし、並行可能な作業を特定する。
- 「終了→開始（FS）」が最も一般的な依存タイプ
- 必須の依存と任意の依存を区別する
- 依存関係がないタスクは並行実行を検討する
ポイント: 依存関係を過剰に設定すると無駄な直列化が起き、期間が延びる。本当に必要な依存だけを定義する。
各タスクに担当者やチームを割り当て、負荷を平準化する。
- メンバーのスキルと稼働可能時間を確認する
- 特定の人にタスクが集中していないかチェック
- ボトルネックとなるリソースを先に確保する
ポイント: リソースの競合が発生した場合は、優先度の高いタスクを先に割り当て、残りを調整する。
ガントチャートなどで全体を可視化し、無理のない計画に調整する。
- クリティカルパスを特定して重点管理対象を明確にする
- バッファ（予備期間）を適切に配置する
- マイルストーンを設定し、進捗確認ポイントを作る
ポイント: スケジュールは「一度作ったら完成」ではない。定期的に見直し、実態に合わせて更新する。
具体例#
状況: エンジニア5名、デザイナー2名のチーム。新規Webサービスを12週間でローンチする計画。
タスク分解と依存関係:
| タスク | 所要時間 | 依存先 | 担当 |
|---|---|---|---|
| 要件定義 | 2週間 | なし | PM+全員 |
| UI設計 | 3週間 | 要件定義 | デザイナー2名 |
| バックエンド開発 | 6週間 | 要件定義 | エンジニア3名 |
| フロントエンド開発 | 5週間 | UI設計 | エンジニア2名 |
| テスト | 3週間 | 両開発完了 | 全員 |
| デプロイ準備 | 1週間 | テスト | エンジニア1名 |
クリティカルパス: 要件定義（2週）→バックエンド開発（6週）→テスト（3週）→デプロイ（1週）= 12週間
最適化: UI設計とバックエンド開発は並行可能（フロントエンドのフロート2週間）。テスト期間の前半でバックエンド単体テストを先行させ、全体を11週間に短縮。
クリティカルパスを明確にしたことで、「バックエンド開発が1週間遅れたらプロジェクト全体が1週間遅れる」という事実をチーム全員が認識し、重点管理ができた。
状況: 従業員80名の産業機器メーカー。3ヶ月後の業界最大の展示会に出展。マーケティング部3名＋営業部2名＋外部業者でプロジェクトを推進。
三点見積もりの活用:
| タスク | 楽観 | 最頻 | 悲観 | 期待値 |
|---|---|---|---|---|
| コンセプト策定 | 1週 | 2週 | 4週 | 2.2週 |
| ブースデザイン | 2週 | 3週 | 5週 | 3.2週 |
| 制作物の作成 | 3週 | 4週 | 7週 | 4.3週 |
| 機材・製品手配 | 1週 | 2週 | 3週 | 2.0週 |
| リハーサル | 0.5週 | 1週 | 2週 | 1.1週 |
リソース調整: ブースデザインと制作物作成を並行させたかったが、外部デザイナーが1名で兼務不可。デザイン完了後に制作に入る直列配置に変更。予算追加で外部デザイナー2名体制にし、並行化を実現。工期を2週間短縮。
この取り組みが示すように、三点見積もりを使ったことで「最悪ケース」を事前に想定でき、展示会2週間前にはすべての準備が完了。余裕のある状態で本番を迎えられた。
状況: 人口12万人の自治体。新庁舎への移転プロジェクト。移転日は議会で決定済み（変更不可）。12部署・職員350名の一斉移転を4日間で完了する必要がある。
並行作業の最大化: 12部署を4グループに分け、4日間で順次移転。各日のスケジュールを30分単位で計画。
| 日程 | 移転部署 | 重点管理事項 |
|---|---|---|
| 1日目（金） | 総務・企画・財政 | サーバー室の先行移転（前日夜間に完了） |
| 2日目（土） | 市民課・福祉・税務 | 窓口業務の継続性確保（臨時窓口を設置） |
| 3日目（日） | 建設・環境・教育・議会 | 重量物（金庫等）の搬入スケジュール |
| 4日目（月） | 予備日（遅延対応） | 残作業の完了とシステム最終確認 |
クリティカルパス: ネットワーク構築（新庁舎）→サーバー移設→基幹システム稼働確認→2日目の窓口業務開始。ここが遅れると市民サービスに直接影響。
バッファ設計: 4日目を予備日として確保。実際には3日目までに95%完了し、4日目は微調整のみ。
「移転日変更不可」という制約下で、30分単位のスケジュールとクリティカルパスの徹底管理により、市民サービスを1日も止めずに350名の移転を完了した。スケジューリングの精度がプロジェクトの成否を分けた好例。
やりがちな失敗パターン#
- 見積もりが楽観的すぎる — 「順調にいけば」を前提にしたスケジュールは必ず遅れる。パーキンソンの法則やバッファも考慮して、現実的な見積もりを行う
- 依存関係を曖昧にする — 「たぶん並行でいける」という曖昧な判断が手戻りを生む。依存関係は1つずつ根拠を明確にする
- リソースの稼働率を100%で計画する — 会議・割り込み・休暇を考慮しないと計画が破綻する。実効稼働率は60〜80%で見積もるのが現実的
- 一度作って更新しない — 状況が変わっているのにスケジュールを放置すると、実態との乖離が広がる。最低でも週次で見直す
まとめ#
プロジェクトスケジューリングは、タスクの分解・依存関係の定義・リソース配分・可視化の4ステップで「いつ・誰が・何をするか」を明確にする計画手法。クリティカルパス法やガントチャートと組み合わせることで精度が上がる。計画は一度作って終わりではなく、定期的な見直しと更新がプロジェクト成功の鍵となる。