【PMP試験対策】 プロジェクトマネジメント・フレームワーク

　【PMP試験対策】は、PMBOK4版をベースに、PMP試験の傾向と対策をまとめるシリーズ。

─────────────────────────────────

　プロジェクトとは何か？PMBOK4ではプロジェクトを次のように定義している。

1. 有期性 : プロジェクトには、開始と終了がある
2. 独自性 : プロジェクトは、独自のプロダクトやサービスをもたらす

　いわゆるルーチン作業は「プロジェクト」と呼ばない。デイリーであっても年単位であっても、繰り返し行われる作業は、プロジェクトとは定義されないのだ。だから、「予算編成プロジェクト」は（PMBOKの定義によると）誤った使い方になる。「試験に出やすい」設問を作るならば、「プロジェクトとは何か？」という問いではなく、「次のうち、プロジェクトではないものを選べ」になる。PMBOK3だと、ここに「段階的詳細化」が追加されるが、4版では無くなっている。

　たとえば、上司がふらりとやってきて、「あのシステムの調子が悪いみたいなんだ。ちょっと行って見てきてくれる？」はプロジェクトだろうか。あるいは、ヘルプデスクみたいなものを想像してみてほしい。誰かが連絡してきたトラブルを解決する。有期性も独自性もあるから、「プロジェクト」になるのだろうか？または、新しいハードウェアを展開するのは「プロジェクトに」なるのだろうか？PMBOK4ではプロジェクトの例を、以下のように挙げている。

1. 新製品や新サービスを開発すること
   
2. 情報システムを開発したり展開すること
   
3. ビルや橋などのインフラを建設すること
   
4. 新たなビジネスプロセスを実務に適用させる

　Rita本では、ユニークな判断基準を設けている。「3ヶ月」「20名」というボリュームだ。つまり、期間が3ヶ月以下だったり、メンバーが20名以下だったりするならば、それは(PMIのいう）「プロジェクト」に相当しない可能性がある、というわけだ。もちろんこれはRita本の見解であり、PMBOKのどこにも書いていないのでご注意を。

　ではRitaのいうプロジェクトは、どれぐらいのサイズになるのか――200人のチーム、少なくとも1年間の期間、そして1,000,000ドルの予算だと、「プロジェクト」になるという。経営陣の思いつきでテケトーに割り当てた予算でやっていけと命ぜられる「プロジェクト」が、いかに名前負けしているかがよく分かる。

　この良い例がRita本にある。小さなプロジェクトだったなら、話す必要がある人と直接会ってミーティングすることが可能だが、PMBOKで扱うのは、コミュニケーションマネジメント計画に数週間を要するぐらいのものだ。話す相手は他の言語だったり、ひょっとすると海の向こう――時差とかを考えなければならない国だったりすかもしれない。

　では、「プロジェクトマネジメント」とは何だろうか？PMBOK4では次のように定義している。プロジェクトマネジメントとは、プロジェクトの要求事項を満たすために、知識・スキル・ツールと技法をプロジェクト活動へ適用すること。そしてプロジェクトマネージャ（PM)とは、プロジェクト目標を達成する責任を負う人のことを指す。

　Rita本ではもっとカッコ良くこう言い切っている――プロジェクトマネジメントとは、システマティックなプロセスに従った、科学であり芸術なのだ、と。プロジェクトマネジメントは5つのプロセスグループに分かれている。すなわち、立ち上げ、計画、実行、監視とコントロール、そして終結のプロセスだ。

　そして、次のプロジェクトの制約要素に制限されないように、バランスをとること。すなわち、スコープ、品質、スケジュール、予算、リソース、リスクのバランスをとりながら、プロジェクトの目的を達成するんだ。

─────────────────────────────────

　【PMP試験対策】シリーズについて。

　ベースは、PMBOKガイド4版と、"PMP Exam Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。ぜひ参照してほしい。

　　　【PMP試験対策】　PMBOK2000版
　　　【PMP試験対策】　PMBOK3版

【PMP試験対策】 試験の傾向

　【PMP試験対策】は、PMBOK4版をベースに、PMP試験の傾向と対策をまとめるシリーズ。

─────────────────────────────────

　PMP試験は、知識だけでなく、PMとしての分析力や応用力を試されるもの。単なる定義の記憶と再生を問うものではないので、ご注意を。およそ150問は、ある状況が与えられて、「あなた（=PM）なら、どうする？」と訊かれる問題だ（situational questions）。これは、実際のPMの現場に携わっていないと、正答するのが難しい。いわゆる「常識的に考えて」が通用しない場合があるからだ。例えばこんな問題になる…

Q1 : プロジェクトに必要な調達物資の一部の納入が遅れることが分かった。次にすべきベストな打ち手は何か？

　A. 無視して進める
　B. 上司に報告する
　C. 顧客に連絡し、善後策を検討する
　D. チームを召集し、代替案を検討する

　答えは、D（反転表示）。この場合、現実の「あなた」がどんな風に対応しているかは、あまり問題ではない。ひょっとすると、「あなた」はPMではなく、メンバーの一人であるかもしれないからだ。「客や上司には言わなくてもいいの？」と反論したくなるだろうが、「次にすべき打ち手」ではない。

　とはいうものの、PMBOKガイドのインプット・アウトプットが「そのまま」出る問題もある。Rita本によると、およそ10-12問だそうな。これは覚えるしかないが、出やすいところというものはある（品質保証と品質管理といった"まぎらわしいもの"）。

　さらに、8-10問は、計算問題（コミュニケーションチャンネル、機械コスト）が出題され、10-12問はアーンドバリュー（EV）関連の問題が出る。EVは確かに計算問題になりやすいが、必ずしも計算の形で問うとは限らない。また、事例や計算問題のデータが被る場合がある。つまり、同一の事例やデータが、複数の設問に流用されているというわけ。

　Rita本によると、ほとんどの解答者は、200問中40問は「あやふや」なまま回答しているそうな。また、多くの受験者は2時間30分でひととおり終わり、残りを見直しているという。わたしの場合、3時間かかって200問終えた。残り45分くらいで見直して、「もう大丈夫」と自信があったので、試験を終了したなぁ…（ENDボタンを押すと、いつでも試験終了→採点できるのだ）。

　消去法で解くべき問題もある。一見したところ、設問とは関係なさそうに見えるのだが、「もっと関係のない」選択肢も並んでいる。一つ一つ消していくと、残ったものが正解となる。例えばこうだ。

Q2 : 熟練労働者により、扉の部品コストは10%減らすことができることが分かった。会社側は次期の製造コストとして、扉3,000あたり21,000ドルかかると見積もった。これが意味するところは

　A. 学習サイクル
　B. 収穫逓減の法則
　C. 80/20の法則
　D. 係数モデルコスト見積もり

　答えはD. （反転表示）。10%だの、21,000ドルだの、それっぽい数字が出てくるが、ダミーなんだ。上の状況において、関係なさそうなものを消していって、残った一つが正解、というカラクリ（いわゆる消去法）。

　出題文が不必要に長ったらしい場合もある。状況を説明し問題を解説する文章がだらだらと続く。文中に人員数や予算といった形で「数字」が出てくるため、心配になってくる。だが、こうした数字が問題の本質となっていることは、ほとんどない。すべきことは一つを選ぶだけ。だから、「結局何が問われているのか？」だけを考えて、状況説明文をナナメ読みしてしまうのも吉。

─────────────────────────────────

　【PMP試験対策】シリーズについて。

　ベースは、PMBOKガイド4版と、"PMP Exam Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。ぜひ参照してほしい。

　　　【PMP試験対策】　PMBOK2000版
　　　【PMP試験対策】　PMBOK3版

【PMP試験対策】 PMP試験はどんな試験か？

　【PMP試験対策】は、PMBOK4版をベースに、PMP試験の傾向と対策をまとめるシリーズ。

─────────────────────────────────

　ここで躓く人がかなりいる模様。PMP試験は、PMBOKガイドで覚えたことを試すものではない。もちろんPMBOKガイドからズバリ出る問題もあるが、そうした記憶に頼る試験準備だと、合格は難しい。なぜなら、「ガイドからズバリ」は、ほとんど無いからだ。代わりに、実際のプロジェクトの経験に沿った「ベターな選択肢」を求める問題が山と出る。その「ベター」とは何かというと、PMBOKガイドに準じているんだ。

　PMP試験は、選択肢の中から正解を一つみつける出題形式だ。200問を4時間かけて解く。25問は事前公開問題（prerelease question）とされ、採点されない。どれが事前公開問題なのかは、ランダムに決められており、受験者には分からない。結局、175問が採点対象となり、合格するためには、この中から最低でも106問の正答が求められる。およぞ61パーセントの正答率で合格となるのだ。

　問題はデータベースで管理されており、かなりの数にのぼるようだ。その中から、200問選ばれるというわけ。出題順はバラバラで、PMBOKガイドのように系統だってはいない。そのため、隣の受験生と違う問題に向き合うことになるわけ。なお、誤答だった場合のペナルティはない。

　ただし、問題の出題率は、プロセスグループごとに決まっており、だいたい下記のような割合を占めている。だからといって安心するなかれ。PMIは定期的に試験の見直しをしており、出題傾向を変えている。動向は公式サイトをチェックすべし。

　　立ち上げプロセス（11%）
　　計画プロセス（23%）
　　実行プロセス（27%）
　　監視・コントロールプロセス（21%）
　　終結プロセス（9%）
　　プロフェッショナルと社会責任（9%）

　以下は、難しいさのレベル。一般に難しいと感じられている順に並べると、次のようになるという。つまり、↑上にいくほど、難しくなり、↓下にいくほど、易しくなる。最初のリストは、知識エリアで切った場合。次のリストは、プロセス群単位に見た場合だ。このリストによると、知識エリアでは「プロジェクトマネジメントプロセス」、プロセス群では「監視・コントロールプロセス」が最も難しく感じられるようだ。

　たしかにそうかもしれない。「プロジェクトマネジメントプロセス」の分野は全知識エリアにまたがっているため、広範な知識を要するし、監視・コントロールプロセスもやはり、全てのプロセス群に連結しており、同様に範囲は広いといえる。

知識エリアごとに分けると、

1. プロジェクトマネジメントプロセス
   
2. 調達マネジメント
   
3. リスクマネジメント
   
4. 統合マネジメント
   
5. 品質マネジメント
   
6. タイムマネジメント
   
7. コストマネジメント
   
8. プロジェクトマネジメントフレームワーク
   
9. スコープマネジメント
   
10. 人的資源マネジメント
    
11. コミュニケーションマネジメント

　調達マネジメントは少し特殊で、実務で携わる人の少なさを物語っている。いわゆる総務での発注・検収の仕事をしていれば入りやすいが、普通のPMではなじみが薄いだろう。反面、人的資源やコミュニケーション関連は、普段の仕事と直結した内容のため、易しいと感じる人が多いのかと。

プロセス群ごとの場合だと、

1. 監視・コントロールプロセス
   
2. 立ち上げ
   
3. 実行
   
4. 計画
   
5. 終結
   
6. プロフェッショナルと社会責任

　いわゆるプロジェクトの立ち上げに携わる人は少ない。そのため、難しいと感じる人が多いようだ。「新しいプロジェクトがあるから行ってくれ」と命じられたときには、プロジェクトをする場所や予算が既に決められており、成果物やメンバーは曖昧になっている。何を作るか玉虫色なのに、納期だけはなぜだかしっかりと決められているんだ。「立ち上げ」は、そもそもそれをプロジェクトとしてする価値があるの？という判断も含まれており、かかわる人は上層部+コンサルタントがほとんどかと。

─────────────────────────────────

　【PMP試験対策】シリーズについて。

　ベースは、PMBOKガイド4版と、"PMP Exam Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。ぜひ参照してほしい。

　　　【PMP試験対策】　PMBOK2000版
　　　【PMP試験対策】　PMBOK3版

PMBOK4の変更点

　PMBOK（A Guide to the Project Management Body of Knowledge）の第4版をデジタルコンテンツとして入手したので、3版からの変更点をまとめる。なお、PMBOK4のデジタルコンテンツを参照するためにはPMI会員になる必要がある（[PMI]が入口）。書影は英語のペーパーバック版。PMP取得を目指すなら必携かと。このエントリのまとめの目次は以下の通り。

　1. プロジェクトマネジメント計画書とプロジェクト文書の包含範囲の変更
　2. 定義変更 : 「変更要求」、「プロジェクト憲章」、「スコープ記述書」
　3. 削除／追加されたプロセス
　4. 知識エリアごとの変更内容

■　1. プロジェクトマネジメント計画書とプロジェクト文書の包含範囲の変更

　まず、「プロジェクトマネジメント計画書」と「プロジェクト文書」が明確に異なるものとして扱われている。3版では「文書⊃計画書」と包含していたが、4版になると両者は別物だそうな。

　3版での両者の構成は以下の通り。

　　主なプロジェクト文書
　　　├プロジェクト憲章
　　　├プロジェクトスコープ記述書
　　　└プロジェクトマネジメント計画書
　　　　　　├スコープマネジメント計画書
　　　　　　├スケジュールマネジメント計画書
　　　　　　├コストマネジメント計画書
　　　　　　├品質マネジメント計画書
　　　　　　├要員マネジメント計画書
　　　　　　├コミュニケーションマネジメント計画書
　　　　　　├リスクマネジメント計画書
　　　　　　└調達マネジメント計画書

　4版での定義づけは、こうなる。「プロジェクト文書は、プロジェクトマネジャーの仕事をアシストする文書であり、プロジェクトマネジメント計画書は含まれない」。プロジェクトマネジメント計画書は、各種の計画書やベースラインにより構成される。

　4版では、次のカテゴライズとなっている。

　　プロジェクトマネジメント計画書
　　　├変更マネジメント計画書
　　　├コミュニケーションマネジメント計画書
　　　├コンフィギュレーションマネジメント計画書
　　　├コストマネジメント計画書
　　　├コストパフォーマンス・ベースライン
　　　├人的資源計画書
　　　├プロセス推進計画書
　　　├調達マネジメント計画書
　　　├品質マネジメント計画書
　　　├要求マネジメント計画書
　　　├リスクマネジメント計画書
　　　├スケジュール・ベースライン
　　　├スケジュールマネジメント計画書
　　　├スコープマネジメント計画書
　　　└スコープ・ベースライン
　　　　　　├スコープ記述書
　　　　　　├WBS
　　　　　　└WBS辞書書

　　プロジェクト文書
　　　├アクティビティ要素
　　　├アクティビティ・コスト見積もり
　　　├アクティビティリスト
　　　├仮定条件の記録（Assumption log）
　　　├見積もりの根拠
　　　├変更記録
　　　├憲章（プロジェクト憲章？）
　　　├契約書
　　　├期間見積もり
　　　├見通し
　　　├イシューログ
　　　├マイルストーンの一覧
　　　├パフォーマンス報告書
　　　├財務観点からの要望書
　　　├提案書
　　　├調達文書
　　　├プロジェクト組織構成図
　　　├品質管理指標値
　　　├品質チェックリスト
　　　├品質マトリックス図
　　　├責任分担マトリックス図
　　　├RBS（Resource Breakdown Structure）
　　　├リソースカレンダー
　　　├リソース要件
　　　├リスク登録表
　　　├役割・責任割り当て
　　　├納入者リスト
　　　├ステークホルダー分析
　　　├ステークホルダーマネジメント戦略
　　　├ステークホルダー登録表
　　　├ステークホルダー要求
　　　├作業記述書
　　　├チーム合意書
　　　├チームパフォーマンス見積もり
　　　├作業パフォーマンス情報
　　　└作業パフォーマンス指標値

■2. 定義変更 : 「変更要求」、「プロジェクト憲章」、「スコープ記述書」

　次に、「変更要求」の定義が広がっている。3版では、「是正措置」、「予防措置」、「欠陥修正」および「要求された変更」は、より一般的な用語「変更要求」に包含される。たしかにプロセスやフェーズで違う言葉を使ってはいるものの、意味合いは一緒だからね。

　次は、「プロジェクト憲章」と「スコープ記述書」について。3版では意味が似通っているため冗長だったとし、4版では重複部を削り、より両者の区別をつけるようにした。「何のためのプロジェクト？」に答えるプロジェクト憲章と、「プロジェクトで何するの？」の範囲を決めるスコープ記述書、性格が似ているからね。

　4版での各構成要素は、それぞれ以下の通り。

　　プロジェクト憲章
　　　├プロジェクトの目的と正当性
　　　├測定可能なプロジェクト成果物と成功基準
　　　├ハイレベル要望
　　　├ハイレベルのプロジェクト記述書、プロダクト仕様
　　　├マイルストーンスケジュールのサマリー
　　　├予算のサマリー
　　　├プロジェクト承認要求
　　　├プロジェクトマネージャに責任と権限をアサイン
　　　└プロジェクト憲章に責任と権限を与える人の名前

　　スコープ記述書
　　　├プロダクト・スコープ記述書
　　　├プロジェクト派生物
　　　├プロダクトユーザー承認基準
　　　├プロジェクトの境界
　　　├プロジェクト構成要素
　　　└プロジェクト条件

■3. 削除／追加されたプロセス

　削除／追加されたプロセスは、次の通り。頭の数字は章節番号。

• 4.2 プロジェクトスコープ記述書暫定版作成　→　削除
  
• 4.7 プロジェクト終結　→　4.6 プロジェクト終結フェーズ
  
• 5.1 スコープ計画　→　削除
  
• 9.4 プロジェクトチームのマネジメント　→　コントロールプロセスから実行プロセスへ
  
• 10.1 ステークホルダーの特定　→　追加
  
• 10.4 ステークホルダー・マネジメント　→　ステークホルダーの期待をマネジメントに変更し、コントロールプロセスから実行プロセスへ
  
• 12.1 購入・取得計画および12.2 契約計画　→　12.1 調達計画へ
  
• 12.3 納入者回答以来および12.4 納入者選定　→　12.2 調達契約

■4. 知識エリアごとの変更内容

　プロジェクト統合マネジメントでの変更点。プロジェクトの目的（暫定版）はプロジェクト憲章で記し、プロジェクトの目的そのものはスコープ記述書で詳述する。その結果、4版ではプロジェクトスコープ記述書暫定版作成プロセスは削除されている。

　プロジェクトスコープマネジメントでの変更点。スコープ計画が「要求の収集」に取って代わっている。ステークホルダーを登録することで、プロジェクトに関心を示すステークホルダーを特定する。

　プロジェクトタイムマネジメントでの変更点。パソコンの普及により、アローダイアグラム（ADM）やアクティビティ・オン・アロー（AOA）手法はほとんど使われなくなったため、その旨が追記されている。ちょっとしたプロジェクトだと、アクティビティが鬼のように出てくるので、もはや手作業ではムリなんだろうね（作れるけど変更が鬼）。

　プロジェクトコストマネジメントの変更点。アーンドバリューがより「使える」ツールとして説明が強化されている。さらに、「パフォーマンスインデックスの達成度計算」が追加されている。

　コミュニケーションマネジメントの変更点。「プロジェクトチーム≒ステークホルダー」とは限らない。プロジェクトチーム「外」のステークホルダーが下す決定を予想することもできない。従って、「ステークホルダー要求」をマネジメントする必要が出てくる。これはコントロールプロセスから実行プロセスへ変更することで、記録／報告するものではなく、「実行」するものだと判断している。

―――――――――――――――――――――――――――――――――――――

　本編は時間を見つけてボチボチ読んでいる。Centuryがゴシックになっており、読みやすい。ステークホルダーのマネジメントに力点が置かれているようだ。いわゆる「プロジェクトへの要望」とはすなわち、プロジェクトチーム「外」のステークホルダーの要求なのだから。

PMP試験対策 2.3.7 「計画」でやっていること（調達）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（調達）

　調達マネジメントにおける第一の目的は、「プロジェクトで必要な製品やサービスを、外部から調達するのか、内部でなんとかするのか検討する」こと。そのため、スコープの境界の間に位置し、プロジェクトの外側/内側を厳密に吟味する必要がある。スコープ定義の後でないと調達プロセスが始められないのも、この理由による。

　第ニの目的は、「調達というプロジェクト」を回すこと。「計画→調達準備→情報収集→検討・契約→契約管理→検収受領」の一連のプロセスは、プロジェクトフェーズの一つのPDCAと、軌を一つにする。

　調達プロセスのPDCA
　　　│
　　　├【Plan】買うか作るか決め、マネジメント計画を立て、調達文書を作る
　　　│　├─調達計画　（購入・取得計画）
　　　│　└─調達準備　（契約計画）
　　　│
　　　├【Do】入札、契約を行う
　　　│　├─情報収集　（納入者回答依頼）
　　　│　└─検討・契約　（納入者選定）
　　　│
　　　├【Check】契約の進捗状況や品質管理を行う
　　　│　└─進捗管理　（契約管理）
　　　│
　　　└【Action】契約したサービス・製品を受領し、契約を終結する
　　　　　　└─検収受領　（契約終結）

12.1 購入・取得計画

　外部から購入するか、内部でまかなうかを決め、調達マネジメント計画書と契約作業範囲記述書（契約SOW:contract statement of work）を作成する。

12.2 契約計画

　調達文書と評価基準を作成する。調達文書は、納入候補者から提案や入札を得るために使い、入札招請書、提案依頼書、見積依頼書、入札公告、交渉招請書、第一次コントラクター提案依頼書ともいう。

　調達マネジメント計画書とは、調達プロセスのマネジメント方法を記述したもので、以下のものが記述されている。[p.279:PMBOK]ｊも見ておく。

• 採用する契約タイプ（定額契約/実費償還契約/T&M契約）
• 母体組織に調達・契約・購買部門がある場合、その部門との役割分担
• 複数の納入者が必要な場合のマネジメントをどうするか
• 契約WBSの作成と維持のマネジメントをどうするか
• 納入者の調達基準と評価基準

　契約作業範囲記述書とは、契約に基づき、何をしてもらうのかを詳細に記述したもの。購入する品目やサービスについて、明確・完全・完結に記述し、運用支援が必要な場合はそれも書いておく。何が必要なのかも分かっていないのに、調達するな、ということ。随意契約というふざけた契約をする連中は、同額の契約金を給与から引いても良いと思う。

　重要なのは、調達プロセスを回すためには、何を作るのか決まっていて（スコープ記述書）、詳細化されており（WBS、WBS辞書）、リスク、コスト、スケジュールが見積もられていなければならない。購入・取得計画プロセスのインプットは、スコープ・コスト・タイム・リスクのアウトプットであるのは、そのせい。

　契約タイプ
　　　│
　　　├【定額契約・一括請負契約】明確な成果物を固定価格で契約
　　　│　├─完全定額契約（FFP）
　　　│　└─定額インセンティブフィー契約（FPIP）
　　　│
　　　├【実費償還契約】実コスト＋納入者利益で契約
　　　│　├─コストプラスインセンティブフィー契約（CPIF）
　　　│　├─コストプラス固定フィー契約（CPFF）
　　　│　└─コストプラスフィー契約（CPF）
　　　│
　　　└【タイムアンドマテリアル（T&M）契約】人時・人月契約

　　FFP:Firm Fixed Price
　　FPIF:Fixed Price Incentive Fee
　　CPIF:Cost Plus Incentive Fee
　　CPFF:Cost Plus Fixed Fee
　　CPF:Cost Plus Fee

　ポイントは、定額契約と実費償還契約のリスク。定額契約は納入者のリスクが高く、実費償還は購入者のリスクが高いこと。なぜなら、定額契約は、何をするのか明確だけど、納入者がどうやって提供するのかに関係なく、価格が決まっているから。1,000万円が契約金なら、1,500万かかったとしても、足が出た500万円は支払われない。一方、実費償還契約は、経費と利益の両方を支払う必要があるため、納入者がコストを度外視する可能性がある。前出の場合だと、1,500万円プラス納入者の利益を支払う必要がある。

　もう一つの曲者がT&M契約で、何を作るのか（スコープ）、いくらで作るのか（コスト）が明確になっていなくても契約できてしまう。社長号令で大目標は決まっているけれど、何をどうやらといった状況で、とりあえずコンサルタントと契約するか、というときにはこれが便利。悪名高き「随意契約」もこれだな。

　IT業界では、契約は定額契約であるにもかかわらず、SOW、つまり何をするのかを決めていない場合もある。PMI からするとふざけているとしか言いようがないが、現実ナリ。何つくるか顧客も分かっていないのに、定額で一括で契約してくる営業は、たくあん石を括りつけて日本海に沈めたほうがお互いのためだと思う今日この頃。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

PMP試験対策 2.3.6 「計画」でやっていること（品質、コミュニケーション、人的資源）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（品質）

　品質は鬼門。PMI にとっての「品質」は、一般的なソレと違うので要注意。そして、かなり厳密に適用しようとする。

　品質とは、本来備わっている特性がまとまって要求事項を満たす度合い。あるべきものが、ちゃんと備わっていること、とでも言い換えればいいだろか。「あるべき」は「暗黙のニーズ」「明示された仕様」のいずれかの形はとるかもしれないが、要求が満たされている＝品質を満足しているといえる。

　さらに、要求を満足するだけでなく、使用適合性（fitness for use）も必要だという。要は客の言うとおり作っても使えなきゃ意味ないよ、ということ。

　それだけではない。品質マネジメントでは、成果物マネジメントだけでなく、プロジェクトのマネジメントまで目配りしなければならない。つまり、「良いものを作れば品質はOK」ではなく、そのプロジェクトのマネジメントそのものも「良く」することが重要だという。製品不良率が小さいだけでなく、手戻りが少ないことも大切。

　その結果、「そのプロジェクト」だけで品質マネジメントを成し遂げるのは困難と言うよりも、ムリ。母体組織による継続的な改善活動が必要。また、後に出てくる「品質コスト」、特に予防と評価への投資は、母体組織で負担することになる。プロジェクトは有期的だからね。

　実行や監視・コントロールプロセスに先行して説明するが、品質の3本柱はコレ↓

• 品質計画（計画）：そのプロジェクトの品質規格を採用し、どう満たすかを決める
• 品質保証（実行）：品質を満足するために、やるべきことをちゃんと実行する
• 品質管理（監視・コントロール）：決めた品質規格に適合しているか判断し、不満足なパフォーマンス要因を取り除く方法を見つける

8.1 品質計画

　どの品質規格がそのプロジェクトに関連するかを特定し、どうやってその規格を満足させるかを決める。品質は、計画・設計・作りこみによって達成されるものであり、検査によってではないことがポイント。品質コスト（適合/不適合コスト）、品質マネジメント（デミング、ジュラン、クロスビー）、品質ベースラインは押さえておく。

■「計画」でやっていること（コミュニケーション）

　よく間違える。PMBOK読んでも「あたりまえ」のコトしか書いていないにもかかわらず、不正解多し。送ったメール=読んだものだと判断するのではなく、重要なら到達確認をするように、「あたりまえ」なことがあってもいちいち確認しながら再読するべ。

10.1 コミュニケーション計画

　ステークホルダーの情報に対するニーズを特定する。つまり、誰が、いつ、どのような情報を必要とし、その情報は、誰が、いつ、どのように提供するかを決定する。プロジェクト成功の要因はコミュニケーションと言われるワリには実践されていないのが現実。実際、「優れたPMは勤務時間の90%をコミュニケーションに使う」というが、デスクにふんぞり返ったままじゃ、先が思いやられますな…

　残念ながら現場では、PMI の真逆を行っている。うんこミュニケーション（うんこ＋コミュニケーション）の実践例なら沢山あるぞ。

• メールを送った=読んだものと判断する：呼べば聞こえるのにメールばかりしこたま送りつけてくる。酷いのになると、「先日送ったあの件はどうなってますか?」（←本文ママ）と訊いてくる
• ノイズ入れまくり：ひょっとして意図を伝えたくないのかしらん、と勘ぐりたくなる。結論なしで「やったこと」だけをダラダラ書く。んなもんメーリングリストで流すな！
• こそあど言葉乱用：「あの件」「それについては…」で会話を成立させている。「ほら、アレだよアレ、わっかんないかなー」って、オレはオマエの番人じゃねぇ！
• 略すな！：略すということは、省略前の言葉を『お互いが』知っていることが前提。「TBを作りました」って何? Trackbackか? まさか、TeraByteなの? トロンボーン? Three quarterBacks か、テルビウムか、ブラウザのThunderbird か? ――結局テーブルを略したそうな―― その理由がイカしてる「TBの方が短くてカッコいいから」

　コミュニケーションマネジメント計画書のアウトプットの中でも、「エスカレーションプロセス」に着目したい。よくある「体制図」は自組織の体制しか書いていないが、一工夫の余地あり。その隣に、顧客の体制図も記述するわけだ。名前が決まっていなければ空欄でもOK。そいつを顧客へ提示するわけだ。「これこれの情報レベルは、この担当が扱いますよ」というメッセージが伝わるはず。で、下位レベルでは解決できない問題は、マネジメントチェーンを通じて上へ持ち上げていくことが視覚化されるわけだ。このレベルを取り違えると、とんでもない悲劇か、全くの時間の浪費か、その両方になる。

■「計画」でやっていること（人的資源）

　「人」も資源と一緒で、必要な時期に適切な人材を、必要な分だけ投入しなければならない。足りなきゃ持ってくるし、スキル不足ならトレーニングが必要（ってことはそのための期間もカネも必要）、いきなり投入しても馴染むのに時間がかかるし、他の足を引っ張るかもしれない。パフォーマンスが上がらないかもしれない。デマルコの傑作「デッドライン」には、その本質がこう書いてある。

　　　・適切な人材を雇用する
　　　・その人材を適所にあてはめる
　　　・人びとの士気を保つ
　　　・チームの結束を強め、維持する

　　　（それ以外のことは全部管理ごっこ）

　確かにその通りなんだけど、必要条件じゃぁないかと。他の要素ばかり目が行って、プロジェクトを実際に動かす「人」を疎かにしないように、という戒めとして読もう。

9.1 人的資源計画

　要員マネジメント計画書を作成する。要員マネジメント計画書には、チームメンバーの調達方法、調達時期、プロジェクトからの離任基準、トレーニングのニーズと特定、報奨の計画、法令・規則への配慮、安全上の課題、組織の要員マネジメント計画への影響が記載されている。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

PMP試験対策 2.3.5 「計画」でやっていること（リスク）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（リスク）

　「リスク」とは一般に、好ましくないことを指すが、PMBOKでは好機もリスクと定義している。プロジェクトの目標にプラスやマイナスの影響を与える不確実な事象・状態のことを、リスクと呼んでいる。

　リスクは二種類ある。「既知のリスク」と「未知のリスク」で、それぞれ、

• 既知のリスク：識別・分析済みのリスクで、対応計画を立てることができる
• 未知のリスク：予測不可。マネジメント・コンティンジェンシー予備を割当てて対処する

とある。重要なのは、「事前に分かっているリスク」は、「何らかの準備をする」か「何も準備せず、監視する」のどちらかになるだけで、その違いは優先度による、ということ。「優先度が高いにもかかわらず、分かっているのに何もしなかった」ことは、決してしない、ということ。また、「このリスク登録簿にないリスクが発生したら、このお金を使う」という予算が、別に割当てられていること（←マネジメント・コンティンジェンシー予備）も重要。

　リスクマネジメントは、一定のフローでまわされる。まず、リスクの識別でブレーンストーミングやSWOT、デルファイ法により、リスクが識別され、定性的リスク分析において、発生確率や影響度を出して、優先すべきリスクとそうでないリスクが分けられる。その後、コストや時間がかかるが、定量的リスク分析において、期待金額やデシジョンツリー分析により、リスクが定量化される。つまり、この対策をした場合のプラスマイナスの金額レベルまで分析される。定量化された優先リスクは、リスク対応計画において、リスクへの対応策が割当てられる。残ったリスクやリスク対応策により発生するリスク（二次リスク）は、低優先度リスクとともに、定例会議の議題に載せられ、監視対象となる。

　あったりまえのことながら、リスクは計画プロセスで全て明らかになるものではない。実行段階でリスクが発見されることもあれば、リスクが現実に発生してしまうこともある。PMI はプロジェクト初期段階でリスクマネジメントを始めることが重要だと説くが、プロジェクト全体で一貫してリスクに取り組む必要があるとも言っている。それぞれ次のように対処させている。

• 未知のリスクが発見された：リスク分析からのサイクルを回し、影響度・リスク対策とともに報告する
• 未知のリスクが現実に発生した：迂回策を取り、問題を回避する[p.355:PMBOK]

11.1 リスクマネジメント計画

　リスクマネジメントをどのように取り組み、処理するべきかを決める。プロジェクトを計画する初期の段階で完了すべき。リスクを構造化した体系であるリスク区分、リスクマネジメント方法論、リスク発生確率と影響度の定義などが決められる。

11.2 リスク識別

　どのリスクがプロジェクトに影響するかを見極め、リスクの特徴を文書化する。できるだけ数多くのプロジェクト関係者―― できれば全員―― がリスク識別に参加することが望ましい。1回こっきりで終わらず、プロジェクトライフサイクルを通じて繰り返し行われる。ブレーンストーミン、デルファイ法、SWOT分析、図解の技法（特性要因図、フローチャート、インフルエンスダイアグラム）を押さえておく。

11.3 定性的リスク分析

　発生確率や影響度から見て、リスクの優先順位付けを行う。つまり、何らかの対策を打っておく必要があるリスクと、放っておいて監視だけするリスクとに分け、さらに準備するべきリスクの重要度を決める。さらに、コスト・スケジュール・スコープ・品質といったプロジェクト制約条件に対するリスク許容度も査定する

11.4 定量的リスク分析

　定性的リスク分析で高優先順位のリスクに対し、数値による等級付けを行う。要は、発生確率と影響度をカネに換算する。定性→定量の順に行うが、一度にする場合もある。ユーティリティ理論、期待金額価値分析（EMV:Expected Monetary Value）、デシジョンツリー分析[p.258:PMBOK]、モンテカルロ法によるシミュレーションを押さえておく。

11.5 リスク対応計画

　プロジェクトの目標に対する好機を活用・共有・強化し、脅威を回避・転嫁・軽減するための選択肢を立案し、処置を決定する。好機・脅威の両方に共通する戦略として、受容があるが、実現したら対処する（受動的受容）と、コンティンジェンシー予備を設定しておく（能動的受容）の2種類ある。各リスク対策の責任者（リスク・オーナー）を任命し、リスクの兆候→具体的行動が取れるようにする。その結果、対応策を講じた後も残る「残存リスク」と、対応策をしたがために発生する「二次リスク」が、低優先リスクとともに監視対象に組み込まれる。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

PMP試験対策 2.3.4 「計画」でやっていること（コスト）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（コスト）

　ここに至るまでに、以下のことがなされている。ただし、常に完全に行われているとは限らない。計画プロセス群を回す中で段階的に詳細化されていればよい。

• 「プロジェクトマネジメント計画書作成」プロセスにおいて、コストマネジメント計画書が作成されている。そこでは、コストの有効桁数や測定単位（円、ドル、千円単位等）、母体組織との手続き、管理限界値、アーンドバリュー適用規則が決められている
• スコープ記述書やWBSが作成されている
• 「アクティビティ資源見積り」プロセスにおいて、資源カレンダーが作成されている
• リスク関連の計画プロセスが行われており、リスクはコスト見積りに反映できる程度まで分析されている
• 「納入者選定」プロセスにおいて、契約がなされている

7.1 コスト見積り

　資源のコストを概算見積りする。リスクも含めて見積もりの変動要因を検討すること。通貨単位で表し、プロジェクトの進展に伴って得られる追加の詳細情報を反映し、改善される。プロジェクトのライフサイクルを通じて見積り精度が上がるとしているが、これは組織のプロセス資産を有効に活用せよ、というPMI からのメッセージとも読み取れる。コスト・コンティンジェンシーもここで見積る。

7.2 コストの予算化

　プロジェクトのパフォーマンス測定をする「コストベースライン」を設定するために、スケジュールアクティビティやワークパッケージの見積りコストを集約する。コスト・ベースラインを作るのが主目的だが、そこに乗せないマネジメント・コンティンジェンシー予備を検討し、設定する。

　コンティンジェンシーとは、「不測の事態」のこと。プロジェクトを進めるに当たって、不足の事態おっと不測の事態が発生することはアタリマエ、だから予め見積もり時点から割り振っておく、というのがPMI イズム。しかも、「一定の確率で起きることが予め分かっている"不測の事態"への予備費」と「まったく予想もつかない"不測の事態"への予備費」の両方を見積りに入れておけ、という。しかも費用だけでなく、バッファ期間も見積もっておけ、だそうな。これを、予備設定分析という。

「アクティビティ所用期間見積り」プロセスの予備設定分析

• コンティンジェンシー予備を、スケジュール全体に組み入れることができる
  
• アクティビティ所用期間に対する一定比率の期間としたり、固定期間としたりできる
  
• 定量的スケジュールリスク分析で決められることもある
  
• プロジェクトが進展し、より正確な情報が利用できるようになる、削減・削除される
  

「コスト見積り」プロセスの予備設定分析

• 「コスト・コンティンジェンシー予備」と呼び、「既知の未知」に備える
  
• PMの裁量で使用できる予備費で、コストベースラインの一部となる
  
• マネジメント方法（1）スケジュールアクティビティの個々のコンティンジェンシー予備を集約して、所用期間ゼロの一つのスケジュールアクティビティとして割当て、ネットワークパス上に配置する
  
• マネジメント方法（2）上記のスケジュールアクティビティを、クリティカルチェーン法のバッファーアクティビティにする。ネットワークパスの最後に配置する
  

「コストの予算化」プロセスの予備設定分析

• 「マネジメント・コンティンジェンシー予備」と呼び、「未知の未知」に備える
  
• PMはこの予備を使用する際、承認が必要
  
• コストベースラインに含まれないが、プロジェクト予算に含まれる。したがって、アーンドバリュー計算の対象外
  

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

PMP試験対策 2.3.3 「計画」でやっていること（タイム）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（タイム）

　WBSで分けられたワークパッケージを、より小さく、マネジメントしやすいスケジュールアクティビティへ要素分解する。さらに依存関係に従って順序性を設定し、いつどのような資源がどれぐらいの量必要かを見積り、アクティビティの所用期間を見積もる。

　上記をベースに、コスト、リスク、品質、コミュニケーション、人的資源、調達の計画を立て、スケジュールを作成する。言い換えると、To Do リスト"だけ"ではスケジュールは立てられないことに注意。特に、「スケジュール作成」プロセスのインプットに「リスク登録簿」があることに注意。PMI イズムでは、『リスクは折込済みで、スケジュールを作成せよ』ということ。

6.1 アクティビティ定義

　WBS最下層のワークパッケージを元に、スケジュールアクティビティに要素分解をする。ワークパッケージが要素成果物単位なら、アクティビティは、その要素成果物を生成するために必要なリストになる。例えば、「要求仕様書の作成」がワークパッケージなら、要求仕様書を作成するために必要な作業、「ヒアリング」「要求仕様書執筆」「レビュー」「レビュー結果の反映」といった作業が各アクティビティとなる。

　あったりまえのことなのだが、一回の計画プロセスにおいて、プロジェクトの全ての作業を、完全にアクティビティまでに分解することは不可能だ。だから、PMBOKではローリングウェーブ計画法というツールを提示している。ローリングウェーブ計画法とは、直近の作業はWBSの下位レベルまで詳細に計画し、遠い作業はWBSの比較的高いレベルの構成要素で計画せよ、というやり方。で、計画プロセスをまわすことで、段階的に詳細化していけるという仕掛け。

　「ローリングウェーブ」なんてロールパンナちゃんの必殺技のような名前がついているが、スパイラル開発、RADモデルといえば理解しやすいだろうか（p.69の図なんてまさにそう）。にもかかわらず、『PMBOK = WaterFall』と誤読する輩がウソを振りまいている。

　ある程度プロジェクトを進めないと明確化できないところは、コントロールアカウントや計画パッケージの単位で管理する。それぞれの関係は、

　←←←　WBSの上位　　　　　　　　　　　　　　　　　　　　WBSの下位　→→→
　コントロールアカウント　＞　計画パッケージ　＞　ワークパッケージ（最下層）

となっている。例えば、「サービス環境の構築」というWBS要素があったすると、これを実現させるためには、「データベース」「アプリケーション」「ネットワーク環境」「ハードウェア環境」ともろもろの決め事・検証事が出てくる。最初の計画段階で決まっているものもあれば、相性を見極めないと何とも決められないものもある。そういうものは、「データベースの選定とテーブル構成」といった大きな単位で管理して、必要なときに詳細化せよ、ということ（もちろん『いつ』までに決めなきゃいけないかは、計画段階で決める）。

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

　スケジュールアクティビティ間の依存関係を元に論理的な順序関係を明確にし、文書化する。リードとラグを適用することで、現実的なスケジュールが作成できる。ただし、あくまでも『論理的な』ところがポイントで、メンバーの夏期休暇や、外部要因によるリスクの影響といった『ブレ』に相当する部分は考慮されていない。

　リードとラグ―― 自分で書くまで理解できなかったが、今は自信を持って書ける↓

リード：複数のタスクをオーバーラップできる期間（タスクBを前倒し）。例えば、仕様書の執筆とレビューは、書けた順にできるため、レビュー開始を前倒しできる。

　　├―――━━┫←タスクA
　　　　　　　┣━━――――――┤←タスクB
　　　　　　　　　↑ココ

ラグ：タスクAが終わった後、一定の期間を経たないとタスクBが開始できない期間のこと。例えば、コンクリートをうったら養生期間（コンクリを乾かす期間）が必要。

　　　　タスクA　　　　　　　　　　　　　タスクB
　　├――――┤　　　　　　　├―――――――┤
　　　　　　　　　　┣━━━━┫
　　　　　　　　　　　　　↑ココ

　アクティビティ順序設定のツールと技法であるPDMとADM、3種の依存関係は重要だが、説明しない（既に理解済みだから）。このblogで学んでいる奇特な方がおられるのなら、[p.132-134:PMBOK]を読んで一覧表を作成すると理解しやすいかと。その一方で、何度も間違えている「フロート」と「フリー・フロート」の違いは書いておこう。

• フロート（総フロート、トータルフロート）：プロジェクト全体の終了日を遅らせることなく、その作業の開始日を遅らせることができる期間
• フリー・フロート（パス・フロート）：直後の最早開始日を遅らせることなく、その作業の終了を遅らせることができる期間

6.3 アクティビティ資源見積り

　プロジェクトアクティビティの実行にあたって、どのような資源(人、機器、資材）がどれだけの量必要となるか、さらにいつ使用可能となるのかを見積もる。コスト見積と密接に関連する。

　ポイントは2つ。1つめは、インプットとして、「組織のプロセス資産」が含まれること。例えば、資源をレンタルにするか購入するかといった方針は、母体組織から提示されるから。2つめは、インプットにある「資源の可用性」。これは、どの資源（人、機器、物資）がいつ利用できるかという情報。人なら、9.2.3.2「プロジェクトチーム編成」のアウトプットとして、プロジェクトメンバーが作業できる期間が出てくる。資源なら「納入者選定」のアウトプットで資源の稼働日・不稼動日が出てくる。

　分かりやすいミスを挙げるなら、「ミドルウェアが届いたけれど、動かせる人がいない」あるいは「動かせる人は休暇中」というやつ。「必要な時に大型鋼材が届いたけれど、クレーンの準備がなされていなかったので、鋼材が降ろせませんでした」というやつ。ネタとしては面白いが、自分のプロジェクトで遭ったらヒサンだぜ。

6.4 アクティビティ所用期間見積り

　アクティビティの実際の所用期間を見積もる。作業範囲、資源の可用性、必要な資源の種類と量を元にアクティビティ単位に期間を見積もる。

　PMI ええこと言うなぁ、と思ったのは、所用期間見積は段階的に詳細化・正確化するという。エンジニアリングや設計作業が進むにつれ、より詳細で正確なインプットデータを利用できるようになり、期間見積精度も向上する、というわけ←要は、段階的に見積りを行い、精度を上げろと言っている。

　ツールと技法の類推見積り、係数見積り、三点見積りは重要だけど説明しない。このblogで学習する人は[p.141-142:PMBOK]でおさえておく。いわゆるバッファーは、PMBOKでは「コンティンジェンシー予備」と呼ばれ、予備設定分析で組み込まれる。コンティンジェンシー予備を、見積り期間の一定比率としたり、固定期間としたり、リスク分析結果によって決められたりする。

　このあたりで標準偏差や三点見積りの計算が求められる。加重平均するのが常だが、PMBOK本文には、単に「平均」と書いてある（どちらが"正しい"かは、分からない）。

　　　標準偏差=（悲観値－楽観値）/6
　　　三点見積=（悲観値＋最頻値*4＋楽観値）/6

　計画プロセス群の「タイム」は、あとひとつ、最重要の「スケジュール作成」が残っているが、いったんここで切る。というのも、スケジュール作成のためには、コスト、リスク、コミュニケーション、人的資源、調達の計画プロセスが終わっているか、ある程度進んでいる必要があるからだ。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】

PMP試験対策 2.3.2 「計画」でやっていること（スコープ）

　ここでは、「計画」でやっていることを説明する。

――――――――――――――――――――――――――――――――

■「計画」でやっていること（スコープ）

　計画プロセス群の最初にコレがきている理由を、まず考えて欲しい。

　そもそも、PMPなんて目指そうとしているのなら、失敗プロジェクトに酷い目に遭ったこともあるだろう。そして、そんな人なら、どうしてそのプロジェクトが失敗したかについて、ハッキリと言えることもあるだろう… 筆頭なのが、「何を作ろうとしているのかハッキリしないまま、プロジェクトが進められた」ではないだろうか。

　プロジェクトが迷走するようになってから、次のようなものを決めようとしても手遅れだ。そして、次のようなことを決めずにプロジェクトを開始するシニアマネージャがいかに多いことか…

• プロジェクトの目標。結局のところ、何を達成したら「プロジェクトは成功した」と言えるのか
• プロジェクトが生成するべきプロダクト、サービスといった成果物の仕様・特性
• プロジェクトに対する要求事項（契約、標準、仕様）と、その優先順位
• プロジェクトの境界。どこまでがプロジェクトに含まれ、どこからがプロジェクトの範囲外となるのか
• プロジェクトの最終的なアウトプットと、そこへ至るまでの補助的な成果物
• 成果物受入れ基準、つまり完成したモノ・サービスを受け入れるプロセスと、その基準を定義したもの
• プロジェクトの制約条件や前提条件。選択肢を制限するような具体的な制約条件、例えば予算やサービス開始の日付

　これ以外にも、プロジェクト組織、初期段階で判明したリスク、スケジュールのマイルストーン、資金、見積もったコスト、プロジェクトそのものが準拠するべき仕様書、コンフィギュレーションマネジメントと変更管理のレベル… といったものを、計画段階で洗い出して記録しておく必要があるという── つまり、これらがプロジェクトスコープ記述書に記載されることだという。

5.1 スコープ計画

　プロジェクトスコープマネジメント計画書を作成する。プロジェクトスコープマネジメント計画書とは、どのようにプロジェクトスコープを定義し、WBSを作成し、変更をコントロールし、検証するのかを記述した文章のこと。スコープの定義とマネジメントは、プロジェクト全体に影響を及ぼす。

5.2 スコープ定義

　ここでプロジェクトスコープ記述書を作成する。プロジェクトスコープ記述書には、プロジェクトの要素成果物や、要素成果物を生成するために必要な作業を記述する。暫定版をもとに、前提条件や制約条件を踏まえ、専門家の判断を入れて作成する。具体的には↑のリストで挙げた事柄が記述される。

5.3 WBS作成

　ここでWBSを作成する。WBSとはWork Breakdown Stractureの略のこと。プロジェクトでするべき作業が、プロジェクトで達成する目標→プロジェクト全体の大枠→各フェーズのフレームワーク→具体的な作業と、段階的に構造化・細分化されている。最下層はワークパッケージと呼ばれ、80時間程度の作業まで分けられる（1人の勤務時間×10日間ぐらいの作業量）

　WBSには一意の識別子（WBSコード）が割当てられ、管理単位となる。また、WBSの作業内容を詳細に記述した文書をWBS辞書と呼び、WBSコード、作業範囲記述書、担当組織、マイルストーンが盛り込まれる。

――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】