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

目次

概要

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

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

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

#プロセスインプットツールと技法アウトプット知識エリア
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) 教訓登録簿

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

インプット

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

が含まれる。

プロセス(ツールと技法)

専門家の判断

データ分析

(p) 代替案生成

会議

アウトプット

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

  • プロジェクト・スケジュールの作成と、
    実行監視・制御する方法を記述する。
  • プロセスの相互作用と依存関係から、変更の反映方法を記述する。
  • 以下の要素から構成される。
  • スケジュール・モデル
    • 方法論
    • ツール(MS Project, etc.)
  • 正確さのレベル、測定単位
    アクティビティの端数処理の単位:週、日、時間
  • コントロールの閾値
    スケジュールの許容差異レベル:%、日、時間(たいてい%)
  • パフォーマンスの測定規則
    • 測定の時期:WBSのレベルを指定
    • 測定の種類:アーンド・バリュー(予算・スケジュールの観点で定量的に評価)

アクティビティ定義

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

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

インプット

プロセス(ツールと技法)

要素分解

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

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

専門家の判断

テンプレート

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

アウトプット

アクティビティ・リスト

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

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

アクティビティ属性

  • 項目(段階的詳細化)

マイルストーン・リスト

  • マイルストーン

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

必要に応じて更新する。

アクティビティ順序設定

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

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

インプット

プロセス(ツールと技法)

依存関係の決定

プレシデンス・ダイアグラム法(PDM)

リードとラグ

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

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

アウトプット

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

  • 手作業で作成してもコンピューターで作成しても良い。
  • プロジェクトの複雑さによって記載のレベルは異なる。
  • 複雑:概要レベルの情報のみ含まれているケース
    • 関連あるアクティビティの集合(ハンモック)
    • ハンモック:関連あるアクティビティのグループをひとまとめにし、
      そのグループに含まれるアクティビティに相応しい表題を付与したもの。
  • 単純:全ての詳細情報が含まれているケース
  • 表現方法
  • ガントチャート / バーチャート
    管理者向けの広く使われている読みやすい図。
  • マイルストーン・チャート
    経営層向けのハイレベルなガントチャート / バーチャート
  • 効果
    アクティビティ・リストで、
    • 見逃していたアクティビティが、浮上したり、
    • 1つで済むと思っていたアクティビティが、2つに分割されたり、

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

プロジェクト文書更新版

必要に応じて更新する。

アクティビティ資源見積(6)

スケジュール資源に移動。

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

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

インプット

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

プロセス(ツールと技法)

所要期間見積

グループ意思決定技法

  • ブレーン・ストーミング
  • デルファイ法
    多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
    さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。
  • ノミナル・グループ技法
    • ブレーン・ストーミングの一技法、集団インタビュー技法。
    • ブレーン・ストーミングに投票プロセスを加え、結論を出す方法。

予備設定分析

その他

アウトプット

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

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

プロジェクト文書更新版

必要に応じて更新する。

スケジュール作成

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

インプット

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

プロセス(ツールと技法)

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

  • プロジェクト・スケジュール・モデルを作成する包括的な技法。
  • 資源の制約を考慮しないので理論上の期日になるので、
    アクティビティ予定の見当を付ける用途で使用する。

クリティカル・パス法

  • CP : クリティカル・パス
  • CPM : クリティカル・パス法

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

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

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

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

資源最適化技法

データ分析、モデリング技法

リードとラグ

スケジュール短縮

プロジェクト・マネジメント情報システム(PMIS)

アジャイルのリリース計画

  • プロダクト進展のための
  • プロダクト・ロードマップと
  • プロダクト・ビジョン

に基づいて

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

を提示する。

  • リリース内のイテレーションやスプリント数を設定する。
  • リリース
  • スプリント
    • イテレーション1
    • イテレーション2
    • ・・・
    • イテレーションn
  • ユーザ・ストーリ
    • フィーチャー1
    • フィーチャー2
    • ・・・
    • フィーチャーn
  • タクス
    • タクス1
    • タクス2
    • タクス3

アウトプット

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

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

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

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

  • 内容
    • アクティビティの開始日 / 終了日
    • アクティビティの所要期間
    • アクティビティの依存関係
    • マイルストーン、資源など。
  • 資源について
    • 資源の割り当ては、[[資源の獲得>]](6)で行われる。
    • コレが完了していない場合、スケジュールは暫定的なものと看做される。

スケジュール・データ

  • スケジュールの根拠となるデータが記載された文書。
  • 推奨
    • コンティンジェンシー予備
    • 代替スケジュール案
    • [[資源ヒストグラム>]]

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

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

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

必要に応じて更新する。

プロジェクト文書更新版

必要に応じて更新する。

ツールと技法

依存関係の決定

強制依存関係

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

任意依存関係

  • 優先ロジック、ソフト・ロジック、選好ロジックとも呼ぶ。
  • プロセス・手順、過去の経験によって導かれる。
  • 例:大まかにスプレー塗装、細かい部分は手作業。
  • 試験に出る。
    • 不規則なトータル・フロート値(最大余裕時間)を生成し、
      スケジュールの選択肢を狭める可能性がある(何故かが不明)。
    • 故に、ファスト・トラッキングの際には、変更・削除の検討対象になる。

外部依存関係

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

内部依存関係

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

プレシデンス・ダイアグラム法(PDM)

特徴

一点見積(?)ダケを使用して所要期間を決定する。

  • ノード = アクティビティ
    アクティビティ・オン・ノード(AON)
  • 番号
  • 開始・終了日
  • 期限
  • フロート(= スラック)

順序関係

  • 終了‐ 開始(FS)
    先行を終了しないと後続を開始できない。
  • 終了‐ 終了(FF)
    行を終了しないと後続を終了できない。
  • 開始‐ 開始(SS)
    先行を開始しないと後続を開始できない。
  • 開始‐ 終了(SF)
    • 先行を開始しないと後続を終了できない。
    • システム移行:移行先システムが開始するまで移行元システムを終了できない。
  • 頻度
    • 終了‐ 開始(FS):多
    • 開始‐ 終了(SF):僅
  • 並行
    • 終了‐ 終了(FF)
    • 開始‐ 開始(SS)

アロー・ダイアグラム法(ADM)

  • 前置き
    • 古い、ほとんど使われない。
    • 業界によっては、PDMよりADMを好む業界がある。
    • アクティビティ順序設定ツール・技法に含まれない。
    • しかし、試験には出るらしい。
  • 特徴
    • 終了‐開始(FS)の依存関係だけを使用し、
      多点見積(?)ダケを使用して所要期間を決定する。
    • ノード = 終了‐ 開始(FS)
    • 矢印 = アクティビティ
      • アクティビティ・オン・アロー(AOA)
      • アクティビティ・オン・ライン(AOL)

GEAT(Graphical Evaluative Review Technique)

  • 条件分岐法。
  • 作業のネットワークを示す手法で、
    条件による分岐・合流、ループを表すことができる。
  • GERTは複数の仕事のうちどれかひとつが実施されればプロジェクト自体は
    完成するという不確定要素のはいった場合を取り扱うことを目標とする。

リードとラグ

ラグ

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

リード

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

所要期間見積

類推見積(トップダウン見積)

  • 概要
    • プロジェクトの総体(全体)を見積る、一種の専門家の判断。
    • 過去のプロジェクト情報が文書化保存されていることが前提。
    • アクティビティの経験者に見積もり作業を担当させる。
  • 特徴
    • プロジェクト情報が限られているときに有用。
    • 時間がかからずコストも低いが制度が劣ることがある。
    • 従って、他の見積手法(三点見積)と併用して利用される。

パラメトリック見積

  • 概要
    • プロジェクトの全体や一部を見積る方法
    • アルゴリズム(作業量 * 単価)と過去データの併用
  • 特徴
    以下のケースで正確
    • 過去データと変数間に統計的な関係がある。
    • 上記のデータの信頼性が高い。

三点見積

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

ボトムアップ見積

  • 概要
    • WBSの下位レベルの構成要素単位に見積・集計する。
    • 必要に応じて、アクティビティ内の作業をさらに分解する。
    • 最も正確な見積もりが可能と言われている。
  • 特徴
    • 最も制度が高い。ただし、バッファが多くなる。
    • 以下のケースでは適用できないので、類推見積(トップダウン見積)を使用
      • プロジェクトの早い段階
      • 大規模・複雑なプロジェクト

クリティカル・パス法

概要

クリティカル・パス法(CPM)は、

  • 前提
  • 逐次ネットワーク(終了‐開始(FS)
    • アクティビティが次のアクティビティの前に実行される。
    • 一連のアクティビティが完了してから一連のアクティビティが開始する。
  • アクティビティごとに1つの所要期間
  • クリティカル・パス(CP)
  • プロジェクトの最長の経路
  • トータル・フロートが0やマイナスになるアクティビティがCPタスクになる。
  • CPタスクの所要期間の合計値が、CPの所要期間。
  • フロートを持つアクティビティがフロートを使い果たすと、そのアクティビティがCPタスクになる。
  • 制約条件のマイルストーンなどで、CPが変化することがある。
  • フロート(= スラック)
  • トータル・フロート(TF)
    • プロジェクトの終了日を遅らせることなく、タスクの開始日を遅らせる事ができる期間。
    • トータル・フロートはプラスになる場合とマイナスになる場合がある。
      プラス:余裕(往路計算の最早終了日より復路計算の最遅終了日が遅い)
      マイナス:スケジュールが逸脱している場合。
  • フリー・フロート(FF)
    後続タスクの最早開始日を遅らせることなく、
    タスクの開始日を遅らせる事ができる期間。

サンプル

  • アクティビティ・依存関係の情報収集
  • 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%
  • 更に、各アクティビティの標準偏差を求めれば信頼係数を割り当てることができる。

サンプル

  • アクティビティ・依存関係の情報収集
  • パート技法の計算シート
  • アクティビティ番号
  • アクティビティの説明
  • 最頻値(tM):最も可能性が高い
  • 楽観値(tO):最良のケース
  • 悲観値(tP):最悪のケース
  • 期待値(ベータ分布):= (tO + 4tM + tP) / 6
  • 標準偏差:= (tP - tO) / 6
  • 標準偏差の2乗:標準偏差 * 標準偏差
  • CPの期待値と標準偏差を計算する。
  • CPの期待値は、各アクティビティの期待値を合計する。
  • CPの標準偏差は以下で算出する。
    • 各アクティビティの標準偏差の2乗を合計する。
    • 上記の合計値の平方根を求める。

資源最適化技法

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

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

  • 資源 余剰(割当不足)の場合は、
    複数のアクティビティのタスクを割り当てる。
  • 資源 不足(割当超過)の場合は、
    以下の 3 つの技法を使用する。

資源平準化

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

  • 以下のケースで使用する。
    • 資源 不足(割当超過)の場合
    • 資源が特定の時期にしか利用できない場合
    • 資源が同時に複数のアクティビティに割当られている場合
  • 資源の不均衡を解決するために、資源の可用性に基づいて開始日・終了日を調整する。
    • 先ず、CPに資源を割り当てる。
    • 2つの方法で資源平準化を実行する。
      • 重要なチーム・メンバのスケジュールに合わせて開始日を遅らせる。
      • 割当不足のチーム・メンバにタスクが割当られるように調整する。

資源円滑化

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

  • 割当不足のチーム・メンバにタスクを割当てる(残業強制もある)。
  • フロート(= スラック)のあるタスクに割当てられているチーム・メンバを、
    CP上のタスクに割り当てる(ファスト・トラッキング)。
  • スキルの優れたチーム・メンバを、
    優先度の高いタスク(CP上のタスク、重要なタスク)に割当てる。

逆資源配分スケジューリング

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

データ分析、モデリング技法

What-If分析

  • 複数の前提条件に基づいて複数の所要期間を算出。
  • 悪条件化でのプロジェクト・スケジュールの実行可能性を判断できる。
  • または、リスク対応やコンティンジェンシー計画の準備に役立つ。

シミュレーション

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

モンテカルロ分析

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

スケジュール短縮

  • 「スコープを変更させることなく」、所要期間を短縮する一種の数学的分析
  • CPMPERTで分析を行った結果、
    当初予定していた期間に収まらなくなった場合に行われる可能性がある。

クラッシング

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

  • CPに資源を追加することによって短縮が行われる。
    • 人海戦術
    • 強制残業
    • 翌日配送
  • 影響
    • 最小のコスト増で、最大のスケジュール短縮を試行する。
    • 人海戦術、強制残業なだけに、コストやリスクが高まるコトがある。
    • CPが変化するので、CPの確認(再計算)を行う。

ファスト・トラッキング

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

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

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-07-31 (火) 21:23:09 (75d)