このシリーズは、私がこれまで経験したプロジェクトで培ったマネジメントノウハウを、PMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの読み物的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。
資源マネジメントにおける各プロセスは以下の通りです。
すごく平たくいえば、プロジェクトメンバのマネジメント、要員管理のことです。
それ以外にはあまり一つのプロジェクトで管理するのではなく、課や部といった組織で管理しているところが多いと思いますが、開発用のPCやサーバー、各種開発時のソフトウェアライセンス、プロジェクトルームの賃貸料なども含まれてきます。ただし、ここでは割愛します。
なお、資源マネジメント、調達マネジメント、ステークホルダーマネジメントとの棲み分けはこのような整理としております。（経験則での記載です。）
| 調達マネジメント | プロジェクトに必要な資源の調達。要員に関して言えば、BPとの契約形態（準委任、工数請負、一括請負）を管理する。 |
| 資源マネジメント | 調達マネジメントで調達してきた要員を管理する。 |
| ステークホルダーマネジメント | 主には顧客、そして要員も含めたプロジェクト関係者を管理する。 |
要員管理のポイント
要員別の責任範囲
PMはプロジェクトメンバのスキルを可視化し、そのうえで各メンバにどの成果物をどこまで任せるのか、誰にレビューをさせるのかを決定します。
そして、各メンバにはそれぞれの役割を与え、その範囲における責任を理解させ、遂行させるように意識づけを行っていきます。
PMの仕事である”見える化”についてこちらの記事もご覧ください。
要員別進捗管理
プロジェクト全体として進捗が問題ない場合であっても、要員別に見た時には遅延しているメンバがいることも多いです。
その場合、いずれはそのメンバのタスクが完了しないことでその工程自体が完了しないことに繋がります。
したがって、要員別の進捗管理を行い、定期的にタスクの再分配を行っていきます。
注意点としては、タスクの再分配を行う際は、メンバの心情に寄り添う、問いかけるです。
前倒ししていたメンバはせっかく進んでいたにもかかわらず仕事が増えることになります。
しかし、プロジェクト全体として再分配が適切である場合は、きちんとそのメンバに感謝を伝え、信頼を置いている旨を伝えてなんとか引き受けてもらうように働きかけます。そして、きちんと組織としての評価に繋げていくことが重要です。
一方、遅れているメンバをタスクを巻き取る際は、遅延している本人に自己申告させ、どこまでならやり切れるかを報告させます。これによりそのタスクに対する責任を持たせ、完遂させます。与えられたタスクはこなせなくても自分で決めた物量に対しては必ずコミットさせるようにします。ここは妥協してはいけません。
当然、プロジェクトとしてはそれでも終わらないことへのリスク対策を検討しておくことにはなりますが、それは当人には伝えず、自己申告の範囲で必ず完遂させることを義務化します。厳しいですが、土日深夜問わず、申告した範囲では成果を出させることです。これが結局は本人の為でもあるので、妥協はしてはいけません。
要員別生産性考察
進捗がオンスケであったり、前倒しだったとしても注意が必要です。
もし、メンバが残業を繰り返してオンスケであったらどうでしょうか。
それは現時点ではオンスケであったも、将来遅延を招くリスクが潜んでいます。
最悪の場合は、メンバが体調不良で数日、数週間、もっといえばプロジェクトから離脱することに繋がります。
生産性はCPIで測ることができます。
オンスケや前倒しというポジティブな要素を盲信してはいけない最たる例です。常に頭の片隅に置いておきましょう。
要員交代・変更の危険性
要員交代
要員交代、要員追加はプロジェクトがうまくいっていないときに一番最初に挙がる対応策です。
しかし、諸刃の剣であることを肝に銘じておかなければいけません。
要員追加をする際、以下のことに気を付けます。
・追加要員の立ち上がり工数を確保
どんなに優れた人であったも参画してその日のうち、もしくは次の日から戦力になるものではありません。
プロジェクト概要を理解し、現状を理解し、雰囲気を把握し、プロジェクトのルールを理解し、システムのことを理解し、要件・仕様を把握し、用語に慣れていく必要があります。仕事環境の構築、開発環境の構築も必要です。
必ず、数日間（感覚としては10日、短くても５日ほど）の立ち上がり工数を設けます。
炎上しているプロジェクトではその5日、10日も惜しいとは思います。しかし、そこはぐっと我慢します。しっかりと立ち上がった要員の方がプロジェクトに対する帰属意識も高くなり、要件・仕様の理解も正しくでき、貢献度も高くなります。
・既存要員のタスクの整理
新規要員が一人でに立ち上がることもありません。誰がか受け入れをしなければいけませんし、説明もしなければいけません。
そうすると、一時的に既存メンバの負荷が上がります。避けて通ることはできませんので、既存メンバには事情を説明し、動機付けをしたうえで対応してもらいます。
しかし、単に押し付けるのではなく、既存メンバのタスクのうち剝がせるものがないかをPMが考えることも大切です。
例えば、追加要員に実施させられるようなタスク（単純作業など）があれば、率先して既存メンバのタスクを軽くします。やれるだけのことはやります。
BP社からの要員追加であれば、その会社のリーダやサブリーダーに受け入れさせます。BPにはこちらからお金を払っている訳ですから、当然その分の受け入れも含めて面倒を見てもらうように促します。
これを断ってくるような会社とはそもそも取引しない方がよいです。
・追加要員のタスクの整理
追加要員がすぐに肝になる要件や仕様、難易度の高い機能を担当できる訳ではありません。
仮に、難易度の高い機能にテコ入れを入れたくても、追加要員が余程優秀でなければ既存要員を割り当て直した方が効果的なことが多いです。
また、前述のとおり、できれば”作業”レベルでできるようなこと（例えば、UTデータがあるうえでのUTテスト消化など。これも難しいことも多いが）を事前に整理しておきます。
・追加要員の定期的な生産性考察
いくら立ち上がりに時間がかかるとはいえ、１か月、２か月経った頃にはその生産性を確認する必要があります。なかなか立ち上がらない場合の対処方法を検討する必要があります。
要員変更
プロジェクトがうまくいかない理由の１つに、そのプロジェクトにおいて影響力が大きい人の存在があります。例えば、権限があることを理由に簡単に決定事項を覆してくる顧客、仕様を一番把握しているが頑固な自社のメンバ、いつもバチバチけんか腰で口論をしてくるメンバなど。
こういう人たちはプロジェクトを遂行するうえでなんとかしなければいけません。それは配置展開であったり、別の人に交代するで対応していきます。
こういった存在は、PMが厄介、プロジェクトに良い影響を与えないと判断したら、除外したり、弱体化させていきます。その権限がPMにはあります。
PMは覚悟をもって要員変更を行いましょう。
まとめ
システム開発プロジェクトにおいて、ヒトは最も重要な資源であり、リソース面でも比重面でもその大部分を占めます。
したがって、極論ヒトをうまくコントロールさえできれば、プロジェクトはうまくいくでしょう。
勿論、メンバ全員がスーパーサイヤ人並みに優れていて、双方にコミュニケーションを図り、自走してくれれば、PMは困ることはないです。何もしなてくもプロジェクトはきっとうまくいくと思います。しかし、現実にはそんなことはありません。
だからこそ、PMが軍師となってメンバを率いてプロジェクトを遂行する必要があるのです。
参考文献
・情報処理教科書 プロジェクトマネージャ （三好康之著）
私は2019年度版を参考にしています。
・プロジェクトマネジメント実践講座 伊藤大輔（著）
コメント