先に要点
- IT開発の見積もりとは、これから作るものにかかる「工数・期間・費用」を、着手前に予測して数字にすること です。占いではなく、前提条件つきの予測として扱います。
- 土台になるのは 工数(人がどれだけ働くか=人日・人月)。工数が決まれば、単価をかけて費用に、投入人数で割って期間に換算できます。
- 代表的な方法は 類推見積もり / 積み上げ(ボトムアップ) / パラメトリック / 三点見積もり の4つ。精度と手間がトレードオフで、プロジェクトのフェーズで使い分けます。
- 精度を上げる近道は 「作業を分解する(WBS)」「前提と除外を明文化する」「過去の実績と照らす」 こと。1人が勘で出す一発見積もりが一番危険です。
この開発、いくらでいつまでにできる？ ── IT の仕事で必ず聞かれるのに、まともに教わる機会が少ないのが見積もりです。金額や納期を一度約束すると後から動かしにくいので、最初の数字の作り方が案件全体の成否を左右します。
この記事では、見積もりの基本(工数・期間・費用の関係)を押さえたうえで、類推見積もり 積み上げ パラメトリック 三点見積もり といった代表的な見積もり方法、アジャイルで使うストーリーポイント、そして精度を上げる進め方までを実務目線で整理します。
ITにおける見積もりとは何か
見積もりとは、ひとことで言うと 「まだ作っていないものの、工数・期間・費用を、着手前に予測して数字にする作業」 です。すでに終わった作業を集計するのが実績、これからの作業を予測するのが見積もり、と考えると区別しやすいです。
大事なのは、見積もりは 確定値ではなく予測 だということです。開発の初期は「何を作るか」がまだ粗く、関係者の認識もそろっていません。その状態で出す数字は、どうしても前提つきの仮説になります。ここを「最初の数字は絶対」と扱うと、途中で破綻します。
見積もりは「この前提ならこのくらいで進められそう」という幅のある予測です。金額の大小だけでなく、何が対象範囲で、何が前提で、何を含まないかが書かれているかを見ます。
見積もりで決める3つの要素
見積もりで出す数字は、突き詰めると次の3つです。この3つは独立ではなく、工数 を土台にしてつながっています。
工数(こうすう)
作業に必要な「人の働き」の総量。人日(にんにち)・人月(にんげつ) で表す。見積もりの土台で、まずこれを出す。
期間(スケジュール)
いつ始まっていつ終わるか。おおまかには 工数 ÷ 同時に動ける人数。ただし人を増やせば比例で短くなるわけではない。
費用(コスト)
いくらかかるか。受託なら 工数 × 人月単価 が基本。これに経費やリスク分のバッファを加える。
つまり、工数さえ筋よく出せれば、費用と期間はそこから計算で導ける 関係にあります。だからこそ、見積もりの中心は工数の見積もりになります。
見積もりの土台「工数」を理解する
工数は「人 × 時間」で測る作業量です。代表的な単位は次のとおりです。
- 人日(にんにち) ── 1人が1日働く量。10人日なら「1人で10日」または「2人で5日」相当
- 人月(にんげつ) ── 1人が1か月働く量。実務では1人月をおおむね20稼働日として扱うことが多い
注意したいのは、工数(人月)と期間(暦の月)は別物 だという点です。6人月の作業を「6人で1か月」で終わらせられるとは限りません。人を増やすと、コミュニケーションや教育のコストが増え、分担できない作業も出てくるため、人を倍にしても期間が半分にはならない のが普通です(これはソフトウェア開発の古典的な経験則として知られています)。工数の考え方をもう少し丁寧に知りたい場合は、用語集の 工数 もあわせて確認してください。
代表的な見積もり方法4つ
見積もりの「やり方」には、大きく4つの代表的な手法があります。精度と必要な手間がトレードオフになっていて、情報が少ない初期はざっくり、設計が固まってきたら積み上げ、と使い分けるのが実務的です。
| 手法 | やり方 | 向いている場面 | 精度 / 手間 |
|---|---|---|---|
| 類推見積もり (トップダウン) |
過去の似た案件の実績から「今回はあれの1.5倍くらい」と推定する | 企画初期。情報が少なく、まず概算が欲しいとき | 精度:低〜中 / 手間:小 |
| 積み上げ (ボトムアップ) |
作業をWBSで細かく分解し、各タスクの工数を足し合わせる | 要件・設計がある程度固まった後。契約前の本見積もり | 精度:高 / 手間:大 |
| パラメトリック (係数見積もり) |
規模指標(画面数・FP・行数など)に単価係数をかけて算出する | 規模を数値化できるとき。標準化された開発 | 精度:中 / 手間:中 |
| 三点見積もり (PERT) |
楽観・最頻・悲観の3つを出し、加重平均でブレを織り込む | 不確実性が高いタスク。リスクを数字に含めたいとき | 精度:中〜高 / 手間:中 |
実際の案件では、これらを組み合わせます。たとえば、提案段階は類推でざっくり示し、受注後に積み上げで精緻化し、読みにくいタスクだけ三点見積もりでブレを足す、という流れが典型です。
三点見積もり(PERT)の計算
不確実なタスクで便利なのが三点見積もりです。「だいたい5日」ではなく、うまくいけば3日(楽観) 普通なら5日(最頻) こじれたら13日(悲観) の3点を出し、次の式で加重平均します。
期待値の計算式
(楽観 + 最頻×4 + 悲観) ÷ 6
上の例なら (3 + 5×4 + 13) ÷ 6 = 6日。単純な「5日」より悲観側に寄り、現実的になる。
ブレ幅(標準偏差)
(悲観 - 楽観) ÷ 6
(13 - 3) ÷ 6 ≒ 1.7日。この値が大きいタスクほど読みにくく、要注意ということが数字で見える。
ポイントは、悲観値を「最悪を想定して」きちんと出すことです。多くの遅延は、悲観側の作業(例外処理・連携・移行・テスト)を軽く見たことから生まれます。三点見積もりは、その軽視を式の中で自動的に補正してくれます。
規模から見積もる ── FP法とアジャイルのストーリーポイント
工数を「作業の感覚」ではなく「規模の指標」から出すアプローチもあります。
ストーリーポイントは、このタスクは、基準にしたあの作業の何倍くらいか を相対値で見積もる方法です。人によって作業速度が違っても、規模感の比はチームで共有しやすい、という発想です。スプリントを重ねると「1スプリントで何ポイント消化できるか(ベロシティ)」が分かり、そこから完了時期を予測します。アジャイル開発の枠組みについては、用語集の スクラム や用語集の ストーリーポイント もあわせて読むと、見積もりが開発プロセス全体のどこに位置するかが見えやすくなります。
工数から費用と期間を出す手順
工数が出たら、費用と期間に変換します。受託開発の典型的な流れは次のとおりです。
ここで効いてくるのが、テストやドキュメント、打ち合わせといった 「機能そのものではないが必ず発生する作業」 です。表向きの機能だけを足すと、ここがまるごと抜けて、見積もりが小さく出ます。
見積もりでありがちな失敗と対策
見積もりが外れる原因は、手法そのものより「前提の置き方」にあることがほとんどです。
- 例外処理・移行・連携を軽く見る ── 表の機能だけ数えて、エラー時の挙動やデータ移行を入れ忘れる。三点見積もりの悲観値で補正する。
- 範囲(スコープ)を曖昧にする ── どこまでが対象か書かないと、後から「これも入っていますよね」で膨らむ。除外事項 を明記する。
- 1人の勘で一発で出す ── レビューなしの見積もりは漏れに気づけない。複数人で出して突き合わせる。
- バッファをゼロにする ── 「最短ならいける」値で約束すると、わずかな想定外で崩れる。
見積もりがなぜズレるのかという構造そのものは、システム開発の見積もりはなぜ外れやすい？ズレる理由と実務での防ぎ方 で、要件の粗さ・例外処理・移行・調整コストの観点から詳しく整理しています。プロジェクト全体が崩れる流れまで見たいなら、なぜITプロジェクトは途中からぐだぐだになるのか もあわせて読むと、見積もりのズレがどこに波及するかがつながります。なお、精度の高い見積もりには要件の言語化が前提になるので、要件定義で最低限おさえる項目チェックリスト もセットで役立ちます。
見積もりに関するよくある質問
Q. 見積もりと概算見積もり、本見積もりは何が違いますか？
A. 同じ見積もりでも、出す段階と精度が違います。概算(ラフ)見積もりは企画初期に類推で大づかみに出すもので、幅(例:300〜500万円)で示すのが誠実です。本見積もりは要件・設計が固まった後に積み上げで出す、契約の根拠になる数字です。初期の概算をそのまま確定値として扱わないことが大事です。
Q. 工数と期間はどう違うのですか？
A. 工数は「人 × 時間」で測る作業の総量(例:6人月)、期間は暦の上での長さ(例:3か月)です。6人月でも、2人なら3か月、3人なら2か月、と投入人数で期間は変わります。ただし人を増やすほど効率は落ちるので、単純な割り算どおりにはなりません。
Q. 初心者でも使いやすい見積もり方法はどれですか？
A. まずは積み上げ(ボトムアップ)がおすすめです。作業をできるだけ細かいタスクに分け、それぞれに「半日」「1日」のように工数を置いて合計するだけなので、考え方がシンプルです。分解が細かいほど、抜けに気づきやすく精度も上がります。
Q. なぜ見積もりにバッファ(予備)を入れるのですか？
A. 見積もりは予測であり、想定外は必ず起きるからです。エラー対応、仕様の認識違い、レビュー指摘の手戻りなどは事前に全部は読めません。不確実性に応じて10〜30%程度を見込んでおくと、小さな想定外でスケジュールが即破綻するのを防げます。バッファを隠し味的にゼロにすると、現場が疲弊します。
Q. ストーリーポイントを時間に直してよいですか？
A. 原則として直さない方が運用しやすいです。ストーリーポイントは相対的な規模を表す指標で、「1ポイント=2時間」と固定すると、結局は時間見積もりに戻り、相対見積もりの利点(人による速度差を吸収できる)が失われます。完了時期は、ポイント総量とベロシティ(1スプリントの消化量)から予測します。
Q. 見積もりが大きく外れたらどうすればよいですか？
A. 黙って残業で吸収せず、早めに「なぜ外れたか」を共有することが先決です。外れた原因(要件追加・例外処理の見落としなど)を特定し、残りの見積もりを引き直します。あわせて、追加要望は影響範囲・工数・優先度を評価してから「入れる/今期は見送る/別フェーズ」のどれかを決める変更管理のルールを持っておくと、ズレの連鎖を止められます。
Q. AIで見積もりは自動化できますか？
A. 部分的に補助はできます。過去案件のデータを学習させて類推見積もりのたたき台を出したり、要件文から作業を洗い出してWBSの初稿を作らせたりする使い方は有効です。ただし、自社固有の制約や移行データのクセ、関係者の事情までは読めないため、AIの出力はあくまで素案として、人がレビューして前提と除外を詰める前提で使うのが安全です。