ブログ›事業者向け2026-08-01約8分

要件が固まっていなくても、システム開発の見積もりは取れる？——概算見積もりの正しい使い方と発注前に準備すべきこと

対象読者: 開発を検討し始めたが要件が固まっておらず、見積もりを取っていいか迷っている事業者・経営者

この記事で分かること

要件が固まっていない段階でも、システム開発の見積もり（概算見積もり）は取れること
概算見積もりと確定見積もりの違い（なぜ金額が後で変わるのか）
要件が曖昧でも、これだけは用意しておくと見積もりの精度が上がる「4つのメモ」
「予算を伝えると、その金額ギリギリで見積もられるのでは？」という不安への答え
受け取った概算見積もりで確認すべきポイント

はじめに

「システムやアプリを作りたい。でも、細かい仕様はまだ何も決まっていない。この状態で開発会社に見積もりをお願いしていいのだろうか——」

開発の発注を検討し始めた事業者の方から、こうした相談をよく受けます。要件がきっちり固まっていないと見積もりを頼んではいけない、と考えて、相談自体をためらってしまうケースは少なくありません。

結論から言うと、要件が固まっていなくても見積もりは取れます。 ただし、その段階で出てくるのは「概算見積もり」であり、あとで金額が変わりうるものだ、という前提を正しく理解しておくことが大切です。この記事では、要件が曖昧な段階で見積もりを取るときに知っておきたいことを、発注する側の目線で整理します。

結論——要件が曖昧でも「概算見積もり」は取れる（ただし"確定"ではない）

見積もりには、大きく分けて2つの段階があります。

概算見積もりと確定見積もりの違い

概算見積もり：要件がまだ固まっていない、構想段階で出す見積もり。「だいたいこのくらいの規模・予算感になりそう」という方向性を掴むためのものです。一般的に精度は±30%程度が目安とされ、あくまで予算を確保したり、進めるかどうかを判断したりするための参考値です。
確定見積もり：要件定義（何を作るかを具体的に決める工程）を経て、作る範囲がはっきりしたうえで出す見積もり。ここで初めて、実際に発注する金額が固まります。

つまり、要件が曖昧な段階で取れるのは「概算」であって「確定」ではない、という点さえ押さえておけば、早い段階から見積もりを取ること自体はまったく問題ありません。むしろ、予算感を早めに掴んでおくことは、その後の計画を立てるうえで有効です。

なぜ要件が曖昧だと金額が変わるのか

そもそも、なぜ概算はあとで金額が変わるのでしょうか。理由はシンプルで、開発費用は「作る量（工数）」で決まるからです。

要件が固まっていない段階では、この「作る量」がまだ確定していません。たとえば「予約機能がほしい」という要望ひとつをとっても、

予約の空き状況をリアルタイムで表示するのか
決済まで連携するのか
キャンセル・変更・リマインド通知まで含むのか

によって、作る量は大きく変わります。概算の段階ではこうした細部が未定なので、開発会社は「一般的にはこのくらい」という前提を置いて金額を出します。その前提が要件定義で具体化されるにつれて、金額も確定に向けて調整されていく——これが、概算があとで変わる仕組みです。

だからこそ、概算の精度を少しでも上げるには、未定の部分について「方向性」だけでも伝えておくことが効いてきます。

要件が固まっていなくても、これだけ用意すると見積もりの精度が上がる

「要件を用意する」というと、仕様書やRFP（提案依頼書）のような、しっかりした書類を思い浮かべるかもしれません。ですが、概算の段階ではそこまで厳密なものは必要ありません。箇条書きのメモ程度で十分です。次の4つを整理しておくだけで、概算の精度と、その後のやり取りのスムーズさが大きく変わります。

① 解決したい課題・目的（何のために作るか）

一番大事なのがこれです。「何を作るか」より先に、「何を解決したいか」を伝えます。たとえば「電話予約の対応に時間を取られているので、Webで予約を受けられるようにしたい」といった具合です。目的が共有できていれば、開発会社は手段（機能）を提案で補えます。

② 使う人・使う場面（誰が・どこで使うか）

社内スタッフが使う業務システムなのか、不特定多数のお客様が使うサービスなのかで、必要な作り込みは大きく変わります。「誰が」「どんな場面で」使うのかを一言添えるだけで、見積もりの前提が具体的になります。

③ 予算感・優先度（どのくらいの規模で考えているか）

「いくらまで出せるか」を厳密に決める必要はありませんが、「このくらいの規模感で考えている」というレンジは伝えておくと、見積もりの前提が具体的になります。予算感がまったくないと、開発会社は適正な規模を判断できず、見積もりの往復が増えてしまいます。

伝え方にはコツがあり、予算は「目標」ではなく「制約条件」として、「この予算内で優先順位をつけて最大限何ができるかを一緒に考えたい」という形で渡すのがおすすめです。なお「予算を伝えると、その金額ギリギリで見積もられるのでは？」という不安については、開発の見積もり、予算はベンダーに伝えるべき？——「予算いっぱいで見積もられそう」への答えと賢い伝え方で詳しく解説しています。

④ 参考にしているサービス・既存業務の資料

「〇〇というアプリのこの機能が近い」といった参考例や、今その業務を紙・Excelでどう回しているかが分かる資料があると、認識のズレが一気に減ります。言葉で説明しづらい部分を、実物で補えるからです。

繰り返しますが、これらはきれいな書類である必要はありません。メールや口頭で伝えられる範囲のメモで十分です。

概算見積もりを受け取ったら確認すべきこと

概算が出てきたら、金額の大小だけを見るのではなく、次の点を確認してください。

前提条件・作業範囲が書かれているか：「どこまでを含み、何を含まないか」が明記されているか。概算は前提を置いて出すものなので、その前提が見えることが重要です。
「一式」だけになっていないか：金額の内訳や、どんな機能を想定しているかが示されているか。「開発費一式 ○○万円」としか書かれていないと、何がどこまで含まれるのかを判断できません。
確定までの流れが示されているか：「この概算のあと、要件定義を経て確定見積もりを出す」という進め方が説明されているか。ここが曖昧なまま発注すると、後から金額が膨らんでトラブルになりがちです。

受け取った見積もりの「見方」そのものについては、以下の記事で詳しく解説しています。あわせてご覧ください。

よくある誤解と失敗

最後に、要件が曖昧な段階の見積もりでつまずきやすいパターンを挙げておきます。

概算を「確定」だと思い込む：概算は±30%程度ぶれるもの、という前提を忘れて予算を組むと、確定段階で「聞いていた金額と違う」となります。概算はあくまで参考値です。
安い概算にそのまま飛びつく：概算が安いのは、単に前提が甘い（＝作る量を少なく見積もっている）だけのこともあります。確定段階で大きく上がる可能性があります。
要件を固めないまま発注してしまう：曖昧なまま走り出すと、作りながら仕様が膨らみ、追加費用と納期遅延の温床になります。概算のあとに要件定義の工程を挟むことが、結果的に一番の近道です。