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

PMP試験対策 2.3.1 「計画」の目的

　ここでは、「計画」の目的を説明する。

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

■「計画」の目的

　プロジェクトマネジメント計画書を作成することが目的。段取り8割、なんだ単純じゃん、と言う莫れ、ここをちゃんとやらない場合、プロジェクトの失敗確率は→100%となる。エイブラハム・リンカーンの「木を切り倒すのに6時間もらえるなら、私は最初の4時間を斧を研ぐことに費やしたい」を思い出す。

　PMI は計画プロセスを非常に重視している。現実は、「先行き不透明だから計画なんてぶっちゃけありえない」なのだが、計画プロセス群を繰り返しまわし、フィードバック・ループをまわしたり、ローリング・ウェーブにより段階的に詳細化することで精度を高めよ、という。ベースラインが決まっていないと、どれぐらい予実が乖離しているかすら気づけない。

4.3 プロジェクトマネジメント計画書作成

　では、プロジェクトマネジメント計画書とは何か。プロジェクトマネジメント計画書とは、どのように作業を実行するかを記述したもので、以下のものを指す。

• スコープマネジメント計画書
• スケジュールマネジメント計画書
• コストマネジメント計画書
• 品質マネジメント計画書
• 要因マネジメント計画書
• コミュニケーションマネジメント計画書
• リスクマネジメント計画書
• 調達マネジメント計画書

　それぞれの知識エリアと一致している。こいつに「プロジェクトスコープ計画書」と「プロジェクト憲章」を加えると、主要なプロジェクト3大文書となる。

　ちょっと図を見て欲しい。

　計画プロセス郡の中の一番はじめに「プロジェクトマネジメント計画書作成」がある。で、下のほうへいくと、スコープ、タイム、コスト、リスク、品質、コミュニケーション、人的資源、調達、と各知識エリアごとに計画プロセスが続き、おのおので各々のマネジメント計画書を作成する。ん、おかしくないか?

　スコープ、タイム、コスト、リスク… のマネジメント計画書を合わせて、「プロジェクトマネジメント計画書」ができ上がるはずなのに、計画プロセスの最初にあるのはヘンじゃないか? ── その指摘はとても正しい。

　実はこれ、2回目以降のことを言っている。つまり、初回は各知識エリアのプロセスを回さずに、組織のプロセス資産などを用いてマネジメント計画書を作り、各知識エリアの計画プロセスに入る、そして計画プロセスを繰り返しまわして行くことで肉付けを行っていくというわけ。「プロジェクトマネジメント計画書」は1回つくったらそれでオシマイではなく、繰り返すことにより進化させていく。

　何をプロジェクトマネジメントの計画書として扱うかは、以下のとおり。

• どのプロジェクトマネジメントプロセスを行うか、決める
• 決めた各プロセスを、どの程度まで実行するか、決める
• プロセスを実行する際に使うツールと技法を盛り込む
• プロジェクト目標を達成させるための作業の実行方法を決める
• 変更を監視し、コントロールする方法を検討し、決める
• コンフィギュレーションマネジメントの実施方法を決める
• ベースラインを決める（スケジュール、コスト、品質、パフォーマンス測定）
• ベースラインの一貫性を維持するための方法を決める
• ステークホルダー間のコミュニケーションのためのニーズ・技法を決める
• プロジェクトライフサイクルを決める
• 未決課題や未決定項目を解決するためにどうマネジメントしていくか、決める
• マイルストーンを洗い出し、リスト化する
• いつごろ、何（人、もの、技術、カネ、資材）が必要になるかかを判断し、資源カレンダーを作成する

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

PMP試験対策 2.2 立上げ

　ここでは、「立上げ」の目的と、行っているプロセスを説明する。

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

■「立上げ」の目的

　プロジェクトを「正式」なものにすることが目的。正式なものにするために、公式な認可を支援したり、プロジェクトのフレームワークを明確化したりする。

　注意点は、1回だけではないこと。プロジェクトが複数のフェーズに分かれている場合は、フェーズごとに「立上げ」がなされることがある。このとき、立上げでは、プロジェクトに必要な資源の可用性や開始基準が検証され、プロジェクトを続けるか、遅らせるか、中止するかの決定が下される。

■「立上げ」でやっていること

4.1 プロジェクト憲章作成

　ビジネスニーズやプロジェクトの妥当性、顧客の要求事項の文書化を行う。また、これらの要求事項を満たすプロダクト、サービス、所産（result）の文書化も行う。プロジェクトマネージャの権限レベルや要約予算も記載する。プロジェクト憲章により、プロジェクトは正式に認可される。

4.2 プロジェクトスコープ記述書暫定版作成

　プロジェクト・イニシエーターやスポンサーから提供される情報をもとに、プロジェクトと成果物への要求事項、プロダクトやサービスの要求事項を文書化する。同時に、プロジェクトの境界や、成果物の受入れ方法、スコープのコントロール方法も検討し、文書化する。初期のWBSや超概算見積り（-50%から+100%の見積り精度）、制約条件や初期のリスクも記載する。

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

PMP試験対策 5.3 解答のポイント

　ここでは、間違えやすいポイントを挙げる。

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

　PMBOK2000版の「ひっかけ問題はこう出る／こう答える」[参照]とほとんど同じだが、その後の勉強でわたしが気づいたことを加筆し、自明だと判断したところは削除してある。

1. 「…以外は何か?」や「…でないのは何か?」などの設問。酷いのになると、「PMが最後にするべきものは何か?」とくる。もちろん「最後にする＝一番やっちゃいけない」と読み替える
2. 「正しい」答えと「ベストな」答えの二つに迷うことがあるかもしれない。そのときは「ベストな」を選ぶこと。もちろん、このベストは、「プロジェクトマネージャが選ぶベストな」という意味で選ぶ
3. 正しいことを言っているんだけど、設問に答えていない選択肢がある。もちろんダミー
4. 「完全に」とか「必ず」を含む選択肢は、まず間違い。代わりに「おそらく」「一般的に」を含む選択肢は、正解に近いといえる
5. 正しいことを言っているんだけど、設問に答えていない選択肢がある。もちろんダミー
6. 「組織のプロセス資産」に注意。これは、あちこちで出てくるにもかかわらず、そのプロセスで必要としている側面によって中身が大幅に変わってくる。例えば、スコープ計画プロセスでのインプットでは、「組織の方針や手順」「過去の教訓」とあるが、品質計画でのインプットだと「母体組織の品質方針」「過去のデータベース」となる
7. PMは「プロアクティブ」でなければならない。試験ではこの「プロアクティブ」という単語はそのままでてこない。PMは先見の明を持ち、問題を事前に捉え、早期に変化を察知し、先行して手をうつもの
8. PMはバランスが肝心。制約3要素「スコープ」「スケジュール」「コスト」の間のトレードオフを図りながら結果を出すことを「品質が良い」という。よくある「スコープ盛りだくさん＝金メッキ」や「バグが少ない」ことは、品質が良いと言わない
9. リスクに注意。「リスク」というとネガティブな意味にとられがちだが、PMI ではチャンスも含む。プロジェクトの目標にプラスまたはマイナスの影響を与える不確実な事象を指す。PMはプラス要素を最大化し、マイナス要素を最小化することが肝要だと説く

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

PMP試験対策 2.1プロジェクトマネジメント・プロセス

　ここでは、単一プロジェクトのプロジェクトマネジメント・プロセスについて説明する。マネジメントプロセスは、プロジェクトをまわす手順だと把握しておけばよい。

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

■プロジェクト成功の定義[p.37]

　「プロジェクトが成功する」とは、どういうことか? PMIはプロジェクト成功の定義を謳っている。よく言われる、品質・納期・コストを守るでは不十分で、以下のように定義される。

• プロジェクト目標を満たすために必要なプロセスを選択する
  
• 要求事項をみたすように成果物の仕様と計画を調整する
  
• ステークホルダーのニーズ、要望、期待に応じた要求事項を満たす
  
• スコープ、タイム、コスト、品質、資源、リスク等の競合する要求のバランスをとって、高い品質のプロダクトを生成する
  

■プロジェクトマネジメントプロセスのカテゴリ[p.38]

　ふたつある。構造化モデルとオブジェクト指向のカテゴリに近い分け方で興味深い。

• プロジェクトマネジメント・プロセス：プロセス（手続き）指向のマネジメント。統合された目的（立上げ、計画、事項、監視、終結）へ向けて実行することで相互に関連するプロセス群
• 成果物指向プロセス：プロジェクトの成果物の仕様を決めて、それを作るためにどうすればよいかを具現化するやり方

いずれの場合でも、考慮するべきプロセスを選ぶ際、PMBOKガイドを利用して、必要にあわせてカスタマイズしなさい、という。これを「テーラーリング」と呼んでいる。

■プロジェクトマネジメント・プロセス[p.40]

　[p.40]の図が全て。ただし、次のことが忘れがち→マネジメントプロセスは、フェーズ内でも回るし、プロジェクト内でも回る（プロジェクト全体を示した図だけではないことに注意！）。プロジェクトマネジメントプロセスのピラミッド[p.69]を見ると分かるが、フェーズで少なくとも1度は回っていると考え、フェーズごとに回転していると理解する。

　プロジェクトマネジメント・プロセス群は、プロジェクト・フェーズではない（←超重要）。よくあるひっかけが「終結プロセスに入った。プロジェクトはもうすぐ終わるか?」といった設問。フェーズの終わりでも「終結プロセス」は存在するため、答えはNOになる。例えば、「要求仕様の抽出を行う」フェーズがあるとすると、「要求仕様書の引継ぎ」が終結プロセスで行われる。でも開発は続くヨどこまでも、次のフェーズになるだけで、プロジェクトは終わらない。

■プロジェクトマネジメント・プロセス群の攻略の前に

　個々のプロセスの話に飛び込む前に、そのプロセスが全体のどこに位置しているのかを考えながら理解する。いきなり細かい話になるので、全体とのつながりが見えにくくなり、「結局どうしてそのプロセスが必要なんだっけ?」と考えるようになる。

　そうならないためには、[p.70]の一覧表と、[p.337]から始まる付録F「知識エリアの要約」が役に立つ。一覧表は、そのプロセスが、立上げ、計画、実行、監視、終結のどの群に配置され、知識エリアのどこに位置しているかが一目でわかる。また、「知識エリアの要約」は、初めてPMBOKを読む人が目を通すには最適の資料だと思う。たった5ページに凝縮されており、「結局ソコで何すんの?」という質問に明確に簡潔に答えているから。

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

PMP試験対策 1.2プロジェクト・ライフサイクル

　ここでは、プロジェクト・ライフサイクルについてまとめる。

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

■ プロジェクト・ライフサイクルの特性

　あたりまえだが、プロジェクトはいくつかのフェーズに分割される。どのように、いくつに分割されるかはプロジェクトによって異なるが、システム開発でいうならば、大きく、設計/製造/テストに分けられる

　もちろん開発手法によって種々の分け方・呼び名があるし、あるフェーズを繰り返しているところもあるだろうが、そうした分割したフェーズの集合体をプロジェクト・ライフサイクルと呼んでいる。

　[p.21:PMBOK] の図のポイントは以下のとおり。絵で見ると一発なので絵を見よ。

プロジェクトの開始時	プロジェクトの中間	プロジェクトの終了時
要員数やコストは少	最大	急激に落ち込む
リスク最大	徐々に減っていく	リスク最小（→完成）
変更（手戻り）コスト極小	徐々に増えていく	変更コスト極大
ステークホルダーの影響力大	影響力はだんだん減っていく	影響力はほとんど及ばない

　プロジェクトの初期はリスクが極大のため、そもそもそのプロジェクトを実施するべきか否かを調査することがある。これをフィージビリティ・スタディと呼ぶ。

■ プロジェクト・フェーズの特性

　フェーズの特性としておさえるべきところは、要素成果物（仕様書、プロトタイプ、サービス）の完成や承認により特徴付けられる。通常、フェーズ終結時のレビューは、現在のフェーズを終了させ、次のフェーズ立上げの承認を得る意味を持つが、フェーズの完了が次のフェーズの開始を意味するわけではないことに注意。

■ プロダクト・ライフサイクルとプロジェクト・ライフサイクルの違い

　[p.24:PMBOK]の図が全て。

■ プロジェクト・ステークホルダーとは

　プロジェクトに積極的にかかわっている人、プロジェクトからプラス・マイナスの影響を受ける個人や組織、プロジェクトの目標や成果物にプラス・マイナスの影響を及ぼす人[p.25:PMBOK]

　ステークホルダーとプロジェクトの関係図は、ちょっと変わっている。「プロジェクト・スポンサー」の位置付けがヘンなのだが、理由があるに違いない。スポンサーは、ステークホルダー、マネジメント・チーム、プロジェクト・マネージャと境界を接しているが、より広く接している「スポンサー」と「マネジメント・チーム」と密接に関係しているとか。

■ 組織構造

　[p.28:PMBOK]の図が全て。補足として、マトリックス型は二人の上司（プロジェクトのマネージャと機能部門のマネージャ）に報告義務があるとか、弱いマトリックス型だとプロジェクトマネージャの役割は調整役となるとか（調整役の方が格上）

• プロジェクト調整役（Project Coordinator）
  
• プロジェクト促進役（Project Expeditor）
  

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

PMP試験対策 1.1フレームワーク

　ここでは、プロジェクトマネジメントフレームワークについてまとめる。プロジェクトマネジメントそのものの『定義』の話。

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

■ PMBOKガイドの目的

　第一の目的：プロジェクトマネジメント知識体系のうち、良い実務慣行（good practice）と一般的に認められている部分を特定する。「良い慣行」が"best practice"でないところがミソ。つまり、選択肢中に「唯一の」「最も」「ベストな」が出てきたら疑ってかかる。

　他の目的として、共通用語集、PMBOK知識体系の入り口、PMP育成の参考書といった位置付け。つまり、この分厚なPMBOK3版は入門書（guide）なんだよと言っている。

■ プロジェクトとは何か

　1.有期性（スタートポイントとエンドポイントがある）
　2.独自の（unique）プロダクト・サービス・所産（result）
　3.段階的詳細化（proguressive elaboration）でだんだん詳細化される

　いっぽう、定常業務は業務が継続して反復的に行われるトコがミソ。

　また、プロジェクトは戦略計画を達成する手段の一つとして、市場需要、組織ニーズ、顧客の要求、技術進歩、法的な用件を考慮した上で決定される。

　いつから燃えてるのか分からない火事場に放り込まれ、当初メンバーは逃げ出して「何を作るのか」はアイマイなまま、段階的にスコープが拡大していく（スコープクリープというらしい）―― プロジェクトの定義から最も遠いところで働く。

■ プロジェクトマネジメントとは何か

　プロジェクトマネジメントとは、プロジェクトの要求事項を満足させるために、知識、スキル、ツールと技法をプロジェクト活動へ適用させること。「要求事項」は、必ずしも顧客の要求事項だけに限らないところがミソ。

　具体的には、要求事項を特定し、目標を確立し、品質・スコープ・タイム・コストの競合する要求のバランスをとり、ステークホルダーがそれぞれ抱える関心・期待に応えるために、仕様・計画を適用させる ―― 上司に読ませてやりたい orz

■ プロジェクトマネージャとは

　プロジェクトマネージャとは、プロジェクト目標を達成する責任を負う人のこと。プロジェクトの実行責任者であり、失敗したときは説明責任がある。チームをアシストし、ステークホルダーの対立を解消する人でもある。制約三条件のバランスをとりながら、プロジェクトをファシリテートする人

　制約三条件として、スコープ、タイム、コストがある。品質は含まれない。プロジェクトの品質はこの3要因のバランスを取ることによって決まる。つまり不具合ゼロのシステムを期限通りサービス開始できたとしても、予算を大幅超過してたら、プロジェクトとしての品質は悪い、ということやね。

■ ポートフォリオ、プログラム、プロジェクト、サブプロジェクト

　ネストはこんな感じ。定常業務はプログラムの配下にぶら下がるところがミソ。

　　ポートフォリオ
　　　└プログラム（複数のプロジェクト、定常業務含む）
　　　　　　├プロジェクト
　　　　　　│　└サブプロジェクト
　　　　　　└定常業務

■ プロジェクトマネジメントに必要な専門領域

　[p.13:PMBOK]の図を参照。PMBOKだけではない。適用分野の標準・規制、プロジェクト環境（文化・社会的環境、国際環境、物理的環境）、一般的なマネジメントスキル、人間関係のスキルがあるそうな。PMBOKはプロジェクトマネジメントを行うために必要な専門領域の『一部』であるところがミソ。

■ PMOとは

　プロジェクト・マネジメント・オフィスのことで、複数のプロジェクトを一元管理し、プロジェクト間の調整を図る… とあるが、リアルは単なるテンプレ屋だったり火消し屋衆の寄せ集めだったりするので要注意。

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

PMP試験対策【まとめ】

　PMP試験対策の入口へようこそ。

　PMP対策のための一連のエントリは、ここにリンクを貼り、（わたしを含め）読者のお役に立てるようにする。コンテンツも無いのにいきなり【まとめ】を作ったのは、自分を追い込むため。さらに宣言する→2007.1 中にPMP資格試験を受験し、合格する

このシリーズの目的

• PMP試験に『わたしが』合格する（2007.1） 合格しますた（2007.1.20）
• PMP試験対策で勉強したことを整理するために書く

（わたしを含む）このシリーズを読む人のための注意事項

• PMBOKガイド3版がベース
• Rita 本は2000年版がベース（したがって、古い）
• あくまで『わたしの』理解なので、誤りがあるかもしれない。読み手は参考程度に留めておいたほうがよいかと
• まちがいじゃね? ツッコミ歓迎
• PMBOK3を持っていることが前提（のつもりで書くので、2000版との違いだとか、インプット/ツール/アウトプット一覧とか、どこかに載っていそうなものは割愛）
• 参照方法[p.40:PMBOK]と書いたとき、PMBOKガイド3版の40ページのこと（無料の pdf は[ここから入手]できるが、登録が必要なのと英語なのでご注意）
• pdf（英語）、ペーパーバック（日本語）、ペーパーバック（英語）全て同じページ番号なので、原著にあたるとき便利かも
• 前回[参照]と異なり、網羅性は追及しない。採れるところはPMBOKガイドでおさえ、ヤヴァそうなところはこのblogで徹底的につぶす
• オタネタ禁止（できれば）

このシリーズは、たぶん、次のような構成になる。

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

1. まず全体を把握する
　1.1 フレームワーク
　1.2 ライフサイクル

2. プロセスから整理する
　2.1 プロジェクトマネジメント・プロセス
　2.2 立ち上げプロセス
　　　2.2.1 「立上げ」の目的とやっていること
　2.3 計画プロセス
　　　2.3.1 「計画」の目的
　　　2.3.2 「計画」でやっていること（スコープ）
　　　2.3.3 「計画」でやっていること（タイム）
　　　2.3.4 「計画」でやっていること（コスト）
　　　2.3.5 「計画」でやっていること（リスク）
　　　2.3.6 「計画」でやっていること（品質、コミュニケーション、人的資源）
　　　2.3.7 「計画」でやっていること（調達）
　2.4 実行プロセス
　2.5 監視・コントロールプロセス
　2.6 終結プロセス

3. 計算問題は確実に取る
　3.1 アーンド・バリュー
　2.2 クリティカルパス
　3.3 コミュニケーション・チャネル
　3.4 三点見積り
　3.5 IRR　[p.146:Rita]
　3.6 ペイバックピリオド
　3.7 BCR（利益コスト率）
　3.8 機会コスト
　3.9 サンクコスト

4. 『わたしが』覚えるべきこと

5. おまけ
　5.1 PMP試験対策（PMBOKガイド2000版対応）シリーズの入口
　5.2 なぜPMP試験は難しいのか?
　5.3 解答のポイント
　5.4 PMP受験報告
　5.5 「PMP試験実践問題」はアラ探ししながら読むのが正しい
　5.6 PMP試験の準備（わたしの場合）

――――――――――――――――――――――――――――――――
履歴
2006.11.10追加　PMP試験対策　1.1 フレームワーク
2006.11.14追加　PMP試験対策　1.2 プロジェクト・ライフサイクル
2006.11.21追加　PMP試験対策　2.1 プロジェクトマネジメント・プロセス
2006.11.30追加　PMP試験対策　5.3 解答のポイント
2006.12.15追加　PMP試験対策　2.2 立ち上げ
2006.12.17追加　PMP試験対策　2.3 計画
2006.12.19追加　PMP試験対策　2.3 計画
2006.12.27追加　PMP試験対策　2.3 計画
2006.12.30追加　PMP試験対策　2.3 計画
2007.01.05追加　PMP試験対策　2.3 計画
2007.01.24追加　PMP試験対策　5.4 おまけ
2007.01.29追加　PMP試験対策　5.5 おまけ
2007.02.02追加　PMP試験対策　2.3 計画
2007.02.08追加　PMP試験対策　5.5 おまけ

なぜPMP試験は難しいのか?

　語弊があるのでこう言い換える── 「なぜわたしはPMP試験対策を難しいと感じたのか」ってね。2年前に始め、投げ出した受験勉強で、少なくともこの疑問に答えられるようになったので、書く。再起動の意思を込めて。

■ 範囲が膨大

　試験対象はPMBOK3、すなわち、プロジェクト・マネジメント知識体系ガイド第3版なんだけど、A4版で400ページある。たっぷり文字が詰まっているので、初めて開けたときは正直ひるんだ。

　しかし、見方を変えるとここからしか出ない、とも言える（プロフェッショナル責任は別）。PMBOKガイド＋問題集＋αで、合格ラインの勉強時間の目安は、およそ120時間だという。もちろんこれより短い時間で合格した人もいるし、もっと長い時間をかけても不合格だった人もいる。それでも、最低でもこれぐらいやれるようにスケジュールを組みなおそう。

■ アタマに入ってこない

　PMBOKは「知識体系」なので、実践での適用とは異なった順番で説明されている。たとえば品質マネジメント。「品質計画」「品質保証」「品質管理」のそれぞれのプロセスは、異なるフェーズで実施されるプロセスであるにもかかわらず、8章プロジェクト品質マネジメントにてひとくくりで説明されている。「品質マネジメント」に特化して、

　1. 計画プロセスで品質計画を立てる
　2. 実行プロセスで品質を保証をする活動を実施する
　3. 監視プロセスで品質管理を行う

　のように書いてあり、それぞれのプロセス内での相互依存関係で語られていない。体系的なものにするために、それぞれのプロセスから摘出しているわけ。これがアタマに入ってこない最大の理由。

　プロセス順に考えると、「品質計画」に先行するプロセスは「WBS作成」で、後続するプロセスは「スケジュール作成」だ（p.47:PMBOK）。その結果、

　1.WBSを作成する
　2.（WBSを元に）品質計画を立てる
　3.（品質計画を元に）スケジュールを作成する

　この順番で作業が進む。流れが納得できるし、何よりもそのプロセスのアウトプットが、後続プロセスのインプットになることが理解できる。だから3章のプロセス相互作用図を見ながら、プロセス順にインプット→ツール→アウトプットを押さえるべし。

■ なぜ『正解』なのか納得できない

　ためしに問題を解いてみると、ボロボロの結果になる。『正答』なる選択肢を見ても納得できない。なぜそれが正解なのか理解できないし、説明はPMBOKガイド○ページ参照とあるだけ。実際のプロジェクトではそれは『正解』からは程遠い選択肢なのに…

　それは、解く姿勢が間違っている。アンタのプロジェクト経験談を訊いているわけではなく、PMIなら何を推奨するか、と問うているわけなのよ。典型的なのは、対立の解決手法。以下の手法のうち、最も妥当なものに○、もっとも不適当なものに×をつけるなら、どうなるだろうか?

• 強制：業務命令、執行指示×
  
• 撤退：意見を取り下げて、相手に従う
  
• 鎮静：同意できない点は目をつぶって先送りする
  
• 妥協：ギブアンドテイク○
  

　答えは反転文字で書いた。現場で対立が昂じてきてどうしようもないほどヒートアップしたとき、「○」で記した解決策はありえない。少なくともわたしの経験では、むしろ「×」で記した方が有効だった。

　だから、自分の経験で回答しようとすると、間違いなく間違える。だから真偽はともかくガイド通りに答えるのが吉。

　さて、ネットに向かって宣言することで自分を追いやってみるとしよう ── PMP対策の勉強を再開する。合格期限は、2007.1 とするってね。短期決戦のため、以前のように勉強の軌跡を記す余裕はないだろうけれど、自分が学んだことを整理する場として、このblogを使ってみるつもり（誰かの役にたつとイイナ！）。

⇒以前のPMP対策シリーズ：プロジェクト・マネジメント・プロフェッショナル資格試験対策（※注：PMBOK2000版）

ウォーターフォールはこう使え（まとめ）

　この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。

　…というわけで、ここでは総括＋補足して締める。

* * *

　ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1）

1. プロジェクトを構造化し、段階を踏んで要素成果物を構築する
   
2. 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる
   
3. 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる
   

　プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープンになり、ベースが明らかになるのでそこへの変更が「変更」として管理できる。（その2）

　クリティカルパスによく乗っかりがちな「仕様の確定」は、日付を決めることで現実的なものにする。契約前はペラペラだろうし、プロジェクト終盤では遅すぎる。だから、契約直後になんとしてでも形にする。そのためには、プロジェクト序盤で、「仕様が明確化されていない」事実を顧客自身の口から言ってもらう。（その3）、（その4）

　責任問題となったとき、最終的にプログラマを「守って」くれるのはドキュメント。プロジェクトが傾いたとき、その建て直しの土台となるのがドキュメント。ソースから自動生成できるが、全部読んで理解することを顧客に求めるのは無謀というもの。ドキュメントとは契約書だと意識すること。（その5）

* * *

　変更、特に仕様の変更について。ウォーターフォール・モデルで「変更」は別ライン、すなわち未来日の peak で受け渡しを約束する別チームが対処する。

　そのためには、リソースを新たに割り当てなければならない。これを嫌がるPMは現在のチームでその作業をさせようとする（←これが間違い）。その結果、現行チームの能率が大幅に低下し、クリティカル・パス上の神輿のスピードが落ちる→未来日の peak に間に合わなくなる… という悪循環がある。

　一方、きちんとリソースを割り当て、別チームが出発できれば、これほど理想的に働く方法はないといえる。なぜなら、未来日の peak で現行チーム・別チームが合流するようコミットできるからだ。ウォーターフォールでマイルストーンの「日付」にやかましいのは、その日をプロジェクト全体として保証するため。「次」はもうないのだ。

* * *

　ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」を割り当てられたチーム内で実行するのはスパイラルが適している。

　つまり、マイルストーン＋成果物のマネジメントはウォーターフォールで、「方式」や「業務」で、peak とチームが割り当てられた中ではスパイラルで回すほうが良い結果を出している。契約のコミットが求められ、後戻りができないものはウォーターフォール、ある程度分解された目標をクリアするにはスパイラルが良い（と経験的に知った）。特に「方式」のネットワークやデータベースアクセス、部品の開発にはスパイラルが最適。

* * *

　わたしはウォーターフォール信者ではなく、アンチ・アジャイルというわけでもない。ウォーターフォール・モデルでのプロジェクト経験が多かったというだけ。良いウォーターフォール悪いウォーターフォールの双方ともに、沢山の knowledge を積んできている。だから、危機に陥ったときどうすればよいか適切に判断できるし、そもそも酷い目に遭わないようにするには何を準備しておくべきなのかも身をもって知っている。

　フシギなことが一つある。スパイラルであれアジャイルであれ、RUPでもいい。世に問われてから随分と時間が経っているが、knowledge は積まれているだろうか? 偉大なるグルの著作物のことではない。ありゃ"教科書"だ。そうではなく、実践において結果を積んでいるだろうか? 単なる「プログラミング＋アルファ」のレベルを超えて、プロジェクト全体を任せられるものとして育っているのだろうか?

　プロジェクト全体を任せた事例があるなら、紹介してほしい。断っておくが、「実験的なプロジェクト」や「どっかの研究室が主催したやつ」ではない。また、一度きりではなく、繰り返し（＝spiral）実践で培った事例だ。10年以上前、まだ「オブジェクト指向」が手垢にまみれてないときから、ずっと探してきたが、いまだに見当たらない。

* * *

　また稿を改め、ウォーターフォールならでの事例を紹介してみたい。あるいはもっと体系的に書き直すべきかも。いずれにせよ、次回からは「スゴ本」の紹介に戻るとしよう。

ウォーターフォールはこう使え（その5）

　ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。

* * *

ドキュメント＝契約書

　なぜドキュメント化が嫌われるのか?

　SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。

　本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。

　これを理解しないまま、ドキュメント排斥を追求すると、思わぬところで足をすくわれる。例えばトラブル。巨大システムもjob sequenceひとつ間違えただけで全面停止になることがある。アナタのアウトプットが起因でトラブルが発生した場合、誰が守ってくれるのか?

　じっさいそういう場面に出くわせば分かるが、誰もアナタの仕事の正当性を保証してくれない…ていうかできない。イザとなったら自分の身は自分で守らないと。そのときの命綱がドキュメントだといえば、少しは怖がってもらえるだろうか。

　「ドキュメント要りませ～ん、開発現場に顧客が同席しているから」

　「動くプログラムから仕様書を自動的に作るから問題ありません」

なんて、どこの研究室の話ですか? あるいはどこの実験「だけの」プロジェクト? とツッコミたくなる。

　顧客はごく少人数で、サービス開始後も同じ開発者が傍らですぐ控えております、なら分かるが、そんなわけない。"顧客"の背後に控えているおおぜいのオペレータの視線を感じたことがないか。目の前の"顧客"を口頭と目視で納得させればOKだなんて、ムシがよすぎやしないか。

　あるいは、ソースから生成した日本語として体を成していないクソ資料を全部読んで理解して、かつ「承認」してくれる顧客がいるならともかく、そんな人間すらいない…ってか「ソースコードが仕様書です」と本気でいう奴はソースから生成したドキュメントを読んだことがあるのか? と問いたい。自分が書いたやつだけでなく、"全部"だ。あれは開発や保守で大づかみに理解したりするために使うんだよおぉぉ。

　ドキュメントを軽視した結果、土壇場になって「オレはそんなこと言ってない、証拠を見せてみろ」と手のひらを返されたことが一度でもあるならば、おいそれと↑のようなセリフは吐けない。ドキュメントとは契約書なのだから。

* * *

ドキュメント＝チーム間の橋渡し

　顧客とベンダとの契約書になるだけではない。チーム内、チーム間の橋渡しの役割もある。アナタが書いたドキュメントは、ひょっとして一度も日の目を見ることがないかもしれないが、必要なときは是が非でも必要となる。

　デスマの火消しに投入されたことはあるだろうか。ウォーターフォールを採用したプロジェクトが燃えている場合、最初に渡されるのが莫大な仕様書（あるいはその残骸）だ。古文書を読み解くが如く、そいつに喰らいつくのが最初の仕事。んで、プログラム動作との Fit/Gap を見つけるのが次の仕事。

　このドキュメント（のあるべき姿）と、目の前で燃えているコード（もしくはテストシステム）の差に対し、3つの切り口がある。

• コードをなんとかして、仕様書どおりに動かす
  
• 仕様書を書き換えて、コードの振る舞いどおりに直す
  
• 動かないところの仕様書を切り離す（段階的にリリースする）
  

　んで、優先度が高い順に財布とカレンダーをにらめっこしながら、コードを書くのかドキュメントを直すのか、あるいは仕切りなおしさせてもらうのか、を選び取るわけだ。

　一方、ドキュメントをちゃんと作っていないプロジェクトが燃えた場合、最悪のことが起こる。

　即ち、「何が本当か分かりません」だ。ソースなのか仕様なのか、誰が本当のことを知っていて（決断できて）、誰がそれを知るべきなのかがぐちゃぐちゃになる。どのチームに影響が出るか分からないから、ミーティングは全員参加、全員周知になる。ソースの修正による影響も特定できないため、全員周知となる。ペアプロじゃなくって全員で同じコードをプログラミングしているようなもんだ。

　いまだに「ソースコードが仕様書です」を胸張って言うプログラマを見かけるたびに、マイクロソフト・ジョーク「それは仕様です」を思い出してこっそり笑わせてもらっている。

ウォーターフォールはこう使え（その4）

決めるべき2つの日どり

　二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。

　こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。

　あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。

　表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書き直さないので、仕様変更ではないと判断される。あいまい仕様に対し、顧客へ問い合わせする度に「固まっているはずの仕様」がずんずん膨らんでくるので、いつしか訊かなくなる。んで、代わりに「自分で考えて」実装するわけだ。

　問い合わせる度に「口頭での」仕様が膨らむ
　→確認する代わりにSE/PGが自分で明確化・実装する
　→"こんなの作れって言ってない"と罵倒される

　この悪循環をモトから絶つわけだ。つまり、「現在仕様は凍結されておらず、○月○日に確定する」と顧客を巻き込んで宣言する。（その1）で書いた「peak に到達する日」を顧客にもコミットしてもらう。スパイラルでもOK、「その日」までに何回くり返すかだけの話。

　その一方で、もう一つの日どりを密かに決めておく。もう一つの日を知っているのはPMとシニアマネージャだけで良いが、必ず決めておく。

　その日とは、「最悪の事態に陥った場合、納期延期を申し入れる日」のこと。プロジェクトにとって重要な日は納期ではない。納期に間に合うように努力と工夫を重ねるのだから、間に合って当然。大事なのは、そうならないことが分かったとき、いつまでがギリギリといえるのか? ということ。

　プロジェクトが燃えさかってくると、「その日」のことが脳裏にちらつき始める。納期より手前であることは分かっているのだが、それが1週間前なのか、1ヶ月前なのかが見当がつかない。だから火事場で顧客とハラの探りあいなんて阿呆なことをしだす奴が出てくる。

　こいつを回避するために、最初に決めておく→「ダメなときお客さんにゴメンナサイを言う日」。そうすることで肝も据わるだろうし、火事場になったとき、「その日」に向かって、今度は回避・低減・転嫁するためにすべきことに準備できる。

　顧客だってそうだ。なんだかヤバそうだぞと見ていると、ギリギリになって「結局できそうもありません、どうしたらよいですか?」と来られても困る。ダメになったことに言いたいことは沢山あるだろうが、ダメならどうする? を考えて来いと。「ゴメンで済んだら警察いらない」はガキの使いやあらへんで。

　だから、いざとなったら、「その日」に向かって準備ができるよう、「その日」を決めておくんだ。ダメになりそうな要素�