第2章 PMBOKの基礎知識

PMBOKの基礎知識
 基本的用語
 9つの知識エリア
1.基本用語
 ステークホルダー

プロジェクトの実行あるいは完了によって自らの利益に影響が出る人や組
織
 プロジェクト・スポンサー

財政的資源を提供する人・組織
 会社の担当役員や部長職以上のプロジェクトに関わる予算に責任を持つ人
 プロジェクトに対して資金を提供する企業
 プロジェクト・マネジャー

プロジェクトのマネジメントに責任を持つ人
 プロジェクトマネジメント・チーム

プロジェクトマネジメントの作業に関わる人
 プロジェクト・チーム・メンバー

マネジャーの指示に従い、目標に向けて作業を行う人
基本用語
 要素成果物

プロジェクトで作成する測定可能な成果や結果、サービス
 プロジェクトマネジメント・プロセス

目標を達成させるために実行される一連のアクティビティ
 PMBOKでは44のプロセスを定義
 プロセス群





立上げプロセス群
計画プロセス群
実行プロセス群
監視コントロール・プロセス群
終結プロセス群
基本用語
 プロジェクト・フェーズおよびプロジェクト・ライフサイクル

例:情報システム開発





計画フェーズ
要件定義フェーズ
設計・開発フェーズ
テスト・移行フェーズ
運用・保守フェーズ
 コストや要員数:少→多→急減
 失敗するリスク:最大→暫時低下
 ステークホルダーがプロジェクトに及ぼす影響:最大→漸低下
基本用語
 9つの知識エリア









プロジェクト統合マネジメント
プロジェクト・スコープ・マネジメント
プロジェクト・タイム・マネジメント
プロジェクト・コスト・マネジメント
プロジェクト品質マネジメント
プロジェクト人的資源マネジメント
プロジェクト・コミュニケーション・マネジメント
プロジェクト・リスク・マネジメント
プロジェクト調達マネジメント
 段階的詳細化

初期段階:大まかな定義→進行に従って:詳細化
2.プロジェクト統合マネジメント
 プロジェクトが認可され終結するまでの7つのプロセス







プロジェクト憲章作成[立上げ]
プロジェクト・スコープ記述暫定版作成[立上げ]
プロジェクトマネジメント計画書作成[計画]
プロジェクト実行の指揮・マネジメント[実行]
プロジェクト作業の監視コントロール[監視コントロール]
統合変更管理[監視コントロール]
プロジェクトの終結[終結]
プロジェクト統合マネジメント
プロジェクト憲章作成
 目的:さまざまな理由から起案されたプロジェクト案を精査、選定し、
その内容を憲章としてまとめ、プロジェクトとして公式に認可させる







顧客、スポンサー、その他のステークホルダーの要求事項
プロジェクトの概要と目的
プロジェクトの成果物
制約条件と前提条件
プロジェクトマネージャーの決定と任命および権限レベル
主要ステークホルダーの関与
要約したスケジュールおよび予算
プロジェクト統合マネジメント
プロジェクト・スコープ記述暫定版作成
プロジェクト統合マネジメント
プロジェクトマネジメント計画書作成
 計画書



プロジェクトの実行
監視コントロール
終結の方法
 プロジェクトの全体像をつかむ


何が大切、何が課題、どの辺りを重点的に管理するのか
プロジェクトの作業・手順・レベル・手段をまとめる
プロジェクト統合マネジメント
プロジェクト実行の指揮・マネジメント
 メンバーの配置やトレーニング
 納入者の選定
 材料・工具・等資材の調達
 プロジェクトの進行に伴う


是正処置・予防処置・変更要求・欠陥修正の実行あるいは実行指揮
および各種修正に関する変更要求
プロジェクト統合マネジメント
プロジェクト作業の監視コントロール
 監視対象




立ち上げに関する
計画
実行
終結
 プロセスを監視
 是正処置と予防処置
 計画書と実際の実績との比較
 必要な情報の提供

リスクの分析・追跡・監視・状況報告
プロジェクト統合マネジメント
統合変更管理
 変更要求




スコープの拡大・縮小
方針・プロセス・計画・手順の修正
コスト・予算の変更
スケジュールの改訂
 是正処置

計画書との差異を解消するための対応
 予防処置

好ましくない結果が発生する確率を低減するための対応
 欠陥処置

品質・検査プロセスで発見された欠陥を修正する対応
プロジェクト統合マネジメント
プロジェクト終結
 締結した各種契約の終結
 顧客あるいはスポンサーが成果物を正式受け入れする調整・折衝
 関連文書の整理
プロジェクト統合マネジメント
プロジェクト発生理由






市場の要求
ビジネスニーズ
顧客要求
技術の進歩
法的要求
社会的ニーズ
プロジェクト・スコープ・マネジメント
プロジェクトの作業範囲を明確にする


成果物スコープ:プロジェクトの成果物に求められる機能や特性
プロジェクト・スコープ:成果物を作成するために必要な作業

各プロセス

計画プロセス群

スコープ計画


スコープ定義


図2−4
WBS(Work Breakdown Structure)作成


マネジメントするための手順を決める
図2−5
監視コントロールプロセス群

スコープ検証


作業の完了と要素成果物についての公式な承認を得るのが目的
スコープ・コントロール

承認済み変更による影響範囲を差異分析により評価し、影響する文書の修正や計画の見直しをする
プロジェクト・スコープ・マネジメント
プロジェクトの作業範囲を明確にする
 スコープ検証

プロジェクトを計画する上で予め明示する必要のある事項
 制約条件

予算、スケジュール、作業場所、調達の制限
 前提条件(確証無く確実と考えた事項)

想定利用客数やデータ量、必要なPC仕様、ソフトウェア
プロジェクト・タイム・マネジメント
2-4. スケジュールを作成する
 計画プロセス群





アクティビティ定義
アクティビティ順序設定
アクティビティ資源見積もり
アクティビティ所要時間見積もり
スケジュール作成
 監視コントロールプロセス群

スケジュールコントロール
プロジェクト・タイム・マネジメント
スケジュールを作成する―アクティビティ定義―
 単位:作業の見積もり、スケジューリング、実行、監視



スコープ記述書、WBS,WBS辞書、マネジメント計画書を基に
プロジェクトが置かれている環境や過去の経験を参考にし
WBSの最下層の要素成果物をより小さくマネジメントし易いスケジュー
ルアクティビティの単位まで分解する
プロジェクト・タイム・マネジメント
スケジュールを作成する―アクティビティ順序設定―
 アクティビティ間で守らねばならない順序関係を確認し、記述する



アクティビティリストおよびアクティビティ属性などを基に
プレシデンス・ダイヤグラム(PDM: Precedence Diagram)図2-6やア
ロー・ダイヤグラム(ADM: Arrow Diagram)などの手法を使い
論理的順序関係をプロジェクト・スケジュール・ネットワーク図2-7にまと
める
プロジェクト・タイム・マネジメント
スケジュールを作成する―アクティビティ資源見積もり―
 見積もる項目



どのような資源(人員、機器、資材、など)
何時
どのくらいの量
プロジェクト・タイム・マネジメント
スケジュールを作成する―アクティビティ所用期間見積もり―
 各アクティビティを完了させるために必要な作業期間を決める

参照項目
 アクティビティリスト
 アクティビティ属性
 アクティビティ資源見積もりプロセスにおける必要資源・必要量・資源
の空き状況
プロジェクト・タイム・マネジメント
スケジュールを作成する―スケジュール作成―
 作成手順





クリティカル・パス法などを利用して、
プロジェクトスコープ記述書に記載されている前提条件や制約事項を満
たすプロジェクト・スケジュールを作成、
各アクティビティに必要なスキルなどを踏まえ具体的な要員を割り当てる
、
稼働時間がある100%を超える要員や逆に手が空くメンバーがいない
かを確認する
バーチャートによるスケジュール例 図2-7
プロジェクト・タイム・マネジメント
スケジュールを作成する―スケジュールコントロール―


総合変更管理プロセスからの承認済み変更要求に基づき、
スケジュールの変更をマネジメントする
 プロジェクトマネージャは



実現可能かつ妥当なスケジュールを作成する
スケジュールと実進捗のずれを把握し
スケジュールに間に合う是正処置を施すか、所定の手続きによりスケジ
ュール変更を行う
プロジェクト・タイム・マネジメント
スケジュールを作成する―スケジュールコントロール―
 リードとラグ



先行のアクティビティ終了と後続のアクティビティ開始間の時間的ギャップ
リード
ラグ
 所要時間



類推見積もり・・・過去の類似の所要時間を参考にする、類似性が高い場
合は良い
係数見積もり・・・作業量と生産性、単位時間当たりの投入資源量を算出
三点見積もり・・・見積もりにリスクを加味する



最頻値
楽観値
悲観値
プロジェクト・タイム・マネジメント
スケジュールを作成する―スケジュールコントロール―
 クリティカルパス


プロジェクト・スケジュール・ネットワーク図を用い、すべてのアクティビティ
の論理的な最早開始日と最早終了日、最遅開始日と最遅終了日を算出
する
フロート::最遅終了日と最早終了日の差=最遅開始日と最早開始日の差

各アクティビティのフロートが0となる経路をクリティカルパス
 クリティカルパスから分かること




プロジェクト全体の所要期間
作業が遅れた場合のプロジェクトへの影響
プロジェクト全体の所要時間を短縮する場合の検討すべきアクティビティ
各アクティビティの開始時間およびその余裕
プロジェクト・タイム・マネジメント
スケジュールを作成する―スケジュールコントロール―
 資源平準化


時期により変動するメンバーの作業負荷を、期間内でスムーズになるよう
に各種調整する作業を指す
一般にこの平準化によりプロジェクトの完了時期が延びる
 所要時間の短縮

クラッシング



クリティカルパス上のアクティビティに追加資源を投入する
投入によりクリティカルパスが変わる場合があるので注意が必要
ファースト・トラッキング

通常、順番に行うアクティビティを並行して行うことで、時間短縮を図る方法
プロジェクト・コスト・マネジメント
2-5.予算を作成する
 概要

プロジェクトが完了するまでに、いくらコストが要るかを算出する




プロジェクトの立上げ時の予算と大幅に異なる場合は、プロジェクトの実施自体を再
検討する必要がある
予算作成後もプロジェクトマネージャは、絶えずそれまでにかかったコストとプロジェ
クトの進捗状況を把握することが必要
プロジェクト完了時までかかるコストと時間の予測を行い、必要に応じて適切な対応
をとり、プロジェクトを予算内に終わらせることが求められる
プロセス

計画プロセス



コスト見積もり
コストの予算化
監視コントロール・プロセス群

コスト・コントロール
プロジェクト・コスト・マネジメント
2-5.予算を作成する

コスト見積もり





各アクティビティを完了するために必要な資源コストを算出することが目的
計画書や登録簿をもとに、環境や経験を参考にして見積もる
各種のイベント毎に継続的に見直しが必要
予備費:想定外の事象に対処するためのもの
コストの予算化


プロジェクトのパフォーマンス測定に利用するコスト・ベースラインを設定するこ
とが目的
コスト・ベースライン



必要となるコストを時系列に展開したもの
横軸に時間、縦軸に累積コストとしたグラフで表現、通常Sカーブになる
コスト・コントロール

コスト・ベースラインと実コストずれを把握し、コストが超過しないように是正処
置あるいは、コスト・ベースラインの変更を手続きに従って要求する
プロジェクト・コスト・マネジメント
2-5.予算を作成する

コスト見積もり法

類推見積もり


ボトムアップ見積もり


最も詳細なレベルのアクティビティのコストを見積もり、総額を算出する
アーンド・バリュー法


過去の類似プロジェクトの実コストを参考に見積もる
過去のデータをもとに、実コストとそれに影響を及ぼす変数との関係を統計的に処
理し、コスト見積もりの算出式が定義されている場合がある。
アーンド・バリュー法

スケジュールとコスト・ベースライン、測定時の作業進捗状況をもとに、測定時のコ
スト差異、スケジュール差異、完成時の総コスト見積もりを算出する手法
プロジェクト品質マネジメント
2-6. 要求された品質を実現する

概要



品質は計画により達成されるものであり検査によってではない、という考え
プロジェクトのマネジメントと成果物のマネジメントを、品質管理の対象とする
品質マネジメントのプロセス群

計画プロセス群





実行プロセス群


品質管理の対象
基準
実現計画
品質チェックリスト
品質監査・・・非効率で効果のない方針やプロセス・手順の調査
監視コントロールプロセス群


成果物や各プロセスが計画通りの品質を確保しているか否かを監視し、原因と改善方法
を特定する
顧客満足



要求事項への適合
使用適合性
検査よりも予防
プロジェクト品質マネジメント
2-6. 要求された品質を実現する

QCの7つ道具







特性要因図
管理図
フローチャート化
ヒストグラム
パレート図
ランチャート
散布図
プロジェクト人的資源マネジメント
2-7.要員を調達し活躍させる

概要



適切なタイミングで、適切な能力、スキル、経験を持つ人に、適切な役割と責任を与
え、プロジェクトに参加させる
個人またはチームが最大のパフォーマンスを発揮するように、表彰や報奨制度、非
公式なコミュニケーション、チーム育成、などを考慮して実施する
プロセス



計画プロセス群:人的資源計画
実行プロセス郡:チーム編成、チーム育成
監視コントロールプロセス郡:チームのマネジメント
プロジェクト人的資源マネジメント
2-7.要員を調達し活躍させる

人的資源計画

個人及びグループの役割と責任、報告関係を決める




チームメンバの調達方法、時期、離任時期、表彰と報償の計画




階層型の組織図
責任分担マトリクス(RAM)
役割ごとにテキストで記述
組織外、内からの調達
作業箇所(一か所、複数個所)
人材資源のヒストグラム
プロジェクトチーム編成

要員の選出





参加可能時期
保有する能力・技術
類似作業の成功体験の有無
プロジェクトの役割への興味の有無
要員確保のコスト
プロジェクト人的資源マネジメント
2-7.要員を調達し活躍させる

プロジェクトチーム育成



プロジェクトチームのマネジメント


メンバーのパフォーマンスを追跡し、フィードバックを行い、抱えてる課題解決の支援を行うこと
で、プロジェクト全体のパフォーマンスを向上させる
チームの育成段階





メンバーの能力を強化する
メンバー間の交流の促進
成立期・・・メンバーが召集され、プロジェクトの目的が説明された
動乱期・・・メンバーが各自の立場を作ろうとし、対立が始まる
安定期・・・自分の立場を確保し、他のメンバーの考え方を理解し始め、共同で推進する気持ち
が芽生える
遂行期・・・互いに尊重し合い、各種の問題に共通の問題意識を持つ.生産性が高い段階
バーチャルルーム


互いに顔を合わせず、各自が役割を果たすチーム状態.
ネットワーク環境の進展でどこでも作業環境を得ることができ、在宅勤務形態やWebサービス
による新たな業務形態が可能となっている
プロジェクト・コミュニケーション・マネジメント
2-8.ステークホルダーとの情報交換を円滑に進める

概要


ステークホルダーなどとのコミュニケーションを成功させるための各種作業
各プロセス



計画プロセス群:コミュニケーション計画
実行プロセス群:情報配布
監視コントロールプロセス群:実績報告、ステークホルダーマネジメント
プロジェクト・コミュニケーション・マネジメント
2-8.ステークホルダーとの情報交換を円滑に進める

コミュニケーション計画


ステークホルダーが必要とする情報とその伝達方法を見極め、明示することが目的
コミュニケーションの留意点




情報配布


コミュニケーション計画プロセスで決めた内容に従って、ステークホルダーが必要と
するプロジェクトの情報を、適切な時期に伝えることが目的
実績報告


文書・口頭・メイルなどの手段
相手の知識や理解度のレベルに合わせた話の内容
相手の話を引き出す
プロジェクトの進捗状況、成果物作成状況、パフォーマンス情報を収集・分析して報
告書にまとめることが目的
ステークホルダーマネジメント

ステークホルダーと適切にコミュニケーションを行い、課題を解決することが目的
プロジェクト・リスク・マネジメント
2-9.万が一に備える

概要


経営や経済活動の結果の不確実性に起因するリスク
各プロセス

計画プロセス群


監視コントロール・プロセス群


リスク・マネジメント計画、リスク識別、定性的リスク管理、定量的リスク管理、リスク
対応計画
リスクの監視コントロール
リスク・マネジメント計画

プロジェクトで発生するリスクに対してどのように取り組み、処理するかを計画する



リスクの識別、分析、対応計画、監視の行い方の定義
リスク管理を行う上での役割と責任の明確化
リスクの発生確率と影響度の定義
プロジェクト・リスク・マネジメント
2-9.万が一に備える

リスク識別

プロジェクトの外的要因がリスクとなる


プロジェクトの内的要因がリスクとなる


天候・災害、為替変動、消費傾向
要員の調達、病気や欠員、人事異動
根本原因の追及・分類



プロジェクトマネジメント・チームでのブレーンストーミング
専門家へのアンケート
類似プロジェクト経験者へのインタビュー
プロジェクト・リスク・マネジメント
2-9.万が一に備える

定性的リスク分析


識別されたリスクに優先順位を付ける
リスクの査定



リスク登録(図2-9)




リスクが発生する確率
リスクがタイム・コスト・スコープ・品質へ与える影響度
リスクの優先順位
WBSやプロジェクトフェーズによる分類
即対応の要否
定量的リスク分析


高い優先度のリスクに対し、プロジェクトへの影響度を詳細に見積もる
技法:感度分析・デシジョンツリー分析・モデル化&シミュレーション
プロジェクト・リスク・マネジメント
2-9.万が一に備える

リスク対応計画




リスクへの対応戦略を考え具体的な対応を行う
どのような処理手法があるのかを見出す
どの程度までリスクを低減させるか(HSISE: How safe is safe enough?)
リスク監視コントロール

継続的リスク監視


既存リスクの再分析、残存リスクの監視、対応策による効果の評価
新たに生じたリスクの識別・分析・対応計画
プロジェクト・リスク・マネジメント
2-9.万が一に備える

マイナスのリスク(脅威)への対応戦略





回避・・・影響を避けるために計画を変更する
転嫁・・・影響を、責任とともに第三者へ移転させる(財務的な対応)
軽減・・・影響度をプロジェクトが受容できる程度まで低減する
受容・・・軽減や回避をしない
プラスのリスクへ(好機)の対応戦略




活用・・・好機が確実にくるように対応する
共有・・・好機を得やすい人と組む
強化・・・確率やプラスの影響を増大させて好機の規模を修正する
受容・・・リスクの軽減や回避をしない
プロジェクト・調達・マネジメント
2-10.外部からプロダクトやサービスを購入する

概要


要素成果物を作成するために外部からプロダクトやサービスを購入する際に、内部
で作成するのか、外部に依頼するのかの決め方
各プロセス

計画プロセス群


実行プロセス群


納入者回答依頼、納入者決定
監視コントロールプロセス群


購入取得計画、契約計画
契約管理
終結プロセス群

契約終結
プロジェクト・調達・マネジメント
2-10.外部からプロダクトやサービスを購入する

購入・取得計画




購入取得する際の方針を決めることが目的
いつまでに、どの部分を、どのような契約タイプで取得するかを検討
メリットとデメリットを分析
契約計画

目的



調達文書


入札招請書、提案依頼書(RFP; Request for Proposal)、見積もり依頼書
評価基準



納入候補者へ配布する調達文書の作成
見積書・提案書を元に納入者を選定する評価基準を作成
価格
手順を管理するマネジメント力、要素成果物を作成する技術力、財務力
納入者回答依頼


調達文書の配布
入札説明会
プロジェクト・調達・マネジメント
2-10.外部からプロダクトやサービスを購入する

納入者選定



契約管理


購入者および納入者が契約に従い行動していることを確認する
契約終結


各評価基準に重み付けを設定し評価する
図2-10
全ての作業と要素成果物が受入れ可能かを検証し、契約を完了させる
契約タイプ

定額契約または一括請負契約


実費償還契約


要素成果物の対価として払う契約
成果物の取得にかかる費用に納入者の利益相当分を加えた額を払う契約
タイム・アンド・マテリアル契約(T&M)

単位時間あたりのレートに作業に費やした時間を乗じた額とする契約
PIMBOKの基礎知識
まとめと課題
•
•
基本用語 ⇒ 本日提出
1.
2.
3.
4.
5.
6.
7.
ステークホルダー
要素成果物
プロセスとプロセス群
プロジェクト・フェーズ
プロジェクト・ライフサイクル
9つの知識エリヤ
段階的詳細化
検討課題 ⇒ 次回に提出
1.
2.
3.
4.
5.
6.
スコープ定義で失敗しないためには
真のニーズを把握するには
プロジェクトチームを育成するには
コミュニケーションの留意点
他国籍プロジェクトでのコミュニケーション
契約計画での留意点
PIMBOKの基礎知識
まとめと課題
1. スコープ定義で失敗しないためには
スコープ定義が曖昧であったことで、プロジェクトが失敗する例は多い.
システム開発会社が、顧客から情報システムの導入を請け負う場合
開発したシステムのトレーニング実施が、プロジェクトのスコープとして記述されていた場合
システム開発会社は顧客側の担当者に開発した情報システムの説明会を実施すれば
よいと理解する.
しかし、顧客側は、すべての利用者が操作方法をマスターするまで教育する、と理解する
かもしれない
⇒スコープ外事項の記述: 立場によるスコープの認識差異を排除することが目的
2. 真のニーズを把握するには
「私のほしいのはこのような物ではない」&「お客様の言われたように作りました」
顧客の真のニーズである「使用適合性」が、顧客の要望に合わないために発生する問題
解釈の違いによる問題を防ぐためには、顧客の要望を聞いた時、自分の価値基準だけで
判断しないこと
PIMBOKの基礎知識
まとめと課題
3. プロジェクトチームを育成するには
人間関係スキルの育成・向上が重要
チームとしての結束力を高めるには、チームの育成段階を理解した上での、地道な活動が必要
チームおよびメンバーに適した非公式なコミュニケーション活動が、相互理解や信頼関係の
塾生に役立つ
チームとしてのパフォーマンスを高めるには、できる限り作業場所を終結することが大事
関連の深いチームは隣同士とし、その上で個人の役割やタイプを勘案した席位置を考慮する
チーム育成プロセスとして、表彰や報奨制度を利用する
メンバーのモチベーションを上げる、
ただし、不公正な評価、目立つことを担当する者のみになることは避ける
4. コミュニケーションの留意点
書面で行うのか、口頭で行うのか
プロジェクト内部か、外部なのか
プロジェクトの非公式な情報なのか否か
受けては、上下関係のある人か否か
文書・口頭・メールなどの手段の特徴を考慮する
相手の知識レベルに合わせた用語を用いる
相手の話を聞くだけではなく、話を引き出すこと
PIMBOKの基礎知識
まとめと課題
5. 他国籍プロジェクトでのコミュニケーション
いろいろな価値観や習慣を持った人が集まるので、相手を尊重し、配慮して行う
例えば、感情を表に出して伝えるほうがよいと考える国の人や、
逆に、なるべく感情を出さないようにするほうが望ましいと考える国の人がいる
まず、相手を尊重すること.互いの文化や倫理観を学ぶ機会を作り、相互に信頼し尊重する関係を
築くことが大事
日本人同士でも類似のことが発生する
終身雇用・年功序列の会社の人 & 外資系のような実力主義の会社の人
以心伝心、言わなくてもわかる、自分勝手な思い込みからコミュニケーションミスが起こる
6. 契約計画での留意点
プロジェクト調達マネジメントの際に発生するミスは、評価基準を決めずに選定を行うことによる
この場合、総合的な判断ができず、特定の項目のみを重視した選定や、主観による選定となってしまう