こんにちわ、スタイル・エッジLABOのOです。
最近はプロジェクト運用について、もっと効率よく出来ないかな？もっといい方法はないかな？ と考える日々です。
そんな中、最近読んだPMBOKについて書いていきたいと思います。
PMBOKとは？
PMBOK Guide、正式名称はProject Management Body Of Knowledge Guideです。 プロジェクトマネジメントの知識を体系化したもの、と本には記載されていました。
そもそもプロジェクトとはなんでしょうか？
PMBOKでは以下のように定義されています。
独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務
決定している納期に合わせて顧客の要望に合う製品やサービスを提供する業務の事
つまり、期限内に誰かの要望を満たす何かを作ったり、サービスを提供することということですね。
このようにプロジェクトとは何か？という定義から、プロジェクトを進めていく上で必要な ドキュメントなど多くの事を定義しています。
今日は10の知識エリアの一つ、プロジェクト統合マネジメントについて少し触れていきたいと思います。 まず10の知識エリアとはプロジェクトマネージャーが注意を払うべき、管理上の10の領域のことです。 プロジェクト運用するにあたってのポイントを大きく10に分けたイメージです。
以下は10の知識エリアの概要をまとめたものとなります。
| 知識エリア名 | 概要 |
|---|---|
| 1.プロジェクト統合マネジメント | プロジェクトやエリアをどのように進めるかを定義する知識エリア |
| 2.プロジェクト・スコープ・マネジメント | プロジェクトやフェーズにおける作業範囲や、成果物の設定に関して定義する知識エリア |
| 3.プロジェクト・スケジュール・マネジメント | 納期管理に関する知識エリア |
| 4.プロジェクト・コスト・マネジメント | プロジェクトで承認された予算に関する知識エリア |
| 5.プロジェクト品質マネジメント | 生成される成果物やプロジェクトの品質に関する知識エリア |
| 6.プロジェクト資源マネジメント | メンバーなどの人的資源や、物的資源などの管理に関する知識エリア |
| 7.プロジェクト・コミュニケーション・マネジメント | 会議予定を設定し、適切にコミュニケーション内容や方法を管理する知識エリア |
| 8.プロジェクト・リスク・マネジメント | プロジェクトにおけるリスクの特定・分析・対応方法、対応策の実行、リスク監視に関する知識エリア |
| 9.プロジェクト調達マネジメント | 契約終結やベンダーの管理に関する知識エリア |
| 10.プロジェクト・ステークホルダー・マネジメント | ステークホルダーの関与度の定義や管理に関する知識エリア |
10の知識エリアは、ここからさらに5つのプロセス群にわかれています。 立ち上げ、計画、実行、監視コントロール、終結というプロジェクトのプロセスごとにプロジェクトの管理方法や必要なドキュメントなどが定義されています。
この10の知識エリアの一つ、プロジェクト統合マネジメントについて少し触れていきたいと思います。
プロジェクト統合マネジメントとは
10の知識エリアの統合的な役割を持ち、プロジェクトやフェーズの進め方・管理や終結の方法を定義している知識エリアです。
例えば上記表の立ち上げプロセス時に必要とされる「プロジェクト憲章」も詳細な定義がされています。 まずプロジェクト憲章とは「プロジェクトの存在を正式に認可するために必要な文書」とあります。
プロジェクト憲章にはプロジェクトの目標や制約条件、ステークホルダーなどを記載するよう定義されています。
目標
- KPIなどの測定可能なプロジェクト目標や成功基準
ステークホルダー
- プロジェクト憲章を認可するスポンサー名
- プロジェクトマネージャー名
- プロジェクト初期段階でアサインされたメンバーリスト
制約条件
- 初期段階の要求事項
- 納期
- 予算
- プロジェクトの終了基準
また、そのプロジェクト憲章を作成する上で必要な文書も定義されています。
ビジネス文書と組織のプロセス資産が必要とあります。 組織のプロセス資産とは過去に実施されたプロジェクトの情報や、これから開始されるプロジェクトで利用できそうな内部資源の事です。
ビジネス文書についての説明は以下の通りです。
ビジネスケースとは
- プロジェクトの実現可能性の有無や、工数をかけてプロジェクトを始めるべきかを検証するための評価指標となる文書
ベネフィットマネジメント計画書とは
- 期待されるベネフィット（成果物）
- ベネフィットの発生時期
- ベネフィットの評価方法
- ベネフィットを確認する人 が記載されている文書
上記をまとめれば
プロジェクト自体のやるべき価値があるか検討し、その成果がいつどのように発生し、評価できるかを見定めた上でプロジェクト憲章を作成しましょう
上記のプロセスを踏む事で無駄なプロジェクトを進めずにすみ、何らかのベネフィットを生み出せるということですね。
このように様々な文書の定義やプロジェクトの進め方などが記載されていますが、PMBOKはあくまで定義、全てを実施する事も推奨していません。
実際に全て実施していければいいでしょうが、現実のプロジェクトでは難しく感じます。
これをかみ砕いてどう現実のプロジェクトに落とし込んでいくか？というところが大事なんだろうな、というのが感想です。
今後、試していこうと思います。
最後に
PMBOKの触りだけ紹介しましたが、いかがでしたでしょうか。
プロジェクトマネジメントはやればやるほど、難しい分野だと感じます。
プロダクトに対する責任、大量のドキュメントとの闘い、メンバーの管理、スケジュールとの闘い、そして決断を常に迫られます。
なので、どうやったら楽になるかを考える日々です！（笑
プロジェクトマネジメントの中で、ドキュメント管理は悩みの種の一つです。
これといった正解が決められているわけでもなく、時間がかかるとわかっていても作らなくてはいけない物です。
仕様書の書き方や設計書の書き方を紹介している書籍もあり、フォーマットが準備されている会社もありますが、全てが最初から用意されていることはほぼなく、結局何かを参考にその場で作っていく事の方が多かったです。
そういった経験から必要なドキュメントは何なのか、どういったフォーマットなら便利に使えるかを考える上の知識としてPMBOKを活用していければと思います。
☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、ぜひ採用サイト↓も覗いてみてください。
