プロジェクト・リーダーの心得
(2)資源の最適配分
2つ目の「資源の最適配分」とは、ヒト、モノ、カネを適切に配分するというだけのことですが、これも実践するのは容易ではありません。ここで大切な考え方は、以下の2つです。
- リソース・ヒスト
- プロジェクトの採算状況確認
リソース・ヒストは、その名の通り、人員配置です。プロジェクトの工程ごとに何人のメンバーをアサインするかを計画します。
表1: リソース・ヒストグラム(※単位は人月)
佐藤 | 4月 | 5月 | 6月 | 7月 |
---|---|---|---|---|
プロジェクト管理 | 0.01 | 0.01 | 0 | 0 |
要求分析 | 0 | 0 | 0 | 0 |
基本設計 | 0 | 0 | 0 | 0 |
詳細設計 | 0 | 0 | 0 | 0 |
製造&単体テスト | 0 | 0 | 0 | 0 |
結合テスト | 0 | 0 | 0 | 0 |
総合テスト | 0 | 0 | 0 | 0 |
ユーザー・テスト・サポート | 0 | 0 | 0 | 0 |
データ移行 | 0 | 0 | 0 | 0 |
マニュアル作成 | 0 | 0 | 0 | 0 |
ユーザー教育 | 0 | 0 | 0 | 0 |
導入後フォロー | 0 | 0 | 0 | 0 |
セットアップ | 0 | 0 | 0 | 0 |
合計(人月) | 0.01 | 0.01 | 0.00 | 0.00 |
合計(人日) | 0.20 | 0.20 | 0.00 | 0.00 |
SE1 | 4月 | 5月 | 6月 | 7月 |
プロジェクト管理 | 0.07 | 0.07 | 0.07 | 0.07 |
要求分析 | 0.2 | 0 | 0 | 0 |
基本設計 | 0.29 | 0 | 0 | 0 |
詳細設計 | 0 | 0 | 0 | 0 |
製造&単体テスト | 0 | 0 | 0 | 0 |
結合テスト | 0 | 0 | 0.15 | 0 |
総合テスト | 0 | 0 | 0.1 | 0 |
ユーザー・テスト・サポート | 0 | 0 | 0.1 | 0 |
データ移行 | 0 | 0 | 0 | 0.1 |
マニュアル作成 | 0 | 0 | 0 | 0 |
ユーザー教育 | 0 | 0 | 0 | 0.05 |
導入後フォロー | 0 | 0 | 0 | 0 |
セットアップ | 0 | 0 | 0.05 | 0.05 |
合計(人月) | 0.56 | 0.07 | 0.47 | 0.27 |
合計(人日) | 11.20 | 1.40 | 9.40 | 5.40 |
SE2 | 4月 | 5月 | 6月 | 7月 |
プロジェクト管理 | 0 | 0 | 0 | 0 |
要求分析 | 0.15 | 0 | 0 | 0 |
基本設計 | 0.2 | 0 | 0 | 0 |
詳細設計 | 0 | 0 | 0 | 0 |
製造&単体テスト | 0 | 0 | 0 | 0 |
結合テスト | 0 | 0 | 0.2 | 0 |
総合テスト | 0 | 0 | 0.1 | 0 |
ユーザー・テスト・サポート | 0 | 0 | 0.05 | 0 |
データ移行 | 0 | 0.4 | 0.1 | 0 |
マニュアル作成 | 0 | 0 | 0 | 0 |
ユーザー教育 | 0 | 0 | 0 | 0.1 |
導入後フォロー | 0 | 0 | 0 | 0 |
セットアップ | 0 | 0 | 0.05 | 0.05 |
合計(人月) | 0.35 | 0.40 | 0.50 | 0.15 |
合計(人日) | 7.00 | 8.00 | 10.00 | 3.00 |
PG1 | 4月 | 5月 | 6月 | 7月 |
プロジェクト管理 | 0 | 0 | 0 | 0 |
要求分析 | 0 | 0 | 0 | 0 |
基本設計 | 0 | 0 | 0 | 0 |
詳細設計 | 0 | 0.2 | 0 | 0 |
製造&単体テスト | 0 | 0.6 | 0 | 0 |
結合テスト | 0 | 0 | 0.1 | 0 |
総合テスト | 0 | 0 | 0.1 | 0 |
ユーザー・テスト・サポート | 0 | 0 | 0 | 0 |
データ移行 | 0 | 0 | 0 | 0 |
マニュアル作成 | 0 | 0 | 0.1 | 0 |
ユーザー教育 | 0 | 0 | 0 | 0 |
導入後フォロー | 0 | 0 | 0 | 0 |
セットアップ | 0 | 0 | 0 | 0 |
合計(人月) | 0.00 | 0.80 | 0.30 | 0.00 |
合計(人日) | 0.00 | 16.00 | 6.00 | 0.00 |
プロジェクトの採算管理では、会社によって独自の仕組みがあることと思います。ExcelやAccessなどを使って独自のフォーマットを作成したり、「SI Object Browser PM」のような、プロジェクトの採算管理が行えるパッケージ・ソフトを導入してもよいでしょう。採算を管理するための仕組みがあれば、フォーマットは何でも構いません。
本来、これらの「資源の最適配分」を行うのは、プロジェクト・マネージャの役割です。しかし、プロジェクト・リーダーであっても、リーダーとしてプロジェクトにかかわる以上、自分のチームの状況を知ることはとても大切です。ワン・ランク上のリーダーになるために、この場で簡単にお伝えします。
プロジェクトの採算管理を行うためには、プロジェクトに関する金額の算出方法を知る必要があります。まず押さえておきたいポイントは、利益とは売上から費用を引いたものである、ということです。つまり、「売上-費用=収益」です。これが採算計算の大原則です。
もう少し細かく見てみましょう。プロジェクトには必ず、開始期間と終了期間が定められています。つまり、簿記で言うところの「損益計算書(P/L)」の概念が必要となります。
P/Lとは、ある一定期間に行われたお金の動きを計算したものです。このため、期間中のお金の出入りをすべて記録しておく必要があります。1つでも抜けてしまえば正確なP/Lを作ることができませんので、注意してください。
それでは、プロジェクトの例に当てはめてみましょう。
表2: 採算管理の例
売上高 | 24,430,000 |
社内原価 | 5,415,000 |
外注費 | 10,332,000 |
実行利益 | 8,683,000 |
部門配布額 | 1,259,760 |
粗利 | 7,423,240 |
粗利率 | 30.4% |
販管費 | 4,795,200 |
営業利益 | 2,628,04 |
利益 | 10.8% |
ユーザーからもらう受注金額(売上高)から、開発原価(社内原価や外注費の合計)を差し引いたものが粗利(売上総利益)となります。会社によっては、自分の部門にかかわる共通の配布費用(社内プロジェクト費用など)が差し引かれることもあります。そして、粗利から販売部門や管理部門で生じた費用、つまり販売管理費を差し引きます。
プロジェクト・リーダーが自分でコントロールできるのは、自分のチーム内の開発原価です。このことから、粗利に注目するとよいでしょう。具体的には、適切なリソース・ヒストを計画し、メンバーが予定工数内で作業を進めているかどうかを日次レベルで確認します。
プロジェクトの開始時に計画された予算に対して、自分のプロジェクトの採算がどのように変化しているのか。これを日々管理することが大切です。