プロジェクトスケジューリング：手順、手法、例

プロジェクトのスケジューリングとは何ですか？

プロジェクトスケジューリング は、各作業をいつ行うかを決めるプロジェクト計画の一部です。スコープを提供するのに必要なアクティビティを列挙し、論理的な順序でつなぎ、所要期間を見積もり、資源を割り当て、開始日と終了日を計算します。そのアウトプットである プロジェクトスケジュールは、チームが従う時刻表であり、進捗を測定する基準となるベースラインです。

2つの考え方を区別しておくと役立ちます。 スケジュールモデル は、ツール内に保持されるアクティビティ、依存関係、所要期間、カレンダーのネットワークです。 スケジュールの表示形式 は、そのモデルから作成するビューで、 ガントチャート、マイルストーン一覧、経営陣向けのプロジェクトタイムライン、ネットワーク図などがあります。「スケジュールを更新する」と言うときは、すべてのビューの整合性が保たれるよう、モデルを更新すべきです。

良いスケジュールは3つの役割を果たします：

• 確約（コミットメント）：ローンチ、引き渡し、本番稼働など、スポンサーや顧客が計画の拠り所にできる日付を示します。
• 調整：各人やサプライヤーに、いつ作業が必要で、それが何に依存しているかを伝えます。
• 早期警告：日付は論理から計算されるため、あるアクティビティが遅れると、まだ対処する時間があるうちに、その波及効果がすぐに表れます。

スケジューリングは、見積りや進捗のコントロールと並んで、プロジェクトのタイムマネジメントというより広い分野の一部であり、そのインプットをコストや資源の計画と共有しています。

PMBOKガイドにおけるプロジェクトスケジューリング

PMIの*PMBOKガイド*は、年月を経てスケジューリングをさまざまな形で説明してきており、試験や職務記述書では両方の見方に出会うことになります。

以前のプロセスベースの版では、スケジューリングを6つのプロセスにまとめていました。スケジュールマネジメントの計画、アクティビティの定義、アクティビティの順序設定、アクティビティ所要期間の見積り、スケジュールの作成、スケジュールのコントロールです。多くの組織や講座では、今でもこれらをスケジュールマネジメントの柱として教えています。

PMIが2025年11月に発行した*PMBOKガイド*第8版は、ガバナンス、スコープ、スケジュール、財務、ステークホルダー、資源、リスクの7つのパフォーマンス領域を中心に構成されています。スケジュールはその領域の1つであり、ガイドは再び、厳格に従うのではなくプロジェクトに合わせて調整する、規範的ではないプロセスを説明しています。また、ローリングウェーブ計画法、工数と所要期間の違い、予測型、適応型、ハイブリッド型のライフサイクルに合わせたアプローチの調整などの考え方も強調しています。

当サイトのおすすめは、従来の手順を漏れを防ぐチェックリストとして扱い、労力をプロジェクトに合わせて調整することです。2週間のマーケティングキャンペーンに必要なのは1ページのタスクリストですが、2年間の建設プログラムには完全なスケジュールマネジメント計画書が必要です。標準自体の概要については、当サイトのガイドをお読みください： PMBOKガイド.

プロジェクトスケジュールに含まれるもの

どのツールを使うにしても、完全なスケジュールには同じ構成要素があります。

アクティビティとタスクは同じ意味で使われることがよくあります。重要なのは、それぞれに担当者が1人いて、終わりが明確であることです。 プロジェクトのマイルストーン は、ほとんどのステークホルダーが実際に目を通す部分であるため、特に注意が必要です。

プロジェクトスケジュールの種類

1つのプロジェクトには通常、同じスケジュールについて、異なる対象読者に向けた複数のビューが必要です。

A 逆算スケジュール は、日付を動かせないイベントやマーケティングのローンチに役立ちます。期限から始めて各アクティビティを逆にたどり、それぞれの最遅開始日を求めます。作業が不確実すぎて全体を計画できない場合、多くのチームはプロジェクト全体のマイルストーンスケジュールと、直近数週間だけの詳細スケジュールを組み合わせています。

プロジェクトスケジュールの作り方（手順別）

以下の手順は、従来のスケジュールマネジメントの流れに沿っています。小規模なプロジェクトでは複数の手順を1回のワークショップで行えますが、大規模なプロジェクトでは各手順に数日かかることもあります。

1. スケジュールの管理方法について合意する

スケジューリングツール、単位（日または時間）、詳細さの程度、進捗の更新頻度、スケジュールを変更できる人、重大な差異とみなす基準を決めます。大規模なプロジェクトでは、これが次に含まれる短いスケジュールマネジメント計画書になります： プロジェクトマネジメント計画書.

2. スコープを分解する

承認済みのスコープから始め、次を使って成果物とワークパッケージに分解します： WBS（ワーク・ブレークダウン・ストラクチャー）。WBSにないものはスケジュールにも載らないため、この手順が作業の漏れを防ぎます。

3. アクティビティを定義する

各ワークパッケージを、1人または1チームが担当できるアクティビティに分解します。よく使われる目安は、アクティビティの長さを1日から2週間にすることです。それより長いと追跡が難しく、短いと管理の手間が過剰になりがちです。各アクティビティには「設計」ではなく「設計を承認する」のように、「動詞＋名詞」の明確な名前を付けます。

4. アクティビティの順序を設定する

各アクティビティを先行アクティビティと後続アクティビティにつなぎます。ほとんどのつながりは終了－開始ですが、開始－開始、終了－終了、まれに開始－終了も使えます。作業が重なる場合や待つ必要がある場合は、リードとラグを追加します。たとえば、コンクリートの養生のための3日間のラグなどです。当サイトの タスクの依存関係 のガイドで、各タイプを例とともに解説しています。

5. 所要期間を見積もる

各アクティビティにどれだけの作業が含まれるかだけでなく、どれだけの期間がかかるかを見積もります。 工数 は必要な人時であり、 所要期間 は経過する作業時間で、何人が取り組むか、各人が週のうちどれだけの時間を割けるかによって変わります。過去のデータがあれば活用し、作業を行う人に尋ね、不確実なアクティビティには三点見積りを使いましょう。類推見積り（類似の過去の作業との比較）やパラメトリック見積り（1日あたりのケーブル敷設メートル数など）も一般的です。

6. 資源とカレンダーを割り当てる

各アクティビティに、指名した人や役割、設備、サプライヤーを割り当て、休日、パートタイムのスタッフ、現場の休業期間に合わせてカレンダーを適用します。持ち時間を超えて予定が入っている人がいないか確認しましょう。各人の週あたりの割り当て時間を、会議、サポート業務、他のプロジェクトを差し引いた実際の持ち時間と比較します。

7. スケジュールを計算し、衝突を解消する

まず クリティカルパス法 を実行して、最早日と最遅日、フロート、クリティカルパスを計算します。次に問題を解消します。過負荷をなくすには 資源平準化 を使い、終了日が遅すぎる場合は、クラッシングやファストトラッキングによる スケジュール短縮 を検討します。

8. レビュー、承認、ベースライン化

作業を行う人々とスポンサーとともにスケジュールを確認します。論理が妥当か、クリティカルパスが信頼できるか、主要なリスクに予備があるかを確認します。承認されたら、後で差異を測定できるよう プロジェクトのベースライン として保存します。

その時点から、仕事はスケジュールのコントロールになります。進捗の更新、予測の見直し、変更の管理で、これについては以下で解説します。

実例：オフィス移転のスケジューリング

20人のチームが新しいオフィスに移転します。プロジェクトマネージャーは6つのアクティビティを、それぞれの所要期間（営業日）、先行アクティビティ、担当者とともに書き出します。

開始から終了までの経路は2つあります：

最も長い経路A-B-D-Fが クリティカルパスであり、移転には少なくとも14営業日が必要です。アクティビティCとEは短い経路上にあり、4日間の フロートを共有しています。つまり、合計4日までなら移転を遅らせずに遅延を吸収できます。最早日と最遅日の計算の全過程は、当サイトの次のガイドで段階的に示しています： フォワードパスとバックワードパス.

論理をカレンダーの日付に変換する

2026年11月2日（月）に作業を開始し、チームが月曜日から金曜日まで働く場合、計算される最早日は次のとおりです：

注目すべき点が2つあります。1つ目に、週末は稼働日を増やさずに暦日を増やすため、14日間のプロジェクトは11月15日ではなく11月19日に終わります。2つ目に、家具サプライヤーのリードタイムがクリティカルパス上にあるため、プロジェクトマネージャーはそれを書面で確認し、早めに催促すべきです。一方、フロートのある梱包作業は小さな遅れを吸収できます。

この例は当サイトの無料の プロジェクトスケジュールテンプレートで再現できます。また、クリティカルパスの計算は次で詳しく示しています： クリティカルパステンプレート.

プロジェクトスケジューリングの技法

ほとんどのスケジュールは複数の技法を組み合わせて使っています。下表は、それぞれがどのような場面で役立つかをまとめたものです。

クリティカルパス法

CPMは、ほぼすべてのスケジューリングツールの背後にある計算です。フォワードパスで各アクティビティの最早開始日と最早終了日を求め、バックワードパスでプロジェクトの終了日を守れる最遅日を求めます。その差がフロートであり、フロートがゼロのアクティビティの連なりがクリティカルパスです。どこに注意を集中すべきか、プロジェクトを早く終える必要がある場合にどのアクティビティを短縮すべきかがわかります。

PERTと三点見積り

所要期間が不確実な場合は、楽観値（O）、最頻値（M）、悲観値（P）の3つの見積りを求めます。PERTの加重平均は (O + 4M + P) ÷ 6 です。4日、6日、14日と見積もられたアクティビティの期待所要期間は (4 + 24 + 14) ÷ 6 = 7日で、最頻値より1日長くなります。これは物事がうまくいかないリスクを反映しています。

資源平準化と資源円滑化

資源平準化は、必要な人が空くまでアクティビティを遅らせるもので、終了日が延びることがあります。資源円滑化は、アクティビティをフロートの範囲内でのみ移動させるため、終了日は固定のままですが、一部の過負荷が残ることがあります。本当に人が過剰に割り当てられている場合は平準化を、期限を動かさずにピークをならしたい場合は円滑化を使いましょう。

クラッシングとファストトラッキング

クラッシングは、クリティカルなアクティビティに資源を追加して短縮するもので、通常はコストが増えます。ファストトラッキングは、順番に計画されていたアクティビティを並行して行うもので、リスクと手戻りが増えます。どちらもクリティカルパスに適用した場合にのみ効果があります。当サイトの ファストトラッキングとクラッシング の比較で、選び方を紹介しています。

アジャイルとハイブリッドのプロジェクトのスケジューリング

アジャイルチームもスケジュールを立てますが、そのレベルが異なります。プロジェクト全体のアクティビティの詳細なネットワークではなく、通常は次のものを使って作業します：

• タイムボックス：固定の長さのスプリントやイテレーション。日付は決まっており、その中のスコープが柔軟に変わります。
• リリース計画：チームの実測ベロシティに基づき、どの機能がどのリリース日までに準備できそうかを予測したもの。参考： アジャイルのリリース計画.
• スプリント計画：次のスプリントだけの詳細な計画で、次で作成します： スプリントプランニング.
• ガバナンスのためのマイルストーン：資金のゲート、規制上の日付、マーケティングのローンチなど、組織全体が計画の拠り所にする必要があるもの。

ハイブリッドのプロジェクトはよくあります。建設やインフラのプロジェクトでは、物理的な工事には予測型のクリティカルパススケジュールを使い、建物を制御するソフトウェアにはアジャイルなアプローチを使うことがあります。その場合は、スプリントのタスクをマスタースケジュールに無理に入れ込むのではなく、共通のマイルストーンで両者を結び付けましょう。そうすれば、1つの上位レベルのタイムラインで、施工フェーズと計画中のソフトウェアリリースの両方を示せます。

スケジュールのコントロール

スケジュールは現実を反映していてこそ役に立ちます。プロジェクトが始まったら：

1. 決まったリズムで進捗を更新する：通常は毎週です。進捗率だけでなく、実際の開始日と終了日、進行中のアクティビティの残りの所要期間を記録します。
2. 再計算し、予測を見直す。 ツールに日付を再計算させ、クリティカルパスが移動していないか確認します。準クリティカルパスは、わずかな遅れでクリティカルになることがあります。
3. 差異を測定する。 予測日をベースラインと比較します。アーンドバリューを使うチームは、次も追跡します： スケジュール差異 とスケジュール効率指数。また、Sカーブで計画と実績の進捗を時系列で示します。
4. 早めに手を打つ。 小さな遅れが積み重なる前に、フロートを活用したり、作業の順序を組み替えたり、クリティカルなアクティビティに資源を追加したり、スコープの変更に合意したりします。
5. 変更を正式に管理する。 ベースラインの変更は次を経て行い、 変更管理、差異の報告が意味を保ち、ステークホルダーがどの日付が承認済みかを把握できるようにします。

プロジェクトスケジューリングのツール

小規模なプロジェクトならスプレッドシートでスケジュールを立てられますが、依存関係が頻繁に変わったり、複数の人が計画を共有したりするようになったら、専用のソフトウェアが時間とミスを減らしてくれます。

ツールを比較する際は、終了－開始などの依存関係のタイプ、タスクが遅れたときの自動再スケジュール、クリティカルパスの強調表示、ベースライン、リソースやワークロードのビュー、ステークホルダーとの簡単な共有があるかを確認しましょう。

当サイトがレビューしているツールの中では、 Wrike が、複数のプロジェクトを同時に運営し、インタラクティブなガントチャート、依存関係、ワークロードビューを1か所で必要とするチームにとって有力な選択肢です。 Smartsheet は、スプレッドシート形式のレイアウトにガントチャートと依存関係の機能を組み合わせたいチームに適しています。より軽いニーズには、当サイトの次で選択肢を比較してください： プロジェクト管理ツールランキング 。または次のガイドをご覧ください： ガントチャートソフトウェア.

プロジェクトスケジューリングでよくある間違い

プロジェクトスケジューリングのチェックリスト

承認を求める前に、次の簡単なチェックを行いましょう：

• WBSのすべての成果物が、少なくとも1つのアクティビティでカバーされている。
• すべてのアクティビティに担当者、所要期間、論理的なつながりがある。
• カレンダーに休日、パートタイムのスタッフ、サプライヤーのリードタイムが含まれている。
• 過負荷の資源がない、または過負荷が理解され受け入れられている。
• クリティカルパスが信頼でき、作業を行う人々とレビュー済みである。
• 主要なマイルストーンが憲章や契約の約束と一致している。
• リスクに対する予備が含まれ、見えるようになっている。
• ベースラインが保存され、更新のリズムについて合意されている。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問