システム開発のプロジェクトマネージャーを任命されたけど、要員計画はどうすればいいの？
そもそも要員計画ってなに？
要員計画のやり方がわからない？
要員計画の目的は、計画通りに要員をアサインしてプロジェクト運営を円滑に進めていくことです。
しかしながら、プロジェクト計画時点では開発規模がぼんやりしていて大雑把な工数しか見えていないため、全工程で要員が何人必要か把握することは難しいと思います。
また、上流工程から参加しているメンバーがプロジェクトの途中で交代するような事態は避けなければなりません。
今回は、プロジェクトにおける要員計画とは何か？外部委託先を含めた要員をどのように計画していくのかをわかりやすく解説します。
前回のおさらい（プロジェクト計画の書き方）
これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。
プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。
これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。
- プロジェクト概要
- マスタースケジュール・WBS
- プロジェクト体制
- 成果物
- 変更管理
- 欠陥管理
- 課題管理
- コミュニケーション計画（会議体）
- 要員計画 今回はここ
- リスク管理
- プロジェクト標準
今回は、要員計画を解説します。
プロジェクトにおける要員計画とは？
プロジェクトの規模によって自社の要員（開発メンバーを指します）だけでよい場合もあれば、外部委託先に要員をアサインすることもあります。ここでは外部委託先を含めた要員をどのように計画していくのかを解説します。
プロジェクト計画では体制図を作成します。体制図の目的は、プロジェクトに参画するすべての方（ステークホルダー）の名前を列挙して、その責任と作業の分担を明確にすることです。したがって、この体制図には自社の要員はもちろん、開発を委託する会社の要員も記載する必要があります。
しかしながら、プロジェクト計画時点では開発規模がぼんやりしていて大雑把な工数しか見えていないため、全工程で要員が何人必要か把握することは難しいと思います。
要員計画を行うためにはプロジェクトの開発規模を見積もる必要がありますが、この段階ではお客様からいただく提案依頼書（RFP）をもとにプロジェクト概要をまとめて、それをベースに超概算で見積もることになります。どうしても見積もり精度が悪くなるため、この時点ではプロジェクトの開発規模を大雑把に算出する程度になりますが、算出した工程別の工数から必要となるだろう要員を計画していきます。
ウォーターフォール型のシステム開発では、各工程で必要となる要員数はプログラム開発時点の要員が一番多く、それを頂点とした山形になります。
プロジェクト開始にあたり、まずは要件定義の要員を手配する必要がありますが、規模が大きくなれば開発期間も長くなるため、自社や委託先会社とも認識を合わせておく必要があります。
そのため、どの時点でどのようなスキルを持った要員が必要なりそうかをプロジェクト計画に明記し、ステークホルダーで共有することが重要になるわけです。
要件定義を行った要員がプロジェクトの途中で交代する事態は避けなければなりません。プロジェクトマネージャーやリーダーは言うまでもなく、要件定義から参画する主要メンバーも交代することがないように自社・委託先会社と要員計画を共有することがプロジェクト成功へのポイントとなります。
必要な要員を検討する
では、それぞれの工程で何人の要員が必要なるでしょうか？
まずはプロジェクトの開発規模を見積もる必要があります。
この段階ではお客様からいただく提案依頼書（RFP）やプロジェクト概要をベースに超概算で見積もります。（見積もり方法については自社のルールに従って算出してください）
開発規模がわかれば、おおよその各工程の工数が見えてきます。自社の過去プロジェクト事例から工程別の工数比率を導き出したり、IPAのソフトウェア開発データ白書より工程比率を利用しましょう。
例えば下記のように工程別の比率があれば、全体の工数から工程別の工数を簡単に計算できます。
| 工程 | 要件定義 | 概要設計 | 詳細設計 | 開発・単体テスト | 結合テスト | システムテスト | 合計 |
| 工程比率 | 6% | 12% | 14% | 43% | 8% | 17% | 100% |
| 工数 | 14.4 （人月） |
28.8 （人月） |
33.6 （人月） |
103.2 （人月） |
19.2 （人月） |
40.8 （人月） |
240.0 （人月） |
※この工程比率は事例です
この工程別の工数をもとに、各工程で必要な要員を検討していきます。
実際には要員を小数点以下の数値で表すことはできませんので、１人月単位に切り上げて必要な要員数を求めます。
この例では、要件定義は14.4人月となっていますが、14名をアサインして残り0.4人月分は残業して対応するか、15名をアサインして対応するかのどちらかになります。このように各工程で必要な要員を検討していきましょう。
工程別の工数を見積もって、各工程で必要な要員を検討していきます。小数点以下は1人月単位に切り上げて1名をアサインしましょう。
開発工程に見合った要員計画を策定する
先に図で示したように、ウォーターフォール型のシステム開発には要件定義や設計、開発、テストなどの工程があります。
例えば、要件定義ではお客様が要求する要件をヒアリングしてビジネスに真に必要な機能は何かを洗い出すスキルが必要ですし、設計では要件定義で洗い出した機能をシンプルで理解しやすいシステムに具現化するスキル、開発では構造化した見やすいプログラミングや効率的なテストを行うスキルが必要なります。
それぞれの開発工程で必要となるスキルが異なりますので、各工程に見合ったスキルの要員をアサインする必要があります。
システム会社では、それぞれスキル別に「上級SE」や「SE」「プログラマー」などの呼称で分類しますが、スキルに見合った要員計画を策定しましょう。
SEの中でもDB設計は特別なスキルが必要なため、別途要員が必要かどうか確認が必要です。サーバやネットワークに関するインフラの技術者も同様です。いざシステム開発を進める段階でDB設計やインフラのスキルを持った要員がいないと言うことがないように注意しましょう。
次の工程に向けて早めのアサインを心がける
こちらも先に図で示したように、工程が進むにつれて要員の数も増えていきます。直前に要員をアサインすると該当するスキルを持った要員がアサインできないことがあります。そのため、自社や委託先会社と今後の要員計画を共有し、常に早めにアサインしていきましょう。
また、開発以降は逆に要員が減っていきます。要員が委託先の場合、少なくとも１か月前には契約終了を通知する必要があります。（各会社の契約内容によって決まっていると思いますので確認しましょう）
どの要員を残すのかをあらかじめ決めておくことが重要です。要件定義から参画している要員を本稼働まで維持することがプロジェクト成功に繋がりますので計画的にアサインしましょう。
工程が進むにつれて要員の数が増えるため、早めにアサインすることを心がけましょう。
また、決まった要員は体制図に名前を明記しましょう。決まっていない箇所はアサイン中であることも明記して共有しましょう。
プロジェクト計画段階で要員計画を共有し、早めに要員をアサインしてプロジェクトを円滑に運営しよう
プロジェクトの成否は、チームワークの取れた組織かどうかによって左右されると思います。プロジェクト推進途中で計画外の要員交代があってはなりません。
また、次の工程に進むために計画通りに要員がアサインできないとスケジュールにも影響してきます。プロジェクト計画時点で、しっかりした要員計画を策定し、ステークホルダーで共有することがプロジェクト成功へのポイントです。
プロジェクト進行に合わせて常に要員計画も見直しながら、早めのアサインでプロジェクトを円滑に運営しましょう。
要員計画の解説はこれで終わりです。
引き続き、プロジェクト計画でやるべき11項目のガイドを解説します。これらをプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。
- プロジェクト概要
- マスタースケジュール・WBS
- プロジェクト体制
- 成果物
- 変更管理
- 欠陥管理
- 課題管理
- コミュニケーション計画（会議体）
- 要員計画
- リスク管理 次回はこちら
- プロジェクト標準
次回はリスク管理について解説します。よろしければ次の記事もお読みください。
