開発会社から見積書が届いたものの、金額が妥当なのか判断できない——これは発注に慣れていない方だけでなく、何度か発注した経験のある方からもよく聞く話です。アプリ開発の見積書は、総額を眺めても判断できません。読むべきは、どの作業にどれだけの時間がかかると見ているかという内訳です。この記事では、項目ごとの意味と、2社の見積もりを同じ条件にそろえて比べる手順を整理します。
📌 この記事の結論
見積書は総額ではなく、作業の単位と想定している工数で読んでください。金額の違いは腕前の差ではなく、ほとんどの場合「どこまでを見積もりに入れたか」の差です。比べる前に前提をそろえると、安い高いではなく、何が含まれているかで選べるようになります。
01アプリ開発の見積書は、総額より「どこに時間がかかると見ているか」を読む
見積書を受け取ってまず目が行くのは合計金額ですが、そこだけを見ると判断を誤ります。同じ機能を作る見積もりでも、設計にどれだけ時間を取るか、テストをどこまでやるか、運用に入ってからの面倒をどちらが見るかで、総額は何倍にも開きます。
読む順番としては、合計を見る前に、各項目の工数（かかる時間）を見てください。そこに開発会社の見立てが出ます。たとえば画面数が同じなのに設計の工数が大きく取られている見積もりは、仕様を固めてから作る進め方を想定しています。逆に設計が薄く開発が厚い見積もりは、動くものを先に作って直していく進め方です。どちらが良いかは案件によりますが、同じ金額でも進め方は違うということは先に知っておく必要があります。
もう一つ見るべきは、「一式」とまとめられている項目がどれだけあるかです。一式は中身が見えないため、後から「それは含まれていません」が起きやすい場所になります。費用の相場感そのものは業務用Webアプリの開発費用と相場に整理していますので、金額の目安を知りたい場合はあわせてご覧ください。
02見積書に並ぶ項目の意味と、工数・単価の読み方
システム開発の見積書は、会社によって書き方が違いますが、中身はおおむね次の区分に収まります。
| 項目 | 何の費用か | 見るべきところ |
|---|---|---|
| 要件定義 | 何を作るかを決める作業 | 打ち合わせの回数と、成果物（仕様書）が残るか |
| 基本設計・詳細設計 | 画面・データ・処理の設計 | 画面数と、設計書が納品物に入っているか |
| 開発（実装） | 実際に作る作業 | 画面単位・機能単位に分かれているか |
| テスト | 動作確認と不具合の修正 | 誰がどこまで確認するか。受入テストの扱い |
| 環境構築 | サーバー・ドメイン・証明書など | 初期費用に含むのか、月額なのか |
| データ移行 | 既存のExcelや旧システムから移す作業 | 件数と、移行の対象範囲 |
| 導入支援・マニュアル | 操作説明と手順書 | 説明の回数と、手順書の形式 |
| 保守・運用 | 公開後の対応 | 月額に何が含まれるか。対応時間と連絡手段 |
| プロジェクト管理 | 進行管理・会議の運営 | 全体の何割か。極端に大きくないか |
工数と単価に分けて見る
開発費は、ほとんどの場合「工数 × 単価」で計算されています。工数は人日や人月で書かれ、単価は1人日あたり、または1人月あたりの金額です。
比べるときは、この2つを分けてください。A社が高いのは単価が高いからなのか、同じ単価で工数を多く見ているからなのかで、意味がまったく違います。単価が高い場合は担当者の経験や体制の違いである可能性があり、工数が多い場合は作業範囲を広く取っているか、リスクを多めに見積もっているかのどちらかです。
工数の書かれていない見積書を受け取ったときは、各項目が何人日の想定かを聞いてください。答えられない見積もりは、根拠がないか、他社の金額に合わせて作られている可能性があります。
032社の見積もりを比べる前にそろえる4つの条件
同じ依頼をしたはずの2社の見積もりが大きく違うとき、原因の多くは伝えた内容の解釈が分かれていることです。比べる前に、次の4つをそろえてください。
そろえる前に比べると、安い方を選んで後から増える
前提がそろっていない見積もりを並べると、たいていは作業範囲を狭く取った見積もりが安く見えます。契約後に「それは別途です」が重なり、最終的な支払いは最初の見積もりを超えることがあります。安さの理由を確かめないまま決めないでください。
- 機能の一覧をこちらで作って渡す。画面名と、その画面でできることを箇条書きにするだけで十分です
- 想定している利用者数と使い方を伝える。社内10人が使うのか、顧客が自由に登録できるのかで設計は変わります
- 納期の希望を同じにする。急ぎの案件は人を増やす前提になり、工数が同じでも金額が上がります
- 保守の範囲を同じ条件で聞く。公開後の障害対応、小さな修正、機能追加のどこまでを月額に含むかを明示して聞きます
この4つを書いた1枚の紙を各社に同じように渡すのが、いちばん確実な方法です。口頭で伝えると、会社ごとに聞き取った範囲が変わってしまいます。
04金額が大きく違うときに起きていること
2社の見積もりが大きく開いたとき、腕前の差だと考える前に、次のどれが起きていないかを確認してください。経験的には、ほとんどがこの範囲で説明できます。
| 起きていること | 見積書に出るサイン | 確認する質問 |
|---|---|---|
| 作業範囲の切り方が違う | 一方に要件定義やテストの項目がない | 「この項目は御社の作業に含まれますか」 |
| 作り方の前提が違う | 既製のサービスを組み合わせるか、作り込むか | 「どの部分を既存のサービスで済ませる想定ですか」 |
| デザインの前提が違う | 画面デザインの工数の有無 | 「画面のデザインはどこまで作りますか」 |
| 保守が別契約になっている | 保守・運用の行がない、または月額だけ | 「公開後の対応は月額に含まれますか」 |
| 発注側の作業を当てにしている | 安いが工数も少ない | 「こちらで用意するものは何ですか」 |
| リスクの見方が違う | 予備費・バッファの項目 | 「想定外が起きたときの扱いはどうなりますか」 |
このうち最後の「発注側の作業を当てにしている」は見落としやすい項目です。データの整理、文章や画像の用意、テストの立ち会いを発注側がやる前提で安くなっていることがあります。社内に手が空いていないなら、その作業も費用に入れて考えたほうが実態に近くなります。
05見積書に書かれていないと後で揉めるところ
次の5つは、見積書に書かれていなくても契約は進みますが、後から必ず話題になります。最初に書面で確認してください。
- ソースコードと著作権の扱い。納品後、自社で改修したり別の会社に引き継いだりできるか
- アカウントと環境の所有者。サーバー、ドメイン、外部サービスの契約名義が自社になるか
- 検収の条件。何をもって完成とするか。受入テストの期間と、不具合の修正はいつまで無償か
- 仕様変更の扱い。途中で変更したい場合の手続きと、追加費用の決め方
- 公開後の対応時間。障害が起きたとき、いつからいつまでの連絡に対応するか
アカウントの名義は、乗り換えのときに効いてきます
サーバーやドメイン、外部サービスの契約が開発会社の名義になっていると、別の会社に引き継ぐときにいったん止める必要が出ることがあります。契約の名義は自社にして、開発会社には作業権限だけを渡す形が安全です。見積書に出てこない項目なので、契約前に 依頼前に決めておくこと と合わせて確認してください。
06見積もりの前後で使うチェックリスト
依頼する前に、発注側で決めておくこと
- 解決したい困りごとを1文で書いた（「Excelの集計に毎月時間がかかる」など）
- 使う人と人数を決めた
- 必要な画面と、その画面でできることを箇条書きにした
- 既存のデータがどこに何件あるかを把握した
- 予算の上限と、いつまでに使えるようにしたいかを決めた
- 社内で誰が窓口になるかを決めた
受け取った見積書を確認するとき
- 各項目に工数（人日・人月）が書かれている
- 「一式」の項目がない、またはその中身を聞いて記録した
- 要件定義・設計・テスト・環境構築・データ移行・導入支援・保守の行がそろっている
- 保守の月額に含まれる作業と、含まれない作業が分かれて書かれている
- 支払いの時期（着手金・中間・納品時）が書かれている
- 見積もりの有効期限が書かれている
- 前提条件と、発注側で用意するものが書かれている
このチェックリストは、見積書に直接書き込みながら使うのが効率的です。埋まらなかった項目が、そのまま質問リストになります。
07よくある失敗とその避け方
1社だけから見積もりを取って判断する。比較対象がないと、その金額が何を含んでいるのか分かりません。発注先を1社に決めているとしても、2社目から取ると自社の要件の抜けが見つかります。
安い見積もりをそのまま選ぶ。安い理由を確認しないまま進めると、含まれていなかった作業が追加費用として積み上がります。安い理由が「範囲が狭い」なら、その外側を誰がやるのかを決めてから選んでください。
要件を固めきってから見積もりを取ろうとする。完璧な要件を社内だけで作るのは難しく、そこで止まってしまいます。画面名と目的の箇条書きだけでも見積もりは取れますし、やりとりのなかで要件が固まることもあります。
保守費用を見ずに初期費用だけで比べる。アプリは作って終わりではありません。数年使う前提なら、初期費用と月額を合わせた総額で比べる必要があります。
社内の工数を数えていない。打ち合わせ、データの整理、テスト、操作説明は発注側の時間を使います。ここを見ていないと、安い見積もりを選んだ結果、社内の負担が増えることになります。
見積書の前提条件を読み飛ばす。前提条件の欄に、作業範囲を限定する重要な記述が入っていることがあります。金額の表より先にここを読んでください。
08自分で進める場合と、専門家に任せる場合の分かれ目
見積もりの読み解きを自分でやるか、詳しい人に見てもらうかの分かれ目は、金額の大きさよりも「社内に仕様を判断できる人がいるか」です。
自分で進めやすいのは、作りたいものが既存の業務をそのままシステムにする形で、現場の業務を把握している人が窓口に立てる場合です。この場合、見積書の各項目が自社の業務のどこに対応するかを判断できるため、工数の多寡も見当がつきます。
相談したほうがよいのは、作りたいものが社内に前例のない仕組みの場合、複数のシステムをつなぐ必要がある場合、提示された工数が妥当か判断する材料がない場合です。また、金額が大きく、契約の条件（著作権、検収、保守）まで含めて確認したいときは、第三者の目を入れたほうが見落ちが減ります。
判断の順番としては、まず自社で機能の一覧と予算の上限を作り、それを渡して2社から見積もりを取る。そこで出た差を質問して埋めてから選ぶ。この順番なら、専門的な知識がなくても比較の土台はできます。差が埋まらない項目だけを、詳しい人に見てもらえば十分です。
09よくある質問
見積もりは無料で出してもらえるものですか？
相見積もりを取ることは失礼になりませんか？
見積もりの金額は交渉できますか？
見積書に「人月」と書かれていますが、何を指しますか？
見積もりを取ったあと、どのくらいで決めるべきですか？
10まとめ：見積書は、比べる前にそろえる
アプリ開発の見積書の見方で大事なのは、金額を評価することではなく、同じ条件で並べられる状態を作ることです。機能の一覧、利用者数、納期、保守の範囲——この4つを自分で決めて同じように各社へ渡せば、戻ってきた見積もりの違いは「考え方の違い」として読めるようになります。
工数が書かれているか、一式の項目がないか、保守の中身が分かれているか。この3つを確認するだけでも、後から増える費用はかなり減ります。見積書に書き込みながら質問リストを作り、差が埋まってから決めてください。
TENERAMENTEなら、お見積もりの段階で要件定義・設計・開発・テスト・環境構築・導入支援・保守を項目ごとに分け、それぞれ何人日の想定かと、御社側で用意していただくものを書面でお示しします。ソースコードとサーバー・ドメインの名義はお客様に残る形にし、初期費用30万円〜、最短2週間でPoC（試作）をお出しできるので、全体を発注する前に「この形で合っているか」を実際の画面で確認してから進められます。AI業務アプリ開発の進め方をご覧いただいたうえで、お問い合わせからお気軽にご相談ください。