【プロジェクトマネジメント】プロジェクトマネジメントする際に忘れてはいけない観点としての知識エリアとプロセス

先日、そもそもプロジェクトとは?というお話をしました。

 

 

www.yoshiyoshiya.com

 

 

今回はプロジェクトマネジメントをしなければ!となった方に向けて、

プロジェクトマネジメントの全体感を捉えていただけるようにマネジメントする際の観点を紹介します。

また、その観点に基づいて、何をすれば良いのか?に踏み込んでいきます。

 

私は、IPAのプロジェクトマネージャを取得してますが、PMPは取得してません。

そのため、紹介する事例がITのシステム開発寄りの記載になります。ご了承ください。

 

f:id:yoshiya_na:20200506173052j:plain

 

 

PMの10の知識エリア

マネジメントする際の観点は、抜け漏れが無いようにPMBOKに従いましょう。そのため、以下の10の知識エリアに従ってプロジェクトをマネジメントしていきます。

  1. 統合
    プロジェクト、フェーズをどのように進めるかを定義
  2. スコープ
    作業範囲、成果物を定義
  3. スケジュール
    納期管理
  4. コスト
    承認予算
  5. 品質
    成果物、プロジェクトの品質
  6. 資源
    人的資源、物的資源の管理
  7. コミュニケーション
    会議体、コミュニケーション方法
  8. リスク
    リスクの特定、分析、対応、監視
  9. 調達
    契約締結、ベンダー管理
  10. ステークホルダー
    ステークホルダーの関与度、管理

f:id:yoshiya_na:20200506174903j:plain

ご自身がプロジェクトマネジメントをすることになった際には、上記の観点が全て考慮できているかを考える必要があります。

PMのプロセス

プロセスについては、以下の5つのプロセスで構成されます。ちなみに、PMBOKでは、知識エリアを縦軸とプロセスを横軸にとって、それぞれの成果物やタスクのイメージがマトリクスになっています。(後述)

  1. 立ち上げプロセス群
    各フェーズでステークホルダーを特定
    例えば、開始時には必要なスキルセットの特定
  2. 計画プロセス群
    各ステークホルダーの要求事項をもとに、
    各フェーズを進める上で必要な実行計画書を作成
  3. 実行プロセス群
    その実行計画書に基づき成果物を生成する作業
    その際に発生した課題への対処
  4. 監視コントロールプロセス群
    プロジェクト状況の定期的な評価
    計画と現実のGAPへの対処検討
  5. 終結プロセス群
    クライアントへの成果物の納品及びその承認
    次フェーズのための成果物作成

 

大事なことは、以下のプロセスを各フェーズで実施できるように準備しておくこと。この立ち上げ、計画、実行、監視、終結がフェーズ毎に繰り返し必要になることを理解してそもそもの計画に入れておくことです。

 

ちなみに、知識エリアとプロセスを軸にして、成果物、タスクが以下のように定義されています。

f:id:yoshiya_na:20200524151248p:plain

 

おそらく、この表を見た方は、プロセスが計画と監視に偏っている!ということに気づかれたと思います。

そのため、先ほど大事なことは事前準備だと言いましたが、さらに端的に言うならば、次フェーズにおいて、各知識エリアをどのようにマネジメントするかの計画ができているか?また、それを監視する仕組みが構築できているか?の2つに重要なポイントを集約することができます。

 

例えばですが、システム開発においては、基本設計時に設計書の品質をどのように管理するか?レビュー指摘の数や質を設計書単位で確認する。ベンダー毎に確認する等々のマネジメント方法を考えておきます。その上で、設計書の本数がトラッキングできるか?レビュー指摘の数や内容がトラッキングできるか?を詰めていくことになります。

 

トラッキングについては、ベンダーに対して、指摘の分類を提示しておくことでその内容を把握できるようにすると言った準備が重要になります。

要件の矛盾、不十分と言った分類と、設計自体の不備、あるいは、記載の分かりやすさ、誤字脱字、レベル感の違うものを一緒くたにすると、原因分析、対処の検討がうまくできません。

そのため、定期的に上記をレポーティングさせるようにテンプレートを作成しておく、報告の時間を設けておくことが重要です。

 

知識エリアから考えるマネジメント観点の詳細化

大枠の考え方がわかったところ、一つ一つの観点をさらに詳細化していきましょう。それぞれの観点が漏れていないかご自身のプロジェクトに当てはめて考えてみることが重要です。

 

統合

  • プロジェクトにおけるフェーズ定義が決まっているか?
  • 各フェーズのクライテリアゲートが決まっているか?(何をすると、フェーズ完了と言えるか?)
  • 変更管理(スケジュール、コスト、スコープ等々)のプロセスが決まっているか?

スコープ

  • 各フェーズの作業範囲が決まっているか?
  • 各フェーズで作成する成果物が決まっているか?
  • 関係チーム、ステークホルダーとの作業分担の境界線が明確になっているか?

スケジュール

  • 各フェーズの期間が決まっているか?
  • 各フェーズのマイルストーン(プロジェクト上の重要な会議や、イベント)が決まっているか?
  • 各成果物を作成可能な期間が決まっているか?
  • 納期(完成)に向けての作業順序が決まっているか?
  • スケジュールの変更要望が収集できるか?

コスト

  • 使える予算が明確になっているか?
  • 必要な予算が明確になっているか?
  • 使える予算が承認されているか?
  • 予算の使い道毎に、必要な予算が明確になっているか?
  • 消費コストが収集できるか?

品質

  • 成果物に求められる品質が定義されているか?
  • 品質を測る情報が収集できるか?

資源

  • 人的資源の総量が把握できているか?
  • 必要な物的資源が把握できているか?
  • 既に利用可能な資源が把握できているか?

コミュニケーション

  • 必要な会議体が設定できているか?
  • 必要なチーム間のコミュニケーションパスができているか?
  • 全体の状況把握、チーム内の状況把握、ラインの状況把握と規模毎の状況把握の仕組みが構築できているか?
  • 各種決定事項に対する承認者及びその権限が明確になっているか?(変更管理を承認できるのは誰か?成果物についてOKと言えるのは誰か?フェーズ完了にOKと言えるのは誰か?)

リスク

  • リスクを収集する仕組みが構築できているか?(要員の病欠、進捗の遅延、品質の低下、外部要因の把握、例えば今だとコロナによる在宅勤務)
  • リスクの影響度、発生確率が計測できるか?
  • リスクに対して対策を立てられているか?
  • 適切なメンバーで対策できているか?(場当たり的な対策でなく、プロジェクト全体への影響を鑑みた対策にすること)

調達

  • 必要なベンダースキルと人数が明確になっているか?
  • 契約体系、成果物、品質、期間等が明確になっているか?(請負、派遣、オンサイト、オフサイト等々)
  • 契約サイクルが明確になっているか?
  • 契約時の承認プロセス、承認者が明確になっているか?

ステークホルダー

  • ステークホルダーが明確になっているか?
  • ステークホルダー毎のタスクが明確になっているか?
  • 各フェーズ完了の承認者が明確になっているか?(予算承認を伴う立ち上げや、設計の完了、あるいは、プロジェクトの完了) 

 

ここまで、私の普段の仕事から思いつくものを羅列しています。今後も定期的に見直して行きますので、参考にしてください。

まとめ

この記事では、プロジェクトマネジメントの全体感を捉えていただけるようにマネジメントする際の観点を紹介してきました。

私は、PMを生業としていますが、改めて書き出してみると色々なことをしているなあと思いまました。(アウトプットって重要ですね)

 

ただ、個人的には、プロジェクトを進めるのはもちろんプロジェクトメンバーであり、プロマネでは無いと思っています。

PMはプロジェクトに必要な色々な仕組み作り、調整を行い、監視して改善するという裏方だと思っています。プロジェクトメンバーが働きやすいような環境作りが一番の仕事です!

 

今後、さらに、一つ一つの知識エリアを細かく説明して行きます。

 

では!