システム開発の概算見積もりの出し方——
要件定義前に「前提条件」を置く3つのコツ

「ざっくりで構わないので、いくらぐらいになりそうですか」。商談の終わり際に、顧客からこう聞かれることがあります。社に戻って開発チームに相談すると、返ってくるのはこの一言です。「要件が決まらないと、見積もれません」。

もっともな話です。ところが、要件を固めるために追加のヒアリングを組み、調べ、社内で揉んでいるうちに数週間が過ぎ、気づけば顧客側の予算取りの締め切りは過ぎている——。システム受託開発会社の提案支援に入ると、私自身、この場面に本当によく出くわします。

先に結論を書きます。システム開発の概算見積もりは、要件定義前でも出せます。決まっていない部分を「前提条件」として仮置きし、書き出す技術があれば、です。足りないのは要件ではありません。前提の置き方です。

概算を幅で伝える言い方や、上限を低く言わない理由は、社内稟議を通す提案書の書き方——担当者は前向きなのに決裁が下りない理由のコツ①に書きました。あちらは、顧客に何をいつ渡すかの話です。この記事はその一つ手前、社内でその数字をどう作るかの話をします。前提条件の置き方（コツ①）、見積書への書き方（コツ②）、外れたときの直し方（コツ③）の順です。

要件定義前に概算見積もりが出せない、たった一つの理由

まず、開発チームの側に立ってみます。「見積もれません」と言うのは、怠慢ではありません。出した数字は一人歩きします。営業の「ざっくり」が、いつの間にか顧客の予算枠になり、契約金額になり、それを超えた瞬間に責められるのは開発です。しかも、納期や予算に合わせて帳尻を合わせた工数は、たいてい無理な工数になります。慎重な人ほど、前提のない数字を出したくない。これは正しい感覚です。

一方で顧客は、どれくらいかかるのかという数字を必ず欲しがります。「見積もれないので分かりません」と返して、契約に進む案件はまずありません。持ち帰って調べている間に顧客は予算の締め切りを迎え、「じゃあ他のところにお願いします」となります。

ここで、私がいつも引っかかる点があります。要件が決まらないと見積もれないのだとしたら、見積もるために要件定義をしなければならなくなります。要件定義は本来、契約後の工程です。契約前に要件定義をやって、それでも受注できなかったら、その工数は誰が持つのでしょうか。

慎重な開発チームと、数字を欲しがる顧客。両方が正しいのに数字が出てこない理由は、一つです。決まっていない部分を「前提条件」として仮置きし、書き出す技術が、社内にないこと。足りないのは要件ではなく、前提です。

当てずっぽうと概算は違います。違いは、前提を置いて算出したかどうかです。「たぶん1,000万円くらい」は当てずっぽうですが、「機能数を45と置き、1機能あたり1.5人日と置き、単価を掛けると、上限でこのくらい」は概算です。当たるかどうかは別の問題で、後で確かめて直せばいい。

私はこれを、仮説思考の型で考えています。仮説は、立てることが目的ではありません。置いて、実行して、検証して、修正するまでがワンセットです。概算見積もりも同じで、「前提を置く」「前提を書く」「外れたら前提を直す」の三段で成り立ちます。この三段が、そのままコツ①②③です。

概算見積もりの出し方のコツ①　要件定義前でも、機能数×工数の前提条件を置けば松竹梅の3案まで出せる

フェルミ推定の考え方を、システム開発の工数見積もりに置き換える

当社が運営するスクールでは、「日本に電柱は何本あるか」のような問いに、前提を置いて算出する練習をします。いわゆるフェルミ推定です。手順は決まっています。分かっている事実を集める、要素に分解する、分からない部分にだけ仮説を置く、掛け算する。これだけです。訳が分からなかった問いが、分解した途端に「計算できる気がしてくる」——ここが肝です。

システム開発の概算も、まったく同じ構造をしています。大きな金額は、「件数 × 1件あたりの工数 × 単価」という掛け算に分解できます。要件が固まっていなくても、この掛け算の変数に前提を置けば、数字は出ます。私が仮置きする変数は、主に4つです。

数字はすべて例で、案件ごとに置き直すものです。大事なのは、これらは全部「仮説」だと、自分にも顧客にも明記することです。私は顧客に機能数を伝えるときも、「この45という数は仮説です」のように必ず添えます。

開発工数以外も、同じ型で置けます。連携先の数 × 1連携あたりの工数。非機能——同時利用人数、稼働時間帯、基盤を流用するか新設するか。そして見落とされやすいのが、顧客側の合意形成にかかる工数です。担当者・部長・役員と階層があれば、一つの資料を通すのに階層ごとの説明と指摘修正の往復が発生します。「ミーティング1回で終わる」前提で組んだ見積もりは、ほぼ確実に破綻します。会社の規模とITリテラシーから、階層と往復回数を前提として置いておく。

積み上がった数字は、そのまま出しません。私は、切りのいい数字まで上に丸めた値を、この前提における上限として置きます。稟議の記事で顧客に口頭で伝える幅の「上限側」は、この丸めた値のことです。前提を置いて積み上げた数字は、経験上そう大きくは外れません。外れたとしても上限側に丸めてあれば収まりますし、収まらなければ、前提のどこかが違うと分かります。

松竹梅の3案は、同じ単価・同じ前提条件から掛け算で出す

④の優先度が置けていれば、「優先度の高い機能だけ」「中まで」「全機能」の3段階は、掛け算で即座に出ます。これが松竹梅です。稟議の記事で書いた「順番の組み替え」は、正式見積もりが予算を超えたあとの対処でした。ここで言う松竹梅は、概算の段階で、同じ単価・同じ前提から先に3つ並べておく話です。後から削るのではなく、最初から並べる。案ごとに前提が変わると比較にならないので、変えるのは優先度の線引きだけです。

この3案を顧客に見せるとき、当てることは目的ではありません。仮置きした変数を顧客に訂正してもらい、前提を一つずつ事実に変えることが目的です。「機能数は45と置きました。多いですか、少ないですか」——数字を先に置いて訂正してもらう技法は提案ヒアリングのコツ3つ——顧客の課題を聞き出し「特にご要望はありません」で終わらせないに書きました。ここではその仮説を、金額の掛け算につなげています。顧客への切り出し方と出すタイミングは、稟議の記事のコツ①のとおりです。

概算見積もりの出し方のコツ②　見積書の前提条件の書き方——高くつく側で置き、仮説と事実を分けて記載する

前提を置いたら、書きます。書き方には3つの原則があります。

原則1　決まっていない項目は、高くつく側の値で置く

開発チームに「こういう要件だった場合は、という前提で見積もってほしい」と頼むと、仮説で見積もるのは危ない、と返されることは珍しくありません。私の答えはいつも同じです。だったら、一番お金がかかる要件で見積もればいい。前提を高くつく側で置けば、外れる方向は下振れしかありません。上振れの危険を抱えたまま出すから、危ないのです。

これは「全項目を最悪値にする」という意味ではありません。線を引くのは、決まっているかどうかです。ヒアリングや資料で確認済みの項目はそのまま使う。決まっていない項目——次の原則2で【仮説】の印を付ける項目——は、一番お金がかかる側で置く。そして積み上げの段階では、納期や予算に合わせて前提そのものを小さくしないことです。素直に積み上げると、たいてい顧客の希望を超えます。それが普通で、超えて初めて「どの前提を変えれば収まるか」を議論できます。合意形成の階層を減らすのか、顧客側の作業を増やすのか、優先度の線引きを動かして竹や梅に切り替えるのか。金額を削るのではなく、前提を動かす。これが後述の記載例にある「前提条件が変わった場合の金額の動き」と、コツ③の「前提を直す」につながります。

原則2　【事実】【仮説】【条件】の3区分で書く

前提条件の一項目ごとに、印を付けます。【事実】は顧客のヒアリングや資料で確認済みのもの。【仮説】は当社で仮置きしたもの。【条件】は顧客側の作業や契約範囲など、当社が置いた条件で、変わったら金額を再提示するもの。提案書で事実と仮説に線を引く理由は説得力のある提案書の書き方——「解釈」を抜き、「事実」で書くに書きましたので繰り返しません。見積書ならではの効用を一つだけ挙げると、【仮説】の印が付いた項目の一覧が、そのまま要件定義で確認すべき論点リストになります。正式見積もりとは、この【仮説】を一つずつ【事実】に置き換えたものです。

原則3　顧客側の作業と、前提が変わった場合の金額の動きまで書く

何を顧客側に任せるかで、金額は大きく変わります。私がよく顧客側にお願いするのは、業務を知っている側が決めたほうが速い作業です。既存データの整備、帳票や通知文の文面、画面に出すメッセージの文言。こちらで一から考えるより速く正確なので、そこはお客さまでご検討ください、と前提に書く。受入テストの実施や連携先APIの開発をどちらが持つかも同じです。任せる範囲を前提として書けば、要件が固まる前でも金額の根拠が立ちます。

書き方の型は、「原則◯◯、ただし△△の場合は別途」です。境界が曖昧な言葉——機能の数え方、連携先の定義、難易度の定義——は、定義から書きます。ただし、概算段階の前提は粗くて構いません。細かい境界ケースは要件整理の段階ではまず出てこず、設計を本格的に始めてから出てくるものです。そこまで詰めてから出そうとしないでください。

そして最後に、「前提条件が変わった場合の金額の動き」を添えます。合意形成の階層が減れば減額要因、連携先が増えれば増額要因、機能数が上限を超えた分は1機能あたりの工数で加算。言われる前に、答えておく。増額の条件が先に書いてある見積もりは、顧客の「後で増やされるのでは」という不安を消します。そしてこの欄は、正式見積もりで【仮説】が【事実】に置き換わったとき、どの前提が動いて金額がいくら変わったかを説明する台帳にもなります。

見積書の前提条件の記載例（システム開発・概算見積もり）

概算見積もりの出し方のコツ③　外れたら金額ではなく、前提条件を修正する

前提を置いて出した概算が外れることは、もちろんあります。そのときにやることは一つで、金額を直すのではなく、前提を直すことです。提案の場で「この前提で出していましたが、違いましたか」と確認し、違えば前提を差し替えて数字を出し直す。前提が書いてあるからこそ、外れた理由が説明できます。

身近な例を挙げます。顧客との会議で、英数字だけのコードが飛び交うことがあります。私は「たぶん製品の型番だろう」と仮置きして、そのまま聞き進めます。話が噛み合っていれば正解、噛み合わなければそこで初めて「製品の型番かと思って聞いていたのですが、違いますか」と前提の側を直す。全部を質問してから進めると、毎回話を止めることになります。見積もりも同じで、全部が決まるのを待つと、どこにも進みません。

提案の場での直し方も決まっています。「そちらの前提でしたか。前提がずれていたので訂正します。だとするとこちらの案のほうがよく、その場合はこうなります」——修正後の前提での案を、その場で出す。前提を置くために顧客を想像した時間は、無駄になりません。想像の過程で周辺の可能性も検討済みなので、外れても即応できるからです。

一つだけ、順番に注意があります。考え切れていない前提は、指摘される前に自分から言う。私は提案の冒頭で「ここまでは考えられていないので、今日この場で相談させてください」と先に宣言します。後から指摘されて直すと、同じ修正でも「私たちが言ったから直した」と受け取られ、前提の差し替えが信頼を削る側に働くからです。

前提を明文化しておくと、もう一つ良いことが起きます。問題が起きたときの議論が、「誰が悪いか」ではなく「どの前提に漏れがあったか」になる。顧客の側から、前提の伝え漏れがあったと認めてもらえることもあります。ここまでやってうまくいかなかったのなら仕方ない、お互い歩み寄ろう——そういう関係になります。

開発チームに前提条件付きの概算見積もりを依頼する5つの進め方

ここまでの話を、明日から社内で回す形にします。相手は顧客ではなく、自社の開発チームです。

①依頼の形を変える——「要件が決まったら見積もって」ではなく、「こういう要件だった場合は、という前提で見積もってほしい」と頼みます。依頼の前に、最後にどんな答えが欲しいかを先に決めておきます。欲しいのは、前提ごとの人日と、合計の上限と、松竹梅の3行です。

②前提は、顧客の情報を持つ側が置く——顧客の情報を持っているのは営業です。記載例の対象範囲・優先度・連携・非機能・顧客側作業・合意形成は営業が置きます。難易度の定義と分布・1機能あたりの工数は、営業が仮置きしたうえで開発に妥当性を見てもらう。単価は当社標準なので固定です。開発には「その前提なら何人日か」の算出に集中してもらいます。

③責任の所在を明言する——前提が大きく外れたときの責任は、前提を置いた側が持ちます。私は開発チームに「仮説が大きくずれても、責任は私が取るので」と先に言います。外れたのは前提であって、開発の工数計算ではありません。この約束があって初めて、開発は前提付きの概算を安心して出せます。

④「間に合うのね」だけの社内合意をやめる——期限を先に決めて、間に合うように計画を作る。普通に見えて、これがいちばん危険です。作業漏れとコストの議論が抜けたまま「間に合うのね」だけで合意し、遅れてから犯人探しが始まる。前提・工数・削ったものを、社内の報告項目にしてください。

⑤収まらなければ、経営判断に持ち込む——前提を置いて積み上げてもなお予算・納期に収まらないなら、それは見積もりの問題ではなく経営判断です。赤字を覚悟して受けるのか、自社では受けられないと伝えるのか。前提が書いてあれば、この判断を数字で議論できます。

前提が共有されると、営業と開発の会話は「前提が妥当か」の議論に絞られます。要件を待つ時間が、前提を置く時間に変わる。それだけで、数字が出るまでの日数は目に見えて縮みます。

まとめ：前提条件付きの概算見積もりを出す前の5つのチェック

「要件が決まらないと見積もれません」は、要件の問題ではなく、前提の問題でした。前提を置く（コツ①）、高くつく側で仮説と事実を分けて書く（コツ②）、外れたら前提を直す（コツ③）。この三つが揃うと、顧客の予算取りに間に合う概算が、開発チームを守りながら出せます。

出来上がった概算を顧客にどう渡すか——幅で伝える言い方と、上限を低く言わない理由は社内稟議を通す提案書の書き方に。正式見積もりの段階で作業を全て開示する出し方は価格勝負から抜け出す見積もりの出し方——「他社さんはもっと安い」と言われたらに書きました。前提を置いて積み上げた作業一覧は、そのまま正式見積もりのWBSになります。

次の商談で「ざっくりいくらですか」と聞かれたら、持ち帰る前に、前提を一つ置いてみてください。数字は、要件が決まるのを待たなくても出ます。

よくある質問

システム開発の概算見積もりは、どのくらいの精度で出せますか

精度は「前提条件を置いたかどうか」で決まります。期限や予算から逆算して帳尻を合わせた数字は、現場で当初想定を大きく超えることが多い——価格勝負の記事でも触れた、業界でよく言われる話です。一方、機能数・難易度・1機能あたりの工数・合意形成の回数といった前提条件を高くつく側で置いて積み上げ、切りのいい数字まで上に丸めた値を上限として出した概算は、経験上そう大きくは外れません。外れた場合も、前提条件が書いてあるので、どこが違ったかを特定して直せます。

要件定義前に出した概算見積もりが後で変わったら、責任を問われませんか

問われるのは、前提条件を書かずに金額だけを出したときです。見積書に何が事実で何が仮説かを分けて書き、「この前提条件における上限側の概算」と位置づけておけば、金額が変わった理由は「前提条件が変わったから」と説明できます。責任を負うのは前提条件を置いた側であり、そのために前提条件を明文化しておくのだと考えてください。

概算見積もりの前提条件には何を書けばよいですか

対象範囲（機能数と数え方）、難易度の定義と分布、優先度の置き方、1機能あたりの工数と含む工程、外部連携の数と方式、非機能、顧客側で実施する作業、合意形成の階層と往復回数、単価——記事中の記載例の1〜9が基本の9項目です。それぞれに【事実】【仮説】【条件】の印を付け、末尾に「前提条件が変わった場合の金額の動き」を添えます。細かい境界ケースは設計段階で出てくるものなので、概算段階では粗くて構いません。

見積もりを松竹梅の3案で出すと、一番安い案ばかり選ばれませんか

松竹梅は値引きの選択肢ではなく、同じ単価・同じ前提条件のもとで「優先度の高い機能だけ」「中まで」「全機能」を掛け算で示すものです。安い案を選ばれても単価は変わらず、含まれない機能が前提条件に明記されているので、あとから「入っていると思った」という齟齬が起きません。顧客が梅を選ぶなら、それは顧客の予算判断として健全です。むしろ一案しか出さないほうが、「他にもやり方があるのでは」という不安を残して決裁を遅らせます。

予算取り用の概算見積もりと正式見積もりの違いは何ですか

違いは金額の精度ではなく、前提条件の欄が【仮説】から【事実】に置き換わっているかどうかです。予算取り用の概算は、仮説の項目が残った状態で上限側の金額を出す。正式見積もりは、要件定義でその項目を一つずつ事実に置き換えて出し直す。概算を渡すときの幅の伝え方や、上限を低く言わない理由は、社内稟議を通す提案書の書き方のコツ①に書いたとおりです。

開発チームに「要件が決まらないと見積もれない」と言われたら、どう依頼すればよいですか

その慎重さは正しいので、否定せずに依頼の形を変えます。「要件が決まったら見積もって」ではなく、「こういう要件だった場合は、という前提で、高くつく側で見積もってほしい」と頼み、対象範囲・連携・非機能・顧客側作業・合意形成といった前提条件は営業側が置きます。開発チームには前提の妥当性の確認と、「その前提なら何人日か」の算出を担ってもらい、前提条件が外れたときの責任は前提を置いた側が持つと明言してください。この約束があって初めて、開発チームは前提条件付きの概算を安心して出せるようになります。