プロジェクト管理における工数割合について（Vol.19）

プロジェクト管理における「工数割合」

プロジェクト管理において、避けては通れず、かつ軽視できないのが「見積」です。

管理（コントロール）すべき作業量・規模（ボリューム）がどれぐらいあるのか、それを見誤っては、いかに優れた手法、ツール、スキルを駆使したとしても「後の祭り」です。

そして「見積」と切っても切れない関係にあるのが「工数」です。

「工数見積なんて時代遅れ」、と言ってしまえば格好いいのですが、「プロジェクトは現場で起きているんだ！」というこのブログでは、それに触れない訳にはいきません。

その「工数見積」において厄介なのが、プロジェクト管理においては、見積根拠をダイレクトに示すことが難しい工程（タスク）が存在することです。例えば、「テスト工数」、「管理工数」などです。それらは、見積根拠が明示できる他の工程（タスク）の規模を基に増減することは示せても、それ単独でダイレクトに見積根拠を示すことはできそうにありません。それを解決するために「工数割合」という考え方が編み出されています。

テスト工数の「工数割合」

テスト工数を見積る時、そのベースとなる要因は、テストをする対象の規模（ボリューム）です。１０の機能を持つシステムのテストと１００の機能を持つシステムでは、まずベースとなるテスト工数が違います。テスト手法やテストツールによってテスト工数が変わるという話しは、そのベースに対する係数でしかありません。

そのため、テスト工数の見積では、「何をベースにするか」と「そのベースに対する係数（工数割合）はどれ位か」を見極め、決めることが重要です。そして、システム開発における常套手段として、ここで「Ｖ字モデル」なるものが登場します。これを読んでいる皆さんには説明するまでもないことですが、次のようなイメージのものです。

（設計を基本設計、機能設計、詳細設計の３段階で行うケース）

プロジェクト管理における工数割合について（Vol.19） 1

このモデルに従えば、ベースとすべき対象は明らかです。「単体テスト」なら「詳細設計」、「結合テスト」なら「機能設計」、「システムテスト」なら「基本設計」、という具合です。つまり、「システムテスト工数＝基本設計工数の40％」というように「工数割合」を考えることが出来ます。ただし、絶対にこのモデルに従うべきという訳ではありません。あくまでも１つの考え方です。

また、このモデルに従ったとしても、ルール化した係数（工数割合）を他のすべてのケースに当てはめてもうまくいきせん。類似のシステム開発かどうか、どういう手法・進め方での設計なのか、どういう手法・進め方でのテストなのか、それらを考慮した上でケース毎に「工数割合」を調整し、運用するべきです。

管理工数の「工数割合」

テスト工数よりも更に厄介なのが「管理工数」です。

テスト工数のようにベースとなる対象が明確でなく、判り易いモデルもありません。かといって軽視することはできず、必ず発生する工数であり、難易度の高いプロジェクトであれば「管理工数」を適切に見積もっておくことが、プロジェクトの成否につながる場合もあります。

ただ、残念ながら「これが正解」というものはなく、うまく紹介することができません。大事なのはテスト工数と同じように、「何をベースにするか」と「そのベースに対する係数（工数割合）はどれ位か」を見極め、決めることです。そして、いったん決めたルールを固定化することなくPDCAサイクルを回すことと、ケース毎に特性を考慮した「工数割合」の調整をうまく運用することになります。