未来PM
PjMテンプレート

見積り原単位表のテンプレート

見積りの根拠を聞かれて「過去の類似案件から」としか答えられない。多くの現場で起きていることです。この答え方の困るところは、外れたときに、どこが外れたのかを追えない点にあります。

原単位表は、それを解決するための表です。「画面1本あたり○人日」という形で、成果物の種類ごとに単価を持ちます。このページでは、原単位表のテンプレートと作り方、記入例、運用のしかたをまとめます。記入例は、事例集の「東和エナジー(架空)の需給管理・料金計算システム刷新」に当てはめたものです。


■ この帳票が要る場面(背景・よくある課題)

よくある症状

本当の原因

見積りが毎回3割ほど超過する

根拠が感覚なので、同じずれが繰り返される

超過しても「見積りが甘かった」としか言えない

本数のずれと、1本あたりのずれを分けていない

見積りができる人が1人しかいない

その人の頭の中にしか単価がなく、引き継げない

ベンダーの見積りが妥当か判断できない

自社側に比較の基準がない

要件が増えたときの追加費用を即答できない

「画面3本増える=○人日」の換算ができない


■ このテンプレートの目的

  1. 見積りを、感覚から計算に変える:「成果物の本数 × 単位あたりの人日」で出せるようにします

  2. 外れた原因を分けられるようにする:本数のずれか、単価のずれかを切り分けます

  3. 見積りを組織の資産にする:特定の人の経験ではなく、表として引き継げるようにします


■ テンプレートの全体像

図 原単位表の回し方

作り方は簡単です。終わった作業の実績工数を、成果物の本数で割るだけ。新しく何かを測る必要はありません。

手順

やること

どこから取るか

1

成果物の種類を決める(6〜10種類)

WBSの成果物欄

2

種類ごとに、完了した本数を数える

成果物そのもの(設計書の章数、モジュール数など)

3

種類ごとの実績工数を集計する

工数実績(日報・WBSの実績列)

4

実績工数 ÷ 本数 を計算する

―

5

設計・実装・テストに分けて記録する

―

種類は6〜10種類が扱いやすい範囲です。細かく分けすぎると、1種類あたりのサンプルが少なくなって精度が落ちます。逆に3種類だと、種類の中のばらつきが大きくなります。


■ 各項目の説明

列

何を書くか

書き方のコツ

成果物の種類

画面(一覧)、画面(入力)、帳票、バッチ、外部I/F など

作る手間が明らかに違うものは分ける(一覧画面と入力画面は別)

単位

1本、1機能、1章

数えられる単位にする

設計

1本あたりの設計工数(人日)

レビューを受ける時間を含める

実装

1本あたりの実装工数(人日)

単体テストケースの作成を含めるかどうかを決めておく

テスト

1本あたりのテスト工数(人日)

単体テストの実施と不具合修正まで

合計

3つの和

見積りで使うのはこの列

サンプル数

この原単位のもとになった本数

10本未満は「参考値」として扱う

ばらつき

最小値〜最大値

幅が大きいものは、種類の分け方が粗い可能性がある

最終更新

いつの実績で更新したか

1年以上前の値は使わない

難易度の係数

標準1.0に対する倍率

「複雑な帳票は1.3倍」など。使いすぎると根拠があいまいになるので3段階まで


■ 記入例:東和エナジー 需給管理システム

R1・R2(2つのリリース、合計176人月)の実績から作った原単位表です。

成果物の種類

単位

設計

実装

テスト

合計

サンプル数

ばらつき

画面(一覧)

1本

1.5

2.5

2.0

6.0人日

34本

4.5〜8.0

画面(入力)

1本

2.0

3.5

3.0

8.5人日

41本

6.0〜12.5

帳票

1本

1.5

2.0

1.5

5.0人日

18本

3.5〜7.0

バッチ

1本

2.5

4.0

3.5

10.0人日

26本

6.0〜16.0

外部I/F

1本

3.0

4.5

4.5

12.0人日

12本

8.0〜18.0

マスタ保守

1機能

1.0

1.5

1.5

4.0人日

22本

3.0〜5.5

データ移行

1テーブル

0.5

1.5

1.0

3.0人日

48本

1.5〜9.0

ばらつきの列を見てください。バッチの6.0〜16.0という幅が目立ちます。これは「バッチ」という分類が粗いことを示しています。単純な集計バッチと、料金計算のような判定ロジックを含むバッチを同じ扱いにしているためです。次の更新では2種類に分ける予定、という形で記録に残しておきます。

見積りへの使い方(R3 需給計画サブ機能の例)

成果物

本数

単位あたり

小計

画面(一覧)

3本

6.0人日

18.0人日

画面(入力)

4本

8.5人日

34.0人日

帳票

2本

5.0人日

10.0人日

バッチ

5本

10.0人日

50.0人日

外部I/F

2本

12.0人日

24.0人日

小計

―

―

136.0人日

レビュー・修正(15%)

―

―

20.4人日

合計

―

―

156.4人日 = 7.8人月

実績は8.2人月でした。乖離は+5.1%です。原単位表がなかったときの見積りは6.0人月(乖離+36.7%)でしたから、大きく改善しています。

ずれの内訳(R3全体)

ずれの種類

内容

人月

次にやること

本数のずれ

外部I/Fが9本の想定に対し12本必要だった

+1.8

変更管理のしくみを見直す

単価のずれ

料金計算バッチ1本あたりが10.0人日に対し12.5人日

+3.3

バッチを2種類に分け、原単位を更新する

単価のずれ

結合テストの修正が想定の15%に対し22%

+3.9

レビュー・修正の比率を20%に改める

この内訳が、原単位表を持つ最大の利点です。「見積りが甘かった」が、3つの具体的な行動に変わります。


■ 運用ルール

  1. フェーズやリリースが終わるたびに更新する。実績を成果物の本数で割るだけなので、半日で終わります

  2. サンプル数が10本未満のものは「参考値」と明記する。使ってよいが、幅を持たせて見積もります

  3. ばらつきが3倍を超える種類は、分け方を見直す。1つの分類に性質の違うものが混ざっています

  4. 1年以上更新していない値は使わない。技術も体制も変わっています

  5. 難易度の係数は3段階まで(0.8/1.0/1.3など)。細かくすると、係数の選び方が感覚に戻ります

  6. 見積りに使ったら、WBSの根拠欄に「○本 × ○人日」と書く。後で検証できる形にします

  7. ずれたら、本数か単価かを必ず分ける。混ぜたまま更新すると、原単位が歪みます

7番目が守られないと、この表は育ちません。要件が増えたぶんを原単位に押し込むと、単価だけが際限なく上がっていきます。


■ 活用シーン

場面

使い方

概算見積りを出すとき

成果物の本数を数え、掛け算する。数時間で根拠つきの数字が出る

追加要望が来たとき

「画面3本+バッチ1本=35.5人日、約1.8人月」と即答できる

ベンダーの見積りを見るとき

自社の原単位と比べ、差が大きい項目の理由を聞く

スコープを削るとき

削る機能の成果物本数から、削減額を計算する

要員計画を作るとき

設計・実装・テストの内訳から、時期ごとに必要な職種と人数を出す

振り返りのとき

ずれを本数と単価に分け、次の原単位に反映する


■ よくある失敗と直し方

失敗

何が起きるか

直し方

種類を3つくらいに粗くまとめる

ばらつきが大きく、見積りに使えない

作る手間が明らかに違うものは分ける(6〜10種類)

種類を30個に細かく分ける

1種類あたりのサンプルが少なく、精度が出ない

10種類程度にまとめる

要件増加分を原単位に含めてしまう

単価だけが年々上がり、実態と合わなくなる

本数のずれと単価のずれを必ず分けて記録する

更新しない

2年前の値で見積もり、大きく外れる

フェーズ完了のチェックリストに更新の行を入れる

難易度の係数を細かくしすぎる

係数を選ぶ作業が感覚に戻り、根拠がなくなる

3段階まで。それ以上必要なら種類を分ける

レビューや修正の工数を入れ忘れる

実績が必ず超過する

「レビュー・修正15〜20%」を別行で必ず加える

他社の一般的な数値をそのまま使う

自社の体制・技術と合わず、当たらない

最初は粗くても、自社の実績から作る


■ 導入効果

項目

原単位表がない場合

原単位表がある場合

見積りの根拠

「過去の類似案件から」

「画面7本 × 8.5人日 + バッチ5本 × 10.0人日」

見積りと実績の乖離

平均 29.5%

平均 14.1%(3〜4周後はさらに縮む)

外れたときの分析

「見積りが甘かった」

本数のずれと単価のずれに分解できる

追加要望への回答

ベンダーに見積り依頼して1週間

その場で概算を出せる

見積りができる人

経験の長い1〜2名

表があれば誰でも同じ数字が出せる

作成の手間

―

初回で半日(終わった案件の実績を割るだけ)

東和エナジーの案件では、R1・R2の実績から原単位表を作り、R3・R4で使いました。乖離は29.5%から14.1%に半減しています。さらにR3の実績を受けてバッチの原単位を10.0→11.5人日に更新し、R4ではその値で見積もりました。実績は11.8人日だったので、次は12.0人日にする予定です。

最後に1つ。最初の原単位表は、粗くて構いません。サンプルが少なくても、感覚で見積もるよりはるかにましです。大事なのは、1周ごとに更新すること。3〜4周すると、多くの成果物で実績と1割以内に収まるようになります。当てる表ではなく、育てる表です。

添付ファイル

ユーザーコメント(0)

  • まだコメントはありません。

ログイン するとコメントを投稿できます。

ホーム画面に追加する