「立上げ、計画、実行、監視・コントロール、終結とは何が違うのだろう？」

プロジェクトマネジメントを学んでいると、プロセス群（Process Groups）という言葉が登場します。

プロセス群とは、プロジェクトマネジメントのプロセスを、プロジェクトを進めるうえでの役割や目的によって分類したものです。

PMBOK^®第6版では、プロジェクトマネジメントのプロセスを次の5つのプロセス群に分類していました。

• 立上げプロセス群
• 計画プロセス群
• 実行プロセス群
• 監視・コントロール・プロセス群
• 終結プロセス群

この記事では、5つのプロセス群の意味や関係、第7版以降との違いについて解説します。

一言でいうと

プロセス群とは、プロジェクトマネジメントのプロセスを、その目的や役割によって分類したグループです。

PMBOK^®第6版では、49のプロジェクトマネジメント・プロセスを5つのプロセス群に分類していました。

プロセス群とは

プロジェクトでは、プロジェクトを開始するだけでなく、計画を立て、作業を実行し、状況を確認・調整し、最後にプロジェクトを終了させる必要があります。

これらの活動を整理したものがプロセス群です。

5つのプロセス群を簡単に表すと、次のようになります。

イメージとしては、

「始める → 計画する → 実行する → 確認・調整する → 終わらせる」

という流れで考えると分かりやすいでしょう。

5つのプロセス群

1．立上げプロセス群

立上げプロセス群は、プロジェクトやフェーズを正式に開始するためのプロセス群です。

プロジェクトの目的や概要を確認し、プロジェクトを正式に開始します。

代表的な活動として、プロジェクト・チャーターの作成やステークホルダーの特定などがあります。

つまり、

「そもそも、このプロジェクトを始めてよいのか。そして、誰が関係するのか」

を明確にする段階です。

2．計画プロセス群

計画プロセス群は、プロジェクトの目標を達成するために、どのようにプロジェクトを進めるのかを決めるプロセス群です。

例えば、次のような計画を作成します。

• スコープ
• スケジュール
• コスト
• 品質
• 資源
• コミュニケーション
• リスク
• 調達
• ステークホルダー

プロジェクトを成功させるための「設計図」を作る段階と考えると分かりやすいでしょう。

3．実行プロセス群

実行プロセス群は、プロジェクトマネジメント計画書に基づいてプロジェクト作業を実施するプロセス群です。

例えば、

• 成果物を作成する
• チームをマネジメントする
• コミュニケーションを実施する
• 品質を保証する
• ステークホルダーと関係を築く
• 調達を実施する

といった活動を行います。

計画を実際の行動に移す段階です。

4．監視・コントロール・プロセス群

監視・コントロール・プロセス群は、プロジェクトの進捗や実績を確認し、必要に応じて是正措置や変更を行うプロセス群です。

例えば、

• スケジュールの遅延を確認する
• コストの超過を確認する
• 品質を確認する
• リスクや課題を監視する
• 変更要求を評価する
• 必要な是正措置を行う

といった活動を行います。

ここで重要なのは、監視・コントロールは「実行が終わってから行うもの」ではないということです。

実行と並行して継続的に行われることがポイントです。

5．終結プロセス群

終結プロセス群は、プロジェクトやフェーズを正式に終了するためのプロセス群です。

成果物を正式に受け入れてもらい、契約を完了し、プロジェクトの記録を整理するなど、プロジェクトを終了するための活動を行います。

また、プロジェクトで得られた教訓を整理し、組織の将来のプロジェクトに活用できるようにすることも重要です。

5つのプロセス群の関係

5つのプロセス群は、単純に一方向へ進むだけではありません。

特に重要なのが、監視・コントロール・プロセス群が、プロジェクトの実行と並行して行われるという点です。

例えば、計画に基づいてプロジェクトを実行しているときに、スケジュールの遅延が発生したとします。

監視・コントロールによって遅延を把握し、原因を分析します。

その結果、計画を変更する必要があれば、変更要求を行い、承認された変更を計画に反映して実行します。

つまり、

計画 → 実行 → 監視・コントロール → 必要に応じて計画や実行を調整

という循環が発生します。

プロセス群と知識エリアの違い

PMBOK^®第6版を理解するうえで、プロセス群と知識エリアの違いを理解しておくことが重要です。

例えば、「リスク・マネジメント」という知識エリアの中にも、計画、実行、監視・コントロールなど、複数のプロセス群にまたがるプロセスがあります。

したがって、

プロセス群＝「いつ・どのような目的で行うプロセスなのか」

知識エリア＝「何について管理するプロセスなのか」

と考えると整理しやすくなります。

プロセス群と第7版の違い

ここは現在のPMBOK^®を学ぶ際に注意が必要なポイントです。

PMBOK^®第6版では、プロジェクトマネジメントを49のプロセスと5つのプロセス群、10の知識エリアという構造で整理していました。

一方、第7版では、プロセス中心の構成から、プロジェクトマネジメントの原則とパフォーマンス領域を中心とした構成へ大きく変わりました。

そのため、現在のPMBOK^®を学ぶ場合には、「5つのプロセス群＝現在のPMBOK^®の中心的な構成」と考えないことが重要です。

ただし、プロジェクトマネジメントの基本的な流れを理解するうえでは、5つのプロセス群は現在でも非常に分かりやすい考え方です。

プロセス群を覚えるポイント

5つのプロセス群は、次の順番で覚えると分かりやすいでしょう。

立上げ → 計画 → 実行 → 監視・コントロール → 終結

ただし、「監視・コントロール」は実行後に一度だけ行うものではありません。

実際には、プロジェクトの実行中に継続して状況を監視し、必要に応じて調整します。

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

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

まず、プロジェクトの目的や関係者を整理し、正式にプロジェクトを開始します。

次に、必要な機能、スケジュール、予算、リスクなどを計画します。

その後、実際に開発作業を進めます。

実行中は、進捗やコスト、品質などを確認し、計画との差異があれば必要な対応を行います。

最終的に成果物が受け入れられ、必要な手続きを終えたら、プロジェクトを正式に終了します。

この一連の流れを整理するための考え方がプロセス群です。

よくある勘違い

プロセス群は必ず順番に一度ずつ実施するものではない

5つのプロセス群は、プロジェクトを理解するための分類です。

特に実行と監視・コントロールは並行して行われ、必要に応じて計画を見直すこともあります。

監視・コントロールは問題が起きたときだけ行うものではない

監視・コントロールは、プロジェクトの状況を継続的に確認する活動です。

問題が起きてから確認するのではなく、計画との差異を早期に把握し、必要な対応を取ることが重要です。

プロセス群と知識エリアは同じではない

プロセス群はプロセスの目的・役割による分類であり、知識エリアはプロジェクトマネジメントの専門領域による分類です。

両者を混同しないように注意しましょう。

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

プロジェクトマネージャ試験でPMBOK^®の考え方を理解する際には、5つのプロセス群を単なる暗記項目として覚えるのではなく、それぞれの役割を理解することが重要です。

• 立上げ＝プロジェクトを正式に開始する
• 計画＝プロジェクトの進め方を決める
• 実行＝計画に基づいて作業を行う
• 監視・コントロール＝実績を確認し、必要に応じて調整する
• 終結＝プロジェクトやフェーズを正式に終了する

特に、「監視・コントロールは実行と並行して行われる」という点は重要です。

PM道場のワンポイント

プロセス群は「プロジェクトをどのように動かしていくのか」を理解するための地図です。

実務では、計画を作ったらそのまま計画どおりに進むとは限りません。

実行してみると問題が発生し、監視・コントロールによってその問題を発見し、計画を修正することがあります。

そのため、プロセス群を、

「立上げ → 計画 → 実行 → 終結」という一本道

ではなく、

「計画して、実行して、確認して、必要なら修正する」

という循環を含む仕組みとして理解することが重要です。

なお、PMBOK^®第7版では構成が大きく変わっているため、試験や実務で利用する際には、どの版の考え方を扱っているのかを確認するようにしましょう。

関連用語

• PMBOK^®ガイド
• 知識エリア
• プロジェクトマネジメント・プロセス
• プロジェクト・チャーター
• プロジェクトマネジメント計画書
• スコープ
• スケジュール
• コスト
• リスクマネジメント
• 変更要求
• 監視・コントロール
• 終結

まとめ

プロセス群とは、プロジェクトマネジメントのプロセスを、その目的や役割によって分類したものです。

PMBOK^®第6版では、次の5つのプロセス群に分類されていました。

• 立上げプロセス群
• 計画プロセス群
• 実行プロセス群
• 監視・コントロール・プロセス群
• 終結プロセス群

プロセス群を理解すると、プロジェクトマネジメントの活動を「プロジェクトのどの段階で、何のために行うのか」という視点から整理できます。

特に重要なのは、監視・コントロールが実行後に行われるのではなく、プロジェクトの実行と並行して継続的に行われるということです。

また、PMBOK^®第7版では構成が大きく変更されているため、5つのプロセス群は主に第6版までのプロセス中心の考え方として理解しておくとよいでしょう。

関連記事

• PMBOK^®ガイドとは？
• 知識エリアとは？
• プロジェクト・チャーターとは？
• プロジェクトマネジメント計画書とは？
• スコープとは？
• スケジュールとは？
• コストとは？
• リスクマネジメントとは？
• 変更要求とは？
• 終結とは？

よくある質問（FAQ）

Q. プロセス群とは何ですか？

A. プロジェクトマネジメントのプロセスを、その目的や役割によって分類したグループです。PMBOK^®第6版では、立上げ、計画、実行、監視・コントロール、終結の5つに分類されていました。

Q. 5つのプロセス群とは何ですか？

A. 立上げプロセス群、計画プロセス群、実行プロセス群、監視・コントロール・プロセス群、終結プロセス群の5つです。

Q. プロセス群と知識エリアの違いは何ですか？

A. プロセス群はプロセスの目的・役割による分類で、知識エリアはスコープ、スケジュール、コスト、リスクなど、プロジェクトマネジメントの専門領域による分類です。

Q. 監視・コントロール・プロセス群はいつ行いますか？

A. プロジェクトの実行と並行して継続的に行います。プロジェクトの実績を確認し、計画との差異があれば必要な対応や調整を行います。

Q. PMBOK^®第7版にも5つのプロセス群がありますか？

A. PMBOK^®第7版では、第6版までのプロセス中心の構成から、原則やパフォーマンス領域を中心とした構成へ大きく変更されています。そのため、第6版までの5つのプロセス群を現在のPMBOK^®の中心的な構成として扱うことは適切ではありません。

The post プロセス群とは？5つのプロセス群をわかりやすく解説 first appeared on PM道場.

「少し修正するだけなので、すぐ終わりますよね？」

プロジェクトでは、このような追加要望が出ることは珍しくありません。

一つひとつは小さな変更でも、正式な変更管理を行わずに積み重なると、納期遅延やコスト超過、品質低下につながることがあります。

この現象をスコープクリープ（Scope Creep）と呼びます。

この記事では、スコープクリープの意味や発生原因、防止方法までわかりやすく解説します。

一言でいうと

スコープクリープとは、「正式な変更管理を行わないまま、プロジェクトの作業範囲が少しずつ増えてしまう現象」のことです。

スコープクリープとは

スコープクリープとは、プロジェクト開始時に合意したスコープを超える作業が、正式な承認や影響分析を行わずに追加されることです。

追加される内容は小さなものが多いため、最初は大きな問題に見えません。

しかし、それが積み重なることで、プロジェクト全体へ大きな影響を及ぼします。

PMBOK®では、スコープクリープはスコープマネジメント上の代表的なリスクとして扱われています。

スコープクリープの具体例

例えば、システム開発で次のような依頼があったとします。

• ボタンの色を変更してほしい
• 検索条件を一つ追加してほしい
• CSV出力もできるようにしてほしい
• マニュアルも少し修正してほしい

それぞれは数時間程度の作業かもしれません。

しかし、このような変更が何十件も積み重なると、数週間分の追加工数になることもあります。

これがスコープクリープです。

スコープクリープが発生する原因

• スコープが曖昧なままプロジェクトを開始した
• 「これくらいなら」と安易に追加要求を受け入れた
• 変更管理プロセスが機能していない
• ステークホルダー間で認識が一致していない
• 要件定義が十分に行われていない

スコープクリープがもたらす影響

• 納期遅延
• コスト超過
• 品質低下
• メンバーの負荷増加
• ステークホルダーとの信頼低下

特に問題なのは、「誰も悪意なく追加している」というケースが多いことです。

変更管理との違い

つまり、変更そのものが悪いのではありません。

問題なのは、「変更を管理していないこと」です。

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

例えば、顧客から「この項目を追加してほしい」という要望があったとします。

その場で対応を約束するのではなく、追加工数や納期への影響を確認し、関係者と協議した上で正式な変更として扱うことが重要です。

このプロセスを徹底することで、スコープクリープを防ぐことができます。

よくある勘違い

追加要求を断れば良いわけではない

顧客の要望には、プロジェクトの価値を高める重要な提案が含まれていることもあります。

重要なのは、「受け入れるか断るか」ではなく、「影響を評価して判断すること」です。

変更があるプロジェクトは失敗ではない

プロジェクトでは変更が発生すること自体は自然なことです。

変更を適切に管理できていれば、それはスコープクリープではありません。

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

IPAのプロジェクトマネージャ試験では、スコープクリープを防ぐための変更管理やステークホルダーとの合意形成が重要なテーマです。

午後試験では、「追加要求に対してどのような影響分析を行い、どのように関係者と合意形成したか」を説明できることが求められます。

「変更を防ぐ」のではなく、「変更を適切に管理する」という考え方を理解しておきましょう。

PM道場のワンポイント

スコープクリープは、「大きな追加要求」ではなく、「小さな親切」の積み重ねから始まります。「これくらいなら無料で対応します。」「今回は特別です。」

このような善意が、気付かないうちにプロジェクトを苦しめることがあります。

優れたプロジェクトマネージャは、追加要求をすぐに断るのではなく、「どんな影響があるか」を見える化し、関係者と共有します。

スコープクリープを防ぐ秘訣は、変更を拒否することではなく、変更を”見える化”して管理することです。

関連用語

• スコープ
• スコープマネジメント
• 変更管理
• 要求事項
• WBS
• ベースライン
• ステークホルダー
• プロジェクト憲章

まとめ

スコープクリープとは、正式な変更管理を行わないまま、プロジェクトの作業範囲が少しずつ増えていく現象です。

一つひとつの変更は小さくても、積み重なることで納期遅延やコスト超過、品質低下につながる可能性があります。

重要なのは、変更を避けることではなく、影響を評価し、関係者と合意した上で適切に管理することです。

関連記事

• スコープとは？
• スコープマネジメントとは？
• 変更管理とは？
• WBSとは？

よくある質問（FAQ）

Q. スコープクリープとは何ですか？

A. 正式な変更管理を行わないまま、プロジェクトの作業範囲が少しずつ増えてしまう現象です。

Q. 変更管理との違いは何ですか？

A. 変更管理は影響分析や承認を行った上で変更を実施しますが、スコープクリープはそれらを行わずに変更が進んでしまう点が異なります。

Q. スコープクリープを防ぐにはどうすれば良いですか？

A. スコープを明確に定義し、追加要求が発生した際は、影響分析・関係者への説明・正式な承認を経て変更管理を行うことが重要です。

The post スコープクリープ（Scope Creep）とは？発生原因や防止方法を初心者向けにわかりやすく解説 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道場.

特に期間の長いプロジェクトや、不確実性の高いプロジェクトでは、後半の作業内容がまだ決まっていないことも多くあります。

そのような場合に活用されるのがローリングウェーブ計画法（Rolling Wave Planning）です。

この記事では、ローリングウェーブ計画法の意味や考え方、実務での活用方法までわかりやすく解説します。

一言でいうと

ローリングウェーブ計画法とは、「近い将来は詳細に、遠い将来は大まかに計画し、進捗に合わせて計画を詳細化していく手法」です。

ローリングウェーブ計画法とは

ローリングウェーブ計画法は、プロジェクトの開始時点ですべてを詳細に計画するのではなく、直近の作業だけを詳細化し、将来の作業は概要レベルで計画しておく手法です。

プロジェクトが進み、情報が増えるにつれて、後半の計画を徐々に具体化していきます。

PMBOK®では、この考え方を「段階的詳細化（Progressive Elaboration）」を実現する代表的な計画手法として紹介しています。

なぜローリングウェーブ計画法が必要なのか

例えば、1年後に実施するテスト工程を、プロジェクト開始日に詳細まで決めても、その頃には要件や設計が変わっている可能性があります。

最初から細かく計画すると、何度も計画を作り直すことになり、かえって非効率です。

そこで、近い将来だけを詳細に計画し、状況に応じて計画を更新していくことで、現実的なプロジェクト運営が可能になります。

ローリングウェーブ計画法のイメージ

プロジェクトが進むにつれて、概要計画だった部分を順番に詳細化していきます。

メリット

• 不確実性の高いプロジェクトへ対応しやすい
• 最新情報を反映した現実的な計画を作成できる
• 計画の作り直しを減らせる
• 見積もり精度が向上する

デメリット

• 計画を定期的に見直す手間がかかる
• 関係者との合意形成を繰り返す必要がある
• 後半の予算やリソースが確定しにくい場合がある

アジャイルとの違い

ローリングウェーブ計画法はアジャイル専用ではありません。

ウォーターフォール型プロジェクトでも、不確実性が高い部分については広く活用されています。

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

例えば、新しい業務システムを開発するプロジェクトでは、要件定義や基本設計は詳細に計画できます。

しかし、運用テストや教育計画は、システムの完成度や利用部門との調整状況によって内容が変わることがあります。

そのため、初期段階では概要だけを計画し、プロジェクトが進んだ段階で詳細なアクティビティへ分解します。

このように、情報が増えるタイミングに合わせて計画を具体化することが、ローリングウェーブ計画法の考え方です。

よくある勘違い

最初は計画しなくても良いという意味ではない

ローリングウェーブ計画法では、後半を「計画しない」のではなく、「概要レベルで計画する」ことが重要です。

全体像がないまま進めることとは異なります。

計画変更を繰り返すことが目的ではない

計画を頻繁に変更することではなく、情報が増えたタイミングで計画の精度を高めることが目的です。

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

IPAのプロジェクトマネージャ試験では、不確実性への対応や計画策定の考え方として、ローリングウェーブ計画法が出題されることがあります。

午後試験では、「情報が不足している状況でどのように計画を立てたか」「段階的に詳細化した理由」を説明できることが重要です。

「最初から完璧な計画は作れない」という前提を理解しておきましょう。

PM道場のワンポイント

ローリングウェーブ計画法は「計画不足」ではなく、「計画の成熟」です。実務では、「全部決まっていないから計画が甘い」と言われることがあります。しかし、本当に重要なのは、今分かる範囲で最も精度の高い計画を立てることです。

未来の不確実な内容まで無理に詳細化すると、変更のたびに計画を作り直すことになります。

優れたプロジェクトマネージャは、「今決めるべきこと」と「後で決めるべきこと」を意識して計画を作成しています。

計画とは、一度作って終わりではなく、プロジェクトの成長とともに育てていくものです。

関連用語

• WBS
• アクティビティ
• スケジュールベースライン
• テーラリング
• プロジェクトライフサイクル
• アジャイル
• ウォーターフォール
• 段階的詳細化（Progressive Elaboration）

まとめ

ローリングウェーブ計画法とは、近い将来は詳細に、遠い将来は概要レベルで計画し、状況に応じて段階的に詳細化していく計画手法です。

不確実性が高いプロジェクトでも、現実的で柔軟な計画を立てられることが大きな特徴です。

重要なのは、「最初から完璧な計画を作ること」ではなく、「必要なタイミングで計画の精度を高めること」です。

関連記事

• WBSとは？
• アクティビティとは？
• スケジュールベースラインとは？
• テーラリングとは？

よくある質問（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道場.

しかし、中には数日遅れてもプロジェクト全体へ影響しない作業もあります。

その「遅れても許容される時間」を表すのがフロート（Float）です。

フロートを理解すると、どの作業を優先的に管理すべきかが分かり、限られたリソースを効率よく活用できるようになります。

この記事では、フロートの意味や種類、クリティカルパスとの関係、実務での活用方法までわかりやすく解説します。

一言でいうと

フロートとは、「ある作業が遅れても、プロジェクト全体や後続作業へ影響しない範囲の余裕時間」のことです。

フロートとは

フロート（Float）は、アクティビティを予定より遅らせても、プロジェクト全体や後続作業へ影響を与えない余裕時間を表します。

プロジェクトマネジメントでは、スケジュールにどれだけの余裕があるかを把握する重要な指標として利用されます。

フロートがあることで、多少の遅れが発生しても、すぐにプロジェクト全体へ影響するわけではありません。

フロートが重要な理由

プロジェクトでは、すべての作業を同じ優先度で管理することは現実的ではありません。

フロートを把握することで、「余裕のある作業」と「今すぐ対応が必要な作業」を判断できます。

また、リソース不足が発生した場合にも、フロートの大きい作業を調整することで、プロジェクト全体への影響を最小限に抑えられます。

フロートの種類

トータルフロート（Total Float）

プロジェクト全体の完了日に影響を与えずに遅らせることができる余裕時間です。

例えば、トータルフロートが3日であれば、その作業は3日遅れてもプロジェクト全体の納期は変わりません。

フリーフロート（Free Float）

後続のアクティビティへ影響を与えずに遅らせることができる余裕時間です。

トータルフロートよりも短くなることが一般的です。

クリティカルパスとの関係

クリティカルパス上のアクティビティは、通常トータルフロートが0日です。

そのため、1日でも遅れるとプロジェクト全体の完了日が遅れる可能性があります。

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

例えば、同じ担当者が2つの作業を抱えているとします。

一方はクリティカルパス上でフロートが0日、もう一方はフロートが4日あります。

この場合は、クリティカルパス上の作業を優先し、もう一方の作業を数日後ろへずらしてもプロジェクト全体への影響はありません。

このように、フロートはリソース調整や優先順位の判断に活用されます。

よくある勘違い

フロートは「自由時間」ではない

フロートがあるからといって、何もしなくてよい期間ではありません。

あくまでスケジュール上の余裕時間であり、使い切ることを前提に計画するものではありません。

フロートは常に一定ではない

プロジェクトが進むと、進捗や計画変更によってフロートは変化します。

定期的にスケジュールを見直し、最新のフロートを確認することが重要です。

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

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

午前試験では計算問題として、午後試験ではフロートを活用したスケジュール調整やリソース配分について問われることがあります。

「フロート＝余裕時間」「クリティカルパス上はフロートが0日」という基本を理解しておくことが重要です。

PM道場のワンポイント

フロートは「使うための余裕」ではなく、「守るための余裕」です。実務では、「まだフロートがあるから大丈夫」と考えてしまうことがあります。しかし、フロートは予期しないトラブルへ対応するための保険です。

予定どおりに使い切ってしまうと、その後に問題が発生したとき、プロジェクト全体へ影響が及びます。

優れたプロジェクトマネージャは、フロートを積極的に消費するのではなく、「できるだけ残す」ことを意識しています。

フロートは余裕ではなく、プロジェクトの安全マージンと考えることが重要です。

関連用語

• クリティカルパス
• アクティビティ
• PDM（プレシデンスダイアグラム法）
• ネットワーク図
• ガントチャート
• スケジュールベースライン
• 進捗管理
• リソース平準化

まとめ

フロートとは、作業が遅れてもプロジェクト全体や後続作業へ影響しない余裕時間のことです。

フロートを把握することで、優先順位の判断やリソース調整がしやすくなり、プロジェクトを効率的に運営できます。

重要なのは、フロートを「使い切る余裕」ではなく、「プロジェクトを守るための安全マージン」と考えることです。

関連記事

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

よくある質問（FAQ）

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

A. 作業が遅れても、プロジェクト全体や後続作業へ影響しない範囲の余裕時間です。

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

A. クリティカルパス上の作業は、通常トータルフロートが0日であり、遅れるとプロジェクト全体の納期へ直接影響します。

Q. トータルフロートとフリーフロートの違いは何ですか？

A. トータルフロートはプロジェクト全体へ影響しない余裕時間、フリーフロートは後続作業へ影響しない余裕時間です。

The post フロートとは？クリティカルパスとの違いや意味を初心者向けにわかりやすく解説 first appeared on PM道場.

すべての作業が同じ重要度ではなく、中には1日遅れただけでプロジェクト全体の完了日が遅れてしまう作業もあります。

そのような作業のつながりを表したものが「クリティカルパス」です。

この記事では、クリティカルパスの意味や考え方、実務での活用方法までわかりやすく解説します。

一言でいうと

クリティカルパスとは、「プロジェクト全体の完了日を決める、最も時間がかかる作業の経路」のことです。

クリティカルパスとは

クリティカルパス（Critical Path）は、プロジェクト開始から終了までの作業の中で、最も長い所要期間となる作業の経路です。

この経路上にあるアクティビティが1日でも遅れると、プロジェクト全体の完了日も同じだけ遅れます。

そのため、プロジェクトマネージャはクリティカルパス上の作業を特に注意して管理する必要があります。

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

例えば、次のようなプロジェクトがあるとします。

この場合、最も長い経路である「A → B → C → E → F」がクリティカルパスになります。

なぜクリティカルパスが重要なのか

プロジェクトでは、すべての作業を同じように管理することは現実的ではありません。

クリティカルパスを把握することで、納期に直接影響する作業へ優先的にリソースを投入できます。

また、遅延が発生した際にも、どの作業を優先して対策すべきかを迅速に判断できます。

フロート（余裕時間）との関係

クリティカルパス上のアクティビティには、原則としてフロート（余裕時間）がありません。

一方、クリティカルパス以外の作業には、多少遅れてもプロジェクト全体へ影響しない余裕時間が存在する場合があります。

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

例えば、開発工程で担当者が体調不良になり、予定より3日遅れることが分かったとします。

その作業がクリティカルパス上であれば、追加メンバーを投入したり、他の作業を並行化したりするなど、早急な対応が必要になります。

一方で、フロートが十分にある作業であれば、プロジェクト全体への影響は限定的です。

このように、クリティカルパスを把握することで、限られたリソースを効果的に活用できます。

よくある勘違い

一番難しい作業がクリティカルパスではない

クリティカルパスは「難易度」ではなく、「完了日へ与える影響」で決まります。

簡単な作業でも、クリティカルパス上にあれば最重要管理対象になります。

クリティカルパスは一度決めたら変わらない

プロジェクトが進むと、進捗や計画変更によってクリティカルパスが変わることがあります。

そのため、定期的に見直すことが重要です。

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

IPAのプロジェクトマネージャ試験では、ネットワーク図やPDMを用いたクリティカルパスの計算問題が午前試験で頻出です。

また、午後試験では、クリティカルパスを意識したスケジュール短縮やリソース調整について問われることがあります。

「クリティカルパス＝納期を決める経路」であることを理解しておくことが重要です。

PM道場のワンポイント

クリティカルパスは「遅れてはいけない作業」ではなく、「最も早く異常を検知すべき作業」です。実務では、「クリティカルパスだから毎日進捗確認しよう」と考えがちです。もちろん重要ですが、それ以上に大切なのは、「遅れそう」という前兆をいち早く捉えることです。

例えば、「レビュー担当者が多忙で日程が決まらない」「必要な環境がまだ準備できていない」といった小さな兆候は、将来の遅延につながる可能性があります。

優れたプロジェクトマネージャは、クリティカルパスそのものではなく、その前兆を管理しています。

問題が発生してから対応するのではなく、問題になりそうな兆候を管理することが、納期を守る最大のポイントです。

関連用語

• アクティビティ
• ガントチャート
• PDM（プレシデンスダイアグラム法）
• ネットワーク図
• フロート
• マイルストーン
• スケジュールベースライン
• 進捗管理

まとめ

クリティカルパスとは、プロジェクト全体の完了日を決定する最も長い作業経路です。

この経路上のアクティビティが遅れると、プロジェクト全体の納期にも直接影響します。

そのため、クリティカルパスを把握し、遅延の前兆を早期に発見・対応することが、プロジェクト成功の重要なポイントになります。

関連記事

• アクティビティとは？
• ガントチャートとは？
• マイルストーンとは？
• PDMとは？

よくある質問（FAQ）

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

A. プロジェクト全体の完了日を決める、最も所要期間が長い作業経路のことです。

Q. クリティカルパス上の作業が遅れるとどうなりますか？

A. 原則として、その遅れだけプロジェクト全体の完了日も遅れます。

Q. クリティカルパスは途中で変わることがありますか？

A. はい。進捗状況や計画変更、リソース調整などによって変化するため、定期的な見直しが必要です。

The post クリティカルパスとは？意味や求め方を初心者向けにわかりやすく解説 first appeared on PM道場.

「タスクと何が違うの？」「WBSとの関係は？」と疑問に思う方も多いのではないでしょうか。

アクティビティは、スケジュールを作成し、進捗を管理するための最小単位となる重要な要素です。

この記事では、アクティビティの意味や役割、WBSやタスクとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

アクティビティとは、「成果物を完成させるために実施する具体的な作業」のことです。

アクティビティとは

アクティビティ（Activity）は、プロジェクトで成果物を作るために実施する具体的な作業を指します。

PMBOK®では、WBSで定義したワークパッケージをさらに細分化し、スケジュールを作成するための作業単位として定義されています。

アクティビティには開始日・終了日・担当者・所要期間などを設定し、スケジュール管理の基礎となります。

アクティビティが重要な理由

WBSだけでは、「何を成果物として作るか」は整理できますが、「どのような作業を行うか」までは分かりません。

そこで、ワークパッケージをアクティビティへ分解することで、期間の見積もりや担当者の割り当て、進捗管理が可能になります。

つまり、アクティビティはガントチャートやネットワーク図を作成するための基礎データになります。

アクティビティの具体例

例えば、「基本設計書を作成する」という成果物がある場合、次のようなアクティビティに分解できます。

このように、「成果物を完成させるための具体的な行動」がアクティビティです。

WBS・ワークパッケージとの関係

WBSで「何を作るか」を整理し、アクティビティで「どのように作るか」を明確にします。

アクティビティとタスクの違い

実務では「アクティビティ」と「タスク」を同じ意味で使うことも少なくありません。

ただし、PMBOK®では「アクティビティ」が正式な用語であり、スケジュール作成の対象となる具体的な作業を指します。

一方、「タスク」は一般的な業務や作業を表す幅広い言葉として使われることが多く、厳密な定義は組織やツールによって異なります。

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

例えば、「テスト実施」というワークパッケージだけでは、担当者は何から始めればよいのか分かりません。

そこで、「テストケース作成」「テスト実施」「不具合確認」「再テスト」といったアクティビティへ分解することで、見積もりや進捗管理がしやすくなります。

また、アクティビティ同士の前後関係を整理することで、クリティカルパスの分析にも活用できます。

よくある勘違い

アクティビティは成果物ではない

アクティビティは「作業」であり、「成果物」ではありません。

成果物を完成させるための行動を表します。

細かく分解すれば良いわけではない

アクティビティを細かくしすぎると、管理コストが増えてしまいます。

担当者が見積もりや進捗管理を行える粒度にすることが重要です。

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

IPAのプロジェクトマネージャ試験では、WBSからアクティビティを定義し、所要期間や依存関係を整理してスケジュールを作成する流れを理解していることが重要です。

また、午前試験では、アクティビティ・ワークパッケージ・マイルストーンの違いが問われることがあります。

午後Ⅱ論文では、「どのように作業を分解し、進捗管理しやすい単位へ整理したか」を説明できると評価につながります。

PM道場のワンポイント

アクティビティは「作業の一覧」ではなく、「進捗を管理できる単位」です。実務では、「設計」「開発」「テスト」のように大きな作業だけでスケジュールを作ってしまうことがあります。しかし、それでは遅れが発生しても、「どこで止まっているのか」が分かりません。

例えば、「レビュー待ち」で止まっているのか、「修正中」なのかでは、必要な対応がまったく異なります。

優れたプロジェクトマネージャは、進捗を把握し、適切な判断ができる粒度までアクティビティを分解しています。

アクティビティを分解する目的は、作業を増やすことではなく、問題を早く見つけることです。

関連用語

• WBS
• ワークパッケージ
• ガントチャート
• マイルストーン
• クリティカルパス
• スケジュール
• 成果物（Deliverable）
• ベースライン

まとめ

アクティビティとは、成果物を完成させるために実施する具体的な作業のことです。

WBSで整理したワークパッケージをアクティビティへ分解することで、スケジュール作成や進捗管理、工数見積もりが可能になります。

重要なのは、管理しやすい粒度でアクティビティを定義し、プロジェクトの状況を正しく把握できるようにすることです。

関連記事

• WBSとは？
• ガントチャートとは？
• マイルストーンとは？
• 成果物（Deliverable）とは？

よくある質問（FAQ）

Q. アクティビティとは何ですか？

A. 成果物を完成させるために実施する具体的な作業のことです。スケジュール管理の基本単位として利用されます。

Q. アクティビティとタスクは同じですか？

A. 実務では同じ意味で使われることもありますが、PMBOK®ではアクティビティはスケジュール作成の対象となる具体的な作業として定義されています。

Q. アクティビティはどこまで細かく分解すればよいですか？

A. 担当者が期間を見積もり、進捗を報告できる程度の粒度が目安です。細かすぎると管理コストが増えるため、適切なバランスが重要です。

The post アクティビティとは？タスクとの違いや意味を初心者向けにわかりやすく解説 first appeared on PM道場.