プロジェクトマネジメント・フレームワークの続き。組織のプロセス資産、教訓について。組織のプロセス資産について。組織のプロセス資産とは、プロジェクトの成功に寄与する知的情報のこと。ガイドラインなどがある。後に説明する「教訓」も含まれていることに注意。大きく2つのカテゴリーに分かれている。プロジェクト・ファイル、過去の情報や教訓、課題と欠陥のマネジメントデータベース、財務データベース教訓について。教訓とは、プロジェクトの途中や終わったときに、「ああすりゃよかった」「こうしなきゃよかった」そして、「もしもう一度やれるんなら、こうする」を集めたもの。よかったもの、悪かったものを含め、プロジェクトを実施する過程で学んだこと。プロジェクトのあらゆる局面で識別され記録される。少なくともプロジェクト終結プロセスにおいて文書化される。例として「見積もりと実績の差異の原因」「選んだ是正処置の根拠」が挙げられる。Rita本は挑発する、「なぜ、プロジェクトは失敗するのか?しかも、同じような失敗ばかりを?」。答えは、教訓が生かされていないから。具体的に言うと、教訓を識別し、記録し、文書化し、次のプロジェクトに向けて共有していないから。プロジェクトが軌道に乗れば、そのプロジェクトからの教訓をアウトプットとしてとりまとめる必要がある――パッと見正しいように見えるが、ウソだ。プロジェクトを始めるときに、これまでの組織の資産としての教訓をインプットする必要があるんだ。うーん、わたしの場合、そういう情報は「デリケートなもの」として扱われている。わたしが一兵卒だからという立場もあるが、部分的・断片的にしか共有されていないようだ。失敗プロジェクトは名ばかりメジャーで地獄谷の代名詞として扱われるが、「なぜ失敗したのか?」は明かされない。コストとタイムと品質の抽象論が掛け合うだけ。内規や規定や定型文書はたくさん転がっている(そういうのを集めるのが好きな会社なのだ)。「どうやったらうまくいったか/いかなかったか」は無い。依存しており、プロジェクトにロックインされた状態で人も教訓も澱むことになる。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。プロジェクトマネジメント・フレームワークの続き。プロダクトライフサイクル、プロジェクトライフサイクル、プロジェクトフェーズ、プロセスについて。プロダクト・ライフサイクルについて。製品のライサイクルだと考えればいい。撤退する一連のライフサイクルを、プロダクトライフサイクルと呼ぶ。プロジェクトの概念は、その中に内包される。新製品の開発という「プロジェクト」があり、市場への投入~拡大のための「プロジェクト」が存在する。プロジェクト・ライフサイクルについて。プロジェクトフェーズの集合を指しているが、業界・分野によって呼び名が異なる場合がある。次のプロジェクトフェーズを束ねたものが、プロジェクト・ライフサイクルと考える。なるが、IT業界だと、設計、コーディング、テスト、インストール、引渡しとなる。プロジェクト・フェーズについて。成果物に着目してプロジェクトを区切った単位を、プロジェクトフェーズと呼ぶ。ひとつのフェーズの中に、次のプロジェクトマネジメントプロセスが含まれている。「立ち上げプロセス」「計画プロセス」「実行プロセス」「監視・コントロールプロセス」「終結プロセス」のこと。単独フェーズのプロジェクトもあるし、複数のフェーズによって分けられているプロジェクトもある。あるフェーズの終結が、次のフェーズのインプットとなる。注意したいのは、フェーズが分割されているからといって、線形に(リニアに)並んでいるとは限らないこと。p.21の図2-5の場合、設計フェーズと建造フェーズが重複している。設計が完全に終わっていない段階でコーディングや試験に着手することを考えると、容易に想像できるだろう。先行フェーズの完了前に後続フェーズを開始させることでスケジュールを短縮させる技法を、ファストトラッキングと呼んでいる。プロジェクトマネジメントプロセスについて。Action)に立ち上げと終結が入っていると考えればよい。プロジェクトを立ち上げて、計画をする。変更が必要な場合は実行プロセスへフィードバックされる。変更の影響範囲が大きかったり、プロジェクトそのものへの変更が必要な場合は、計画プロセスへフィードバックされる。ベースラインから大きく逸脱し、プロジェクトそのものの見直しが必要な場合は、立ち上げプロセスに戻る。全ての作業が実行されたり、プロジェクトを中止する場合は、監視・コントロールから終結プロセスへ移る。ここでわたしがやった間違いは、プロジェクトライフサイクルと、プロジェクトマネジメントプロセスを混同すること。「計画プロセス=設計プロセス」とか、「実行プロセス=コーディングと試験」なんて勝手に置き換えてしまったのだ。プロジェクトフェーズと混交させるとワケ分からなくなる。それぞれの関係を、一つの例として表すとこうなる。これは一例であることに注意。上はプロセス、フェーズ、ライフサイクルの大小関係を分かりやすく示したものであり、必ずこのようになるとは限らない。フェーズは線形ではなく重複する場合があるし(p.21)、そもそも「1プロジェクト・ライフサイクル=1プロジェクト・フェーズ」のプロジェクトだってある(p.19)。PMBOKを「巨大システム・建造物の構築」すなわち「ウォーターフォール」だと早とちりしてたのは、ほかならぬわたし。プロダクトライフサイクルとの大小関係はこうなる(プロジェクトとプロダクトの「ライフサイクル」は省略)。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。プロジェクトマネジメント・フレームワーク(その4)【PMP試験対策】は、PMBOK4版をベースに、PMP試験の傾向と対策をまとめるシリーズ。品切れ状態が続いていたPMBOK4日本語版は、現在在庫アリ。輸入モノなので必要な人はすぐに確保すべし。プロジェクトマネジメント・フレームワークの続き。機能型組織、プロジェクト型組織、マトリックス型組織について。完全に無風状態でプロジェクトが運営されることは、ありえない。会社の文化やマネジメントのポリシー、組織上の手続きといった、プロジェクトの組織構成に、いわば"翻弄"されるのが常だ。優れたPMは、そうした組織構成を見越して、プロジェクトを有利に持っていくもの......とRita本は言う。組織構造のタイプ(型)は、PMがどれくらいの権威(authority)を持っているかによって決まってくる。それぞれのタイプにおける得意・不得意を把握しておけば、試験対策は充分だろう。一般的な組織構成で、部門ごとに分割されている。いった分け方になっている。プロジェクトはふつう、ある一つの部門の中で発生し、完結する。別の部門の助けが必要な場合、いったん部門長(p.29の言い方だと「機能部門マネジャー」)を経由して調整されてくる。「営業部門に新規ITシステムを導入するプロジェクトで、収支決済を調整する必要が出てきた。部門長で話し合い、経理から担当がアサインされた」という事例など。思い浮かべれば、そればかりやっているから当然だよね。メンバーはただ1人の上司に報告すればよい。似たようなリソースが集中しているため、その分野のプロ単位に組織化されているし、キャリアパスがはっきりしている。機能型組織の欠点は、プロジェクトの遂行よりも、目先の業務をこなすことに注力しがちになることが挙げられる。プロジェクトマネージャは、何の権威もなく、プロジェクトマネジメントのキャリアパスは育たない。プロジェクト単位に組織されているのが特徴で、PMがプロジェクト組織を担っている。home)、プロジェクトが終結すれば、別プロジェクトにアサインするか、別の仕事を見つけてもらうしかないのだ。プロジェクト型組織の利点は、プロジェクト指向の組織のため、案件に対し最も効率のよい組織といえること。機能型よりもコミュニケーションがやりやすい(風通しがいい)ことが挙げられる。プロジェクト型組織の欠点は、プロジェクトが終結したら、「ホーム」がなくなること、(経理や人事などの)プロフェッショナルが育ちにくいことが挙げられる。プロジェクト毎に経理や人事などの仕事が重複して存在するため、全社的に見ると非効率的になっているのだ。人材の育成やリソースアサインの観点からすると、部分最適となっているのがプロジェクト型組織になる。機能型とプロジェクト型の両方の強みを生かしたのがこれ。一言でまとめるなら、「マトリックス型組織とは、ボスが2人いる組織」になる。PMのボスと部門のボスの2人だ。指示がちぐはぐだったりすれ違ったりする可能性もあるが、「(帰るべき)ホームもありながらプロジェクトにアサインされる」形態となっている。「強いマトリックス」や「弱いマトリックス」は何を指すのだろうか?図だけを見ても分からないかもしれない。実はこれ、PMの権限のことを「強い」「弱い」で表現しているのだ。「弱いマトリックス」の場合、権限は機能部門マネジャーが持っており、PMはリーダーというよりもむしろ調整役になっている。expediter)は権能が弱く、スタッフのアシスタント役か連絡係のような役割となっている。coordinator)は、プロジェクト促進係よりも権能が強く、一部の決定権や上級マネージャーへの報告といった役割を担っている。マトリックス型組織の利点は、プロジェクトの目標が見えやすいこと、機能組織からのサポートが受けやすいこと、帰るべき「ホーム」があることが挙げられる。限られたリソースを最大限に用いる、リソース管理能力が育てられる。プロジェクト型だと(担当の重複で)リソースのムダ使いするかもしれないし、機能型だとPMの権限が少ないためリソース管理をさせてもらえないかもしれない。その両者の欠点を克服しているのが、マトリックス型組織になる。水平・垂直の両方向にコミュニケーションが取れる。水平は、プロジェクトメンバー同士。垂直は、プロジェクトマネージャ同士で、連絡が密になる。マトリックス型組織の欠点は、プロジェクトチームにとって、報告するべきボス・上司が2人以上いること、コントロールが複雑なところ、リソースの割り当てが難しいところ......と多数上げられる。優先順位づけがプロジェクト/機能部門で異なる場合、マネージャーどうしの調整が大変になる。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。プロジェクトマネジメント・フレームワークの続き。プログラム、ポートフォリオ、PMO、目的によるマネジメントについて。「プログラム」とは何か。プログラムとは、プロジェクトをグルーピングしたものであり、複数のプロジェクトの協調させ、調和が取れるようにマネジメントする。一例として、ロケット開発プログラムでは、ロケットエンジン、本体、衛星のそれぞれの開発プロジェクトを協調させながらすすめる必要がある。プログラムには反復的および周期的業務も含まれることに注意。PMBOK3版p.16の例によると、公共事業では、年次「建設プログラム」と呼ばれるが、これは毎年積み重ねで実施される一連の建設プロジェクトのことを指している。プロジェクトは周期性を持たないが、プログラムは周期性を持つ業務「を含む」のだ。「ポートフォリオ」とは何か。ポートフォリオとは、プログラムとプロジェクトをグルーピングしたものであり、ビジネス上の戦略的目的を達成するためにまとめられている。ひとつのポートフォリオに、複数のプロジェクト、プログラム、定常業務が含まれている、と考える。「プロジェクトマネジメント・オフィス(PMO)」とは何か。ともすると分散しがちなプロジェクトのマネジメントを集中化させるたに、次のような役割を果たすオフィス。1組織におけるPMポリシーや方法論、テンプレートを提供する。2組織においてプロジェクトをマネジメントするためのサポートやガイダンス、トレーニングを行う。3プロジェクトマネージャを提供し、プロジェクトの結果に責任を負う。PMOが超越的な権限を持っている人だと考えてはいけない、あくまでも一組織だ。組織によって様々な役割を果たす。――プロジェクト間の相互依存関係を調整したり、プロジェクトを終結させたり、組織のルールとしてコンプライアンスをモニタリングしたり、教訓を収集して組織内で共有化したり、変更管理委員会として働いたり、ステークホルダーそのものとなったりする。――とRita本にあるが、PMの吹き溜まりとなってやしないだろうか?かつては敏腕を鳴らしたPMでも、技術革新に取り残されたり、貢献に見合うポストが提供できなかったりの理由で、PMOに「安置」させられてやしないか?PMOを設置してこれで大丈夫だと胸を張る経営者を見ていると、そんな疑問が頭から離れない。そんなわたしの疑いに応えるように、Ritaはこう述べている。PMOは最近のトレンドだが、まともに働かせるためには、1役割の明確な定義づけ、2なんにでも関わらないこと、3有資格者(PMP)が携わること、4トップマネジメントのコミットメントと関与が必要などと述べている。そもそも、PMO自体が適切なプロジェクトマネジメントを要するので、「組織をつくればOK」という経営者が安易過ぎることがよく分かる。ああ、誰かさんに読ませてやりたいナリ。プロジェクトマネジメントにおける「目的」とは、「そのプロジェクトの結果、生み出されるサービスや製品」だけではないことに注意。目的は、プロジェクト憲章など、プロジェクトを通じて生み出されるものを含む。目的は、立ち上げ時に特定され、計画時にブラッシュアップされる。そのプロジェクトで何を目指すのか?が最初に決められるのだ。目的が、「予定通り」であれば、それは上手くいっているプロジェクトと呼んでもいい。逆に、目的に適っていないプロジェクトは、それをやめさせる理由にもなる。そのため、プロジェクトに対する要求と目的は、トレードオフの関係になることがよくある。言い換えると、「目的」とは、作業が向かうべき方向であり、達成すべき目標であり、取得すべき所産や、産出すべきプロダクト、実行すべきサービスだったりする。Objectives)とは、次の3ステップによる。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。プロジェクトとは何か?PMBOK4ではプロジェクトを次のように定義している。プロジェクトは、独自のプロダクトやサービスをもたらすいわゆるルーチン作業は「プロジェクト」と呼ばない。デイリーであっても年単位であっても、繰り返し行われる作業は、プロジェクトとは定義されないのだ。「予算編成プロジェクト」は(PMBOKの定義によると)誤った使い方になる。「試験に出やすい」設問を作るならば、「プロジェクトとは何か?」という問いではなく、「次のうち、プロジェクトではないものを選べ」になる。PMBOK3だと、ここに「段階的詳細化」が追加されるが、4版では無くなっている。上司がふらりとやってきて、「あのシステムの調子が悪いみたいなんだ。行って見てきてくれる?」はプロジェクトだろうか。ヘルプデスクみたいなものを想像してみてほしい。誰かが連絡してきたトラブルを解決する。有期性も独自性もあるから、「プロジェクト」になるのだろうか?または、新しいハードウェアを展開するのは「プロジェクトに」なるのだろうか?PMBOK4ではプロジェクトの例を、以下のように挙げている。新製品や新サービスを開発すること情報システムを開発したり展開することビルや橋などのインフラを建設すること新たなビジネスプロセスを実務に適用させるRita本では、ユニークな判断基準を設けている。「3ヶ月」「20名」というボリュームだ。期間が3ヶ月以下だったり、メンバーが20名以下だったりするならば、それは(PMIのいう)「プロジェクト」に相当しない可能性がある、というわけだ。これはRita本の見解であり、PMBOKのどこにも書いていないのでご注意を。Ritaのいうプロジェクトは、どれぐらいのサイズになるのか――200人のチーム、少なくとも1年間の期間、そして1,000,000ドルの予算だと、「プロジェクト」になるという。経営陣の思いつきでテケトーに割り当てた予算でやっていけと命ぜられる「プロジェクト」が、いかに名前負けしているかがよく分かる。この良い例がRita本にある。小さなプロジェクトだったなら、話す必要がある人と直接会ってミーティングすることが可能だが、PMBOKで扱うのは、コミュニケーションマネジメント計画に数週間を要するぐらいのものだ。話す相手は他の言語だったり、ひょっとすると海の向こう――時差とかを考えなければならない国だったりすかもしれない。「プロジェクトマネジメント」とは何だろうか?PMBOK4では次のように定義している。プロジェクトマネジメントとは、プロジェクトの要求事項を満たすために、知識・スキル・ツールと技法をプロジェクト活動へ適用すること。プロジェクトマネージャ(PM)とは、プロジェクト目標を達成する責任を負う人のことを指す。Rita本ではもっとカッコ良くこう言い切っている――プロジェクトマネジメントとは、システマティックなプロセスに従った、科学であり芸術なのだ、と。プロジェクトマネジメントは5つのプロセスグループに分かれている。とコントロール、そして終結のプロセスだ。次のプロジェクトの制約要素に制限されないように、バランスをとること。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。PMP試験は、知識だけでなく、PMとしての分析力や応用力を試されるもの。単なる定義の記憶と再生を問うものではないので、ご注意を。questions)。これは、実際のPMの現場に携わっていないと、正答するのが難しい。いわゆる「常識的に考えて」が通用しない場合があるからだ。プロジェクトに必要な調達物資の一部の納入が遅れることが分かった。チームを召集し、代替案を検討する答えは、D(反転表示)。この場合、現実の「あなた」がどんな風に対応しているかは、あまり問題ではない。すると、「あなた」はPMではなく、メンバーの一人であるかもしれないからだ。「客や上司には言わなくてもいいの?」と反論したくなるだろうが、「次にすべき打ち手」ではない。いうものの、PMBOKガイドのインプット・アウトプットが「そのまま」出る問題もある。Rita本によると、およそ10-12問だそうな。これは覚えるしかないが、出やすいところというものはある(品質保証と品質管理といった"まぎらわしいもの")。8-10問は、計算問題(コミュニケーションチャンネル、機械コスト)が出題され、10-12問はアーンドバリュー(EV)関連の問題が出る。EVは確かに計算問題になりやすいが、必ずしも計算の形で問うとは限らない。事例や計算問題のデータが被る場合がある。同一の事例やデータが、複数の設問に流用されているというわけ。Rita本によると、ほとんどの解答者は、200問中40問は「あやふや」なまま回答しているそうな。多くの受験者は2時間30分でひととおり終わり、残りを見直しているという。わたしの場合、3時間かかって200問終えた。残り45分くらいで見直して、「もう大丈夫」と自信があったので、試験を終了したなぁ...(ENDボタンを押すと、いつでも試験終了→採点できるのだ)。消去法で解くべき問題もある。一見したところ、設問とは関係なさそうに見えるのだが、「もっと関係のない」選択肢も並んでいる。一つ一つ消していくと、残ったものが正解となる。熟練労働者により、扉の部品コストは10%減らすことができることが分かった。会社側は次期の製造コストとして、扉3,000あたり21,000ドルかかると見積もった。10%だの、21,000ドルだの、それっぽい数字が出てくるが、ダミーなんだ。上の状況において、関係なさそうなものを消していって、残った一つが正解、というカラクリ(いわゆる消去法)。出題文が不必要に長ったらしい場合もある。状況を説明し問題を解説する文章がだらだらと続く。文中に人員数や予算といった形で「数字」が出てくるため、心配になってくる。した数字が問題の本質となっていることは、ほとんどない。すべきことは一つを選ぶだけ。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。ここで躓く人がかなりいる模様。PMP試験は、PMBOKガイドで覚えたことを試すものではない。PMBOKガイドからズバリ出る問題もあるが、そうした記憶に頼る試験準備だと、合格は難しい。「ガイドからズバリ」は、ほとんど無いからだ。代わりに、実際のプロジェクトの経験に沿った「ベターな選択肢」を求める問題が山と出る。その「ベター」とは何かというと、PMBOKガイドに準じているんだ。PMP試験は、選択肢の中から正解を一つみつける出題形式だ。200問を4時間かけて解く。question)とされ、採点されない。どれが事前公開問題なのかは、ランダムに決められており、受験者には分からない。結局、175問が採点対象となり、合格するためには、この中から最低でも106問の正答が求められる。およぞ61パーセントの正答率で合格となるのだ。問題はデータベースで管理されており、かなりの数にのぼるようだ。その中から、200問選ばれるというわけ。出題順はバラバラで、PMBOKガイドのように系統だってはいない。そのため、隣の受験生と違う問題に向き合うことになるわけ。誤答だった場合のペナルティはない。問題の出題率は、プロセスグループごとに決まっており、だいたい下記のような割合を占めている。いって安心するなかれ。PMIは定期的に試験の見直しをしており、出題傾向を変えている。動向は公式サイトをチェックすべし。立ち上げプロセス(11%)計画プロセス(23%)実行プロセス(27%)監視・コントロールプロセス(21%)終結プロセス(9%)プロフェッショナルと社会責任(9%)以下は、難しいさのレベル。一般に難しいと感じられている順に並べると、次のようになるという。↑上にいくほど、難しくなり、↓下にいくほど、易しくなる。最初のリストは、知識エリアで切った場合。次のリストは、プロセス群単位に見た場合だ。このリストによると、知識エリアでは「プロジェクトマネジメントプロセス」、プロセス群では「監視・コントロールプロセス」が最も難しく感じられるようだ。たしかにそうかもしれない。「プロジェクトマネジメントプロセス」の分野は全知識エリアにまたがっているため、広範な知識を要するし、監視・コントロールプロセスもやはり、全てのプロセス群に連結しており、同様に範囲は広いといえる。知識エリアごとに分けると、プロジェクトマネジメントプロセス調達マネジメントリスクマネジメント統合マネジメント品質マネジメントタイムマネジメントコストマネジメントプロジェクトマネジメントフレームワークスコープマネジメント人的資源マネジメントコミュニケーションマネジメント調達マネジメントは少し特殊で、実務で携わる人の少なさを物語っている。いわゆる総務での発注・検収の仕事をしていれば入りやすいが、普通のPMではなじみが薄いだろう。反面、人的資源やコミュニケーション関連は、普段の仕事と直結した内容のため、易しいと感じる人が多いのかと。終結プロフェッショナルと社会責任いわゆるプロジェクトの立ち上げに携わる人は少ない。そのため、難しいと感じる人が多いようだ。「新しいプロジェクトがあるから行ってくれ」と命じられたときには、プロジェクトをする場所や予算が既に決められており、成果物やメンバーは曖昧になっている。何を作るか玉虫色なのに、納期だけはなぜだかしっかりと決められているんだ。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。Knowledge)の第4版をデジタルコンテンツとして入手したので、3版からの変更点をまとめる。PMBOK4のデジタルコンテンツを参照するためにはPMI会員になる必要がある([PMI]が入口)。書影は英語のペーパーバック版。PMP取得を目指すなら必携かと。このエントリのまとめの目次は以下の通り。プロジェクトマネジメント計画書とプロジェクト文書の包含範囲の変更まず、「プロジェクトマネジメント計画書」と「プロジェクト文書」が明確に異なるものとして扱われている。3版では「文書⊃計画書」と包含していたが、4版になると両者は別物だそうな。3版での両者の構成は以下の通り。└調達マネジメント計画書4版での定義づけは、こうなる。「プロジェクト文書は、プロジェクトマネジャーの仕事をアシストする文書であり、プロジェクトマネジメント計画書は含まれない」。プロジェクトマネジメント計画書は、各種の計画書やベースラインにより構成される。4版では、次のカテゴライズとなっている。次に、「変更要求」の定義が広がっている。「要求された変更」は、より一般的な用語「変更要求」に包含される。たしかにプロセスやフェーズで違う言葉を使ってはいるものの、意味合いは一緒だからね。次は、「プロジェクト憲章」と「スコープ記述書」について。3版では意味が似通っているため冗長だったとし、4版では重複部を削り、より両者の区別をつけるようにした。「何のためのプロジェクト?」に答えるプロジェクト憲章と、「プロジェクトで何するの?」の範囲を決めるスコープ記述書、性格が似ているからね。4版での各構成要素は、それぞれ以下の通り。削除/追加されたプロセス削除/追加されたプロセスは、次の通り。知識エリアごとの変更内容プロジェクト統合マネジメントでの変更点。プロジェクトの目的(暫定版)はプロジェクト憲章で記し、プロジェクトの目的そのものはスコープ記述書で詳述する。その結果、4版ではプロジェクトスコープ記述書暫定版作成プロセスは削除されている。プロジェクトスコープマネジメントでの変更点。スコープ計画が「要求の収集」に取って代わっている。ステークホルダーを登録することで、プロジェクトに関心を示すステークホルダーを特定する。プロジェクトタイムマネジメントでの変更点。パソコンの普及により、アローダイアグラム(ADM)やアクティビティ・オン・アロー(AOA)手法はほとんど使われなくなったため、その旨が追記されている。したプロジェクトだと、アクティビティが鬼のように出てくるので、もはや手作業ではムリなんだろうね(作れるけど変更が鬼)。プロジェクトコストマネジメントの変更点。アーンドバリューがより「使える」ツールとして説明が強化されている。「パフォーマンスインデックスの達成度計算」が追加されている。コミュニケーションマネジメントの変更点。「プロジェクトチーム≒ステークホルダー」とは限らない。プロジェクトチーム「外」のステークホルダーが下す決定を予想することもできない。従って、「ステークホルダー要求」をマネジメントする必要が出てくる。は時間を見つけてボチボチ読んでいる。Centuryがゴシックになっており、読みやすい。ステークホルダーのマネジメントに力点が置かれているようだ。いわゆる「プロジェクトへの要望」とはすなわち、プロジェクトチーム「外」のステークホルダーの要求なのだから。やっていること(調達)調達マネジメントにおける第一の目的は、「プロジェクトで必要な製品やサービスを、外部から調達するのか、内部でなんとかするのか検討する」こと。そのため、スコープの境界の間に位置し、プロジェクトの外側/内側を厳密に吟味する必要がある。スコープ定義の後でないと調達プロセスが始められないのも、この理由による。一連のプロセスは、プロジェクトフェーズの一つのPDCAと、軌を一つにする。work)を作成する。調達文書と評価基準を作成する。コントラクター提案依頼書ともいう。調達マネジメント計画書とは、調達プロセスのマネジメント方法を記述したもので、以下のものが記述されている。[p.279:PMBOK]jも見ておく。契約に基づき、何をしてもらうのかを詳細に記述したもの。記述し、運用支援が必要な場合はそれも書いておく。何が必要なのかも分かっていないのに、調達するな、ということ。随意契約というふざけた契約をする連中は、同額の契約金を給与から引いても良いと思う。重要なのは、調達プロセスを回すためには、何を作るのか決まっていて(スコープ記述書)、詳細化されており(WBS、WBS辞書)、リスク、コスト、スケジュールが見積もられていなければならない。購入・取得計画プロセスのインプットは、スコープ・コスト・タイム・リスクのアウトプットであるのは、そのせい。Feeポイントは、定額契約と実費償還契約のリスク。定額契約は納入者のリスクが高く、実費償還は購入者のリスクが高いこと。定額契約は、何をするのか明確だけど、納入者がどうやって提供するのかに関係なく、価格が決まっているから。経費と利益の両方を支払う必要があるため、納入者がコストを度外視する可能性がある。前出の場合だと、1,500万円プラス納入者の利益を支払う必要がある。一つの曲者がT&M契約で、何を作るのか(スコープ)、いくらで作るのか(コスト)が明確になっていなくても契約できてしまう。社長号令で大目標は決まっているけれど、何をどうやらといった状況で、とりあえずコンサルタントと契約するか、というときにはこれが便利。悪名高き「随意契約」もこれだな。IT業界では、契約は定額契約であるにもかかわらず、SOW、つまり何をするのかを決めていない場合もある。するとふざけているとしか言いようがないが、現実ナリ。やっていること(品質)品質は鬼門。とっての「品質」は、一般的なソレと違うので要注意。厳密に適用しようとする。品質とは、本来備わっている特性がまとまって要求事項を満たす度合い。あるべきものが、ちゃんと備わっていること、とでも言い換えればいいだろか。「あるべき」は「暗黙のニーズ」「明示された仕様」のいずれかの形はとるかもしれないが、要求が満たされている=品質を満足しているといえる。use)も必要だという。要は客の言うとおり作っても使えなきゃ意味ないよ、ということ。品質マネジメントでは、成果物マネジメントだけでなく、プロジェクトのマネジメントまで目配りしなければならない。「良いものを作れば品質はOK」ではなく、そのプロジェクトのマネジメントそのものも「良く」することが重要だという。製品不良率が小さいだけでなく、手戻りが少ないことも大切。その結果、「そのプロジェクト」だけで品質マネジメントを成し遂げるのは困難と言うよりも、ムリ。母体組織による継続的な改善活動が必要。後に出てくる「品質コスト」、特に予防と評価への投資は、母体組織で負担することになる。プロジェクトは有期的だからね。品質計画どの品質規格がそのプロジェクトに関連するかを特定し、どうやってその規格を満足させるかを決める。品質は、計画・設計・作りこみによって達成されるものであり、検査によってではないことがポイント。品質コスト(適合/不適合コスト)、品質マネジメント(デミング、ジュラン、クロスビー)、品質ベースラインは押さえておく。■「計画」でやっていること(コミュニケーション)よく間違える。PMBOK読んでも「あたりまえ」のコトしか書いていないにもかかわらず、不正解多し。送ったメール=読んだものだと判断するのではなく、重要なら到達確認をするように、「あたりまえ」なことがあってもいちいち確認しながら再読するべ。コミュニケーション計画ステークホルダーの情報に対するニーズを特定する。誰が、いつ、どのような情報を必要とし、その情報は、誰が、いつ、どのように提供するかを決定する。プロジェクト成功の要因はコミュニケーションと言われるワリには実践されていないのが現実。うんこミュニケーション(うんこ+コミュニケーション)の実践例なら沢山あるぞ。メールを送った=読んだものと判断する:呼べば聞こえるのにメールばかりしこたま送りつけてくる。酷いのになると、「先日送ったあの件はどうなってますか?」(←本文ママ)と訊いてくるノイズ入れまくり:ひょっとして意図を伝えたくないのかしらん、と勘ぐりたくなる。結論なしで「やったこと」だけをダラダラ書く。んなもんメーリングリストで流すな!こそあど言葉乱用:「あの件」「それについては...」で会話を成立させている。「ほら、アレだよアレ、わっかんないかなー」って、オレはオマエの番人じゃねぇ!略すな!:略すということは、省略前の言葉を『お互いが』知っていることが前提。その理由がイカしてる「TBの方が短くてカッコいいから」コミュニケーションマネジメント計画書のアウトプットの中でも、「エスカレーションプロセス」に着目したい。ある「体制図」は自組織の体制しか書いていないが、一工夫の余地あり。その隣に、顧客の体制図も記述するわけだ。名前が決まっていなければ空欄でもOK。そいつを顧客へ提示するわけだ。「これこれの情報レベルは、この担当が扱いますよ」というメッセージが伝わるはず。下位レベルでは解決できない問題は、マネジメントチェーンを通じて上へ持ち上げていくことが視覚化されるわけだ。このレベルを取り違えると、とんでもない悲劇か、全くの時間の浪費か、その両方になる。■「計画」でやっていること(人的資源)「人」も資源と一緒で、必要な時期に適切な人材を、必要な分だけ投入しなければならない。足りなきゃ持ってくるし、スキル不足ならトレーニングが必要(ってことはそのための期間もカネも必要)、いきなり投入しても馴染むのに時間がかかるし、他の足を引っ張るかもしれない。パフォーマンスが上がらないかもしれない。デマルコの傑作「デッドライン」には、その本質がこう書いてある。・適切な人材を雇用する・その人材を適所にあてはめる・人びとの士気を保つ・チームの結束を強め、維持する(それ以外のことは全部管理ごっこ)確かにその通りなんだけど、必要条件じゃぁないかと。他の要素ばかり目が行って、プロジェクトを実際に動かす「人」を疎かにしないように、という戒めとして読もう。要員マネジメント計画書を作成する。2004.05.21プロジェクトは終わった。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。