English translation under construction. Stay tuned!

プロジェクトマネジメントのポイント

皆さまこんにちは。前回は、問題解決者の皆さまを支えるソフトスキルの1つである“プロジェクトマネジメント”について、3つの代表的なアプローチ(PMBOK/PRINCE2/CMMI)を紹介しつつ、概要を押さえました。

今回は、上記3つの中でも、問題解決者として押さえるべきPMBOKと、これまで書いてきた一般的な問題解決(as-is ~ to-be)およびリーンシックスシグマの進め方とマッピングして、“プロジェクトマネジメント”として追加する必要があるタスクをもう少し具体的に書いてみたいと思います。

1.プロジェクトマネジメントとして追加する必要があるタスク

ということで、まずはマッピングしてみます。

一般的な問題解決・リーンシックスシグマの流れとプロジェクトマネジメントのマッピング
図1. 一般的な問題解決・リーンシックスシグマの流れとプロジェクトマネジメントのマッピング

ちょっとゴチャゴチャしていますが(笑)、順番に説明していきます。

まず一般的な問題解決(as-is ~ to-be)とリーンシックスシグマの進め方と、PMBOKの“プロセス(横軸)”は、順番の入り繰りはありますが、概ねカバーされています。ここで注意していただきたいのが、一般的な問題解決(as-is ~ to-be)とリーンシックスシグマには2ステップが有り得るという点です。まず問題の根本原因を探って、解決策を考えるステップ(Step1)と、考えた解決策を実行するステップ(Step2)の2つです。どちらも、いわゆる“プロジェクト”として実行することができますので、その場合はどちらにも“プロジェクトマネジメント”が必要になる、ということです。

次に、PMBOKの表の縦軸”知識エリア“についてです。PMBOKには全部で10の知識エリアがありますが(詳細はこちら)、このうち”統合/スコープ/タイム/ステークホルダー/品質“の各マネジメントは、既に一般的な問題解決(as-is ~ to-be)とリーンシックスシグマの流れの中でカバーされていると言えます。

そして“コミュニケーションマネジメント”は、以前書きました“チェンジマネジメント(チェンマネ)”でカバーされますよね。

そうすると“プロジェクトマネジメント”としてカバーする必要があるのは、“リスク/コスト/資源/調達”の各マネジメントとなります。

ここで上図のPMBOKの表内の“プロジェクト(簡易)”と“プロジェクト(フルバージョン)”について説明させていただきます。

“プロジェクト”という言葉の定義は、一応PMBOKの中でもされていて“独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務”とされています。確かに、いわゆる“定常業務(ルーチンワーク)”とは異なる期限付きの業務、くらいの認識は皆あるかと思いますが、実際には何をもって“プロジェクト”と言うのかは、企業によってもだいぶ異なると言えます。

企業の中には、いわゆる“プロジェクト投資委員会”のような機関を設置し、ここで承認されたプロジェクトのみが予算とリソース(主にプロジェクトメンバー)を獲得し、実行することが認められる、というところもあれば、そこまで厳密ではなく、“出たとこ勝負(笑)”でやっているところもあると思います。

で、上述の“プロジェクト(簡易)”と“プロジェクト(フルバージョン)”ですが、きちんと予算・リソースを獲得して進めるものを“プロジェクト(フルバージョン)”、そうでないものを“プロジェクト(簡易)”と、ここでは呼びたいと思います。

“フルバージョン”の場合、予算内でプロジェクトを完了させることが大事なので、“コストマネジメント”が求められます。また予算の範囲内で必要なリソース(資源)を洗い出し、調達する“資源マネジメント”、さらに資源が社外の場合は、その“調達マネジメント”が求められます。この辺りは、コンサル会社の方(特に“マネージャー”以上の方)の場合は重要業務なので、釈迦に説法かと思います。一般事業会社の方でも、“プロジェクト投資委員会”的な機関があるような大企業の場合、この辺りはしっかり実行されていると思いますので、当ブログでは割愛させていただきます。

実は、当ブログで書いてきている“問題解決”は“簡易版プロジェクト”のイメージが強いです。その場合、“プロジェクトマネジメント”として追加して実行すべきは“リスクマネジメント”ということになります。図1の説明が長くなりました(笑)。

2. “リスクマネジメント”の概要

“リスク”とは何でしょうか?よく混同されるのが“イシュー(問題)”です。“イシュー”は既に顕在化している問題で、“リスク”は未だ発生していないものの今後起こり得る“潜在的な問題”と言うことができます。

“リスクマネジメント”は、この潜在的な問題を、早いタイミングで洗い出し、原因とその影響度を分析して、リスク軽減策(対応策)を考えておくというものです。詳細はこちらをご覧ください。

PMBOKの中では“リスク登録簿”と言われますが、例えばこんな感じのフォーマットを使って、マネジメントします。

リスク登録簿(イメージ)
図2. リスク登録簿(イメージ)

マネジメントなので、ただ書き出しておけば良いのではなく、定期的にレビューします。ステアリングコミッティ等があれば、そのアジェンダの1つとして組み込んでおくと良いと思います。

今回はこのくらいにさせていただき、また次回以降、続けていきたいと思います。 最後まで読んでいただき、ありがとうございました。

Sponsored Link