PMP：計画 - 時間 のバックアップ(No.13)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PMP：計画 - 時間 へ行く。
  • 1 (2018-04-11 (水) 16:29:47)
  • 2 (2018-04-11 (水) 16:45:52)
  • 3 (2018-04-16 (月) 22:16:21)
  • 4 (2018-04-17 (火) 19:35:07)
  • 5 (2018-05-11 (金) 21:21:38)
  • 6 (2018-05-15 (火) 17:28:42)
  • 7 (2018-05-15 (火) 18:36:04)
  • 8 (2018-05-24 (木) 22:08:45)
  • 9 (2018-05-30 (水) 22:30:36)
  • 10 (2018-05-30 (水) 22:40:02)
  • 11 (2018-05-31 (木) 12:42:07)
  • 12 (2018-05-31 (木) 15:57:43)
  • 13 (2018-05-31 (木) 19:53:43)
  • 14 (2018-05-31 (木) 21:34:53)
  • 15 (2018-06-01 (金) 22:41:55)
  • 16 (2018-06-05 (火) 17:17:30)
  • 17 (2018-06-05 (火) 21:48:14)
  • 18 (2018-06-06 (水) 20:27:42)
  • 19 (2018-06-13 (水) 21:51:10)
  • 20 (2018-06-25 (月) 15:11:40)
  • 21 (2018-06-26 (火) 15:05:06)
  • 22 (2018-06-27 (水) 11:40:55)
  • 23 (2018-07-04 (水) 19:30:41)
  • 24 (2018-07-13 (金) 23:14:52)
  • 25 (2018-07-14 (土) 21:00:24)
  • 26 (2018-07-16 (月) 20:00:48)
  • 27 (2018-07-18 (水) 00:56:34)
  • 28 (2018-07-31 (火) 21:23:09)
  • 29 (2018-11-06 (火) 16:32:06)
  • 30 (2018-11-06 (火) 20:49:32)
  • 31 (2018-11-25 (日) 19:51:49)
  • 32 (2018-11-29 (木) 20:25:44)
  • 33 (2018-12-22 (土) 17:09:09)
  • 34 (2018-12-22 (土) 21:42:25)
  • 35 (2019-01-03 (木) 21:55:17)
  • 36 (2019-01-04 (金) 19:01:40)
  • 37 (2019-01-23 (水) 14:12:32)
  • 38 (2019-01-25 (金) 10:03:27)
  • 39 (2019-02-23 (土) 22:56:22)
  • 40 (2019-02-27 (水) 12:31:19)
  • 41 (2019-03-07 (木) 22:13:01)
  • 42 (2019-06-29 (土) 17:40:25)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

計画 - スケジュール・プロセスの主要な役割 †

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

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

インプット・アウトプット †

スケジュール・マネジメント計画 †

インプット †

この中で、プロジェクト・マネジメント計画書には、

• スコープ・ベースライン
  プロジェクトのすべての作業が記載される。
  • 承認済みの、プロジェクト・スコープ記述書
  • WBS
  • WBS辞書

が含まれる。

プロセス（ツールと技法） †

専門家の判断 †

データ分析 †

(p) 代替案生成

会議 †

アウトプット †

スケジュール・マネジメント計画書 †

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

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

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

• スケジュール・モデル
  • 方法論
  • ツール（MS Project, etc.）

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

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

• パフォーマンスの測定規則
  • 測定の時期：WBSのレベルを指定
  • 測定の種類：アーンド・バリュー（予算・スケジュールの観点で定量的に評価）

アクティビティ定義 †

• ワーク・パッケージ・レベルを更に分解して、アクティビティを定義する。
• こてにより、簡単に、見積もり、スケジュール、割当などのコントロールするための基盤を構築する。

• アクティビティは、
  • 成果物を生成するために実行する個別の作業単位である。
  • 成果物・アクティビティは、名詞か？動詞か？で区別する。

• 実際には
  • WBS作成
  • アクティビティ順序設定

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

インプット †

プロセス（ツールと技法） †

要素分解 †

ローリング・ウェーブ計画法 †

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

専門家の判断 †

テンプレート †

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

アウトプット †

アクティビティ・リスト †

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

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

アクティビティ属性 †

• アクティビティ・リストを拡張したもの。
• アクティビティの特性を記述する。
• 後述のスケジュール作成プロセスのインプットとなる。

• 項目（段階的詳細化）

• 上流
  • アクティビティID
  • WBS識別コード
  • アクティビティ名

• 下流
  • 先行 / 後続アクティビティ
  • 論理的順序関係
  • リードとラグ
  • 資源に対する要求事項
  • 制約条件 / 前提条件

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

• マイルストーン

• 大きな目標
  • 成果物の完了
  • 重要なイベント

• 例
  • 契約の承認
  • プロジェクト成果物の承認
  • プロトタイプの作成
  • システム・テストの完了

• マイルストーン・リスト
  • 成果の記録
  • 必須 / 任意の文書化

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

プロジェクト・マネジメント文書更新版 †

アクティビティ順序設定 †

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

• 実際には
  • WBS作成
  • アクティビティ定義

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

インプット †

プロセス（ツールと技法） †

依存関係の決定 †

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

リードとラグ †

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

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

アウトプット †

プロジェクト・スケジュール・ネットワーク図 †

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

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

• 複雑：概要レベルの情報のみ含まれているケース
  • 関連あるアクティビティの集合（ハンモック）
  • ハンモック：関連あるアクティビティのグループをひとまとめにし、
    そのグループに含まれるアクティビティに相応しい表題を付与したもの。

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

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

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

プロジェクト文書更新版 †

必要に応じて更新する。

アクティビティ所要期間見積 †

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

インプット †

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

プロセス（ツールと技法） †

所要期間見積 †

その他 †

• グループ意思決定技法

• ブレーン・ストーミング

• デルファイ法 多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
  さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。

• ノミナル・グループ技法
  ブレーン・ストーミングに投票プロセスを加え、結論を出す方法。

• 予備設定分析
  • コンティンジェンシー予備
    • スケジュール・ベースラインに含まれる。
    • リスク計画プロセスで特定される作業（既知の未知）に使用される。

• マネジメント予備
  • スケジュール・ベースラインに含まれない（所要時間全体の要求事項の一部）。
  • 不測のリスク（未知の未知）発生に対処するための予備の予算や期間
  • 発生した場合は、スケジュール・ベースラインの変更が必要になる。

• スケジューリング・ソフトウェアを使用できる。
  • プロジェクト・カレンダーを入力
  • 所要時間を入力
  • 所要期間を出力

アウトプット †

アクティビティ所要時間見積 †

プロジェクト文書更新版 †

スケジュール作成 †

• 計画プロセス群の中の中心的なプロセス。

• スケージュールの作成
  • 開始/終了日
  • 所要時間
  • スケジューリング・ソフトウェアに入力

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

インプット †

プロジェクト・スコープ記述書の、制約条件・前提条件が特に重要になる。

制約条件 †

時間の制約

• 指摘日
  • アクティビティの開始/終了日に影響を与える。
  • スケジューリング・ソフトウェアが処理する。

• 重要なイベント、主要なマイルストーン
  • 特定の期日までに特定の成果物を完成させる必要がある。
  • ステークホルダー・顧客との引渡期日の
    合意（口頭/思い込みも含まれる）も制約条件になる。

前提条件 †

プロセス（ツールと技法） †

スケジュール・ネットワーク分析 †

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

• 以下の技法を使用してプロジェクトの最早/最遅 開始日、最早/最遅 終了日を計算する。
  • クリティカル・パス法
  • クリティカル・チェーン法(6)
  • 資源最適化技法
  • モデリング技法

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

クリティカル・パス法 †

クリティカル・チェーン法(6) †

資源最適化技法 †

モデリング技法 †

リードとラグ †

スケジュール短縮 †

プロジェクト・マネジメント情報システム（PMIS） †

アウトプット †

スケジュール・ベースライン †

プロジェクト・スケジュール †

• スケジュール・アクティビティ

スケジュール・データ †

プロジェクト・カレンダー †

プロジェクト・マネジメント計画書更新版 †

プロジェクト文書更新版 †

ツールと技法 †

依存関係の決定 †

強制依存関係 †

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

任意依存関係 †

• 優先ロジック、ソフト・ロジック、選好ロジックとも呼ぶ。
• プロセス・手順、過去の経験によって導かれる。
• 例：大まかにスプレー塗装、細かい部分は手作業。

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

外部依存関係 †

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

内部依存関係 †

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

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

特徴 †

• ノード＆矢印（アクティビティ・オン・ノード（AON））
• 一点見積もりダケを使用して所要時間を決定する。

図 †

• ノード = アクティビティ
  • 名
  • 番号
  • 開始・終了日
  • 期限
  • フロート（= スラック）

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

• 終了‐ 開始（FS）
  先行を終了しないと後続を開始できない（多）。
• 開始‐ 終了（SF）
  先行を開始しないと後続を終了できない（僅）。

• 並行
  • 終了‐ 終了（FF）
    先行を終了しないと後続を終了できない。
  • 開始‐ 開始（SS）
    先行を開始しないと後続を開始できない。

アロー・ダイアグラム法（ADM） †

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

• 特徴
  • ノード＆矢印
    • アクティビティ・オン・アロー（AOA）
    • アクティビティ・オン・ライン（AOL）

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

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

GEAT（Graphical Evaluative Review Technique） †

• 条件分岐法。

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

• PERT においては矢線図上の仕事はすべて行われなければならないが、
  GERTは複数の仕事のうちどれかひとつが実施されればプロジェクト自体は
  完成するという不確定要素のはいった場合を取り扱うことを目標とする。

リードとラグ †

ラグ †

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

リード †

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

所要期間見積 †

類推見積 †

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

• 特徴
  • プロジェクト情報が限られているときに有用。
  • 時間がかからずコストも低いが制度が劣ることがある。

パラメトリック見積 †

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

• 特徴
  以下のケースで正確
  • 過去データと変数間に統計的な関係がある。
  • 上記のデータの信頼性が高い。

三点見積 †

• 概要 以下の平均値を求める。
  • 最頻値(tM)：最も可能性が高い
  • 楽観値(tO)：最良のケース
  • 悲観値(tP)：最悪のケース
  • 平均値
    • 三角分布の期待値：tE = (tO + tM + tP) / 3
    • ベータ分布の期待値：：tE = (tO + 4tM + tP) / 6

• 特徴
  類推見積と併用する。

ボトムアップ見積 †

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

• 特徴
  • 最も制度が高い。
  • ただし、バッファが多くなる。

クリティカル・パス法 †

概要 †

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

• スケジュール・ネットワーク分析の１技法
  • プロジェクトの最早/最遅 開始日、最早/最遅 終了日を（資源の制約を考慮せず）計算する。
  • 各ネットワーク・パスのフロート（= スラック）量（スケジュールの柔軟性）を計算する。
  • プレシデンス・ダイアグラム法（PDM）を使用してクリティカル・パス法（CPM）を実行することもできる。

• 前提

• 逐次ネットワーク（終了‐開始（FS））
  • アクティビティが次のアクティビティの前に実行される。
  • 一連のアクティビティが完了してから一連のアクティビティが開始する。

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

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

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

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

• クリティカル・パス・タスクの所要期間の合計値が、クリティカル・パスの所要期間。

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

• 制約条件のマイルストーンなどで、クリティカル・パスが変化することがある。

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

• トータル・フロート（TF）
  プロジェクトの終了日を遅らせることなく、
  タスクの開始日を遅らせる事ができる期間。
  

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

サンプル †

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

• クリティカル・パスの図
  （プロジェクト・スケジュール・ネットワーク図）

• クリティカル・パス法の計算シート

• アクティビティ番号
• アクティビティの説明

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

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

• 最早開始日
• 最早終了日

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

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

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

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

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

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

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

• 最遅終了日：
  クリティカル・パスの末端アクティビティの最早終了日
  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%

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

サンプル †

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

• クリティカル・パスの図
  （プロジェクト・スケジュール・ネットワーク図）

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

• アクティビティ番号
• アクティビティの説明

• 最頻値(tM)：最も可能性が高い
• 楽観値(tO)：最良のケース
• 悲観値(tP)：最悪のケース
• 期待値（ベータ分布）：= (tO + 4tM + tP) / 6

• 標準偏差：= (tP - tO) / 6
• 標準偏差の2乗：標準偏差 * 標準偏差

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

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

• CPの標準偏差は以下で算出する。
  • 各アクティビティの標準偏差の2乗を合計する。
  • 上記合計値の平方根を求める。
  • 上記平方根をCPの標準偏差として利用する。

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.140 sec.