PMP

PMP資格取得-PMBOK第6版(基本)

最近はテックから少し離れて、PM業務が多くなってきてしまっています。テックに触れたいのですが、業務上PMP資格取得が最優先となったので、しばらくはPMPに関する記事が続きます。

PMP資格とは?

PMP資格については、日本プロジェクトマネジメント協会のHPで記載されているので、そのまま引用します。プロジェクトマネジメント業務を行う上で必要な知識が問われる資格といえばいいでしょうか。

・PMP®(Project Management Professional)は、PMI®(Project Management Institute)が認定するプロジェクトマネジメントの資格であり、PMI®が定めるPMP®資格認定プロセスを経て認定されます。
・PMP®資格は1984年に創設され、2012年10月現在、PMP®資格取得者は世界で49万人超、日本在住の取得者は2万9千人を超えています。 (PMI®アジアパシフィックサービスセンター調べ)
・PMP®資格はプロジェクトの全般にわたるタスクを指導・指揮するプロジェクト・マネジャーとして実践するための関連職務実績と職務知識の保有をPMI®が認定するものです。
・認定プロセスにはコンピュータを用いた知識試験が含まれます。この試験(以下PMP®試験)は4者択一の問題が200問出題され、4時間以内で解答します。
200問の中には、統計データを取得するための問題25問が不規則に入っており、これは合否には関係ありません。
合格するためには、残りの175問中108問(61.0%)以上を正解しなければなりません。

引用元:PMI PMP資格に関して

PMP資格は誰でも受験できるわけでなく

  • プロジェクトマネジメントの経験:大卒の場合は 4,500時間(36ヶ月)、高卒の場合は 7,500時間(60ヶ月)
  • プロジェクトマネジメントの教育:35時間(自己学習はカウントされず PMP教育が許可されたプログラムのみ認可)

という前提条件があります。さらに取得後も3年ごとに 60PDU(Professional Development Unit)というPMとしての活動ポイントを申請して、資格更新する必要があります。

PMP資格を持っていなくてもPM業務をすることは多いので

受講前のTaka
受講前のTaka
本当に必要なの?
最近はアジャイル開発が多いから今更いらないんじゃない?

と思っていましたが、研修会社によるプロジェクトマネジメント研修で教育を受けた後は

受講後のTaka
受講後のTaka
資格取得の価値はあるなぁ…
というより実務経験がフラッシュバックしてくるようで面白い!

と実感しました。

受験には最低3年のPM実務経験が事前に必要ですが、その経験と研修で学ぶことを照らし合わせるとより学習に身が入りました。何より「学んだことを現場でも生かしてみたい」と意気込むことは間違いなしです(笑)

なお、研修会社の学習以外だと、PMBOKガイド第6版と図解の2冊を参考にしました。

それでは学習したことをまとめていきます。

プロジェクトについて

プロジェクトと呼ばれるためには3つの条件があります。

  1. 有期性(Temporary):開始(立ち上げ)と終了(終結)がある。
  2. 独自性(Unique):PMBOKガイドでは「独自のプロダクト、サービス、所産を創造するための有期性の業務である」と定義
  3. 段階的詳細化(Progressive Elaboration):時間経過により予算やスケジュールなどの情報が詳細化される。(例) ローリング・ウェーブ計画法

終わりのない保守・運用などの業務は定常業務(Operation)と呼ばれます。

ポートフォリオ・プログラムとプロジェクト

プログラムは、複数のプロジェクト、サブプログラム、プログラム活動の集合体で、戦略目標とベネフィットを達成するために、全体の調和を保ち、一元的にマネジメントすることをプログラムマネジメントと呼ばれます。ここでは相互依存関係に焦点が当たっています。

ポートフォリオは、組織の戦略目標を達成のために、プログラムやプロジェクト、定常業務がグループ化されています。

例えば、CRMシステムを提供するIT企業Xの「データを活用した新事業展開による利益向上」という戦略があり、その目標達成のために「RPA」「AI」「マーケティング」などのポートフォリオがあるというイメージです。

まとめると以下のような感じでしょうか。

  • 組織→戦略→ポートフォリオ→複数のプログラム・プロジェクト・定常業務
  • プログラム→複数のプロジェクト・定常業務(相互依存)

ライフサイクルとフェーズ

プロジェクトの開始、計画、実行、終結までを管理しやすいように区分したものをフェーズといいます。そしてフェーズの集合体をプロジェクトライフサイクルといいます。

さらに各フェーズ内では マネジメントプロセス監視・コントロールプロセスである「立上げ・計画・実行・監視コントロール・終結」のプロセス、つまりPDCAサイクルが実行されます。

1つのフェーズが完了すると、次のフェーズへ移行する前にフェーズ・ゲートと呼ばれるレビュー期間が存在します。フェーズゲートでは “次のフェーズへ移行すべきか”や”プロジェクトを継続してもよいか” などが判断します。

フェーズゲートでのレビューには以下のドキュメントが参照されます。

  • ビジネス文書:ビジネスケースやベネフィットマネジメント計画書
  • プロジェクト憲章:プロジェクトの目的や目標、スケジュールやスコープ概要など
  • プロジェクトマネジメント計画書:計画プロセスで作成される文書
ビジネスケース
データにより裏付けされた市場規模やビジネスニーズ費用便益分析などが記載されており、プロジェクトを実行する価値があるかどうかを判断できる

ベネフィットマネジメント計画書
プロジェクトによるベネフィットや SOW が定義されています。

プロジェクトライフサイクルでの、開始のフェーズは別名「コンセプトもしくはフィージビリティスタディ」フェーズとも呼ばれ、不確実性(リスク)が最も高く、コストや要員数が最も少ないフェーズです。

開発ライフサイクルと呼ばれる、プロダクトの開発やサービスに関するライフサイクルとして以下があります。

  1. 予測型:ウォーターフォール型
  2. 反復型、漸新型
  3. 適応型:アジャイル型

PMBOKは1のウォーターフォール型を基本とした考え方のようですが、最近はアジャイル型の開発についても少しずつ触れるようにしているようです。

プロジェクトマネージャーについて

プロジェクトマネージャーとして求められる能力(コンピテンシー)は3つあります。

  1. テクニカルプロジェクトマネジメント
  2. リーダーシップ
  3. 戦略的およびビジネスのマネジメント

特に3を求められる傾向が出てきたとのことでした。要は統合的にみてプロジェクトはニーズや市場にフィットしているのか、そういった視点でプロジェクトをマネジメントできるかどうかということが重要である、という考え方です。

またコミュニケーション能力が求められるスキルであり、コミュニケーションに90%の時間を費やすということが指標のようです。

プロジェクトの組織構造

プロジェクトを実行する組織の構造により、プロジェクトマネージャーの役割や権限も異なります。主なプロジェクト体制として以下の3つがあります。

  1. 機能型組織:トップダウン組織で指揮命令系統が明確。PMの権限は弱い
  2. マトリックス型組織(弱い・バランス・強い):1と3の中間
  3. プロジェクト型組織:PMの権限が強い。プロジェクト単位での組織構造

1 の機能型は組織図上の上位役職者が権限を持ちプロジェクトの予算や人員を決定します。例えば、人事部のシステム導入プロジェクトにおいて、人事部長が最高権限を持ってプロジェクトをマネジメントします。その際、PMは存在しますがパートタイムであり、権限がないため、プロジェクトコーディネーター(エクスペディター)と呼ばれることもあります。

3 のプロジェクト型は、プロジェクト単位でチームが形成されており、PMが強い権限を持っています。予算管理などをすべてPMが行い、専属(フルタイム)でプロジェクトに従事します。プロジェクト終結とともに解散されるため、プロジェクトで得た経験や知識が、その他のチームや組織全体に共有される機会が少ないのが欠点です。

2 のマトリックス型は、1と3のハイブリットであり、機能型の組織にプロジェクト単位でPMを設けて、各部門からメンバーを招集してプロジェクトに取り組みます。弱いマトリックス型は機能型寄り、強いマトリックス型はプロジェクト型寄りで、バランスマトリックスが中間の位置になります。IT関連のプロジェクトでは、この組織型が多く利用されているのではないでしょうか。

タイプPMの権限PMの役割予算管理
機能型なしパートなし
弱いマトリックス型なし、弱いパートなし
バランスマトリックス型中程度パート共有
強いマトリックス型中~強いフルあり
プロジェクト型強いフルあり

プロジェクトマネジメントオフィス

PMOのことで、PMBOKガイドでは「プロジェクトに関連するガバナンス・プロセスを標準化し、資源、方法論、ツールおよび技法の共有を促進する組織構造」と記載されています。ここでは共有の促進というところがキーです。

PMOには3つの種類があり、それぞれ役割や権限が違います。

  1. 支援型:テンプレートやベストプラクティス、トレーニング、プロジェクトの情報や教訓を提供するサポート的な役割
  2. コントロール(管理)型:支援に加え、組織のガバナンスに基づくコンプライアンスを要求する。プロジェクトへのPMOのコントロールはある程度強い。
  3. 指揮型:プロジェクトを直接マネジメントする。コントロールが強い。

PMOは組織図上でいうと上位に配置されたり、各プロジェクトの上位に置かれることが多い組織です。

組織体の環境要因(EEF)

組織体とは、組織全体(会社全体からグループ企業含めた広い意味)の Enterprise という意味であり、組織体の環境要因(Enterprise Environment Factor) は組織体を取り巻く組織内・外の要素で「コントロールに及ばないが、プロジェクトに影響・制約・指示を与える状況」として定義されています。

組織内EEF

  • 組織の文化・構造・ガバナンス
  • 施設や資源の地理的分布
  • インフラストラクチャー
  • 情報技術ソフトウェア
  • 資産の可用性
  • 従業員の能力

組織外EEF

  • 市場の状況
  • 社会的・文化的な影響と課題(政治勢力、行動規範など)
  • 法的規制
  • 商用データベース
  • 学術研究
  • 国家標準、業界標準
  • 財務上の考慮事項
  • 物理的な環境要素(労働条件、天候、制約条件)

組織のプロセス資産(OPA)

OPAは組織内で使われるプロセス・方針・手続き知識リポジトリというプロジェクトを通して得られた知識や経験を教訓としてまとめたものを資産として管理し、プロジェクトのインプットとして利用したり、アウトプットとして更新するものです。

マネジメントプロセス群と知識エリア

最後に、プロジェクトマネジメントのプロセス群と知識エリアについてまとめます。

プロセス群

これはフェーズのところでふれた「立上げ・計画・実行・監視コントロール・終結」の5つのプロセス群を意味します。これらプロセス群に後述の知識エリアがあります。

  1. 立上げ:プロジェクトやフェーズと開始する認可を得ることが目的
  2. 計画:プロジェクト目標達成のための計画。知識エリアが一番多いプロセス群
  3. 実行:要求事項を満たすための計画を実行する
  4. 監視・コントロール:計画および実行のプロセスを監視・コントロールする。変更が必要な場合は、変更プロセスを実行する
  5. 終結:プロジェクトおよびフェーズを終結し、成果物を移管するプロセス

知識エリア

プロジェクトマネジメントプロセスは10の知識エリアに分類されます。

  1. 統合
  2. スコープ
  3. スケジュール
  4. コスト
  5. 品質
  6. 資源
  7. コミュニケーション
  8. リスク
  9. 調達
  10. ステークホルダー

これらの詳細についてはここでは触れず、1つずつ別記事でブレークダウンしていきます。

次は統合編

基本編だけでも結構なボリュームでしたが、1つずつじっくり理解をしていくとすんなり頭の中に入っていく内容でした。個人的にはEEFとOPAが好きです。どうでもいいことなんですが。

次は統合編ということで、一番最初の知識エリアを切り崩していきます。

それでは今回はここまで!