見出し画像

#051 プロマネのお仕事(本編1) - 資源マネジメント(メンバーを集めよう)

画像1

こんにちは。中小企業診断士の多田と申します。

いよいよ今回から、プロジェクトマネジメントの具体的なお仕事についてまとめていきたいと思います。
PMBOKの「10の知識エリア」を、1つづつ順番に紹介していく予定です。

# 051: 資源マネジメント ← 今回
# 052: コミュニケーション・マネジメント
# 053: ステークホルダー・マネジメント
# 054: リスク・マネジメント
# 055: スケジュール・マネジメント
# 056: コスト・マネジメント
# 057: 品質マネジメント
# 058: 調達マネジメント
# 059: 統合マネジメント
# 060: スコープ・マネジメント

今回から3回は、プロジェクトを進める上で最も大切な「人」に焦点をあてていきます。

「資源マネジメント」とは

今回扱うのは、上から6番目の「資源マネジメント」です。

PMBOK_資源マネジメント

この「資源マネジメント」、PMBOKでは
「プロジェクトを成功裏に完了させるために必要な資源を特定し、獲得し、そしてマネジメントするプロセスからなる。」
と定義されています。(PMBOK 第6版 p.24)

「資源」というのは、「チーム資源」と「物的資源」の2つに分けられます。
「チーム資源」はプロジェクトメンバー、要するに人のこと
「物的資源」は、プロジェクトを進めるにあたって必要となる、人以外の装置や資材、施設、お金などのことです。

これらの資源を、リストアップし、獲得し、調整していくことがこの知識エリアの仕事になります。

PMBOK に書かれているプロセス

まずは、教科書通りに PMBOK に書かれている、この知識エリアでやるべき事(PMBOKではプロセスと言います)の内容をまとめておきましょう。
「資源マネジメント」では、以下の6つを行うのが良いとされています。

(ちなみに、この章では教科書通りのことしか書かないので、読むのがめんどくさかったら次の章まで読み飛ばしていただいてOKです。)

1. 「資源マネジメントの計画」
→ どうやって資源のマネジメントを行うかの計画書を作成します。
→ アウトプット文書: 資源マネジメント計画書

2. 「アクティビティ資源の見積り」
→ プロジェクトを進めるにあたって、どのタイミングでどれくらいの資源が必要かを見積もります。
→ アウトプット文書: 見積の根拠、資源ブレークダウンストラクチャ(RBS)

3. 「資源の獲得」
→ 見積りに書かれている、必要な資源を獲得します。
→ アウトプット文書: プロジェクトチームの任命、資源カレンダー

4. 「チームの育成」
→ メンバーに対して必要な教育を行うなどして、チームを育成します。

5. 「チームのマネジメント」
→ チームがきちんと機能するようにマネジメントします。
→ メンバー間でケンカが起きそうになったら間に入って仲裁したり、機械が壊れたら修理したりします。

6. 「資源のコントロール」
→ 業務がきちんと回っているか監視して、人が足りなくなったら追加招集したり、業務負荷が偏ってきたら割当てを変えるなどのコントロールを行います。

では、以下、これらのうち、これだけはやったほうが良いことを厳選してまとめていきます。
(それ以外の項目はとりあえず忘れても何とかなると思います。^^)

「資源マネジメントの計画」 → スポンサーを明確にしよう!

プロジェクトにおけるスポンサーとは「お金を出してくれる人」
中小企業の場合は社長さんであることが多いと思います。

プロジェクトの計画時に、スポンサーが誰かを明確にし、必要な資源を提供してもらえることをきちんとコミットしてもらっておきましょう。

意外とスポンサーが不明確なプロジェクトって多いのですが(特に大企業の社内プロジェクト)、そういうプロジェクトは、途中で「最初に言い出したのは誰か」が曖昧になってしまい、有耶無耶のうちにプロジェクトが消えてしまうことが多いと思います。

「アクティビティ資源の見積り」→ プロジェクトの体制図をつくろう!

ここでは「資源ブレークダウンストラクチャ(RBS: Resource Breakdown Structure)」という表を紹介します。
「RBS」などというと難しそうに聞こえますが、要するに、やるべき仕事に対して必要な資源を割り当てた表のこと。
「ブレークダウン」とは、階層化・細分化、という意味です。必要な資源を、徐々に段階を経て細分化していくことで、必要な資源を明確にしていきます。

例えば、「新しく会社紹介の Web サイトを立ち上げる」というプロジェクトの場合、以下のような RBS が作れると思います。

画像3

大切なのは、この図を作る過程を通して忘れている資源がないかどうか確認することです。
特に、もし業務をアウトソースしたり、コンサルを雇うことを計画しているのであれば、そうしたリソースについても予めリストアップしておきましょう。
誰か1人の頭の中だけで「このプロジェクトは何人くらい必要だな」「100万円くらい予算とっておけば大丈夫だろう」という「どんぶり勘定」をしていると、必ず後で人や予算が足りなくなり、プロジェクトが止まります

体制図ができたら、スポンサーに見せて「これぐらいかかりそうなんですが」といって了承を得ましょう。
プロジェクトの立ち上げをスムーズに進めるために、予算の見積りを少なめにして了承を得ておき、後からなし崩し的に人や予算を追加する、というテクニックもあるにはありますが、そういうことを繰り返していくとだんだん信用を失っていきますので、止めた方が良いと思います。

「資源の獲得」→ 責任分担マトリックスをつくろう!

体制図に従ってメンバーを集めたら、それぞれのメンバーがどういう仕事を担当するかの表を作っておきましょう。
ここでは「責任分担マトリックス(RAM: Responsibility Assignment Matrix)」を紹介します。

「責任分担マトリックス」とは、プロジェクトメンバーの役割を「RACI」という4つの分類で定義した表のこと。「RACIチャート」と呼ぶこともあります。

以下、「Webサイト構築プロジェクト」の RACI チャートの例です。

RACIチャート

RACI チャートを作る際のポイントを挙げておきます。

・「A(その業務の責任者)」は、1つの業務に対して1人にする。
→ ここを複数人にしてしまうと仕事に責任感が生まれません。

・その業務に一番詳しい人は、できれば「C(相談される人)」にする。
→ その業務に一番詳しい人を「A」にしがちですが、そうすると、その業務が行き詰まった際に上手く回らなくなってしまうことが多いです。
→ プロジェクトは、「独自性(これまでやったことがない)」業務です。一番詳しい人を「C」にしておくことで、「いざとなったらあの人に聞けば良い」という安心感から責任者のプレッシャーを減らすことができますし、結果的に責任者を育成することにもつながります。

・世話好きで話しかけられやすい人を「I(報告先)」にしておく。
→ プロジェクトを進めていく上で危険なのが、「悪い情報が上がってこない」という状況です。みんな、うまくいっていない状況を人に話すのは嫌なものです。しかし、そうした悪い情報をできるだけ早く把握することが、プロジェクト成功の鍵です。
→「この人になら何を話しても大丈夫」という人を「I」としてプロジェクトに参加させておくと、プロジェクト内のコミュニケーションが良くなって、成功確率が高まることが多いです。

作成した RACI チャートは、必ずメンバー全員で共有し、自分の役割を理解・納得してもらうようにしましょう。
また、プロジェクトの途中で役割が変わった場合には、随時チャートを更新しておきましょう。

「資源の獲得」→ 相談できる人を確保しよう!

プロジェクトメンバーを集める際、特に、RACIの「C(相談相手)」をプロジェクト初期の段階できちんと用意しておくことが大切です。
その業務のことをよく知っている相談相手がいないと、メンバー各自が、経験のない業務を試行錯誤しながら進めざるを得ない状況になってしまいます。

新規事業においては、失敗を恐れずにチャレンジし、失敗から学べば良い、などと言われることもありますが、必要な準備をしないで突き進んでしまった無謀な挑戦からは、何も得ることができません。
避けられる失敗は避けるべきです。

自社内部のリソースだけにこだわらず、必要であれば中小企業診断士のような外部のコンサルを「C(相談相手)」として活用するのも良いと思います。

「チームのマネジメント」→ メンバーと話をしよう!

プロマネの仕事のほとんどはこれかもしれません。
各自の業務が予定通りに進んでいるかどうかをこまめに確認し、遅れているようなら、その都度対処方法を考える必要があります。

優れたプロマネは、常に「現時点でだれも気がついていないプロジェクトの問題点」にどうやったら気がつくことができるか、を考えています。
今見えていない問題やリスクに気がつく一番の方法は、メンバー間で会話することで、新たな気付きを得ることです。
たわいも無い話の中から「そういえば、○○が気になってます」という、「そういえば、」を引き出せるかどうかが、プロジェクトを上手く進めるために重要です。

「チームのマネジメント」→ メンバーの不満を解消しよう!

「コンフリクトの解消」もプロマネの重要な仕事です。要するに、メンバーの不満の解消や、ケンカの仲裁。
テクニックとしては、

1. 強制(Forcing): 権力を持っている人が言って聞かせる
2. 鎮静(Smoothing): 根本原因の解決はとりあえず後回しにして、その場を治める
3. 撤回(Withdrawal): 片方が自分の意見を取り下げる
4. 妥協(Compromising): お互いが妥協して着地点を探る
5. 対峙(Confronting): 徹底的に意見をぶつけ合って、解決点を見出す

等がありますが、場面場面によって適切な対処法は異なります。
「5. 対峙」できちんとお互いが納得する形にするのが良いですが、プロジェクトのスケジュールやコストの問題などで対峙に十分な時間がとれない場合もあります。
「2. 鎮静」でとりあえずその場を凌いでおき、裏で根本原因の特定と解決を行う、といったあたりが現場では多いような気がします。
プロマネとしての人間力が試されるところですね。

「資源のコントロール」 → 場合によってはメンバーから外れてもらおう!

最後にちょっと厳しい話。

プロジェクトを進める上で、必要な人を呼んでくるのももちろん大切ですが、それ以上に「プロジェクトにいてはいけない人をきちんと排除する」ことが大切になる場面があります。

例えばボトムアップ型のプロジェクトの場合。
できるだけたくさんの人に参加して欲しくて、「やりたい人は自由に誰でも参加して下さい!」みたいな集めかたをすることがあります。
しかし、いつまでもそのやり方だと、各自が自分のやりたいことを始めてしまったり、間違った口出しをしてしまったりすることが往々にして発生します。

そういう場合には、プロジェクト全体への影響を考えて、メンバーから外れてもらわなければなりません。
辛い仕事ですが、必要な時には心を鬼にする覚悟もプロマネには必要です。

まとめ。

(1) 「プロジェクト資源マネジメント」とは、プロジェクトに必要な「チーム資源」と「物的資源」をリストアップし、獲得し、マネジメントしていく活動のことです。

(2) ツールとしては、資源をリストアップするための「資源ブレークダウンストラクチャ」や、メンバーの業務を明確にするための「RACIチャート」などがあります。

(3) その他、プロマネとしては、スポンサーを明確にしてスポンサーからの承認を得ること、メンバーとコミュニケーションをとって常に今見えていないリスクを見つけることを心掛けること、メンバーが気持ちよく仕事できるような環境を整えてあげること、が重要です。

----------
(ここに書かれている内容はいずれも筆者の経験に基づくものではありますが、特定の会社・組織・個人を指しているものではありません。)

この記事が気に入ったらサポートをしてみませんか?