プロジェクトの要員計画・リソースプランどうすればいいの?
なにかおすすめのテンプレート無いの?
といった疑問に答えます。
この記事を読むことで、
・要員計画・リソースプランの進め方
・使えるテンプレート
を知ることができます。
ここで重要なポイントが、テンプレを手にしただけでは質の高い要員計画は立てられないという点です。質の高い要員計画を立てるためには、
①そもそもプロジェクト遂行にどんな人材が必要か?=経験
②どんなリソース・タレントが社内にいるのか=人材データベース
が必要になります。
ほとんどの企業では、人材データーベースはなく、知識と経験であの人はこれができるといった感じで決まるのがほとんどですが、本来はこの2つの情報が重要になります。
本記事では、書き方・テンプレの紹介にとどまらず、この①の経験が必要な部分をどのように補填できるのか?に関しても解説していきます。
プロジェクト要員計画に必要な人材を洗い出す5つの方法
ITプロジェクトを例にプロジェクト推進に必要な人材の考え方を解説します。方法は5つあります。
・過去の経験から反省・改善をふまえ必要人材を特定する
・必要な作業・タスクを洗い出し要員計画をする
・ベンダーの提案を元に必要人材を特定する
・有識者に相談する
・有識者を採用する
過去の経験から反省・改善をふまえ必要人材を特定する
これが一番の王道です。プロジェクトを導いてきた経験と知見を元に要員計画を検討します。過去のプロジェクト体制の上手くいかなかった点を考慮し新しい体制図・要員計画に繋げます。過去の経験を着実に積み上げる為に、プロジェクトの振り返り・ドキュメントの整理をしっかりしておくことをおすすめします。
とはいえ、初めてのプロジェクトや知見があまりない場合はどうすればいいの?となります。その場合の対処方法を以下で解説します。
必要な作業・タスクを洗い出し要員計画をする
必要な要員は?といきなり聞かれると難しいですが、考え方を変え、プロジェクト遂行に必要な作業は?であれば、考えやすいです。
例:
必要な要員は?の場合、PM、開発担当、インフラ担当
必要な役割・作業は?プロジェクト管理、開発推進、インフラを検討する人
こういった具合です。
こちらで紹介しているテンプレートであれば、役割も記入できるので検討しやすいと思います。
ベンダーの提案を元に必要人材を特定する
(上記はイメージ画像 by ラクプレ)大きなプロジェクトの知見・経験が無い場合、検討が進まない事もあります。その場合、有効な手段は3つあります。1つ前は、ベンダーの提案を元に必要なリソース・役割を認識する方法です。
ただし、1つのベンダーからの提案では抜け漏れがある場合もあります。その場合、相見積もりのベンダーの提案と必要リソースを比較して整合性を確認がおすすめです。
また、以下で紹介する他2つの方法も有効です。
有識者に相談する
社内や外部で有識者がいる場合は、どんどん遠慮せずに聞くべきです。意外と多くのケースで社内に有識者がいるのに部署が違うので相談しないケースを驚くほど見かけます。心理的に、ストッパーがあるのかもしれませんが、意外と好意的にアドバイスいただけるケースがほとんどなので気軽に相談すべきです。その相談から新しいコネクションができる場合がかなりあります。
何を知っているか?よりも、誰を知っているか?が重要です。
有識者を採用する
有識者を採用してします。これが一番のおすすめですが、企業・部署の状態によっては難しい場合があると思い最後の選択肢にしました。しかし、新しいソリューションの導入やプロジェクトで立ち上げゆくゆくは部署への成長を検討しているのであればなおさら有識者を採用してしまうのも検討を進めるべきです。
要員計画・リソースプランを進める4つのステップ
ここからはテンプレートを交え具体的に何を作っていくべきか?を解説します。
進め方は、PMBOK(Project Management Body of Knowledge=プロジェクトマネジメントの知識体系ガイド)で解説されているフレームワークに沿って解説していきます。
人員資源のマネジメントに関連したプロセスは以下の4つです。
・人的資源マネジメント計画
・プロジェクト管理のためのチーム編成
・プロジェクト管理のためのチーム育成
・プロジェクト管理のためのチームマネジメント
1つづつのプロセスの概要と何を具体的に準備必要か解説します。
人的資源マネジメント計画
必要な人員の役割や調達、育成などのマネジメント方針を計画して決めます。
具体的には、RACIチャートを作ります。
<RACIチャート>
役割を明確にするためのチャートです。エクセルで縦にプロジェクトに必要な役割を一覧化しその右にその役割の責任を定義します。
定義する内容は、
Responsible(実行責任)
Accountable(説明責任)
Consult(相談対応)
Inform(情報提供)
となります。
プロジェクトでSierさんを巻き込む場合も、RACIを自社で一度作成し、そのRACIに基づきすり合わせ→見積もりといった流れで進めます。
例
事業 | 社内SE | ベンダー | |
要件定義 | A | C/I | R |
基本設計 | C/I | A | R |
テスト(ユニットテスト) | C/I | R/A | |
テスト(IT) | I | R/A | C |
テスト(UAT) | R/A | C/I | C/I |
上記はあくまでサンプルですが、このように役割の期待値を明確化するとベンダーさん・事業との分業がしやすくなります。
RACIの詳しい説明とダウンロードは以下のサイトからできます。
プロジェクト管理のためのチーム編成
RACIで役割を定義がわれば、プロジェクトに必要な人材をアサインしチームを構成します。このときに、社内に人材データベースがあれば参照し活用することができます。
プロジェクト管理のためのチーム育成
必要な人員のスキルやチームワークを強化し、プロジェクトに対してのパフォーマンス向上をさせます。
上記の人材データベースに関連しますが、人のスキルが見える化できていれば、プロジェクトに必要な人材の不足しているスキルを意識して上げる仕掛けも効率的に検討可能です。
プロジェクト管理のためのチームマネジメント
プロジェクト遠隔に推進するために、プロジェクト運営を実施します。プロジェクトマネージメントのコツに関しては以下の2つの記事で詳しく記載しています。合わせてご覧ください。
要員計画・リソース計画で注意する点・アドバイス
ここまでで、要員計画・リソース計画の進め方をご紹介しました。最後に、失敗しない要員計画をするためにプロジェクトで陥りがちな注意点をいくつかご紹介します。
・プロジェクトと組織を混同しない
・リソース計画の目的を理解
・役割を礼儀する
・しがらみを捨てる
プロジェクトと組織を混同しない
リソース・要員を洗い出し体制図を作る際に気を付ける点は、プロジェクトと組織図を混同しないことです。組織の中で役職はありますが、その上位者が必ずプロジェクトで上位の役割につかなければいけないわけではありません。
例えば、
役職=課長のAさん、平のBさんがいたとしても、プロジェクトでは、Bさんがプロジェクトリードの役割で参画し、課長のAさんは登場しない構成があってもいいわけです。この場合、プロジェクトの中で、BさんはAさんに報告義務はありませんが、組織のレポートラインとしてAさんに活動報告の一環でプロジェクトの様子を共有する必要はあります。
さらに詳しく体制図に関して学びたい方は、以下の記事をあわせてご覧ください。
リソース計画の目的を理解
リソース計画作成の目的は、リソース計画を作ることではありません。当たり前のことですがこれもかなり陥りやすい、手段が目的になるケースです。リソース計画の最終目的は、プロジェクトを成功に導き事であり、そのために必要な管理すべきリソースを管理できる状態にすることです。
決して、リソース・要員を一覧化して満足してはいけません。
役割を定義する
体制図からついつい作り始めてしまうケースもあります。同じ人でプロジェクトリソースの話をする場合はこれでOKかもしれません。しかし、他部署・他関連会社・海外現法等の役割の共通認識がないステークホルダーとリソースの話をする場合には必ず役割の定義が必要です。
しがらみを捨てる
リソース計画・要員計画はプロジェクトを成功に導くために行い、必要なリソースの調達と管理を助けるツールです。折角洗い出せたのに、あの部署は話しにくい、他の組織は知らないから会話しない、知っている人で固めてしまうにとどめるアクションでは、リソース計画・要員計画も元も子もありません。しがらみを捨てプロジェクト成功に必要な行動につなげましょう。
プロジェクトの要員計画・リソースプランの始め方【テンプレあり】まとめ
この記事でご紹介した、プロジェクト要員・リソース計画を上手く始めるポイントのまとめです。
プロジェクト要員計画に必要な人材を洗い出す5つの方法
・過去の経験から反省・改善をふまえ必要人材を特定する
・必要な作業・タスクを洗い出し要員計画をする
・ベンダーの提案を元に必要人材を特定する
・有識者に相談する
・有識者を採用する
要員計画・リソースプランを進める4つのステップ
・人的資源マネジメント計画
・プロジェクト管理のためのチーム編成
・プロジェクト管理のためのチーム育成
・プロジェクト管理のためのチームマネジメント
要員計画・リソース計画で注意する点・アドバイス
・プロジェクトと組織を混同しない
・リソース計画の目的を理解
・役割を礼儀する
・しがらみを捨てる