アローダイアグラムにおけるクリティカルパスの計算 – IPA午前Ⅱ対策

Tech
<!--
{
  "title": "アローダイアグラムにおけるクリティカルパスの計算 - IPA午前Ⅱ対策",
  "primary_category": "プロジェクトマネジメント",
  "secondary_categories": [
    "スケジュール管理",
    "システム開発"
  ],
  "tags": [
    "クリティカルパス",
    "アローダイアグラム",
    "IPA午前Ⅱ",
    "プロジェクトマネジメント",
    "最早開始時刻",
    "最遅完了時刻",
    "フロート"
  ],
  "summary": "IPA午前Ⅱ試験で頻出するアローダイアグラムを用いたクリティカルパスの計算方法について、具体的な手順と例題を通して解説します。プロジェクトの最短完了期間を特定し、遅延が許されない重要経路を理解するための基礎知識を提供します。",
  "mermaid": true,
  "verify_level": "未検証",
  "tweet_hint": "IPA午前Ⅱで頻出のクリティカルパス計算を解説!アローダイアグラムの読み解き方から最早・最遅時刻、フロートの計算まで、具体例でしっかり理解しよう。#IPA #プロジェクトマネジメント #クリティカルパス",
  "link_hints": [
    "PMBOK®ガイド",
    "情報処理技術者試験",
    "プロジェクトマネジメント知識体系"
  ]
}
-->

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。

アローダイアグラムにおけるクリティカルパスの計算 – IPA午前Ⅱ対策

プロジェクトの最短完了期間を特定し、遅延が許されない重要経路を見つけ出すクリティカルパスの計算は、IPA午前Ⅱ試験で頻出する要点です。

背景

プロジェクトマネジメントにおいて、スケジュールは成功を左右する重要な要素です。プロジェクトの納期を遵守し、リソースを効率的に配分するためには、各タスクの所要時間と依存関係を正確に把握し、全体の完了までの期間を予測する必要があります。アローダイアグラム(PERT図、CPM図とも呼ばれる)は、これらのタスクと依存関係を視覚的に表現し、プロジェクトのスケジュールを分析するための強力なツールです。特に、クリティカルパスの特定は、プロジェクト全体の遅延に直結するタスクを識別し、重点的に管理するために不可欠です。

IPA午前Ⅱにおける出題ポイント

IPA午前Ⅱ試験では、アローダイアグラムが提示され、それに基づいてプロジェクト全体の所要日数を算出したり、クリティカルパス上のアクティビティを特定したりする問題が出題されます。具体的には、以下の項目が問われる傾向にあります。

  • プロジェクトの最短完了期間の算出:順方向計算(最早時刻の計算)を正確に行い、最終ノードの最早完了時刻を特定する。

  • クリティカルパスの特定:フロート(余裕時間)がゼロとなる経路を識別する。

  • 最早開始時刻、最遅完了時刻、フロートの計算:各アクティビティにおけるこれらの値を算出する。

クリティカルパスの計算手順

クリティカルパスを特定するには、順方向計算と逆方向計算の2段階が必要です。

用語の定義

  • アクティビティ:プロジェクトを構成する個々の作業。アローダイアグラムでは矢印で表現されます。

  • 結合点(ノード):アクティビティの開始点と終了点。アローダイアグラムでは丸(イベント)で表現されます。

  • 最早開始時刻 (Early Start, ES):そのアクティビティが最も早く開始できる時刻。

  • 最早完了時刻 (Early Finish, EF):そのアクティビティが最も早く完了できる時刻。EF = ES + アクティビティ所要時間

  • 最遅完了時刻 (Late Finish, LF):プロジェクト全体の完了を遅らせることなく、そのアクティビティが最も遅く完了できる時刻。

  • 最遅開始時刻 (Late Start, LS):プロジェクト全体の完了を遅らせることなく、そのアクティビティが最も遅く開始できる時刻。LS = LF - アクティビティ所要時間

  • フロート (Float):そのアクティビティが遅れても、プロジェクト全体の完了に影響を与えない許容時間。フロート = LF - EF または フロート = LS - ES

  • クリティカルパス:フロートがゼロとなるアクティビティが連なる経路。この経路上のアクティビティに遅延が発生すると、プロジェクト全体の完了が遅延します。

例題のアローダイアグラム

以下のプロジェクトにおけるクリティカルパスと所要日数を求めます。 (矢印上の数値はアクティビティの所要日数を示します。)

graph TD
    1["開始"] --> |要件定義 (2日)| 2
    1 --> |設計 (3日)| 3
    2 --> |開発A("4日")| 4
    3 --> |開発A("4日")| 4
    3 --> |開発B("5日")| 5
    4 --> |テスト (2日)| 6["完了"]
    5 --> |テスト (2日)| 6

注釈:

  • ノード1: プロジェクト開始

  • アクティビティ「要件定義」: 所要日数2日

  • アクティビティ「設計」: 所要日数3日

  • ノード2: 「要件定義」完了

  • ノード3: 「設計」完了

  • アクティビティ「開発A」: 所要日数4日(「要件定義」と「設計」の両方が完了後開始可能)

  • アクティビティ「開発B」: 所要日数5日(「設計」完了後開始可能)

  • ノード4: 「開発A」完了

  • ノード5: 「開発B」完了

  • アクティビティ「テスト」: 所要日数2日(「開発A」と「開発B」の両方が完了後開始可能)

  • ノード6: プロジェクト完了

1. 最早時刻の順方向計算(開始から終了へ)

各結合点について、最早完了時刻を計算します。結合点に複数の経路が到達する場合、最も遅い完了時刻を採用します。

  • ノード1 (開始): 最早完了時刻 = 0日

  • ノード2 (要件定義完了):

    • 経路1→2 (要件定義): 0日 (ノード1) + 2日 (要件定義) = 2日
  • ノード3 (設計完了):

    • 経路1→3 (設計): 0日 (ノード1) + 3日 (設計) = 3日
  • ノード4 (開発A完了):

    • 経路2→4 (開発A): 2日 (ノード2) + 4日 (開発A) = 6日

    • 経路3→4 (開発A): 3日 (ノード3) + 4日 (開発A) = 7日

    • 複数の経路が合流する場合、最も遅い完了時刻を採用するため、ノード4の最早完了時刻は 7日

  • ノード5 (開発B完了):

    • 経路3→5 (開発B): 3日 (ノード3) + 5日 (開発B) = 8日
  • ノード6 (テスト完了 / プロジェクト完了):

    • 経路4→6 (テスト): 7日 (ノード4) + 2日 (テスト) = 9日

    • 経路5→6 (テスト): 8日 (ノード5) + 2日 (テスト) = 10日

    • 複数の経路が合流する場合、最も遅い完了時刻を採用するため、ノード6の最早完了時刻は 10日

プロジェクト全体の最短完了期間は 10日 です。

2. 最遅時刻の逆方向計算(終了から開始へ)

プロジェクトの最終結合点(ノード6)の最遅完了時刻を、順方向計算で求めたプロジェクト完了期間(10日)とします。そこから逆算して、各結合点の最遅開始時刻を計算します。結合点から複数の経路が出発する場合、最も早い開始時刻を採用します。

  • ノード6 (完了): 最遅開始時刻 = 10日 (最遅完了時刻)

  • ノード5 (開発B完了):

    • 経路5→6 (テスト): 10日 (ノード6最遅開始) – 2日 (テスト) = 8日
  • ノード4 (開発A完了):

    • 経路4→6 (テスト): 10日 (ノード6最遅開始) – 2日 (テスト) = 8日
  • ノード3 (設計完了):

    • 経路3→4 (開発A): 8日 (ノード4最遅開始) – 4日 (開発A) = 4日

    • 経路3→5 (開発B): 8日 (ノード5最遅開始) – 5日 (開発B) = 3日

    • 複数の経路が出発する場合、最も早い開始時刻を採用するため、ノード3の最遅開始時刻は 3日

  • ノード2 (要件定義完了):

    • 経路2→4 (開発A): 8日 (ノード4最遅開始) – 4日 (開発A) = 4日
  • ノード1 (開始):

    • 経路1→2 (要件定義): 4日 (ノード2最遅開始) – 2日 (要件定義) = 2日

    • 経路1→3 (設計): 3日 (ノード3最遅開始) – 3日 (設計) = 0日

    • 複数の経路が出発する場合、最も早い開始時刻を採用するため、ノード1の最遅開始時刻は 0日

3. フロートの計算とクリティカルパスの特定

各アクティビティのフロートを計算し、フロートがゼロとなる経路をクリティカルパスとして特定します。

アクティビティ 所要時間 最早開始(ES) 最早完了(EF) 最遅開始(LS) 最遅完了(LF) フロート (LS-ES または LF-EF)
要件定義 (1→2) 2日 0日 2日 2日 4日 2日
設計 (1→3) 3日 0日 3日 0日 3日 0日
開発A (2/3→4) 4日 3日 7日 4日 8日 1日
開発B (3→5) 5日 3日 8日 3日 8日 0日
テスト (4/5→6) 2日 8日 10日 8日 10日 0日

上記の表から、フロートがゼロとなるアクティビティは「設計 (1→3)」「開発B (3→5)」「テスト (5→6)」です。

したがって、クリティカルパスは、 「開始 (ノード1) → 設計 (3日) → 開発B (5日) → テスト (2日) → 完了 (ノード6)」 であり、この経路の合計所要日数は 3 + 5 + 2 = 10日 です。

要点

  • クリティカルパスは、プロジェクトの最短完了期間を決定する最も長い経路です。

  • クリティカルパス上のアクティビティは、一切の遅延が許されません。遅延するとプロジェクト全体の完了が遅れます。

  • クリティカルパスの特定には、最早時刻を求める順方向計算と、最遅時刻を求める逆方向計算が必要です。

  • フロート(余裕時間)がゼロとなるアクティビティがクリティカルパスを構成します。

  • アローダイアグラムのノードに複数のアクティビティが合流する場合、最早時刻は最大値を、最遅時刻は最小値を採用します。

ライセンス:本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました