• 戻る（PMP：計画）

• 後続の実行、監視・制御のプロセス群では、
  ココで決めた文書を使用して、プロジェクトの進捗状況を測定・評価する。

• 作業

  • スケジュール・マネジメント計画書を作成し、
  • WBS（PMP：計画 - 範囲の該当節を参照）を使用して、アクティビティを順番に並べ、
  • 実行に必要な資源（PMP：計画 - 資源）と時間を見積もり、
  • 最後に、プロジェクト・スケジュール, etc. を作成する。

表中で参照しているページは以下（元の PukiWiki ではセル内がリンクだった）。

• PMP：立上（プロジェクト憲章、前提条件ログ）
• PMP：計画（プロジェクト・マネジメント計画書）
• PMP：計画 - 範囲（スコープ・マネジメント計画書、スコープ・ベースライン、 プロジェクト・スコープ記述書）
• PMP：計画 - 原価（コスト・ベースライン）
• PMP：計画 - 資源（資源要求事項、資源カレンダー、見積根拠）
• PMP：計画 - リスク（リスク登録簿、RBS）
• PMP：環境（組織体の環境要因、組織のプロセス資産）
• PMP：実行（教訓登録簿）
• PMP：実行 - 資源（プロジェクト・チーム任命）
• PMP：監視・制御（プロジェクト・マネジメント情報システム（PMIS））

#	プロセス	インプット	ツールと技法	アウトプット	知識エリア
6	スケジュール・マネジメント計画	・プロジェクト憲章 ・プロジェクト・マネジメント計画書 　　★(p) スコープ・マネジメント計画書 　　★(p) 開発アプローチ ---------- ・組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ・データ分析 　　(p) 代替案生成 ・会議	★スケジュール・マネジメント計画書	プロジェクト・タイム・マネジメント
7	アクティビティ定義	(p) プロジェクト・マネジメント計画書 　　★スコープ・ベースライン 　　・スケジュール・マネジメント計画書 ---------- ・組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ★要素分解 ・ローリング・ウェーブ計画法 (p) 会議	★アクティビティ・リスト ★アクティビティ属性 ★マイルストーン・リスト (p) プロジェクト・マネジメント文書更新版 　　(p) スケジュール・ベースライン 　　(p) コスト・ベースライン	〃
8	アクティビティ順序設定	(p) プロジェクト・マネジメント計画書 　　(p) スコープ・ベースライン 　　・スケジュール・マネジメント計画書 ・プロジェクト文書 　　(p) 前提条件ログ 　　・プロジェクト・スコープ記述書 　　・アクティビティ・リスト 　　★アクティビティ属性 　　★マイルストーン・リスト ---------- ・組織体の環境要因 ・組織のプロセス資産	★プレシデンス・ダイアグラム法（PDM） ・依存関係の決定 ・リードとラグ (p) プロジェクト・マネジメント情報システム（PMIS）	★プロジェクト・スケジュール・ネットワーク図 ・プロジェクト文書更新版 　　(p) 前提条件ログ 　　(p) アクティビティ・リスト 　　(p) アクティビティ属性 　　(p) マイルストーン・リスト	〃
9	アクティビティ資源見積(6)				〃
10	アクティビティ所要期間見積	(p) プロジェクト・マネジメント計画書 　　(p) スコープ・ベースライン 　　・スケジュール・マネジメント計画書 ・プロジェクト文書 　　(p) 前提条件ログ 　　・プロジェクト・スコープ記述書 　　・アクティビティ・リスト 　　・アクティビティ属性 　　(p) マイルストーン・リスト 　　・資源要求事項 　　・リスク登録簿 　　(p) 教訓登録簿 　　(p) プロジェクト・チーム任命 　　・RBS 　　・資源カレンダー ---------- ・組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ・所要期間見積 　　★類推見積 　　★パラメトリック見積 　　★三点見積 　　★ボトムアップ見積 (p) データ分析 　　(p) 代替案生成 　　・予備設定分析 (p) 意思決定 (p) 会議	★アクティビティ所要期間見積 ★(p) 見積根拠 ・プロジェクト文書更新版 　　(p) 前提条件ログ 　　(p) アクティビティ属性 　　(p) 教訓登録簿	〃
11	スケジュール作成	(p) プロジェクト・マネジメント計画書 　　(p) スコープ・ベースライン 　　・スケジュール・マネジメント計画書 ・プロジェクト文書 　　(p) 前提条件ログ 　　・プロジェクト・スコープ記述書 　　・アクティビティ・リスト 　　・アクティビティ属性 　　(p) マイルストーン・リスト 　　・資源要求事項 　　・プロジェクト・スケジュール・ネットワーク図 　　★アクティビティ所要期間見積 　　★(p) 見積根拠 　　・リスク登録簿 　　(p) 教訓登録簿 　　・プロジェクト・チーム任命 　　・RBS 　　・資源カレンダー (p) 合意書 ---------- ・組織体の環境要因 ・組織のプロセス資産	・スケジュール・ネットワーク分析 ★クリティカル・パス法 ・クリティカル・チェーン法(6) ・資源最適化技法 (p) データ分析 　　(p) What-If分析 　　(p) シミュレーション ・モデリング技法 ・リードとラグ ・スケジュール短縮 ・スケジューリング・ソフトウェア ・プロジェクト・マネジメント情報システム（PMIS） (p) アジャイルのリリース計画	★スケジュール・ベースライン ★プロジェクト・スケジュール ・スケジュール・データ ・プロジェクト・カレンダー ・プロジェクト・マネジメント計画書更新版 　　(p) スケジュール・マネジメント計画書 　　(p) コスト・ベースライン ・プロジェクト文書更新版 　　(p) 前提条件ログ 　　(p) アクティビティ属性 　　(p) アクティビティ所要期間見積 　　(p) 資源要求事項 　　(p) リスク登録簿 　　(p) 教訓登録簿	〃

この中で、プロジェクト・マネジメント計画書（PMP：計画の該当節を参照）には、

• プロジェクト・ライフサイクル（PMP：共通の該当節を参照）と、

• スコープ・ベースライン（PMP：計画 - 範囲の該当節を参照）
  プロジェクトのすべての作業が記載される。

  • 承認済みの、プロジェクト・スコープ記述書
  • WBS
  • WBS辞書

が含まれる。

• 専門家の判断（PMP：立上の該当節を参照）
• データ分析
  • (p) 代替案生成（PMP：計画 - 範囲の該当節を参照）
• 会議（PMP：立上の該当節を参照）

• プロジェクト・スケジュールの作成と、
  実行、監視・制御する方法を記述する。

• プロセスの相互作用と依存関係から、変更の反映方法を記述する。

• 以下の要素から構成される。

  • スケジュール・モデル

    • 方法論
    • ツール（MS Project, etc.）

  • 正確さのレベル、測定単位
    アクティビティの端数処理の単位：週、日、時間

  • コントロールの閾値
    スケジュールの許容差異レベル：％、日、時間（たいてい％）

  • パフォーマンスの測定規則

    • 測定の時期：WBSのレベルを指定
    • 測定の種類：アーンド・バリュー（EV）

• ワーク・パッケージ・レベル（PMP：計画 - 範囲の該当節を参照）を更に分解して、アクティビティを定義する。

• これにより、簡単に、見積もり、スケジュール、割当などをコントロールするための基盤を構築する。

• アクティビティは、

  • 成果物（プロダクト / サービス / 所産）（PMP：共通の該当節を参照）を生成するために実行する個別の作業単位である。
  • 成果物・アクティビティは、名詞か？動詞か？で区別する。

• 実際には

  • WBS作成（PMP：計画 - 範囲の該当節を参照）
  • アクティビティ順序設定

  を同時に行い、完了させる。

インプット・アウトプット（ITTO）を参照。

• 要素分解（PMP：計画 - 範囲の該当節を参照）
  WBSの要素分解と同様で、アウトプットは、スケジュール・アクティビティ（スケジュール・データ）になる。

• ローリング・ウェーブ計画法（PMP：計画 - 範囲の該当節を参照）

  • 一種の段階的詳細化
  • サブ・プロジェクトのアクティビティ定義は、
    サブ・マネージャーに委任することがある。

• 専門家の判断（PMP：立上の該当節を参照）

• テンプレート
  また、過去のアクティビティ・リスト（このプロセスのアウトプット）を、テンプレートとして使用することもできる。

チーム・メンバが作業の内容と実行方法を理解できるようにする。

• 構成要素
  • スケジュール・アクティビティ（スケジュール・データ）のアクティビティ名と同じ、
    プロジェクトで実行されるすべてのアクティビティ名。
  • 各アクティビティ名に対応する作業範囲の説明と識別子（コード or 番号）

• アクティビティ・リストを拡張したもの。

• アクティビティの特性を記述する。

• 後述のスケジュール作成プロセスのインプットとなる。

• 項目（段階的詳細化）

  • 上流

    • アクティビティID
    • WBS識別コード（PMP：計画 - 範囲の該当節を参照）
    • アクティビティ名

  • 下流

    • 先行 / 後続アクティビティ
    • 論理的順序関係
    • リードとラグ
    • 資源に対する要求事項
    • 前提条件・制約条件（PMP：計画 - 範囲の該当節を参照）

• マイルストーン

  • 大きな目標

    • 成果物（プロダクト / サービス / 所産）の完了
    • 重要なイベント

  • 例

    • 契約の承認
    • 成果物（プロダクト / サービス / 所産）の承認
    • プロトタイプの作成
    • システム・テストの完了

• マイルストーン・リスト

  • 成果の記録
  • 必須 / 任意の文書化

• アクティビティ順序設定プロセスのインプットとなる。

必要に応じて更新する。

• アクティビティを正しい順番に並べる。

• 実際には

  • WBS作成（PMP：計画 - 範囲の該当節を参照）
  • アクティビティ定義

  を同時に行い、完了させる。

インプット・アウトプット（ITTO）を参照。

• 依存関係の決定

• プレシデンス・ダイアグラム法（PDM）

• リードとラグ

• スケジュール・ネットワーク・テンプレート

  • また、過去のプロジェクト・スケジュール・ネットワーク図（このプロセスのアウトプット）を、テンプレートとして使用することもできる。
  • 部分的に適用するテンプレートは、サブ・ネットワーク・テンプレート、部分ネットワーク・テンプレートと呼ぶ。

• 手作業で作成してもコンピューターで作成しても良い。

• プロジェクトの複雑さによって記載のレベルは異なる。

  • 複雑：概要レベルの情報のみ含まれているケース

    • 関連あるアクティビティの集合（ハンモック）
    • ハンモック：関連あるアクティビティのグループをひとまとめにし、
      そのグループに含まれるアクティビティに相応しい表題を付与したもの。

  • 単純：全ての詳細情報が含まれているケース

• 表現方法

  • ガントチャート / バーチャート
    管理者向けの広く使われている読みやすい図。

  • マイルストーン・チャート
    経営層向けのハイレベルなガントチャート / バーチャート

  • スケジューリング・ソフトウェア（PMP：監視・制御の該当節を参照）を使用する。

• 効果
  アクティビティ・リストで、

  • 見逃していたアクティビティが、浮上したり、
  • １つで済むと思っていたアクティビティが、２つに分割されたり、

  するので、プロジェクト文書を更新する。

必要に応じて更新する。

スケジュール（PMP：共通の該当節を参照） → 資源（PMP：共通の該当節を参照）に移動。

必要な時間を、スケジュール作成に入力できるように見積もる。

組織のプロセス資産にプロジェクト・カレンダーがある。

• 所要期間見積

PMP：グループ意思決定技法を参照。

• コンティンジェンシー予備
  リスク計画プロセスで特定される作業（既知の未知）に使用される。

  • スケジュール・ベースラインに含まれる。

• マネジメント予備
  不測のリスク（未知の未知）発生に対処するための予備の予算や期間

  • スケジュール・ベースラインに含まれない（所要期間全体の要求事項の一部）。
  • 発生した場合は、スケジュール・ベースラインの変更が必要になる。

• スケジューリング・ソフトウェア（PMP：監視・制御の該当節を参照）を使用できる。
  • プロジェクト・カレンダーを入力
  • 所要期間を入力
  • 所要期間を出力

• アクティビティの完成に必要とされる作業期間の見積
• 通常、時間・週・日・月などで表される定量的な値
• 範囲の可能性を含める場合、100±10時間などと表記する。

必要に応じて更新する。

• 計画プロセス群（PMP：計画）の中の中心的なプロセス。

• スケジュールの作成

  • 開始/終了日
  • 所要期間
  • スケジューリング・ソフトウェア（PMP：監視・制御の該当節を参照）に入力

• 承認後、ベースラインを追跡開始。

プロジェクト・スコープ記述書（PMP：計画 - 範囲の該当節を参照）の、
前提条件・制約条件が特に重要になる。

• プロジェクト・スケジュール・モデルを作成する包括的な技法。

• 以下の技法を使用してプロジェクトの最早/最遅 開始日、最早/最遅 終了日を計算する。

  • クリティカル・パス法
  • クリティカル・チェーン法
  • 資源最適化技法
  • モデリング技法

• 資源の制約を考慮しないので理論上の期日になるので、
  アクティビティ予定の見当を付ける用途で使用する。

※ PMBOK 第6版で活用ケースが少ないということで削除されている。

• スケジュール・ネットワーク分析の１技法

• クリティカル・パス法の入力に

  • 制約条件（PMP：計画 - 範囲の該当節を参照）
  • 資源の可用性

  を加えることにより、プロジェクト・バッファ、合流バッファ、リソース・バッファ
  などのバッファー・アクティビティを加え、CPを保護し、その所要期間を管理する。

• タスクごとにバッファをとるのではなく、全タスクの後ろでまとめてバッファをとる。

  1. 各タスクのABP: Aggressive but Possible（50%の確率で達成される目標スケジュール）見積
  2. 各タスクのHBP: Highly Possible（90%の確率で達成される確実なスケジュール）見積
  3. (全タスクのHBPの合計 - 全タスクのABPの合計) * 0.5 = 用意すべきバッファ

• ポイント

  • 資源の限られた or 予測不可能なプロジェクトの問題に対処できる。

  • リソースが十分に存在し、各作業での競合が発生しない場合、
    クリティカル・チェーンとクリティカル・パスは同じになる。

  • As Soon As Possible (ASAP)ではなく、
    As Late As Possible (ALAP)らしいが詳細不明。

• クリティカル・パス法（CP : クリティカル・パス、CPM : クリティカル・パス法）
• 資源最適化技法
• データ分析、モデリング技法
• リードとラグ
• スケジュール短縮
• プロジェクト・マネジメント情報システム（PMIS）（PMP：監視・制御の該当節を参照）

• プロダクト進展のための

  • プロダクト・ロードマップと
  • プロダクト・ビジョン

  に基づいて

  • リリース・スケジュール
  • ハイレベルの要求タイムライン

  を提示する。

• リリース内のイテレーションやスプリント数を設定する。

  • リリース

  • スプリント

    • イテレーション１
    • イテレーション２
    • ・・・
    • イテレーションｎ

  • ユーザ・ストーリ

    • フィーチャー１
    • フィーチャー２
    • ・・・
    • フィーチャーｎ

  • タスク

    • タスク１
    • タスク２
    • タスク３

ココのアウトプットを使用して、プロジェクトの進捗状況を測定・評価する。

• 補助計画書（PMP：計画の該当節を参照）（ベースライン）の一部。

• 承認

  • プロジェクト・スケジュールを承認したもの。
  • ステークホルダーと機能部門マネージャの承認を得る必要がある。
  • 期日と資源に対する確約は、協力の確認にもなる。

• 以下の内容に基づく

  • タイムライン
  • スコープ文書（PMP：計画 - 範囲）
  • 資源計画書（PMP：計画 - 資源）

• 以下の結果を含む

  • アクティビティ順序設定
  • アクティビティ所要期間見積
  • スケジュールの制約条件（PMP：計画 - 範囲の該当節を参照）の検討結果
  • 資源に対する要求事項の分析結果

• 内容

  • アクティビティの開始日 / 終了日
  • アクティビティの所要期間
  • アクティビティの依存関係
  • マイルストーン、資源など。

• 資源について

  • 資源の割り当ては、資源の獲得（PMP：実行 - 資源の該当節を参照）(6)で行われる。
  • コレが完了していない場合、スケジュールは暫定的なものと看做される。

• スケジュールの根拠となるデータが記載された文書。

  • 最小限

    • マイルストーン
    • スケジュール・アクティビティ
    • アクティビティ属性
    • スケジュールの前提条件・制約条件（PMP：計画 - 範囲の該当節を参照）

  • 推奨

    • コンティンジェンシー予備
    • 代替スケジュール案
    • 資源ヒストグラム（PMP：計画 - 資源の該当節を参照）

プロジェクトの稼働日を表す。

必要に応じて更新する。

必要に応じて更新する。

• ハード・ロジック、ハード依存関係とも呼ぶ。
• 作業内容でアクティビティの順番が決まる。
• 例：ペンキ剥ぎ、下地塗り、ペンキ塗り

• 優先ロジック、ソフト・ロジック、選好ロジックとも呼ぶ。

• プロセス・手順、過去の経験によって導かれる。

• 例：大まかにスプレー塗装、細かい部分は手作業。

• 試験に出る。

  • 不規則なトータル・フロート値（最大余裕時間）を生成し、
    スケジュールの選択肢を狭める可能性がある（何故かが不明）。
  • 故に、ファスト・トラッキングの際には、変更・削除の検討対象になる。

• プロジェクト外部の依存関係
• 例：プロジェクト外部の何らかの認可（法律の認可）がおりないと、先に進めない。

• プロジェクト内部の依存関係
• 例：プロジェクト・組織内部の何らかの認可（内規の認可）がおりないと、先に進めない。

一点見積（？）ダケを使用して所要期間を決定する。

• ノード = アクティビティ
  アクティビティ・オン・ノード（AON）

  • 名
  • 番号
  • 開始・終了日
  • 期限
  • フロート（= スラック）

• 矢印 = 順序関係
  論理的順序関係、プレシデンス順序関係

• 終了‐開始（FS）

  • 最も一般的
  • 先行を終了しないと後続を開始できない。

• 終了‐終了（FF）

  • 先行を終了しないと後続を終了できない。
  • ラグを含むケースが解り易い ... A終了後、X後にB終了

• 開始‐開始（SS）

  • 先行を開始しないと後続を開始できない。
  • ラグを含むケースが解り易い ... A開始後、X後にB開始

• 開始‐終了（SF）

  • 先行を開始しないと後続を終了できない。
  • 移行先システムが開始するまで移行元システムを終了できない（稀）。

• 頻度

  • 終了‐開始（FS）：多
  • 開始‐終了（SF）：僅

• リードとラグ

  • 終了‐開始（FS）
  • 開始‐開始（SS）

• 並行

  • 終了‐終了（FF）
  • 開始‐開始（SS）

• 前置き

  • 古い、ほとんど使われない。
  • 業界によっては、PDMよりADMを好む業界がある。
  • アクティビティ順序設定ツール・技法に含まれない。
  • しかし、試験には出るらしい。

• 特徴

  • 終了‐開始（FS）の依存関係だけを使用し、
    多点見積（？）ダケを使用して所要期間を決定する。

• 図

  • ノード = 終了‐開始（FS）
  • 矢印 = アクティビティ

• 別称

  • アクティビティ・オン・アロー（AOA）
  • アクティビティ・オン・ライン（AOL）

• 条件分岐法。

• 作業のネットワークを示す手法で、
  条件による分岐・合流、ループを表すことができる。

• GERTは複数の仕事のうちどれかひとつが実施されればプロジェクト自体は
  完成するという不確定要素のはいった場合を取り扱うことを目標とする。

• 後続アクティビティが遅れる（アクティビティ間で時間が経過すると発生）。
• 後続のアクティビティの開始（日）・終了（日）が遅れる。
• 例：下地塗りの後、下地が乾くのを待ってからペンキ塗りを開始した。

• 後続アクティビティを早める。
• 後続のアクティビティの開始（日）・終了（日）を早める（時間を差し引く）。
• 例：ペンキ剥ぎが不要な部位があったため、下地塗りを開始した。

• 概要

  • プロジェクトの総体（全体）を見積る、一種の専門家の判断。
  • 過去のプロジェクト情報が文書化保存されていることが前提。
  • アクティビティの経験者に見積もり作業を担当させる。

• 特徴

  • プロジェクト情報が限られているときに有用。
  • 時間がかからずコストも低いが精度が劣ることがある。
  • 従って、他の見積手法（三点見積）と併用して利用される。

• 概要

  • プロジェクトの全体や一部を見積る方法
  • アルゴリズム（作業量 * 単価）と過去データの併用

• 特徴
  以下のケースで正確

  • 過去データと変数間に統計的な関係がある。
  • 上記のデータの信頼性が高い。

• 概要

  • 平均値
    以下の平均値を求める。

    • 最頻値(tM)：最も可能性が高い
    • 楽観値(tO)：最良のケース
    • 悲観値(tP)：最悪のケース

  • 期待値

    • 三角分布の期待値：tE = (tO + tM + tP) / 3
    • ベータ分布の期待値：tE = (tO + 4tM + tP) / 6

• 特徴

  • リスクと不確実性を含めることで精度を上げる。
  • 類推見積（トップダウン見積）と併用する。

• 概要

  • WBSの下位レベルの構成要素単位に見積・集計する。
  • 必要に応じて、アクティビティ内の作業をさらに分解する。

• 特徴

  • 最も正確な見積もりが可能と言われている。
  • 精度は高いが、ただし、バッファが多くなる。
  • 以下のケースでは適用できないので、
    類推見積（トップダウン見積）を使用
    • プロジェクトの早い段階
    • 大規模・複雑なプロジェクト

クリティカル・パス法（CPM）は、

• スケジュール・ネットワーク分析の１技法

  • プロジェクトの最早/最遅 開始日、最早/最遅 終了日を（資源の制約を考慮せず）計算する。
  • 各ネットワーク・パスのフロート（= スラック）量（スケジュールの柔軟性）を計算する。

• 前提

  • 逐次ネットワーク（終了‐開始（FS））

    • アクティビティが次のアクティビティの前に実行される。
    • 一連のアクティビティが完了してから一連のアクティビティが開始する。
    • 従って、アロー・ダイアグラム法（ADM）ベース。
    • ただし、プレシデンス・ダイアグラム法（PDM）を使用することもできるらしい。

  • アクティビティごとに１つの所要期間

• クリティカル・パス（CP）

  • プロジェクトの最長の経路

  • トータル・フロートが０やマイナスになるアクティビティがCPタスクになる。

  • CPタスクの所要期間の合計値が、CPの所要期間。

  • フロートを持つアクティビティがフロートを使い果たすと、そのアクティビティがCPタスクになる。

  • 制約条件（PMP：計画 - 範囲の該当節を参照）のマイルストーンなどで、CPが変化することがある。

• フロート（= スラック）

  • トータル・フロート（TF）

    • プロジェクトの終了日を遅らせることなく、タスクの開始日を遅らせる事ができる期間。
    • トータル・フロートはプラスになる場合とマイナスになる場合がある。
      プラス：余裕（往路計算の最早終了日より復路計算の最遅終了日が遅い）
      マイナス：スケジュールが逸脱している場合。

  • フリー・フロート（FF）
    後続タスクの最早開始日を遅らせることなく、
    タスクの開始日を遅らせる事ができる期間。

• アクティビティ・依存関係の情報収集

  • CPの図
    （プロジェクト・スケジュール・ネットワーク図）

  • CPMの計算シート

    • アクティビティ番号

    • アクティビティの説明

    • 依存関係
      開始前に終了しなければならないアクティビティの番号を記入

    • 所要期間
      月, 日, 時などの単位を指定して記入。開始日・終了日なら日

    • 最早開始日

    • 最早終了日

    • 最遅開始日：フロート 0 のCPでは、= 最早開始日

    • 最遅終了日：フロート 0 のCPでは、= 最早終了日

    • フロート（= スラック）
      = 最遅終了日 - 最早終了日（= 最遅開始日 - 最早開始日）

• 往路時間計算と復路時間計算

  • 往路時間計算：
    最早開始日、最早終了日を求めることができる。

    • 最早開始日：
      CPの先頭アクティビティの開始日
      or 前のアクティビティの最早終了日（合流するときは遅い方）の翌日。

    • 最早終了日：
      = 最早開始日 + 所要期間 - 1

  • 復路時間計算：
    最遅開始日、最遅終了日を求めることができる。

    • 最遅終了日：
      CPの末端アクティビティの最早終了日
      or 後続のアクティビティの最遅開始日（合流するときは早い方）の前日。

    • 最遅開始日：
      = 最遅終了日 - 所要期間 + 1

PERT : Program Evaluation and Review Technique

• あまり使われていないが、大規模・複雑なプロジェクトでは有用。

• CPMでは所要期間を使用したが、PERTでは、
  所要期間を三点見積（ベータ分布）で処理した期待値（加重平均）を使用する。

  • 期待値（加重平均）= (tO + 4tM + tP) / 6

  • 標準偏差 = (tP - tO) / 6

  • 標準偏差毎の確率
    ベータ分布で、標準偏差毎の確率が決まっている。

    • ± 1 * 標準偏差 : 68.26%
    • ± 2 * 標準偏差 : 95.44%
    • ± 3 * 標準偏差 : 99.73%

• 更に、各アクティビティの標準偏差を求めれば信頼係数を割り当てることができる。

• アクティビティ・依存関係の情報収集

  • CPの図
    （プロジェクト・スケジュール・ネットワーク図）

  • パート技法の計算シート

    • アクティビティ番号

    • アクティビティの説明

    • 最頻値(tM)：最も可能性が高い

    • 楽観値(tO)：最良のケース

    • 悲観値(tP)：最悪のケース

    • 期待値（ベータ分布）：= (tO + 4tM + tP) / 6

    • 標準偏差：= (tP - tO) / 6

    • 標準偏差の2乗：標準偏差 * 標準偏差

• CPの期待値と標準偏差を計算する。

  • CPの期待値は、各アクティビティの期待値を合計する。

  • CPの標準偏差は以下で算出する。

    • 各アクティビティの標準偏差の2乗を合計する。
    • 上記の合計値の平方根を求める。

クリティカル・パス法をベースとするが、

• クリティカル・パス法
• パート技法

では考慮しない、資源の可用性を考慮に加えている。

• 資源 余剰（割当不足）の場合は、
  複数のアクティビティのタスクを割り当てる。

• 資源 不足（割当超過）の場合は、
  以下の 3 つの技法を使用する。

フロート（= スラック）を活用するが、資源の可用性に基づいてCPを変更する。

• 以下のケースで使用する。

  • 資源 不足（割当超過）の場合
  • 資源が特定の時期にしか利用できない場合
  • 資源が同時に複数のアクティビティに割当られている場合

• 資源の不均衡を解決するために、資源の可用性に基づいて開始日・終了日を調整する。

  • 先ず、CPに資源を割り当てる。
  • 2つの方法で資源平準化を実行する。
    • 重要なチーム・メンバのスケジュールに合わせて開始日を遅らせる。
    • 割当不足のチーム・メンバにタスクが割当られるように調整する。

フロート（= スラック）の範囲内で調整することでCPを変更しない。

• 割当不足のチーム・メンバにタスクを割当てる（残業強制もある）。

• フロート（= スラック）のあるタスクに割当てられているチーム・メンバを、
  CP上のタスクに割り当てる（ファスト・トラッキング）。

• スキルの優れたチーム・メンバを、
  優先度の高いタスク（CP上のタスク、重要なタスク）に割当てる。

• ある人的資源がアクティビティを実行できる唯一の資源である場合などに使用される。
• 開始日からではなく終了日からアクティビティに人的資源を割り当てる（なぜ？）。

• 複数の前提条件に基づいて複数の所要期間を算出。
• 不確定要素をマネジメントするために、所要期間バッファーを追加する。
• 悪条件下でのプロジェクト・スケジュールの実行可能性を判断できる。
• または、リスク対応やコンティンジェンシー計画の準備に役立つ。

• 各アクティビティの所要期間の確率分布を三点見積などで定義する。
• これに基づいて、プロジェクト全体の所要期間の確率分布を計算する。

PMP：試験 - テクニックの該当節を参照。

• アクティビティの所要期間の確率分布、スケジュール予想の計算を繰り返す。
• これにより、予測の確率、CPの所要期間とフロート（= スラック）を算出する。

• 「スコープを変更させることなく」、
  所要期間を短縮する一種の数学的分析

• CPMやPERTで分析を行った結果、
  当初予定していた期間に収まらなくなった場合に行われる可能性がある。

コストとスケジュールのトレードオフを検討する短縮技法

• CPに資源を追加することによって短縮が行われる。

  • 人海戦術
  • 強制残業
  • 翌日配送

• 影響

  • 最小のコスト増で、最大のスケジュール短縮を試行する。
  • 人海戦術、強制残業なだけに、コストやリスクが高まるコトがある。
  • CPが変化するので、CPの確認（再計算）を行う。

重複実行可能なアクティビティのタスクに対してのみ適用できる。

• マルチフェーズ・プロジェクト（PMP：共通の該当節を参照）（＝重複関係）化による短縮技法。

  • 強制依存関係（ハード・ロジック）でない任意依存（ソフト・ロジック）であれば適用可能な方法。
  • そう言えば昔インターフェイスで切って、並行開発するって思想があった。

• 影響

  • 重複実行なだけに、手直しなどのリスクが高まるコトがある。
  • コストやCPに関しては明記されていないが、恐らく、
    • コストは追加しない。
    • CPは、CPが重複実行可能なら短縮可能。

移行メモ

• 誤記を修正した。「こてにより」→「これにより」、 「制度が劣ることがある」「制度は高いが」→「精度」、 「悪条件化での」→「悪条件下での」、 「ハード依存症」→「ハード依存関係」、 「タクス」→「タスク」、 「ベータ分布の期待値：：」の全角コロン重複、 「WBSの要素分解所なり」→「WBSの要素分解と同様で」。
• 見出し「GEAT（Graphical Evaluative Review Technique）」は、 本文が「GERTは〜」と述べているとおり GERT の誤記のため、 「GERT（Graphical Evaluation and Review Technique）」に修正した。
• CPM の計算シートの「フロート（= スラック） = 最遅終了日 - 最早開始日」は、 同ページの「フロート 0 のCPでは 最遅終了日 = 最早終了日」という記述と 整合しないため、「= 最遅終了日 - 最早終了日（= 最遅開始日 - 最早開始日）」に修正した。
• 復路時間計算の「最遅終了日：…or 前のアクティビティの最遅開始日の前日」は、 復路（後ろから前へ）の計算のため「後続のアクティビティの最遅開始日の前日」に修正した。
• 「プロジェクト・スケジュール」の「タイムライン」はリンク先が空（#） だったため、プレーンテキストにした。
• PMBOK 第6版で削除された項目の見出しは、打ち消し線ではアンカが不安定なため 「（PMBOK 第6版で削除）」という表記に改めた（表中の打ち消し線はそのまま）。
• 各プロセスの「プロセス（ツールと技法）」配下は、見出しだけで本文が無く 「ツールと技法」節を指すものが大半だったため、箇条書きのリンクにまとめた。 同名の見出し（「インプット」「アウトプット」「概要」「サンプル」など）は、 GitHub Wiki でアンカが衝突するため括弧で文脈を補って一意にした。
• ITTO の表はセル内が全てリンクだったため、 セルの内容をプレーンテキストとし、参照先ページを表の直上に列挙した。 セルの縦結合（~）は 〃 に置き換えた。 なお、8 のインプットにあった「プロダクト・スコープ記述書」は、 リンク先が「プロジェクト・スコープ記述書」の節だったため名称を合わせた。

---

Tags: 移行, PMP, 計画, 時間, スケジュール, アクティビティ, クリティカル・パス法, PERT, PDM, 資源最適化技法, スケジュール短縮, ITTO