プロジェクトマネージャをしていると、こんな状況に遭遇することがあります。

プロジェクトでは、限られた期間の中で多くの作業を完了させなければなりません。

そのためには、いつ、誰が、何をするのかを整理し、計画と実績を比較しながら適切にコントロールする必要があります。

このような活動を体系的に行うのがスケジュールマネジメントです。

一言でいうと

スケジュールマネジメントとは、プロジェクトの作業をいつ実施するのかを計画し、スケジュールを管理・コントロールすることです。

単純に「ガントチャートを作ること」だけがスケジュールマネジメントではありません。

プロジェクトで必要な作業を明確にし、作業同士の関係を整理し、期間を見積もり、スケジュールを作成します。

そして、プロジェクトが始まった後は、実際の進捗を確認し、遅れが発生した場合には対応を検討します。

つまり、

計画する → 実行する → 進捗を確認する → 必要に応じて対応する

という活動を継続的に行うことがスケジュールマネジメントです。

スケジュールマネジメントの目的

スケジュールマネジメントの目的は、単純に「納期を守る」ことだけではありません。

プロジェクトの作業を適切な順序とタイミングで進め、プロジェクトの目標を達成できるようにすることが重要です。

具体的には、次のような目的があります。

• プロジェクトの完了時期を明確にする
• 必要な作業を整理する
• 作業の順序や依存関係を明確にする
• 作業に必要な期間を見積もる
• 遅延を早期に発見する
• 遅延がプロジェクト全体に与える影響を把握する
• 必要な対策を検討する

スケジュールマネジメントの基本的な流れ

スケジュールを管理するためには、いきなりガントチャートを作るのではなく、まずプロジェクトに必要な作業を整理します。

基本的には次のような流れで考えると分かりやすいでしょう。

1. スケジュールマネジメントを計画する
2. アクティビティを定義する
3. アクティビティの順序を決める
4. アクティビティの期間を見積もる
5. スケジュールを作成する
6. スケジュールをコントロールする

1．スケジュールマネジメントを計画する

まず、プロジェクトでどのようにスケジュールを作成・管理するのかを決めます。

例えば、

• どのツールを使うのか
• どの程度の粒度でスケジュールを作るのか
• 進捗をどのように測定するのか
• 誰がスケジュールを更新するのか
• どの程度の遅延で報告するのか

などを決めます。

プロジェクトによって必要な管理レベルは異なるため、プロジェクトの規模や特性に合わせてスケジュール管理の方法を決めることが重要です。

2．アクティビティを定義する

次に、プロジェクトで実施する作業を具体化します。

例えば、「システムを開発する」という作業だけでは、スケジュールを管理するには大きすぎます。

そこで、

• 要件定義
• 基本設計
• 詳細設計
• プログラム開発
• 単体テスト
• 結合テスト
• システムテスト

などに分解します。

このように、スケジュールを作成するための具体的な作業をアクティビティとして整理します。

3．アクティビティの順序を決める

作業を整理したら、それぞれの作業をどの順番で実施するのかを決めます。

プロジェクトの作業には、順番が決まっているものがあります。

例えば、設計が完了しなければ開発を始められない場合、

設計 → 開発

という関係になります。

このような作業同士の関係を依存関係として整理します。

アクティビティの依存関係

スケジュールを考えるうえで、アクティビティ同士の依存関係は非常に重要です。

代表的な関係として、次のようなものがあります。

終了・開始（FS）

先行する作業が終了した後に、次の作業を開始する関係です。

例えば、

設計完了 → 開発開始

という関係です。

一般的なプロジェクトで最もよく利用される関係です。

開始・開始（SS）

先行する作業が開始した後に、次の作業を開始する関係です。

例えば、設計作業が始まった後、一定の条件を満たせば開発作業も開始できるようなケースです。

終了・終了（FF）

先行する作業が終了するまで、次の作業も終了できない関係です。

開始・終了（SF）

先行する作業が開始することによって、次の作業を終了できる関係です。

実務ではFSが最も一般的ですが、プロジェクトの状況に応じてさまざまな依存関係を利用します。

4．アクティビティの期間を見積もる

作業の順序を整理したら、それぞれの作業にどのくらいの期間が必要なのかを見積もります。

例えば、

• 要件定義：10日
• 基本設計：15日
• 詳細設計：20日
• 開発：30日

といった形です。

ただし、作業期間を適当に決めてはいけません。

過去の実績や担当者の経験、作業量、利用可能なリソースなどを考慮して見積もる必要があります。

5．スケジュールを作成する

作業、依存関係、期間などが整理できたら、プロジェクト全体のスケジュールを作成します。

代表的な方法がガントチャートです。

ガントチャートを使うことで、

• いつ作業を開始するのか
• いつ作業が終了するのか
• どの作業が並行しているのか
• プロジェクト全体の期間はどのくらいか

などを視覚的に確認できます。

6．スケジュールをコントロールする

プロジェクトが開始したら、計画したスケジュールと実際の進捗を比較します。

例えば、

「予定では50％完了しているはずなのに、実際には30％しか終わっていない」

という状況であれば、遅延が発生しています。

このとき重要なのは、単純に「遅れている」と判断することではありません。

なぜ遅れているのか、プロジェクト全体への影響はどの程度なのか、どのように対応するのかを考える必要があります。

クリティカルパスとは？

スケジュールマネジメントで重要な用語の一つがクリティカルパスです。

クリティカルパスとは、簡単に言えば、プロジェクトの完了日を決める重要な作業の経路です。

クリティカルパス上の作業が遅れると、プロジェクト全体の完了日も遅れる可能性があります。

そのため、プロジェクトマネージャは、すべての作業を同じように見るのではなく、プロジェクトの完了日に大きな影響を与える作業を重点的に管理することが重要です。

フロートとは？

スケジュールマネジメントでは、フロートという考え方も重要です。

フロートとは、作業の開始や終了を遅らせることができる余裕時間のことです。

例えば、ある作業が1日程度遅れてもプロジェクト全体の完了日に影響しないのであれば、その作業には一定の余裕があります。

一方、余裕がほとんどない作業が遅れると、プロジェクト全体に影響する可能性があります。

そのため、スケジュールを見るときには、単純に「遅れている作業」だけではなく、「余裕がどのくらい残っているか」を見ることも重要です。

スケジュール遅延が発生したらどうする？

プロジェクトでは、スケジュール遅延を完全になくすことは難しいでしょう。

重要なのは、遅延が発生したときに適切に対応することです。

原因を確認する

まず、なぜ遅れているのかを確認します。

例えば、

• 作業量の見積もりが甘かった
• 必要な人員が確保できなかった
• 技術的な問題が発生した
• 要求変更が発生した
• 前工程が遅れた
• 品質問題による手戻りが発生した

など、原因はさまざまです。

プロジェクト全体への影響を確認する

ある作業が遅れているからといって、必ずしもプロジェクト全体が遅れるとは限りません。

フロートが十分に残っていれば、プロジェクトの完了日への影響がない場合もあります。

そのため、個別の作業の遅れとプロジェクト全体の遅れを分けて考えることが重要です。

対応策を検討する

プロジェクト全体への影響が大きい場合には、対応策を検討します。

例えば、

• 作業の優先順位を変更する
• リソースを追加する
• 作業を並行して進める
• 作業方法を変更する
• スコープを見直す
• ステークホルダーと納期を再調整する

などがあります。

重要なのは、「とにかく人を増やす」というような単純な対応をしないことです。

原因やプロジェクト全体への影響を確認したうえで、最適な対応を選択します。

スケジュール短縮の代表的な方法

クラッシング

クラッシングとは、追加のリソースを投入することで、スケジュールを短縮する方法です。

例えば、開発者を追加して作業を早く終わらせる方法などがあります。

ただし、人員を追加すれば必ず短縮できるとは限りません。

追加コストが発生するほか、コミュニケーションコストが増えて逆に効率が落ちる可能性もあります。

ファストトラッキング

ファストトラッキングとは、本来順番に実施する作業を一部並行して進めることで、スケジュールを短縮する方法です。

例えば、完全に設計が終了してから開発を始めるのではなく、設計が完了した部分から開発を始めるような方法です。

ただし、作業を並行して進めることで、手戻りやリスクが増える可能性があります。

スケジュールマネジメントでよくある失敗

最初に作ったスケジュールを絶対視する

プロジェクト開始時に作ったスケジュールが、その後も必ず正しいとは限りません。

要求変更やリスク、実績などによって状況は変化します。

そのため、スケジュールは現実の状況を反映しながら適切に更新する必要があります。

作業の遅れだけを見る

「この作業が3日遅れています」という情報だけでは、プロジェクトマネージャとして十分な判断はできません。

重要なのは、

「その3日の遅れがプロジェクト全体にどのような影響を与えるのか？」

です。

スケジュールを細かくしすぎる

細かいスケジュールを作れば、必ず管理しやすくなるわけではありません。

細かくしすぎると更新作業そのものが負担になり、重要な遅延を見落とす可能性もあります。

プロジェクトの規模や特性に応じて、適切な粒度にすることが重要です。

スケジュールマネジメントとリスクマネジメント

スケジュールとリスクは密接に関係しています。

例えば、「主要メンバーが体調不良などで離脱する」というリスクがある場合、その結果としてスケジュールが遅れる可能性があります。

また、技術的な問題や要求変更などもスケジュールに影響する可能性があります。

そのため、スケジュールを作るだけではなく、スケジュールに影響を与えるリスクを事前に把握することが重要です。

スケジュールマネジメントと変更管理

プロジェクトでは、途中で要求やスコープが変更されることがあります。

変更を受け入れる場合、スケジュールへの影響を確認する必要があります。

例えば、新しい機能を追加すれば、開発やテストに必要な期間が増えるかもしれません。

そのため、変更要求を受けたときには、

• スケジュールへの影響
• コストへの影響
• 品質への影響
• リソースへの影響
• リスクへの影響

などを総合的に評価することが重要です。

プロジェクトマネージャにとってのスケジュールマネジメント

プロジェクトマネージャにとって、スケジュールマネジメントは単にガントチャートを更新する仕事ではありません。

重要なのは、スケジュールを通してプロジェクトの状態を把握し、必要な意思決定を行うことです。

例えば、ある作業が遅れていたとしても、クリティカルパス上でなければ、すぐに大きな問題になるとは限りません。

一方で、まだ遅延していなくても、クリティカルパス上の作業で余裕がなくなっているのであれば、早めに対応する必要があります。

つまり、優れたスケジュールマネジメントでは、

「今、何日遅れているか」

だけではなく、

「このまま進むと、プロジェクトはどうなるのか？」

を見ることが重要です。

プロジェクトマネージャ試験ではここが重要

スケジュールマネジメントでは、次の用語を整理しておくとよいでしょう。

• アクティビティ
• 依存関係
• ガントチャート
• クリティカルパス
• フロート
• クラッシング
• ファストトラッキング
• スケジュール遅延
• スケジュール・ベースライン

特に、「作業が遅れていること」と「プロジェクト全体が遅れること」は同じではないという点は重要です。

クリティカルパスやフロートを考慮し、プロジェクトの完了日にどのような影響があるのかを判断することが重要になります。

PM道場のワンポイント

スケジュールマネジメントで大切なのは、「遅れをゼロにすること」ではなく、「遅れの影響をコントロールすること」です。

プロジェクトを進めていると、予定より遅れる作業は必ずと言っていいほど出てきます。

そのたびに「遅れている！大変だ！」と騒いでいては、プロジェクトマネージャとして適切な判断はできません。

まず確認するべきなのは、

「その遅れは、プロジェクト全体に影響するのか？」

です。

フロートが残っているなら、その遅れは吸収できるかもしれません。

逆に、クリティカルパス上の作業であれば、数日の遅れでもプロジェクトの完了日に影響する可能性があります。

さらに、今は問題がなくても、フロートを使い切ってしまえば、次の遅延を吸収できなくなるかもしれません。

だからこそ、スケジュールを見るときには、単純な「予定対実績」だけではなく、プロジェクト全体のつながりを見ることが重要です。

そして、遅延が発生したときには、クラッシングやファストトラッキング、スコープの見直しなど、さまざまな選択肢の中からプロジェクトに合った対応を選びます。

スケジュールは「守るもの」であると同時に、プロジェクトの未来を予測するための道具でもあります。

この視点を持つと、スケジュールマネジメントが単なる進捗管理ではなく、プロジェクトマネージャの重要な意思決定ツールであることが分かります。

関連用語

• スケジュール・ベースライン
• アクティビティ
• ガントチャート
• クリティカルパス
• フロート
• WBS
• 見積もり
• リスクマネジメント
• 変更管理
• コストマネジメント
• EVM
• 進捗管理

まとめ

スケジュールマネジメントとは、プロジェクトの作業を計画し、スケジュールを作成・管理・コントロールすることです。

基本的には、

1. スケジュールマネジメントを計画する
2. アクティビティを定義する
3. アクティビティの順序を決める
4. 期間を見積もる
5. スケジュールを作成する
6. スケジュールをコントロールする

という流れで進めます。

また、クリティカルパスやフロートを理解することで、プロジェクトの完了日に影響する作業を重点的に管理できるようになります。

スケジュールが遅れた場合も、単純に「遅れているから問題」と考えるのではなく、その遅れがプロジェクト全体にどのような影響を与えるのかを確認することが重要です。

スケジュールマネジメントは、ガントチャートを作って終わりではありません。

計画と実績を比較し、将来のプロジェクトの状態を予測し、必要な意思決定を行う活動です。

プロジェクトマネージャにとって、スケジュールは単なる予定表ではなく、プロジェクトを成功に導くための重要な管理ツールだと考えておきましょう。

関連記事

• WBSとは？
• ガントチャートとは？
• クリティカルパスとは？
• スケジュールベースラインとは？
• フロートとは？
• 見積もりとは？
• リスクマネジメントとは？
• 変更管理とは？
• コストマネジメントとは？
• EVMとは？
• 進捗管理とは？

よくある質問（FAQ）

Q. スケジュールマネジメントとは何ですか？

A. プロジェクトで実施する作業の順序や期間を計画し、スケジュールを作成・管理・コントロールする活動です。

Q. スケジュールマネジメントと進捗管理の違いは何ですか？

A. スケジュールマネジメントは、作業の計画からスケジュールの作成、コントロールまでを含む広い活動です。進捗管理は、その中でも計画と実績を比較し、現在の進み具合を把握する活動として考えると分かりやすいでしょう。

Q. クリティカルパスとは何ですか？

A. プロジェクトの完了日を決める重要な作業の経路です。クリティカルパス上の作業が遅れると、プロジェクト全体の完了日が遅れる可能性があります。

Q. フロートとは何ですか？

A. 作業の開始や終了を遅らせることができる余裕時間です。フロートが少ない作業ほど、遅延によるプロジェクト全体への影響に注意する必要があります。

Q. スケジュールが遅れたらどうすればよいですか？

A. まず遅延の原因とプロジェクト全体への影響を確認します。そのうえで、リソース追加、作業の並行化、スコープの見直しなど、プロジェクトの状況に応じた対応策を検討します。

Q. クラッシングとファストトラッキングの違いは何ですか？

A. クラッシングは追加のリソースを投入してスケジュールを短縮する方法です。ファストトラッキングは、本来順番に行う作業を一部並行して進めることでスケジュールを短縮する方法です。

The post スケジュールマネジメントとは？プロジェクトの納期を守るための基本を解説 first appeared on PM道場.

そう聞くと、PM経験5年の人よりもPMとして強そうに感じるかもしれません。

確かに、PMとして長く仕事をしてきたことは、それだけで一つの強みです。

さまざまなプロジェクトを経験し、さまざまな問題に向き合ってきた可能性があります。

しかし、私はPM経験年数だけでは、その人のPM戦闘力を判断できないと考えています。

なぜなら、同じ「PM経験10年」でも、経験してきたプロジェクトの難しさや、そこから何を学んできたかによって、PMとしての強さは大きく変わるからです。

PM戦闘力を高めるために重要なのは、単純な経験年数ではありません。

どのような経験をしたのか。

そして、その経験から何を学び、次のプロジェクトで何を変えたのか。

今回は、PM経験の「質」について考えてみます。

PM経験年数は重要。でも、それだけでは足りない

まず、誤解のないようにしておきたいのですが、私は「PM経験年数なんて意味がない」と考えているわけではありません。

むしろ、経験年数はPM戦闘力を考えるうえで重要な土台です。

1年目のPMと10年目のPMでは、経験してきたことに大きな差があるでしょう。

ただし、

経験年数＝PM戦闘力

ではありません。

重要なのは、

経験をどのようにPMとしての能力に変えてきたか

です。

同じ10年間でも、毎回似たようなプロジェクトを、同じような方法で進めてきた人と、異なる環境・難易度のプロジェクトに挑戦し、そこで得た教訓を次のプロジェクトに活かしてきた人では、経験の価値は変わります。

だから私は、

PM経験年数は「経験の量」を表す一つの指標であって、経験の質まで表しているわけではない

と考えています。

PM経験の「質」は何で決まるのか？

では、どのようなプロジェクトを経験すると、PMとしての経験値が高まるのでしょうか。

私自身の経験から考えると、特に重要なのは次の5つです。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

もちろん、これだけが全てではありません。

しかし、こうした条件が複雑になるほど、PMにはより高度なマネジメントが求められます。

① ステークホルダーが難しい

私が経験値が高いと感じるプロジェクトの中でも、特に重要なのがステークホルダーの難しさです。

例えば、次のような状況です。

• 初めて取引する顧客
• 自社に対して良い印象を持っていない顧客
• 要求が非常に多い顧客
• 意思決定者が複数いる
• 顧客と自社で利害が一致していない
• 社内でもプロジェクトに対する考え方が異なる

プロジェクトマネジメントは、計画を作って、その通りに進めれば終わる仕事ではありません。

人が関わる以上、認識の違いや期待値の違いが生まれます。

ステークホルダーが難しくなるほど、PMに求められる能力も増えていきます。

• コミュニケーション
• 交渉
• 期待値のコントロール
• 合意形成

そのため、難しいステークホルダーとのプロジェクトを経験することは、PMの戦闘力を高める大きな経験になると考えています。

② メンバーが多い

メンバーが増えると、単純に管理する人数が増えるだけではありません。

例えば、10人のメンバーを一つのチームとして管理するのではなく、複数のチームに分ける必要が出てくるとします。

すると、次のような新しいマネジメントが必要になります。

• チーム間の認識合わせ
• チーム間の依存関係
• チーム間の優先順位
• チーム間のコンフリクト
• 情報共有

人数が増えることで、

「一人ひとりとコミュニケーションを取ればいい」

というマネジメントから、

「チームという単位をマネジメントする」

という段階に変わっていきます。

これもPMとして重要な経験です。

③ 技術的な難しさ

技術的に難しいプロジェクトも、PMにとって貴重な経験になります。

• そもそも技術的に成功する可能性が低い
• やってみなければ結果が分からない
• 前例がない

このようなプロジェクトでは、単純に「計画通りに進める」だけでは対応できません。

例えば、

「もし技術的に実現できなかったらどうするのか？」

というところまで考えておく必要があります。

場合によっては、失敗した場合の代替案や関係者への説明方法まで、事前に準備しておく必要があるでしょう。

つまり、技術的な難しさが増えるほど、

不確実性をマネジメントする力

が求められます。

こうした経験は、次のプロジェクトでリスクを考えるときにも活きてきます。

④ メンバーの質

メンバーの経験やスキルも、プロジェクトの難易度を大きく左右します。

例えば、経験豊富なメンバーが揃っているプロジェクトであれば、PMが細かく指示を出さなくても、それぞれが自律的に動けるかもしれません。

一方、若手メンバーが多いプロジェクトでは、そうはいきません。

プロジェクトを進めるだけではなく、

メンバーを育成すること

も必要になります。

• 何をすべきなのか
• なぜそれをするのか
• どういう観点で仕事をしてほしいのか

こうしたことを伝えながら、プロジェクトそのものも前に進めなければなりません。

これは、単なるタスク管理とは違うPM経験です。

⑤ ベンダーが多い

複数のベンダーが関わるプロジェクトも、PMにとって難易度が上がります。

ベンダーごとの管理だけならまだしも、複数のベンダーが関係すると、

ベンダー同士をどう連携させるか

という問題が出てきます。

例えば、次のような状況です。

• A社の作業が終わらないとB社が作業できない
• A社とB社で責任範囲の認識が違う
• ベンダー間で優先順位が異なる
• 問題が発生したときに責任の所在が曖昧になる

ここではベンダーマネジメントだけではなく、ベンダー間の調整も必要になります。

これもPMとして重要な経験になります。

重要なのは「難しいプロジェクトを経験した数」だけではない

ここまで読むと、

「では、とにかく難しいプロジェクトをたくさん経験すればいいのか？」

と思うかもしれません。

私は、それも少し違うと考えています。

もちろん、さまざまな状況のプロジェクトを経験したほうが、PMとしての引き出しは増えます。

しかし、同じようなプロジェクトでも、経験から教訓を得て、より良いマネジメントができるようになれば、経験値は上がります。

例えば、前回のプロジェクトで、

「メンバーへの指示がうまく伝わらなかった」

という問題が起きたとします。

その原因を分析し、

「メンバーがプロジェクトマネジメントの意図を理解していなかった」

と分かった。

そこで次のプロジェクトでは、

「なぜこの指示をするのか」

まで説明するようにした。

これだけでも、同じような規模のプロジェクトを経験しているにもかかわらず、PMとしての能力は変わっています。

つまり、

経験の質は、プロジェクトそのものの難しさだけで決まるわけではありません。

経験から何を得たか。

これも、経験の質を決める重要な要素です。

失敗は、失敗のまま終わらせなければ戦闘力になる

私は、失敗した経験もPM戦闘力を高める重要な材料になると考えています。

例えば、次のような経験です。

• スケジュールが遅れた
• 顧客との認識が合わなかった
• メンバーへの指示が伝わらなかった
• リスクへの対応が遅れた
• ベンダーとの調整に失敗した

こうした経験は、決して無駄ではありません。

ただし、

「失敗した」という事実だけでは、PM戦闘力にはなりません。

重要なのは、その後です。

• なぜ失敗したのか？
• 原因を分析する
• 次はどうすれば防げるのか？
• 対策を考える
• 次のプロジェクトで実際に対策する
• その結果を確認する

こうして初めて、失敗が「教訓」に変わります。

私は、

失敗を失敗のまま終わらせなければ、その経験は戦闘力になる

と考えています。

私自身の経験：若手メンバーとのプロジェクト

ここで、私自身の経験を紹介します。

ある小規模なプロジェクトで、私以外のメンバーは入社3年以内の若手が2人。

そこに50代の営業担当者が1人。

そして、顧客は要望が多く、プロジェクトを失敗させると厳しいクレームにつながる可能性がある顧客でした。

人数だけを考えれば、それほど大きなプロジェクトではありません。

しかし、PMとしては簡単なプロジェクトではありませんでした。

特に課題だったのが、若手メンバーとどのようにプロジェクトを進めるかでした。

そこで私は、プロジェクトのマネジメント方法を一から伝えることにしました。

そして、キックオフミーティングでは、

「このプロジェクトでは、メンバーとしてこういうことを意識してほしい」

ということを伝えました。

単に「これをやってください」と指示するのではありません。

なぜ自分がその指示をしているのか。

プロジェクトマネジメントの観点から、なぜその行動が必要なのか。

そこまで理解してもらおうとしました。

なぜ、そこまでやったのか？

実は、これは前のプロジェクトから得た教訓でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していませんでした。

そのため、私が出した指示の意図がうまく伝わらず、結果として納期遅延を起こしてしまいました。

そこで私は、

「次のプロジェクトでは、メンバーに指示を出すだけではなく、プロジェクトマネジメントそのものを理解してもらおう」

と考えました。

これが、次のプロジェクトでの行動につながりました。

そして、そのプロジェクトでは、前回の教訓を活かしてプロジェクトを進めることができました。

これこそが「経験が戦闘力になる」ということ

この経験から、私はPMにとって重要なのは、

「何年PMをやったか」ではない

と改めて感じました。

もちろん、経験年数は重要です。

しかし、

前のプロジェクトで何が起きたのか。

↓

なぜ起きたのか。

↓

次はどうするのか。

↓

実際に次のプロジェクトで行動を変える。

このサイクルを回すことが重要です。

前のプロジェクトでの失敗が、次のプロジェクトでの成功につながった。

そして、その成功体験が、さらに次のプロジェクトで使える。

こうして経験が積み重なっていきます。

経験とスキルは相互に作用する

親記事では、PM戦闘力を、

（経験 × スキル × 適用力）＋（資格＋実績）

と考えました。

ここでいう「経験」と「スキル」は、一方通行ではありません。

経験 → スキル

という流れもあれば、

スキル → 経験

という流れもあります。

プロジェクトを経験することで、

「こういうときには、こう対応すればいい」

というスキルが身につく。

一方で、すでに持っているスキルを使うことで、

「このプロジェクトでは、ここが問題になりそうだ」

と気づくこともあります。

つまり、

経験とスキルは、お互いを高め合う関係

なのです。

ただし、ここでも重要なのは、自分で考えることです。

経験しただけ。

研修を受けただけ。

資格を取っただけ。

これでは十分ではありません。

経験から考える。

考えたことをスキルに変える。

スキルを次のプロジェクトで使う。

その結果を振り返る。

また次のプロジェクトで活用する。

この循環を自分自身で作る必要があります。

「経験年数」ではなく「経験をどう変えたか」を考える

PMとして経験を積んでいると、いつの間にか、

「PM歴○年」

という数字を自分の強さの指標にしてしまうことがあります。

しかし、PM戦闘力を高めるうえで重要なのは、単純な年数ではありません。

• どんなプロジェクトを経験したのか
• どんな難しさに直面したのか
• 何に失敗したのか
• 何を教訓にしたのか
• 次のプロジェクトで何を変えたのか

そして、

その経験を、次のプロジェクトで再現できる能力に変えられたのか。

ここまで考えて、初めて「経験」がPM戦闘力につながるのだと思います。

まとめ：経験を積むだけではなく、経験を戦闘力に変える

PM経験年数は、PM戦闘力を考えるうえで重要な土台です。

しかし、

PM経験10年＝PM戦闘力10

のように単純に考えることはできません。

経験の質によって、得られるものは大きく変わります。

特に、次のような要素が複雑になるほど、PMにはより高度なマネジメントが求められます。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

一方で、難しいプロジェクトだけが価値のある経験というわけでもありません。

同じようなプロジェクトであっても、

過去の教訓を活かして、前回より良いマネジメントができた

のであれば、それもPM戦闘力を高める重要な経験です。

そして、失敗も同じです。

失敗する → 原因を分析する → 対策を考える → 教訓にする → 次のプロジェクトで活かす

このサイクルを回すことで、失敗は戦闘力に変わります。

PMとして大切なのは、

経験年数を増やすことではなく、経験を戦闘力に変え続けること。

私はそう考えています。

あなたは、これまでのPM経験から、どんな教訓を得てきましたか？

そして、その教訓を次のプロジェクトで活かせているでしょうか。

経験を「年数」で終わらせず、「次のプロジェクトで使える力」に変えていく。

それが、PM戦闘力を高める一つの方法だと思います。

PM戦闘力シリーズ

PM戦闘力について、さらに詳しく知りたい方はこちらもどうぞ。

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM戦闘力を高めるPMスキルとは？重要な4つのスキル考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由 first appeared on PM道場.

「予算は使いすぎていないだろうか。」

進捗だけを見ても、コストだけを見ても、プロジェクトの本当の状況は分かりません。

そこで活用されるのがEVM（Earned Value Management：アーンド・バリュー・マネジメント）です。

EVMは、スケジュールとコストを同時に管理できるPMBOK®︎推奨の管理手法です。

この記事では、EVMの基本と、EV・PV・AC・CPI・SPI・BACについてまとめて解説します。

一言でいうと

EVMとは、「進捗・コスト・計画を数値で比較し、プロジェクトの健全性を客観的に評価する管理手法」です。

EVMとは

EVMは、実際に完了した作業量（出来高）を基準として、計画と実績を比較する管理手法です。

通常の進捗管理では「50％完了」という情報しか分かりませんが、EVMでは「予定より遅れているのか」「予算を超過しているのか」まで把握できます。

PMBOK®︎では、コスト・パフォーマンスとスケジュール・パフォーマンスを管理する代表的な手法として紹介されています。

EVMで使用する6つの重要な用語

① EV（Earned Value：出来高）

実際に完了した作業を金額で表した値です。

例えば、予算100万円の作業が50％完了した場合、EVは50万円になります。

計算式

EV = 完了率 × BAC

② PV（Planned Value：計画価値）

計画上、この時点で完了しているはずの作業額です。

コストベースラインをもとに算出されます。

計画どおり進んでいれば、EVとPVは一致します。

③ AC（Actual Cost：実コスト）

実際に支出した費用です。

人件費や外注費など、実際に発生したコストを表します。

④ CPI（Cost Performance Index：コスト効率指数）

コスト効率を表す指標です。

計算式

CPI = EV ÷ AC

⑤ SPI（Schedule Performance Index：スケジュール効率指数）

スケジュール効率を表す指標です。

計算式

SPI = EV ÷ PV

⑥ BAC（Budget at Completion：完成時総予算）

プロジェクト全体の承認済み予算です。

EVMでは、EVや将来予測の計算基準として利用されます。

BACは、プロジェクト開始時に設定されるコストベースラインの総額と考えると理解しやすいでしょう。

EVMのイメージ

この3つを比較することで、プロジェクトの状況を客観的に把握できます。

実務ではこんな場面で活用される

例えば、BACが1,000万円のプロジェクトで、3か月経過した時点の状況が次のとおりだったとします。

• PV：600万円
• EV：500万円
• AC：550万円

この場合、

• CPI＝500÷550＝0.91
• SPI＝500÷600＝0.83

となります。

つまり、予定より遅れており、さらに予算効率も悪化していることが分かります。

この結果をもとに、人員の再配置やスケジュール見直しなどの対策を検討します。

よくある勘違い

進捗率とEVは同じではない

進捗率は作業量の割合ですが、EVは金額換算した出来高です。

EVMでは金額ベースで管理することが特徴です。

CPIやSPIは1に近いほど良い

どちらも「1」が計画どおりです。

1未満なら改善が必要であり、1を大きく上回る場合も、計画自体が適切だったかを確認する必要があります。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験やPMP®試験では、EVMは頻出テーマです。

午後試験では、次のような内容を説明できることが重要です。

• EV・PV・ACの意味
• CPI・SPIの読み取り方
• コスト超過や遅延への対応
• EVMを活用したプロジェクト管理

計算問題だけでなく、「数値からどのような状況を判断するか」が問われることも多いため、意味まで理解しておくことが重要です。

PM道場のワンポイント

EVMは、「数字を計算すること」が目的ではありません。

目的は、問題を早期に発見し、プロジェクトを立て直すことです。

優れたプロジェクトマネージャは、CPIやSPIが悪化した理由を分析し、次のアクションにつなげています。

「計算するPM」ではなく、「数字から判断できるPM」になることが重要です。

関連用語

• コストマネジメント
• コストベースライン
• 予算
• 見積もり
• スケジュールベースライン
• マイルストーン
• クリティカルパス
• 進捗管理

まとめ

EVMとは、進捗・コスト・計画を金額ベースで比較し、プロジェクトの状況を客観的に把握する管理手法です。

EV・PV・ACを基礎として、CPIやSPIを活用することで、コスト超過やスケジュール遅延を早期に発見できます。

プロジェクトマネージャにとって、EVMはプロジェクトを数値で「見える化」し、適切な意思決定を支える重要なマネジメント手法と言えるでしょう。

関連記事

• コストマネジメントとは？
• コストベースラインとは？
• 予算とは？
• 見積もりとは？
• スケジュールベースラインとは？

よくある質問（FAQ）

Q. EVMとは何ですか？

A. 進捗・コスト・計画を金額ベースで比較し、プロジェクトの状況を客観的に評価する管理手法です。

Q. EV・PV・ACの違いは何ですか？

A. EVは実際に完了した作業の価値、PVは計画上の作業価値、ACは実際に発生したコストです。

Q. CPIとSPIはどのように判断しますか？

A. CPIはコスト効率、SPIはスケジュール効率を表します。どちらも1が計画どおりで、1未満は改善が必要な状態を示します。

The post EVM（アーンド・バリュー・マネジメント）とは？進捗とコストを同時に管理する手法を解説 first appeared on PM道場.

「見積もりは経験だけで決めてもよいのだろうか。」

プロジェクトを成功させるためには、現実的なスケジュールや予算を計画することが重要です。

その土台となるのが見積もり（Estimate）です。

この記事では、見積もりの意味や目的、代表的な見積もり手法、PMBOK®︎との関係、実務で意識すべきポイントについて解説します。

一言でいうと

見積もりとは、「プロジェクトに必要な期間・コスト・工数・資源などを予測する活動」です。

見積もりとは

見積もりとは、プロジェクトを実施するために必要な工数、期間、コスト、資源などを予測することです。

プロジェクトの初期段階では情報が限られているため、見積もりはあくまで予測であり、プロジェクトが進むにつれて精度を高めていきます。

PMBOK®︎では、見積もりはスケジュールマネジメントやコストマネジメントなどの計画プロセスで重要な活動として位置付けられています。

見積もりが重要な理由

見積もりが不正確だと、その後に作成するスケジュールや予算、要員計画にも大きな影響を与えます。

例えば、次のような問題が発生する可能性があります。

• スケジュールが現実的ではない
• 予算不足になる
• 要員が不足する
• 納期遅延や品質低下につながる

適切な見積もりを行うことで、実現可能な計画を立てることができます。

代表的な見積もり手法

類推見積もり（Analogous Estimating）

過去の類似プロジェクトを参考に見積もる方法です。

短時間で実施できますが、過去の実績に大きく依存します。

パラメトリック見積もり（Parametric Estimating）

単価や生産性などの統計データを用いて算出する方法です。

例えば、「1画面あたり20時間」といった基準を利用します。

ボトムアップ見積もり（Bottom-Up Estimating）

WBSで分解した最小単位の作業ごとに見積もり、それらを積み上げる方法です。

時間はかかりますが、高い精度が期待できます。

三点見積もり（Three-Point Estimating）

楽観値・最頻値・悲観値の3つを用いて見積もる方法です。

不確実性を考慮した、より現実的な見積もりが可能になります。

見積もりの精度は段階的に高まる

プロジェクト初期は情報が少ないため、見積もりの精度は高くありません。

要件が明確になり、設計が進むにつれて精度は向上します。

そのため、見積もりは一度作成したら終わりではなく、必要に応じて見直すことが重要です。

見積もりと予算の違い

つまり、見積もりをもとに予算が作成されます。

実務ではこんな場面で活用される

例えば、新しいWebシステムを開発するプロジェクトを考えます。

プロジェクトマネージャは、まずWBSを作成し、各アクティビティの工数をボトムアップ見積もりで算出します。

さらに、過去のプロジェクト実績も参考にしながら見積もりを補正し、最終的な期間とコストを算出します。

その見積もりをもとに、スケジュールや予算を作成し、スポンサーの承認を得てプロジェクトを開始します。

よくある勘違い

見積もりは「約束」ではない

見積もりは、現時点で得られる情報をもとにした予測です。

要件変更や新たなリスクによって見積もりが変わることは珍しくありません。

経験だけで見積もるのは危険

経験は重要ですが、それだけでは精度に限界があります。

WBSや過去実績、統計データなどを活用し、客観的な根拠を持って見積もることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、見積もり手法や見積もり精度に関する問題が出題されます。

午後試験では、次のような観点を説明できることが重要です。

• どの見積もり手法を採用したか
• 見積もりの根拠は何か
• 見積もり精度をどのように向上させたか
• 見積もり結果を計画へどのように反映したか

「経験で見積もった」だけではなく、「WBSや過去実績などを活用し、根拠のある見積もりを実施した」と説明できることが評価につながります。

PM道場のワンポイント

見積もりは、「未来を当てること」ではなく、「現時点で最も合理的な予測をすること」です。

プロジェクトでは、不確実性をゼロにすることはできません。

だからこそ、根拠を明確にし、不確実性も考慮した見積もりを行うことが重要です。

優れたプロジェクトマネージャは、「当たる見積もり」ではなく、「説明できる見積もり」を作成しています。

関連用語

• WBS
• 予算
• コストベースライン
• コストマネジメント
• スケジュールベースライン
• ローリングウェーブ計画法
• リスク分析
• アクティビティ

まとめ

見積もりとは、プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

見積もりの精度はプロジェクトの進行とともに高まり、その結果はスケジュールや予算の基礎となります。

プロジェクトマネージャにとって、根拠のある見積もりを行うことは、現実的な計画を立てるための重要なスキルと言えるでしょう。

関連記事

• WBSとは？
• 予算とは？
• コストベースラインとは？
• コストマネジメントとは？
• スケジュールベースラインとは？
• ローリングウェーブ計画法とは？

よくある質問（FAQ）

Q. 見積もりとは何ですか？

A. プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

Q. PMBOK®︎で代表的な見積もり手法には何がありますか？

A. 類推見積もり、パラメトリック見積もり、ボトムアップ見積もり、三点見積もりなどがあります。

Q. 見積もりと予算の違いは何ですか？

A. 見積もりは必要な期間や費用を予測する活動であり、予算はその見積もりをもとに承認された資金計画です。

The post 見積もりとは？プロジェクト計画の精度を左右する重要なプロセスを解説 first appeared on PM道場.

プロジェクトでは、このような要望を受けることがあります。

しかし、人員を増やすだけでは対応できないケースも少なくありません。

そのようなときに検討されるスケジュール短縮手法の一つがファストトラッキング（Fast Tracking）です。

この記事では、ファストトラッキングの意味や考え方、クラッシングとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

ファストトラッキングとは、「本来は順番に実施する作業を、並行して進めることでプロジェクト期間を短縮する手法」です。

ファストトラッキングとは

ファストトラッキング（Fast Tracking）は、スケジュール圧縮技法の一つです。

通常は前のアクティビティが完了してから開始する後続作業を、一部重ねて実施することで、プロジェクト全体の期間を短縮します。

PMBOK®では、クラッシングと並ぶ代表的なスケジュール圧縮技法として位置付けられています。

ファストトラッキングの具体例

例えば、システム開発では「基本設計 → 詳細設計 → 開発」という順番で進めることが一般的です。

しかし、基本設計がすべて完了するのを待たずに、完成した機能から詳細設計や開発を開始することで、プロジェクト全体の期間を短縮できます。

このように、作業を重ねて進めることがファストトラッキングです。

ファストトラッキングのメリット

• 追加コストを抑えながら納期を短縮できる
• リソースを増やさなくても実施できる場合がある
• クリティカルパスを短縮できる可能性がある

ファストトラッキングのデメリット

• 手戻りが発生しやすい
• 品質低下のリスクが高まる
• 変更管理が難しくなる
• 関係者間のコミュニケーションがより重要になる

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

ファストトラッキングは「リスクを取って時間を短縮する」、クラッシングは「コストをかけて時間を短縮する」という違いがあります。

実務ではこんな場面で活用される

例えば、システム開発で100画面ある場合、すべての画面設計が終わるまで待つのではなく、完成した画面から順番に開発を開始することがあります。

また、テストケースの作成も、設計書が完成した部分から進めることで、後半工程の負荷を分散できます。

このように、依存関係を見極めながら並行作業を取り入れることで、納期短縮を図ります。

よくある勘違い

ファストトラッキングは「何でも並行作業にする」ことではない

依存関係が強い作業を無理に並行実施すると、大きな手戻りにつながる可能性があります。

どの作業なら並行できるかを慎重に判断することが重要です。

リードと同じ意味ではない

リードはアクティビティ間の前倒し時間を表すスケジュール上の設定です。

一方、ファストトラッキングは、そのリードなどを活用してプロジェクト全体を短縮するスケジュール圧縮手法です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、クラッシングとの違いや、ファストトラッキングによるリスク増加について理解していることが重要です。

午後試験では、「納期短縮のために並行作業を採用した理由」と、「増加したリスクに対してどのような対策を講じたか」を説明できると評価につながります。

PM道場のワンポイント

ファストトラッキングは「早く進める技術」ではなく、「リスクを管理する技術」です。並行作業を行えば、確かに納期は短縮できます。しかし、前工程で仕様変更が発生すると、後工程の作業をやり直さなければならない可能性があります。

つまり、ファストトラッキングとは「時間を短縮する代わりに、手戻りリスクを受け入れる」という意思決定でもあります。

優れたプロジェクトマネージャは、ただ並行作業を増やすのではなく、「どこなら手戻りが許容できるか」「どこは絶対に順番を守るべきか」を見極めています。

納期短縮だけを目的にするのではなく、リスクとのバランスを考えることが成功への鍵です。

関連用語

• クラッシング
• リード
• ラグ
• クリティカルパス
• ネットワーク図
• PDM（プレシデンスダイアグラム法）
• アクティビティ
• スケジュールベースライン

まとめ

ファストトラッキングとは、本来は順番に実施する作業を並行して進めることで、プロジェクト期間を短縮するスケジュール圧縮技法です。

追加コストを抑えられる一方で、手戻りや品質低下などのリスクが高まるため、慎重な判断が求められます。

重要なのは、「早く進めること」ではなく、「どのリスクなら受け入れられるか」を見極めながらプロジェクトを進めることです。

関連記事

• クラッシングとは？
• リードとは？
• クリティカルパスとは？
• ネットワーク図とは？

よくある質問（FAQ）

Q. ファストトラッキングとは何ですか？

A. 本来は順番に実施する作業を並行して進めることで、プロジェクト期間を短縮する手法です。

Q. クラッシングとの違いは何ですか？

A. ファストトラッキングは並行作業によって期間を短縮する手法で、リスクが増加します。一方、クラッシングはリソースを追加して期間を短縮する手法で、コストが増加します。

Q. ファストトラッキングはどのようなプロジェクトでも利用できますか？

A. 利用できますが、依存関係が強い作業では手戻りリスクが高くなるため、適用できる範囲を慎重に判断する必要があります。

The post ファストトラッキング（Fast Tracking）とは？クラッシングとの違いを初心者向けにわかりやすく解説 first appeared on PM道場.

プロジェクトでは、このような要望を受けることがあります。

その際、単純に担当者へ残業をお願いするだけでは、品質低下やメンバーの負荷増加につながる可能性があります。

そこで活用されるスケジュール短縮手法の一つがクラッシング（Crashing）です。

この記事では、クラッシングの意味や考え方、ファストトラッキングとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

クラッシングとは、「追加のリソースやコストを投入して、プロジェクト期間を短縮する手法」です。

クラッシングとは

クラッシング（Crashing）は、スケジュール短縮技法の一つです。

クリティカルパス上のアクティビティへ追加の人員や設備、予算を投入し、作業期間を短縮することで、プロジェクト全体の納期短縮を目指します。

PMBOK®では、ファストトラッキングと並ぶ代表的なスケジュール圧縮技法として位置付けられています。

クラッシングの具体例

例えば、開発工程に10日かかる予定だったとします。

そこで、開発メンバーを2人追加し、並行して作業できるようにした結果、7日で完了できるようになりました。

このように、追加リソースによって作業期間を短縮するのがクラッシングです。

クラッシングのメリット

• プロジェクト全体の納期を短縮できる
• 作業の順番を変更しないため品質への影響が比較的小さい
• クリティカルパスを重点的に短縮できる

クラッシングのデメリット

• 追加コストが発生する
• 人員を増やしても必ず短縮できるとは限らない
• 教育やコミュニケーションコストが増える

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

クラッシングは「お金を使って時間を買う」、ファストトラッキングは「リスクを取って時間を短縮する」と考えると理解しやすくなります。

実務ではこんな場面で活用される

例えば、顧客の要望でリリース日を2週間前倒しする必要が生じたとします。

その場合、クリティカルパス上の工程へ経験豊富なメンバーを追加したり、外部ベンダーへ一部作業を委託したりすることで、納期短縮を図ります。

ただし、追加コストと短縮効果を比較し、本当に実施すべきかを判断することが重要です。

よくある勘違い

人を増やせば必ず早く終わるわけではない

新しいメンバーへの教育や引き継ぎが必要になり、かえって効率が下がる場合があります。

特に終盤工程では、単純な増員だけでは効果が出にくいことがあります。

クラッシングはすべての作業に適用するものではない

期間短縮の効果があるのは、基本的にクリティカルパス上のアクティビティです。

クリティカルパス以外を短縮しても、プロジェクト全体の納期は変わらない場合があります。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、クラッシングとファストトラッキングの違いや、クリティカルパスを対象にスケジュール短縮を行う考え方が重要です。

午後試験では、「追加コストと納期短縮の効果をどのように評価したか」を説明できると評価につながります。

PM道場のワンポイント

クラッシングは「人を増やすこと」ではなく、「投資する価値があるかを判断すること」です。納期が迫ると、「とにかく応援を呼ぼう」という判断をしてしまいがちです。しかし、応援要員にも教育や調整が必要であり、追加コストも発生します。

優れたプロジェクトマネージャは、「どこへ投資すれば最も大きな短縮効果が得られるか」を考えます。

クラッシングとは、時間を短縮する技術ではなく、限られた予算を最も効果的に使う意思決定でもあります。

関連用語

• ファストトラッキング
• リード
• クリティカルパス
• フロート
• アクティビティ
• ネットワーク図
• PDM（プレシデンスダイアグラム法）
• スケジュールベースライン

まとめ

クラッシングとは、追加の人員や設備、予算を投入してプロジェクト期間を短縮するスケジュール圧縮技法です。

期間短縮には効果がありますが、その分コストも増加するため、費用対効果を考慮して実施することが重要です。

重要なのは、「人を増やせば早く終わる」と考えるのではなく、クリティカルパスを分析し、最も効果の高い場所へ投資することです。

関連記事

• ファストトラッキングとは？
• クリティカルパスとは？
• リードとは？
• ネットワーク図とは？

よくある質問（FAQ）

Q. クラッシングとは何ですか？

A. 人員や設備などのリソースを追加して、プロジェクト期間を短縮する手法です。

Q. ファストトラッキングとの違いは何ですか？

A. クラッシングはコストを増やして期間を短縮する手法、ファストトラッキングは並行作業によって期間を短縮する手法です。

Q. クラッシングはどの作業に適用すべきですか？

A. 原則として、プロジェクト全体の納期に影響するクリティカルパス上のアクティビティへ適用します。

The post クラッシング（Crashing）とは？ファストトラッキングとの違いを初心者向けにわかりやすく解説 first appeared on PM道場.

そのスケジュールを関係者で合意し、「これを基準として管理する」と決めて初めて、進捗や遅延を正しく管理できるようになります。

この管理基準となるスケジュールがスケジュールベースラインです。

この記事では、スケジュールベースラインの意味や役割、実務での活用方法までわかりやすく解説します。

一言でいうと

スケジュールベースラインとは、「進捗や遅延を評価するための正式に承認されたスケジュール」のことです。

スケジュールベースラインとは

スケジュールベースライン（Schedule Baseline）は、関係者の承認を受けたプロジェクトスケジュールであり、進捗管理の基準となる計画です。

PMBOK®では、プロジェクトの実績と比較し、進捗や遅延を管理するための重要なベースラインとして位置付けられています。

実績は常にスケジュールベースラインと比較することで、「予定どおりか」「どの程度遅れているか」を客観的に評価できます。

なぜスケジュールベースラインが重要なのか

例えば、プロジェクトの途中で担当者が勝手にスケジュールを変更してしまうと、「本当に遅れたのか」「最初からその予定だったのか」が分からなくなります。

そこで、一度承認されたスケジュールを変更管理の対象とし、正式な手続きを経て変更することで、プロジェクト全体の管理が適切に行えるようになります。

つまり、スケジュールベースラインは「約束した計画」を守るための基準なのです。

スケジュールベースラインとプロジェクトスケジュールの違い

すべてのスケジュールがベースラインではありません。

正式な承認を受け、管理基準となったスケジュールだけがスケジュールベースラインです。

実務ではこんな場面で活用される

例えば、設計工程の完了予定日が6月30日だったとします。

実績では7月5日に完了した場合、スケジュールベースラインと比較することで「5日遅延した」と客観的に判断できます。

また、顧客から追加要件が発生し、正式な変更管理を経て納期が変更された場合は、新しいスケジュールベースラインを設定することがあります。

よくある勘違い

スケジュールベースラインは変更してはいけないものではない

ベースラインは一度決めたら絶対に変更できないわけではありません。

ただし、変更する場合は、変更管理プロセスを経て関係者の承認を得る必要があります。

最新のスケジュールが常にベースラインとは限らない

担当者が作業用に更新しているスケジュールと、正式なスケジュールベースラインは異なる場合があります。

進捗評価では、どのスケジュールを基準としているのかを明確にすることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、ベースラインはスコープ・スケジュール・コストの各管理で重要な概念として出題されます。

午後試験では、「どの基準と比較して進捗を評価したか」「変更管理をどのように行ったか」を説明できることが重要です。

単なる予定表ではなく、「正式に承認された管理基準」であることを理解しておきましょう。

PM道場のワンポイント

スケジュールベースラインは「予定表」ではなく、「約束」です。実務では、「少し予定を変えておきました」と気軽にスケジュールが更新されることがあります。しかし、もし基準そのものを簡単に変えてしまうと、「遅れたのか」「計画を変更したのか」が分からなくなってしまいます。

優れたプロジェクトマネージャは、作業用のスケジュールと、正式な管理基準であるスケジュールベースラインを明確に区別しています。

変更が必要になった場合も、「なぜ変更するのか」「誰が承認したのか」を記録し、プロジェクトの透明性を維持します。

ベースラインとは、プロジェクトメンバーとステークホルダーが合意した”約束”であり、その約束を守ることが信頼につながります。

関連用語

• ベースライン
• プロジェクトスケジュール
• ガントチャート
• クリティカルパス
• 変更管理
• 進捗管理
• マイルストーン
• スコープベースライン

まとめ

スケジュールベースラインとは、正式に承認されたスケジュールであり、進捗や遅延を評価するための管理基準です。

実績と比較することで、プロジェクトの状況を客観的に把握でき、変更が必要な場合も適切な変更管理を行えるようになります。

重要なのは、スケジュールベースラインを単なる予定表ではなく、プロジェクト全体で合意した「約束」として管理することです。

関連記事

• ベースラインとは？
• ガントチャートとは？
• クリティカルパスとは？
• 変更管理とは？

よくある質問（FAQ）

Q. スケジュールベースラインとは何ですか？

A. 関係者の承認を受けた正式なスケジュールであり、進捗や遅延を評価するための基準です。

Q. プロジェクトスケジュールとの違いは何ですか？

A. プロジェクトスケジュールは計画全般を指しますが、スケジュールベースラインは正式承認された管理基準となるスケジュールです。

Q. スケジュールベースラインは変更できますか？

A. はい。変更できますが、変更管理プロセスを経て、関係者の承認を得る必要があります。

The post スケジュールベースラインとは？意味や役割を初心者向けにわかりやすく解説 first appeared on PM道場.

ガントチャートを見ると作業期間は分かりますが、作業同士の依存関係までは把握しにくいことがあります。

そこで活用されるのがネットワーク図です。

ネットワーク図を作成することで、作業の前後関係を整理でき、クリティカルパスやフロートを分析することができます。

この記事では、ネットワーク図の意味や目的、ガントチャートとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

ネットワーク図とは、「アクティビティ同士の順番や依存関係を図で表したもの」です。

ネットワーク図とは

ネットワーク図とは、プロジェクトで実施するアクティビティを矢印や線で結び、どの作業がどの作業に依存しているかを表現した図です。

PMBOK®では、スケジュールを作成するための重要なツールとして位置付けられています。

ネットワーク図を利用することで、作業の流れが明確になり、クリティカルパスやフロートを分析できるようになります。

ネットワーク図のイメージ

例えば、次のような作業があるとします。

• A：要件定義
• B：基本設計
• C：詳細設計
• D：開発
• E：テスト

これをネットワーク図で表すと、次のような流れになります。


A → B → C → D → E


もし「テスト環境構築」が開発と並行して進められる場合は、途中で分岐したネットワーク図になります。

このように、作業の前後関係や並行作業を視覚的に表現できることがネットワーク図の特徴です。

ネットワーク図が重要な理由

ネットワーク図を作成することで、単なる作業一覧では分からない依存関係を把握できます。

また、「どの作業が遅れるとプロジェクト全体へ影響するのか」を分析できるため、スケジュール管理の精度が向上します。

さらに、クリティカルパスやフロートを求めるための基礎資料にもなります。

ガントチャートとの違い

ネットワーク図は「作業のつながり」を見るための図、ガントチャートは「いつ実施するか」を見るための図です。

PDMとの関係

現在のプロジェクトでは、ネットワーク図の多くがPDM（プレシデンスダイアグラム法）によって作成されています。

PDMでは、アクティビティを四角形で表し、FS（終了-開始）やSS（開始-開始）などの依存関係で接続します。

つまり、PDMはネットワーク図を作成する代表的な表現方法の一つです。

実務ではこんな場面で活用される

例えば、納期短縮の検討を行う際、ガントチャートだけでは「どの作業を並行化できるか」が分かりにくいことがあります。

ネットワーク図を見ることで、依存関係を確認しながら、リードやラグを活用したスケジュール変更を検討できます。

また、クリティカルパスを分析し、重点的に管理すべき作業を明確にする際にも利用されます。

よくある勘違い

ネットワーク図はガントチャートの代わりではない

ネットワーク図とガントチャートは役割が異なります。

実務では、ネットワーク図で依存関係を整理し、その結果をガントチャートへ反映することが一般的です。

ネットワーク図は試験だけの知識ではない

普段はプロジェクト管理ツールが自動で作成しているため意識しないこともありますが、作業の依存関係を理解する考え方は実務でも非常に重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、ネットワーク図からクリティカルパスやフロートを求める問題が頻繁に出題されます。

また、PDMによる依存関係（FS・SS・FF・SF）の理解や、リード・ラグを含めたスケジュール分析も重要なポイントです。

ネットワーク図は、スケジュールマネジメント分野の基礎となる知識です。

PM道場のワンポイント

ネットワーク図は「スケジュールを描く図」ではなく、「制約を見つける図」です。実務では、ガントチャートだけを見てスケジュールを調整することがあります。しかし、本当に重要なのは、「どの作業が次の作業を止めてしまうのか」という依存関係を理解することです。

例えば、担当者を追加しても、前工程が終わらなければ後工程は始められません。

優れたプロジェクトマネージャは、日程だけを見るのではなく、「どの制約を解消すればプロジェクト全体が前に進むのか」をネットワーク図から読み取っています。

プロジェクトを動かしているのは日付ではなく、アクティビティ同士のつながりです。

関連用語

• PDM（プレシデンスダイアグラム法）
• アクティビティ
• クリティカルパス
• フロート
• リード
• ラグ
• ガントチャート
• スケジュールベースライン

まとめ

ネットワーク図とは、アクティビティ同士の依存関係を表した図です。

クリティカルパスやフロートを分析し、現実的なスケジュールを作成するための基礎となります。

ガントチャートだけでは見えない「作業のつながり」を理解することで、より精度の高いプロジェクトマネジメントを実践できるようになります。

関連記事

• PDMとは？
• クリティカルパスとは？
• フロートとは？
• ガントチャートとは？

よくある質問（FAQ）

Q. ネットワーク図とは何ですか？

A. アクティビティ同士の順番や依存関係を図で表したものです。

Q. ガントチャートとの違いは何ですか？

A. ネットワーク図は作業の依存関係を整理するための図であり、ガントチャートは時間軸に沿ってスケジュールや進捗を管理するための図です。

Q. ネットワーク図を作るメリットは何ですか？

A. 作業の依存関係が明確になり、クリティカルパスやフロートを分析しやすくなります。また、スケジュール短縮やリスク分析にも役立ちます。

The post ネットワーク図とは？ガントチャートとの違いや意味を初心者向けにわかりやすく解説 first appeared on PM道場.

例えば、コンクリートを打設した後は硬化するまで待つ必要がありますし、システム変更後は一定期間の稼働確認を行ってから次の工程へ進むことがあります。

このように、作業と作業の間に意図的に設ける待ち時間が「ラグ（Lag）」です。

この記事では、ラグの意味やリードとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

ラグとは、「前の作業が終わってから、次の作業を開始するまでに設ける待ち時間」のことです。

ラグとは

ラグ（Lag）は、アクティビティ間の依存関係において、後続作業を開始する前に必要となる待機時間を表します。

PMBOK®では、アクティビティ間の論理的な関係を調整するための時間として定義されています。

ラグを設定することで、乾燥・養生・承認待ち・経過観察など、実際の業務に必要な待機期間をスケジュールへ正しく反映できます。

ラグの具体例

例えば、次のようなケースではラグを設定します。

このように、人が作業をしていない時間であっても、プロジェクト上は重要な時間として管理する必要があります。

ラグを利用するメリット

• 現実的なスケジュールを作成できる
• 品質を確保できる
• 手戻りを防止できる
• 承認や確認期間を計画へ反映できる

ラグを考慮しないスケジュールは、実際のプロジェクトでは実現できない計画になってしまうことがあります。

ラグとリードの違い

ラグは「待つ」、リードは「早く始める」という、正反対の考え方です。

実務ではこんな場面で活用される

例えば、システムを本番環境へリリースした後、すぐに次のリリースを行うのではなく、1週間程度は稼働状況を確認するケースがあります。

また、設計レビューが終わっても、顧客承認を得るまで開発を開始できない場合もあります。

このような「待ち時間」をラグとしてスケジュールへ組み込むことで、現実的で実行可能な計画を作成できます。

よくある勘違い

ラグは「何もしない時間」ではない

ラグ中でも、品質確認や監視、承認待ちなどが行われていることがあります。

担当者が手を動かしていなくても、プロジェクトとしては重要な期間です。

ラグは削れば良いわけではない

納期を短縮したいからといって、必要なラグを削ると品質低下や手戻りにつながる可能性があります。

短縮する場合は、十分にリスクを評価した上で判断することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、PDM（プレシデンスダイアグラム法）やネットワーク図でリードとラグの違いが問われることがあります。

また、午後試験では、品質確保や承認プロセスを考慮したスケジュール設計について説明できることが重要です。

「ラグ＝待機時間」「リード＝前倒し時間」という基本を正しく理解しておきましょう。

PM道場のワンポイント

ラグは「無駄な待ち時間」ではなく、「品質を守るための時間」です。実務では、「少しでも納期を短縮したいから、承認待ちを省略しよう」「確認期間を短くしよう」という話が出ることがあります。しかし、多くのトラブルは、この「待つべき時間」を削ったことで発生します。

例えば、リリース直後の稼働確認期間を設けなかったため、不具合が見逃され、大きな障害につながることもあります。

優れたプロジェクトマネージャは、ラグを単なる待機時間ではなく、品質やリスクを管理するための重要な時間として設計しています。

プロジェクトを早く終わらせることよりも、確実に成功させることの方が重要です。

関連用語

• リード
• アクティビティ
• PDM（プレシデンスダイアグラム法）
• クリティカルパス
• フロート
• ガントチャート
• ファストトラッキング
• 品質マネジメント

まとめ

ラグとは、前工程が終了してから後続作業を開始するまでに設ける待機時間のことです。

適切なラグを設定することで、品質や安全性を確保しながら、現実的なスケジュールを作成できます。

重要なのは、ラグを「削るべき時間」と考えるのではなく、プロジェクトを成功へ導くための必要な時間として管理することです。

関連記事

• リードとは？
• PDMとは？
• クリティカルパスとは？
• アクティビティとは？

よくある質問（FAQ）

Q. ラグとは何ですか？

A. 前工程が終了してから後続作業を開始するまでに設ける待機時間のことです。

Q. ラグとリードの違いは何ですか？

A. ラグは待機時間を設ける考え方、リードは後続作業を前倒しで開始する考え方です。

Q. ラグはスケジュール短縮のために削っても良いですか？

A. 必要なラグを削ると品質低下や手戻りにつながる可能性があります。短縮する場合は、リスクを十分に評価した上で判断することが重要です。

The post ラグ（Lag）とは？リードとの違いや意味を初心者向けにわかりやすく解説 first appeared on PM道場.

例えば、設計がすべて完了していなくても、完成した部分から開発を始められることがあります。

このように、後続作業を前倒しで開始するための考え方が「リード（Lead）」です。

この記事では、リードの意味やラグとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

リードとは、「前の作業が完了する前に、後続作業を前倒しで開始できる時間」のことです。

リードとは

リード（Lead）は、アクティビティ間の依存関係において、後続作業を前倒しして開始できる時間を表します。

PMBOK®では、スケジュールを短縮するために利用される手法の一つとして扱われています。

リードを設定することで、複数の作業を並行して進められるため、プロジェクト全体の期間を短縮できる場合があります。

リードの具体例

例えば、「基本設計」が10日間かかるプロジェクトを考えてみます。

通常であれば、基本設計がすべて完了した後に開発を開始します。

しかし、画面設計が完了した部分から順次開発を開始すれば、設計完了を待つ必要はありません。

このように、後続作業を前倒しで開始する時間がリードです。

リードを利用するメリット

• プロジェクト全体の期間を短縮できる
• 待ち時間を減らせる
• リソースを有効活用できる
• 納期短縮に対応しやすくなる

特に納期が厳しいプロジェクトでは、リードを活用して並行作業を行うことがあります。

リードとラグの違い

リードは「早く始める」、ラグは「少し待つ」という違いがあります。

実務ではこんな場面で活用される

例えば、100画面あるシステム開発では、すべての画面設計が終わるまで待つ必要はありません。

完成した画面から順番に開発を始めることで、開発期間を短縮できます。

また、テストケース作成も、設計が完成した部分から開始することで、後半工程の負荷を分散できます。

このように、リードは並行作業を実現するための重要な考え方です。

よくある勘違い

リードは必ず設定すれば良いわけではない

前倒しして開始すると、設計変更が発生した場合に手戻りが増える可能性があります。

期間短縮と手戻りリスクのバランスを考えて設定することが重要です。

リードは依存関係を無視することではない

前工程がある程度完了していることが前提です。

必要な情報が揃っていない状態で無理に開始すると、品質低下や作業のやり直しにつながります。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、PDM（プレシデンスダイアグラム法）やネットワーク図において、リードとラグの意味や使い分けが問われることがあります。

また、午後試験では、納期短縮のために並行作業を取り入れた理由や、その際のリスク管理について説明できることが重要です。

PM道場のワンポイント

リードは「時間を短縮する技術」ではなく、「リスクを引き受ける判断」です。実務では、「納期が厳しいから並行作業にしよう」という判断をすることがあります。しかし、リードを設定するということは、「前工程で変更が発生したら、後工程の手戻りを受け入れる」という意思決定でもあります。

例えば、設計途中で開発を始めれば、設計変更が発生した際に開発済みのプログラムを修正しなければならないかもしれません。

優れたプロジェクトマネージャは、単にスケジュールを短縮するのではなく、短縮によって増えるリスクと納期短縮の効果を比較して判断しています。

リードは「早く始める技術」ではなく、「リスクをコントロールしながら早く進める考え方」です。

関連用語

• ラグ
• アクティビティ
• PDM（プレシデンスダイアグラム法）
• クリティカルパス
• フロート
• ガントチャート
• ファストトラッキング
• クラッシング

まとめ

リードとは、前工程が完全に終了する前に後続作業を開始できる時間のことです。

適切に活用することで、プロジェクト全体の期間を短縮できますが、同時に手戻りのリスクも高まります。

重要なのは、納期短縮だけを見るのではなく、品質やリスクとのバランスを考えながらリードを活用することです。

関連記事

• ラグとは？
• クリティカルパスとは？
• PDMとは？
• アクティビティとは？

よくある質問（FAQ）

Q. リードとは何ですか？

A. 前工程が完了する前に、後続作業を前倒しで開始できる時間のことです。

Q. リードとラグの違いは何ですか？

A. リードは後続作業を早く開始する時間、ラグは一定時間待ってから開始する時間です。

Q. リードを設定するメリットは何ですか？

A. プロジェクト全体の期間を短縮できることです。ただし、設計変更などによる手戻りリスクも考慮する必要があります。

The post リード（Lead）とは？ラグとの違いや意味を初心者向けにわかりやすく解説 first appeared on PM道場.