わたしが知らないスゴ本は、きっとあなたが読んでいる

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

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

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

　プロジェクトマネジメント・フレームワークの続き。組織のプロセス資産、教訓について。

　組織のプロセス資産について。組織のプロセス資産とは、プロジェクトの成功に寄与する知的情報のこと。公式、非公式を問わず、標準、方針、計画書、手順書、ガイドラインなどがある。後に説明する「教訓」も含まれていることに注意。大きく2つのカテゴリーに分かれている。

1. プロセスと手順 : 作業指示書、パフォーマンス測定基準、受入基準、要求事項、テンプレート、変更管理手順、承認・許可証の発行手続き
   
2. 企業の知識ベース : プロジェクト・ファイル、過去の情報や教訓、課題と欠陥のマネジメントデータベース、財務データベース

　教訓について。教訓とは、プロジェクトの途中や終わったときに、「ああすりゃよかった」「こうしなきゃよかった」そして、「もしもう一度やれるんなら、こうする」を集めたもの。よかったもの、悪かったものを含め、プロジェクトを実施する過程で学んだこと。プロジェクトのあらゆる局面で識別され記録される。少なくともプロジェクト終結プロセスにおいて文書化される。例として「見積もりと実績の差異の原因」「選んだ是正処置の根拠」が挙げられる。

　Rita本は挑発する、「なぜ、プロジェクトは失敗するのか？しかも、同じような失敗ばかりを？」。答えは、教訓が生かされていないから。具体的に言うと、教訓を識別し、記録し、文書化し、次のプロジェクトに向けて共有していないから。プロジェクトが軌道に乗れば、そのプロジェクトからの教訓をアウトプットとしてとりまとめる必要がある――パッと見正しいように見えるが、ウソだ。プロジェクトを始めるときに、これまでの組織の資産としての教訓をインプットする必要があるんだ。

　うーん、わたしの場合、そういう情報は「デリケートなもの」として扱われている。単にわたしが一兵卒だからという立場もあるが、部分的・断片的にしか共有されていないようだ。失敗プロジェクトは名ばかりメジャーで地獄谷の代名詞として扱われるが、「なぜ失敗したのか？」は明かされない。コストとタイムと品質の抽象論が掛け合うだけ。

　いっぽう、内規や規定や定型文書はたくさん転がっている（そういうのを集めるのが好きな会社なのだ）。しかし、「どうやったらうまくいったか／いかなかったか」は無い。個人に蓄積された know how や know who に依存しており、プロジェクトにロックインされた状態で人も教訓も澱むことになる。PMBOKの掛け声は社内で聞くようになったが、その展開のためには、（個人に試験を受けさせるだけでなく）組織としての取り組みが必要であることが分かっているのかなあ。

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

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

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

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

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

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

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

　プロジェクトマネジメント・フレームワークの続き。プロダクトライフサイクル、プロジェクトライフサイクル、プロジェクトフェーズ、プロセスについて。

　プロダクト・ライフサイクルについて。製品のライサイクルだと考えればいい。新製品の開発から市場への導入、成長、成熟、衰退、そして撤退する一連のライフサイクルを、プロダクトライフサイクルと呼ぶ。プロジェクトの概念は、その中に内包される。つまり、新製品の開発という「プロジェクト」があり、市場への投入～拡大のための「プロジェクト」が存在する。

　プロジェクト・ライフサイクルについて。プロジェクトフェーズの集合を指しているが、業界・分野によって呼び名が異なる場合がある。例えば、次のプロジェクトフェーズを束ねたものが、プロジェクト・ライフサイクルと考える。建設業の場合、フィージビリティ、計画、設計、建築、引渡しとなるが、IT業界だと、設計、コーディング、テスト、インストール、引渡しとなる。

　プロジェクト・フェーズについて。成果物に着目してプロジェクトを区切った単位を、プロジェクトフェーズと呼ぶ。ひとつのフェーズの中に、次のプロジェクトマネジメントプロセスが含まれている。即ち、「立ち上げプロセス」「計画プロセス」「実行プロセス」「監視・コントロールプロセス」「終結プロセス」のこと。単独フェーズのプロジェクトもあるし、複数のフェーズによって分けられているプロジェクトもある。あるフェーズの終結が、次のフェーズのインプットとなる。注意したいのは、フェーズが分割されているからといって、線形に（リニアに）並んでいるとは限らないこと。p.21の図2-5の場合、設計フェーズと建造フェーズが重複している。設計が完全に終わっていない段階でコーディングや試験に着手することを考えると、容易に想像できるだろう。先行フェーズの完了前に後続フェーズを開始させることでスケジュールを短縮させる技法を、ファストトラッキングと呼んでいる。

　プロジェクトマネジメントプロセスについて。全体は以下の通り。

　　　　　┌─→立ち上げプロセス
　　　　　│　　　↓
　　　　　├─→計画プロセス
　　　　　│　　　↓
　　　　　├←→実行プロセス
　　　　　│　
　　　　　├─→終結プロセス
　　　　　│
　　　　監視・コントロールプロセス

　いわゆるPDCA（Plan Do Check Action）に立ち上げと終結が入っていると考えればよい。プロジェクトを立ち上げて、計画をする。計画されたものが実行され、ベースライン通りに行われているか、監視・コントロールする（Check & Action）。変更が必要な場合は実行プロセスへフィードバックされる。変更の影響範囲が大きかったり、プロジェクトそのものへの変更が必要な場合は、計画プロセスへフィードバックされる。ベースラインから大きく逸脱し、プロジェクトそのものの見直しが必要な場合は、立ち上げプロセスに戻る。全ての作業が実行されたり、プロジェクトを中止する場合は、監視・コントロールから終結プロセスへ移る。

　ここでわたしがやった間違いは、プロジェクトライフサイクルと、プロジェクトマネジメントプロセスを混同すること。「計画プロセス=設計プロセス」とか、「実行プロセス=コーディングと試験」なんて勝手に置き換えてしまったのだ。さらに、プロジェクトフェーズと混交させるとワケ分からなくなる。それぞれの関係を、一つの例として表すとこうなる。

新製品開発プロジェクト・ライフサイクル
　┌――――――――――――――――――――
　│
　│調査フェーズ
　│　　┌―――――――――――――
　│　　│　　　┌─→立ち上げ
　│　　│　　　│　　　↓
　│　　│　　　├─→計画
　│　　│　　　│　　　↓
　│　　│　　　├←→実行
　│　　│　　　│　
　│　　│　　　├─→終結
　│　　│　　　│
　│　　│　　監視・コントロール
　│　　└―――――――――――――
　│　　　　↓
　│設計フェーズ
　│　　┌―――――――――――――
　│　　│　　　┌─→立ち上げ
　│　　│　　　├─　　…略…
　│　　│　　監視・コントロール
　│　　└―――――――――――――
　│　　　　↓
　│　製造フェーズ
　│　　┌―――――――――――――
　│　　│　　　┌─→立ち上げ
　│　　│　　　├─　　…略…
　│　　│　　監視・コントロール
　│　　└―――――――――――――
　│　　　　↓
　│　試験フェーズ
　│　　┌―――――――――――――
　│　　│　　　┌─→立ち上げ
　│　　│　　　├─　　…略…
　│　　│　　監視・コントロール
　│　　└―――――――――――――
　│　　　　↓
　│　移行フェーズ
　│　　┌―――――――――――――
　│　　│　　　┌─→立ち上げ
　│　　│　　　├─　　…略…
　│　　│　　監視・コントロール
　│　　└―――――――――――――
　│
　└――――――――――――――――――――

　ただし、これは一例であることに注意。上はプロセス、フェーズ、ライフサイクルの大小関係を分かりやすく示したものであり、必ずこのようになるとは限らない。フェーズは線形ではなく重複する場合があるし（p.21）、そもそも「1プロジェクト・ライフサイクル=1プロジェクト・フェーズ」のプロジェクトだってある（p.19）。PMBOKを「巨大システム・建造物の構築」すなわち「ウォーターフォール」だと早とちりしてたのは、ほかならぬわたし。なお、プロダクトライフサイクルとの大小関係はこうなる（プロジェクトとプロダクトの「ライフサイクル」は省略）。

　　　　　　　プロセス⊂フェーズ⊆プロジェクト⊂プロダクト

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

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

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

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

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

　【PMP試験対策】は、PMBOK4版をベースに、PMP試験の傾向と対策をまとめるシリーズ。ずっと品切れ状態が続いていたPMBOK4日本語版は、現在在庫アリ。輸入モノなので必要な人はすぐに確保すべし。

　プロジェクトマネジメント・フレームワークの続き。機能型組織、プロジェクト型組織、マトリックス型組織について。

　完全に無風状態でプロジェクトが運営されることは、ありえない。会社の文化やマネジメントのポリシー、組織上の手続きといった、プロジェクトの組織構成に、いわば"翻弄"されるのが常だ。優れたPMは、そうした組織構成を見越して、プロジェクトを有利に持っていくもの……とRita本は言う。

　組織構造のタイプ（型）は、PMがどれくらいの権威（authority）を持っているかによって決まってくる。さらに、それぞれのタイプにおける得意・不得意を把握しておけば、試験対策は充分だろう。

　機能型組織について : 最も一般的な組織構成で、部門ごとに分割されている。つまり、経理部門や営業部門、製造部門といった分け方になっている。プロジェクトはふつう、ある一つの部門の中で発生し、完結する。別の部門の助けが必要な場合、いったん部門長（p.29の言い方だと「機能部門マネジャー」）を経由して調整されてくる。例えば、「営業部門に新規ITシステムを導入するプロジェクトで、収支決済を調整する必要が出てきた。部門長で話し合い、経理から担当がアサインされた」という事例など。

　機能型組織の利点は、スペシャリストが育ちやすい。経理専門、営業専門を思い浮かべれば、そればかりやっているから当然だよね。そして、メンバーはただ1人の上司に報告すればよい。また、似たようなリソースが集中しているため、その分野のプロ単位に組織化されているし、キャリアパスがはっきりしている。

　機能型組織の欠点は、プロジェクトの遂行よりも、目先の業務をこなすことに注力しがちになることが挙げられる。さらに、プロジェクトマネージャは、何の権威もなく、プロジェクトマネジメントのキャリアパスは育たない。

　プロジェクト型組織について : プロジェクト単位に組織されているのが特徴で、PMがプロジェクト組織を担っている。メンバーは帰るべきホーム部門がなく（no home）、プロジェクトが終結すれば、別プロジェクトにアサインするか、別の仕事を見つけてもらうしかないのだ。

　プロジェクト型組織の利点は、プロジェクト指向の組織のため、案件に対し最も効率のよい組織といえること。さらに、機能型よりもコミュニケーションがやりやすい（風通しがいい）ことが挙げられる。

　プロジェクト型組織の欠点は、プロジェクトが終結したら、「ホーム」がなくなること、（経理や人事などの）プロフェッショナルが育ちにくいことが挙げられる。プロジェクト毎に経理や人事などの仕事が重複して存在するため、全社的に見ると非効率的になっているのだ。人材の育成やリソースアサインの観点からすると、部分最適となっているのがプロジェクト型組織になる。

　マトリックス型組織について : 機能型とプロジェクト型の両方の強みを生かしたのがこれ。一言でまとめるなら、「マトリックス型組織とは、ボスが2人いる組織」になる。つまり、PMのボスと部門のボスの2人だ。当然、指示がちぐはぐだったりすれ違ったりする可能性もあるが、「（帰るべき）ホームもありながらプロジェクトにアサインされる」形態となっている。p.29-30 の「強いマトリックス」や「弱いマトリックス」は何を指すのだろうか？図だけを見ても分からないかもしれない。

　実はこれ、PMの権限のことを「強い」「弱い」で表現しているのだ。「弱いマトリックス」の場合、権限は機能部門マネジャーが持っており、PMはリーダーというよりもむしろ調整役になっている。なかでもプロジェクト促進係（project expediter）は権能が弱く、スタッフのアシスタント役か連絡係のような役割となっている。いっぽう、プロジェクト・コーディネーター（project coordinator）は、プロジェクト促進係よりも権能が強く、一部の決定権や上級マネージャーへの報告といった役割を担っている。

　マトリックス型組織の利点は、プロジェクトの目標が見えやすいこと、機能組織からのサポートが受けやすいこと、帰るべき「ホーム」があることが挙げられる。さらに、限られたリソースを最大限に用いる、リソース管理能力が育てられる。つまり、プロジェクト型だと（担当の重複で）リソースのムダ使いするかもしれないし、機能型だとPMの権限が少ないためリソース管理をさせてもらえないかもしれない。その両者の欠点を克服しているのが、マトリックス型組織になる。水平・垂直の両方向にコミュニケーションが取れる。水平は、プロジェクトメンバー同士。垂直は、プロジェクトマネージャ同士で、連絡が密になる。

　マトリックス型組織の欠点は、プロジェクトチームにとって、報告するべきボス・上司が2人以上いること、コントロールが複雑なところ、リソースの割り当てが難しいところ……と多数上げられる。優先順位づけがプロジェクト／機能部門で異なる場合、マネージャーどうしの調整が大変になる。また、仕事を進める上での方針や手続きが、両部門にまたがるため、やはり複雑なプロセスになる。

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

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

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

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

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

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

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

　プロジェクトマネジメント・フレームワークの続き。プログラム、ポートフォリオ、PMO、目的によるマネジメントについて。

　「プログラム」とは何か。プログラムとは、プロジェクトをグルーピングしたものであり、複数のプロジェクトの協調させ、調和が取れるようにマネジメントする。一例として、ロケット開発プログラムでは、ロケットエンジン、本体、衛星のそれぞれの開発プロジェクトを協調させながらすすめる必要がある。

　ただし、プログラムには反復的および周期的業務も含まれることに注意。PMBOK3版p.16の例によると、公共事業では、年次「建設プログラム」と呼ばれるが、これは毎年積み重ねで実施される一連の建設プロジェクトのことを指している。プロジェクトは周期性を持たないが、プログラムは周期性を持つ業務「を含む」のだ。

　「ポートフォリオ」とは何か。ポートフォリオとは、プログラムとプロジェクトをグルーピングしたものであり、ビジネス上の戦略的目的を達成するためにまとめられている。ひとつのポートフォリオに、複数のプロジェクト、プログラム、定常業務が含まれている、と考える。

　「プロジェクトマネジメント・オフィス（PMO）」とは何か。ともすると分散しがちなプロジェクトのマネジメントを集中化させるたに、次のような役割を果たすオフィス。①組織におけるPMポリシーや方法論、テンプレートを提供する。②組織においてプロジェクトをマネジメントするためのサポートやガイダンス、トレーニングを行う。③プロジェクトマネージャを提供し、プロジェクトの結果に責任を負う。

　PMOが超越的な権限を持っている人だと考えてはいけない、あくまでも一組織だ。そして、組織によって様々な役割を果たす。たとえば――プロジェクト間の相互依存関係を調整したり、プロジェクトを終結させたり、組織のルールとしてコンプライアンスをモニタリングしたり、教訓を収集して組織内で共有化したり、変更管理委員会として働いたり、ステークホルダーそのものとなったりする。

――とRita本にあるが、PMの吹き溜まりとなってやしないだろうか？かつては敏腕を鳴らしたPMでも、技術革新に取り残されたり、貢献に見合うポストが提供できなかったりの理由で、PMOに「安置」させられてやしないか？PMOを設置してこれで大丈夫だと胸を張る経営者を見ていると、そんな疑問が頭から離れない。

　そんなわたしの疑いに応えるように、Ritaはこう述べている。PMOは最近のトレンドだが、まともに働かせるためには、①役割の明確な定義づけ、②なんにでも関わらないこと、③有資格者（PMP）が携わること、④トップマネジメントのコミットメントと関与が必要などと述べている。そもそも、PMO自体が適切なプロジェクトマネジメントを要するので、「組織をつくればOK」という経営者が安易過ぎることがよく分かる。ああ、誰かさんに読ませてやりたいナリ。

　「目的」とは何か。プロジェクトマネジメントにおける「目的」とは、「そのプロジェクトの結果、生み出されるサービスや製品」だけではないことに注意。目的は、プロジェクト憲章など、プロジェクトを通じて生み出されるものを含む。目的は、立ち上げ時に特定され、計画時にブラッシュアップされる。つまり、そのプロジェクトで何を目指すのか？が最初に決められるのだ。

　目的が、「予定通り」であれば、それは上手くいっているプロジェクトと呼んでもいい。逆に、目的に適っていないプロジェクトは、それをやめさせる理由にもなる。そのため、プロジェクトに対する要求と目的は、トレードオフの関係になることがよくある。言い換えると、「目的」とは、作業が向かうべき方向であり、達成すべき目標であり、取得すべき所産や、産出すべきプロダクト、実行すべきサービスだったりする。

　また、「目的によるマネジメント」（MBO/Management by Objectives）とは、次の3ステップによる。①具体的な目的を確立し、②その目的に適応しているか、定期的にチェックし、③必要に応じ是正処置を施す。

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

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

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

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

【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試験対策【まとめ】