最近はテックから少し離れて、PM業務が多くなってきてしまっています。テックに触れたいのですが、業務上PMP資格取得が最優先となったので、しばらくはPMPに関する記事が続きます。
what you learn
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資格は誰でも受験できるわけでなく
という前提条件があります。さらに取得後も3年ごとに 60PDU（Professional Development Unit）というPMとしての活動ポイントを申請して、資格更新する必要があります。
PMP資格を持っていなくてもPM業務をすることは多いので
と思っていましたが、研修会社によるプロジェクトマネジメント研修で教育を受けた後は
と実感しました。
受験には最低3年のPM実務経験が事前に必要ですが、その経験と研修で学ぶことを照らし合わせるとより学習に身が入りました。何より「学んだことを現場でも生かしてみたい」と意気込むことは間違いなしです（笑）
なお、研修会社の学習以外だと、PMBOKガイド第6版と図解の2冊を参考にしました。
それでは学習したことをまとめていきます。
プロジェクトと呼ばれるためには３つの条件があります。
終わりのない保守・運用などの業務は定常業務（Operation）と呼ばれます。
プログラムは、複数のプロジェクト、サブプログラム、プログラム活動の集合体で、戦略目標とベネフィットを達成するために、全体の調和を保ち、一元的にマネジメントすることをプログラムマネジメントと呼ばれます。ここでは相互依存関係に焦点が当たっています。
ポートフォリオは、組織の戦略目標を達成のために、プログラムやプロジェクト、定常業務がグループ化されています。
例えば、CRMシステムを提供するIT企業Xの「データを活用した新事業展開による利益向上」という戦略があり、その目標達成のために「RPA」「AI」「マーケティング」などのポートフォリオがあるというイメージです。
まとめると以下のような感じでしょうか。
プロジェクトの開始、計画、実行、終結までを管理しやすいように区分したものをフェーズといいます。そしてフェーズの集合体をプロジェクトライフサイクルといいます。
さらに各フェーズ内では マネジメントプロセスと監視・コントロールプロセスである「立上げ・計画・実行・監視コントロール・終結」のプロセス、つまりPDCAサイクルが実行されます。
１つのフェーズが完了すると、次のフェーズへ移行する前にフェーズ・ゲートと呼ばれるレビュー期間が存在します。フェーズゲートでは “次のフェーズへ移行すべきか”や”プロジェクトを継続してもよいか” などが判断します。
フェーズゲートでのレビューには以下のドキュメントが参照されます。
プロジェクトライフサイクルでの、開始のフェーズは別名「コンセプトもしくはフィージビリティスタディ」フェーズとも呼ばれ、不確実性（リスク）が最も高く、コストや要員数が最も少ないフェーズです。
開発ライフサイクルと呼ばれる、プロダクトの開発やサービスに関するライフサイクルとして以下があります。
PMBOKは１のウォーターフォール型を基本とした考え方のようですが、最近はアジャイル型の開発についても少しずつ触れるようにしているようです。
プロジェクトマネージャーとして求められる能力（コンピテンシー）は3つあります。
特に３を求められる傾向が出てきたとのことでした。要は統合的にみてプロジェクトはニーズや市場にフィットしているのか、そういった視点でプロジェクトをマネジメントできるかどうかということが重要である、という考え方です。
またコミュニケーション能力が求められるスキルであり、コミュニケーションに90％の時間を費やすということが指標のようです。
プロジェクトを実行する組織の構造により、プロジェクトマネージャーの役割や権限も異なります。主なプロジェクト体制として以下の３つがあります。
1 の機能型は組織図上の上位役職者が権限を持ちプロジェクトの予算や人員を決定します。例えば、人事部のシステム導入プロジェクトにおいて、人事部長が最高権限を持ってプロジェクトをマネジメントします。その際、PMは存在しますがパートタイムであり、権限がないため、プロジェクトコーディネーター（エクスペディター）と呼ばれることもあります。
3 のプロジェクト型は、プロジェクト単位でチームが形成されており、PMが強い権限を持っています。予算管理などをすべてPMが行い、専属（フルタイム）でプロジェクトに従事します。プロジェクト終結とともに解散されるため、プロジェクトで得た経験や知識が、その他のチームや組織全体に共有される機会が少ないのが欠点です。
2 のマトリックス型は、1と３のハイブリットであり、機能型の組織にプロジェクト単位でPMを設けて、各部門からメンバーを招集してプロジェクトに取り組みます。弱いマトリックス型は機能型寄り、強いマトリックス型はプロジェクト型寄りで、バランスマトリックスが中間の位置になります。IT関連のプロジェクトでは、この組織型が多く利用されているのではないでしょうか。
| タイプ | PMの権限 | PMの役割 | 予算管理 |
| 機能型 | なし | パート | なし |
| 弱いマトリックス型 | なし、弱い | パート | なし |
| バランスマトリックス型 | 中程度 | パート | 共有 |
| 強いマトリックス型 | 中～強い | フル | あり |
| プロジェクト型 | 強い | フル | あり |
PMOのことで、PMBOKガイドでは「プロジェクトに関連するガバナンス・プロセスを標準化し、資源、方法論、ツールおよび技法の共有を促進する組織構造」と記載されています。ここでは共有の促進というところがキーです。
PMOには３つの種類があり、それぞれ役割や権限が違います。
PMOは組織図上でいうと上位に配置されたり、各プロジェクトの上位に置かれることが多い組織です。
組織体とは、組織全体（会社全体からグループ企業含めた広い意味）の Enterprise という意味であり、組織体の環境要因（Enterprise Environment Factor) は組織体を取り巻く組織内・外の要素で「コントロールに及ばないが、プロジェクトに影響・制約・指示を与える状況」として定義されています。
組織内EEF
組織外EEF
OPAは組織内で使われるプロセス・方針・手続きや知識リポジトリというプロジェクトを通して得られた知識や経験を教訓としてまとめたものを資産として管理し、プロジェクトのインプットとして利用したり、アウトプットとして更新するものです。
最後に、プロジェクトマネジメントのプロセス群と知識エリアについてまとめます。
これはフェーズのところでふれた「立上げ・計画・実行・監視コントロール・終結」の５つのプロセス群を意味します。これらプロセス群に後述の知識エリアがあります。
プロジェクトマネジメントプロセスは10の知識エリアに分類されます。
これらの詳細についてはここでは触れず、1つずつ別記事でブレークダウンしていきます。
基本編だけでも結構なボリュームでしたが、１つずつじっくり理解をしていくとすんなり頭の中に入っていく内容でした。個人的にはEEFとOPAが好きです。どうでもいいことなんですが。
次は統合編ということで、一番最初の知識エリアを切り崩していきます。
それでは今回はここまで！