株式会社ペンタゴンは「アプリ開発に特化した専門パートナー」です。要求をカタチにするのは当たり前。さらに「もっとこうすれば良くなる」という鋭いデザインや機能の提案を次々に出します。新しいサービスを検討中なら、一度ご相談ください!

実績 相談してみたい→
Pentagonのメンバー

システム開発の見積もりを徹底解説|費用相場・内訳・妥当性の見極め方

更新日:

システム開発の見積もりは、「工程ごとの内訳」「工数と金額の根拠」「含まれないものの明記」の3点がそろっていれば妥当性を判断できます。費用の目安は、当社(株式会社ペンタゴン)の水準で小規模300万円程度、中規模700万円程度、大規模1,500万円以上です。一式・一括でまとめられた見積書や、根拠を聞いても説明が返ってこない金額は要注意です。

発注側が見落としやすいのは、テストやプロジェクト管理、導入・移行といった目立たない工程が削られていないかという点です。当社は受託開発会社として10年以上、相見積もりで比較される側に立ってきました。その経験から、見積書のどこを見れば金額の差の理由が分かるのかを解説します。

この記事でわかること:

  • システム開発の費用の目安(規模別)と、金額を左右する6つの要素
  • 見積書の内訳(要件定義〜テスト・運用)と各項目が意味すること
  • 見積書で必ず確認したい7つのポイントと、失敗事例から分かる注意点

» 【無料】システム開発の見積もりを株式会社ペンタゴンに相談する

アプリ開発専門のプロ「株式会社 Pentagon(ペンタゴン)」とは?

Pentagonのメンバー

Pentagon(ペンタゴン)は、アプリ開発を専門に行う会社です。私たちは単なる開発会社ではなく、お客様の事業の成長を共に創り上げるアプリ開発パートナーです。お客様の事業の成長に本気で向き合うため、当社のアプリ開発では、

  • 「もっとこうすれば良くなる」という提案を次々と出します
  • 「使いやすさ」と「成果があがること」のどちらも妥協しないアプリを作ります
  • リリース後もデータを見ながら、改善・グロースまで一緒に考えます

詳しくはペンタゴンの特徴をご覧ください。無料相談はこちらから

この記事の内容【クリックして移動できます】

システム開発の見積もりが重要な理由

見積もりが重要なのは、予算と体制を確保するための根拠になるうえ、発注側と開発会社が「何を、どこまで作るか」を合意する最初の場になるからです。

見積もりがプロジェクト成功の鍵を握る

見積もりは、システムを作るのに必要な作業量とコストを事前に把握し、予算と体制を確保するためのものです。同時に、発注側と開発会社が「何を、どこまで作るか」を最初に文字で合意する場でもあります。ここで認識がそろっていれば、開発が始まってからの手戻りや追加費用は大きく減ります。

見積もりの精度が低いとトラブルの原因に

見積もりの精度が低いと、次のようなトラブルを招きます。

  • 予算不足による開発の中断や品質低下
  • 納期遅延によるビジネスチャンスの損失
  • 要件漏れによる仕様変更と追加費用の発生
  • 必要以上の作り込みによる無駄なコスト

契約後に金額を見直すのは、発注側にとっても開発会社にとっても負担が大きい作業です。見積もりの段階で中身を確かめておくほうが、結果的に安く済みます。

システム開発の見積もりはいくら?費用の目安

Webシステム・業務システムの開発費は、当社の水準で小規模300万円程度、中規模700万円程度、大規模1,500万円以上が目安です。規模を分けるのは、扱う業務の数、利用者の種類と権限、外部システムとの連携の有無です。

規模当社での開発費の目安期間の目安想定例
小規模300万円程度1.5〜3ヶ月予約管理、顧客管理、日報など1〜2業務の管理画面
中規模700万円程度2〜4ヶ月複数業務の横断、権限管理、既存SaaSとの連携
大規模1,500万円以上4〜5ヶ月以上基幹システムとの連携、複数拠点、取引先も使う外部ポータル
期間は要件定義(1〜2ヶ月)を含みます

従来の一般的な進め方では、小規模でも500万円・2〜3ヶ月、中規模で1,000〜1,500万円程度になることが多く、当社の目安はそれより低めです。差が出るのは、FigmaをベースにしたAI駆動開発でコーディングの工数を大きく圧縮しているためです。浮いた工数は値引きに回すのではなく、要件定義とテスト・品質改善に使っています。

従来の開発とAI駆動開発の工数比較。AI駆動開発ではコーディング工数が大幅に削減され、要件定義とテスト・品質改善に時間を使える
従来の開発とAI駆動開発の工程比較(株式会社ペンタゴン作成)

要件定義ではFigmaで主要な画面を先に作り、画面を見ながら「この項目は要る・要らない」を決めていきます。文章だけの仕様書より認識のずれが起きにくく、見積もりの前提もはっきりします。

見積書の内訳と各項目の意味

見積書の金額は、工程ごとの作業量(人日・人月)に担当者の単価を掛けて積み上げたものです。まずは各項目が何の作業を指しているのかを押さえておきましょう。

要件定義・設計・開発・テストなどの内訳

一般的なシステム開発の見積書には、次のような項目が並びます。

項目主な作業内容確認したいこと
要件定義現行業務の調査、必要な機能・データ・権限の整理、画面設計誰が作業し、何が成果物として納品されるか
設計基本設計・詳細設計、データベース設計、UI/UXデザイン画面数・帳票数など、設計の対象が数で書かれているか
開発(実装)設計に基づくプログラミング、外部システムとの連携機能ごとに工数が分かれているか
テスト単体・結合・総合テスト、受け入れテストの支援テストの範囲と、発注側が担う作業の線引き
導入・移行本番環境の構築、既存データの移行、操作説明移行するデータの件数・形式が前提に書かれているか
プロジェクト管理進捗管理、課題管理、定例会議会議の頻度と、窓口になる担当者
インフラ・ツール費サーバー、クラウド利用料、有償ライブラリのライセンス初期費用か月額か、誰の名義で契約するか

人件費の部分は、次のように役割ごとの工数で書かれることが多いです。

・プロジェクトマネージャー:○○人日
・システムエンジニア:○○人日
・プログラマー:○○人日
・デザイナー:○○人日
・ドキュメント作成:○○人日

金額は「工数(人日)×単価」で積み上がります。当社がアプリ開発の見積書サンプルとして公開しているものでは、工程が7つに分かれ、合計95人日・約578万円でした。単価は多くの工程で1人日6万円(月に換算すると約120万円)です。

  • 開発(画面の実装):25人日×6万円=150万円
  • システム連携・API開発:20人日×6万円=120万円
  • デザイン:12人日×5万円=60万円

このように工程ごとの人日・単価・金額と主な作業内容が並んでいれば、「なぜこの金額か」を1行ずつ確かめられます。備考欄には「打ち合わせはオンライン」「クラウドサーバーを使用」といった前提が書かれ、ここが含まれる範囲と含まれない範囲の境目になります。

当社の小規模案件(300万円程度)では、要件定義が100〜200万円、残りが実装からテストまでの費用というのが一つの目安です。要件定義の比重が大きいのは、画面とデータ項目まで決めておくほど、実装とテストの工数を正確に見積もれるためです。

見積書には、金額とあわせて前提条件も書かれています。たとえば次のような記載です。

・要件定義は貴社にて実施するものとする
・外部システムとの連携は○○社の支援を前提とする
・データ移行は○○件を想定する
・運用保守は見積もりに含まない

この前提が1行変わるだけで、金額は大きく動きます。自社の想定とずれていないかを、金額より先に確認してください。

システム開発の見積金額は何で決まる?

見積金額を左右するのは、主に次の6つの要素です。同じ「顧客管理システム」でも、この6つの組み合わせ次第で金額は数倍変わります。

要素金額が上がりやすいケース
①開発する機能・画面の数画面や帳票の種類が多い、締め日・割引などの例外ルールが多い
②ユーザーの種類・権限社員・管理者・取引先など立場ごとに見える画面や操作できる範囲が違う
③外部システム・データ連携会計ソフト・基幹システム・SaaSとつなぐ、仕様書のない既存システムと連携する
④UI/UXの作り込み現場の担当者が迷わず使える画面にするための検証や、スマートフォン対応を行う
⑤非機能要件・品質レベル同時アクセス数が多い、応答速度の基準が厳しい、監査やセキュリティの要件がある
⑥テスト・品質管理の範囲対応ブラウザ・端末が多い、第三者による検証や負荷テストを行う

見積金額を下げたいときは、単価の安い会社を探すより、この6つのうちどれを第1弾から外せるかを考えるほうが効果的です。当社では、最初のリリースに必要な機能に絞り、使われ方を見ながら段階的に広げる進め方をよく提案しています。

システム開発会社によって見積もり金額が異なる理由

複数社から見積もりを取ると、金額が2倍以上開くことは珍しくありません。その差は、たいてい各社の「算出方法」「開発手法」「前提にした仕様の粒度」の3つの違いから生まれます。

見積もりの算出方法の違い

見積もりの算出方法には、主に次の4つがあります。

・トップダウン法:過去の類似案件の実績から全体の工数を概算する
・ボトムアップ法:作業を細かく分け、各作業の工数を積み上げる
・パラメトリック法:画面数や機能数などの規模から計算式で工数を出す
・プライスツーウィン法:顧客の予算から逆算して工数を決める

一般的に精度が高いのはボトムアップ法で、プライスツーウィン法は予算に合わせるぶん精度が下がります。最初の相談で出る概算はトップダウン法、要件定義後の確定見積もりはボトムアップ法、というように段階で使い分けるのが普通です。比べている2社の見積もりが、それぞれどの方法で出されたものかを確認してください。

開発手法(ウォーターフォール型 vs アジャイル型)の違い

ウォーターフォール型は、要件定義から設計、実装、テストへと工程を順に進めます。最初に全体の作業量を見込むため、予算と納期を確定させやすい反面、仕様変更が起きると見積もりの組み直しが必要です。

アジャイル型は、短い期間の開発を繰り返しながら機能を足していきます。仕様変更には柔軟ですが、最初の見積もりは大まかな規模感にとどまり、総額や完了時期が読みにくくなります。どちらの手法を前提にした金額なのかで、同じ数字でも意味が変わります。

設計書や仕様書のレベル感の違い

発注側から渡す資料が大まかだと、開発会社は細部を想定で補って見積もります。想定が実際とずれていれば、金額は過大にも過小にもなります。リスクを見込んで多めに積む会社と、最低限で積む会社とで差が開くのはこのためです。

資料を細かく作り込むほど見積もりは正確になりますが、発注側の負担も増えます。対象の業務、使う人数、つなぐ既存システムの3つが分かれば概算は出せるので、確定見積もりに必要な画面とデータ項目は、要件定義の中で開発会社と一緒に決めるのが現実的です。

システム開発の見積書で必ず確認したい7つのポイント

見積書を受け取ったら、金額を見る前に次の7点を確認してください。どれか1つでも答えが曖昧なら、その部分が契約後の追加費用やトラブルの火種になります。

①見積もり対象の機能・画面が合っているか

見積書や添付の機能一覧に、依頼した機能と画面がすべて載っているかを照らし合わせます。「顧客管理機能 一式」のようなまとめ方では、検索や帳票出力が含まれているのか判断できません。画面名と主な機能が1行ずつ書かれているのが理想です。

②要件定義からリリースまで、どこまで含まれているか

要件定義・設計・実装・テスト・導入・移行のうち、どの工程が金額に入っているかを確認します。安い見積もりでは要件定義が「貴社にて実施」になっていたり、データ移行や本番環境の構築が抜けていたりすることがあります。工程ごとの工数の比率も見ておきましょう。要件定義や設計が極端に少ない場合は、既存の資料がある前提なのか、作業そのものを省いているのかを聞いてください。

③「見積もりに含まれないもの」が明記されているか

含まれるものと同じくらい大事なのが、含まれないものの記載です。運用保守、サーバー費用、外部サービスの利用料、操作マニュアルの作成などは、会社によって扱いが分かれます。当社は見積もりの段階で前提とスコープを書面で示し、含まれない作業も明記しています。

④工数・金額の根拠を説明してもらえるか

「なぜこの機能が10人日なのか」と聞いて、作業の中身で答えが返ってくるかを確かめます。人月単価は会社の規模や体制によって数十万円から100万円を超えるものまで幅があるため、単価の高低だけを比べても意味がありません。同じ機能に対して何人日かかると見ているかを比べると、前提の取り違えやスコープの解釈の違いが見えてきます。

⑤テスト・品質管理の工数が含まれているか

テストは、見積もりを安く見せたいときに真っ先に削られやすい工程です。テストの項目が見当たらない、または開発工数に比べて極端に少ない見積もりは、不具合の発見を発注側の受け入れテストに頼る前提になっている可能性があります。誰が、どの範囲を検証するのかまで確認してください。第三者検証の有無をどう確かめるかは、このあとの「見積もりで品質管理体制を確認しよう」で解説します。

⑥仕様変更時の追加費用の考え方が明確か

開発中に仕様変更が起きるのは珍しいことではありません。問題になるのは、変更の費用をどう決めるかが事前に決まっていない場合です。変更の受付方法、費用と納期への影響をいつ提示するのか、どの程度の修正までなら見積もりの範囲内なのかを確認しましょう。当社では、仕様変更が発生するたびに費用と期間への影響を提示し、合意してから着手しています。

⑦リリース後の費用まで把握できているか

システムは納品して終わりではなく、サーバー費用、保守費用、改修費用が毎年かかります。保守費は当社では開発費の年15%前後が目安です。あわせて、検収の基準、不具合への対応範囲(契約不適合責任)、ソースコードや設計書の著作権の帰属、契約終了時に受け取れるものも、見積もりの段階で確認しておくと後から揉めません。

7つのポイントを、見積書を受け取ったときに使えるチェックリストにまとめました。

  • 依頼した機能・画面が一覧ですべて確認できる
  • 要件定義からリリースまで、含まれる工程とスケジュールが明記されている
  • 見積もりに含まれないもの(保守・サーバー費・マニュアル等)が書かれている
  • 工数と金額の根拠を質問したら、作業の中身で説明が返ってきた
  • テストの範囲と担当が決まっている
  • 仕様変更時の費用の決め方が書面で合意できる
  • 保守費用、検収条件、著作権の帰属が確認できている

7つのポイントで確認しても判断がつかない項目があれば、見積もりを依頼する前の段階からご相談ください。

» 【無料】見積書の内容について株式会社ペンタゴンに相談する

見積もりで「品質管理体制」を確認しよう|第三者検証の有無がトラブルを分ける

見積もりを比較する際は、金額や工数だけでなく「開発会社がどのような品質管理体制をとっているか」も必ず確認しましょう。ここは発注側が見落としがちですが、納品後のトラブルを大きく左右する重要なポイントです。

たとえば当社では、開発担当とは別の視点でチェックする「第三者検証」の仕組みを整え、品質を担保しています。第三者によるテスト・検証だけを切り出して依頼したい場合は、テスト代行サービスもご活用いただけます。

こうした第三者検証の仕組みがないと、開発側が不具合に気づけなかったり、発注者側で見つかる不具合が多くなったりして、トラブルの原因になります。「とりあえず動く」状態と、リリース後に安定して使える品質とは別物であり、その差は検証体制の有無で大きく変わります。

そのため見積もりの段階では、「システム開発会社側でどのような品質管理・検証体制をとってもらえるのか」「そこにどれくらいのコストがかかっているのか」を確認するようにしましょう。テスト・検証の工数が極端に少ない、あるいは項目として見当たらない見積もりは注意が必要です。

正確な見積もりを得るための発注者の心構え

見積もりの精度は、開発会社の力量だけでなく、発注側が渡す情報の質にも左右されます。正確な見積もりを得るために発注側ができることは3つあります。

RFPやシステム化要件の明確化が見積り精度を上げる

RFP(提案依頼書)は、システム開発の目的や背景、求める機能、納期、予算などを開発会社に伝える文書です。作る過程で発注側自身の要件が整理され、各社が同じ前提で見積もれるようになります。

RFPを書く前に、現状の業務フローを書き出し、どの部分をシステム化するのかを決めておきましょう。完璧な資料である必要はありません。いまの業務の流れ、使っているExcelや帳票、困っていることが分かる材料があれば、開発会社は概算を出せます。

曖昧な表現を避け、具体的な数値指標を示すことの重要性

「高速に処理できること」「使いやすい画面」といった表現では、開発会社ごとに解釈が分かれ、見積もりがばらつきます。「データ登録の処理時間は3秒以内」「同時アクセスは100名程度」「1日あたりの登録件数は1,000件」のように、数字で伝えるのが基本です。

利用者数や想定データ量は、サーバーの構成や必要なテストの量に直結します。おおよその数字でも構わないので、分かる範囲で開示してください。

納得するまで開発会社と認識のすり合わせを行う

RFPを送って終わりにせず、開発会社からの質問に答え、打ち合わせで認識をそろえましょう。見積書が届いたら根拠と前提条件を確認し、疑問点は納得できるまで説明を求めてください。認識のずれを放置したまま契約すると、開発が始まってから手戻りや予算超過として表に出てきます。

社内にITに詳しい担当者がいない場合は、情報システム部門や外部の専門家に同席してもらうのも一つの方法です。当社の場合は、画面のイメージを見ながら話を進めるので、専門用語に詳しくない方でも判断しやすい形で認識をそろえられます。

見積もりの依頼から契約までの標準的な流れ

一般的なシステム開発の見積もり依頼から契約までの流れは、次のようになります。

  1. RFPの作成と開発会社への提示
  2. 開発会社からの質問への回答、打ち合わせ
  3. 開発会社から見積書・提案書が提出される
  4. 見積書の内容を精査し、疑問点の説明を求める
  5. 複数社の見積もりを比較し、依頼先を選定する
  6. 契約条件を協議し、正式に契約する

RFPの作成から契約まで、2〜3ヶ月ほどかかるケースが多いようです。開発規模や社内の決裁の流れによって変わるので、目安と考えてください。

要件が固まっていない段階では、最初に出るのは概算の見積もりです。金額が動かなくなる確定見積もりは、画面とデータ項目まで決めた要件定義の完了時に出ます。当社では要件定義だけを先に契約する進め方(1〜2ヶ月・100〜200万円が目安)にも対応しており、その成果物をもとに他社へ相見積もりを取っていただいても構いません。

システム開発の失敗事例に学ぶ見積もりの重要性

見積もりの段階での判断ミスは、納期遅延やコスト超過、品質の低下としてあとから表面化します。一般的によく見られる失敗のパターンを3つ紹介します(当社の案件ではありません)。

安い見積もりを選んだら必要工程が含まれていなかった

ある小売企業が在庫管理システムの刷新を計画し、詳細な要件定義をしないまま大まかな機能リストだけで見積もりを依頼しました。最も安い会社を選んで着手したものの、その見積もりは要件の詰めやテストの工数が十分に含まれていない前提のものでした。

開発が進むと要件の不足が次々に見つかり、仕様変更が重なって納期は大幅に遅延しました。完成したシステムは不具合が多く、結局は別の会社に修正を依頼することになりました。要件定義とテストがどこまで含まれているかを確認していれば、金額の安さが何を省いた結果なのかに気づけた事例です。

要件追加によって開発費が増大

ある自治体の住民情報システムの再構築では、詳細な要件定義のうえで見積もりを取り、順調に開発が始まりました。ところが途中から機能追加や画面デザインの変更依頼が相次ぎ、定めていた変更管理の手順は守られなくなりました。

工数は当初の見積もりを大きく超え、予算は2倍近くに膨らみました。テストの時間も削られ、リリース後に不具合が多発しています。見積もりの段階で仕様変更時の費用の決め方を合意し、変更のたびに費用と納期への影響を確認していれば防げた失敗です。

金額だけで発注先を選定したことで泥沼化

ある中堅企業がワークフローシステムを導入する際、他社の半分以下の金額を提示した会社を選びました。しかし設計書の品質が低く認識のずれが多発し、進捗の報告も滞りがちで、問題が起きても適切な対応がとられませんでした。

結果は大幅な納期遅延と予算超過で、別の会社に改修を依頼することになりました。極端に安い見積もりは、工数を削っているか、品質管理を省いている可能性があります。金額と同時に、技術力や実績、プロジェクト管理の体制も評価する必要があります。

3つの事例に共通するのは、見積書の金額だけを見て、何が含まれているか・変わったときにどうなるかを確認していなかった点です。見積書で確認したい7つのポイント(機能・画面、含まれる工程、含まれないもの、工数の根拠、テスト、仕様変更、リリース後の費用)は、こうした失敗を防ぐためのものです。

システム開発の外注先選定のコツ

外注先選びのコツは、複数社から相見積もりを取ることと、RFP(提案依頼書)で全社に同じ前提を渡すことの2つです。

必ず複数社から相見積もりを取る

1社だけの見積もりでは、その金額が高いのか安いのか判断できません。2〜3社から相見積もりを取ると相場感がつかめ、提案内容から各社の強みも見えてきます。

比べるときは金額の安さで決めず、含まれる範囲がそろっているかを先に確認してください。打ち合わせでの質問への答え方や、課題に対する提案の具体性も判断材料になります。

RFP(提案依頼書)を作成する

RFPに目的、要件、スケジュール、予算を書いて各社に渡すと、全社が同じ前提で見積もるため比較がしやすくなります。要件の認識違いも減り、見積もりの精度が上がります。

依頼先が決まったら、見積書の内容が契約書に正しく反映されているか、曖昧な表現が残っていないかを確認してから契約しましょう。

当社の小規模・中規模・大規模ごとの見積もり目安は、システム開発の規模別の費用目安で公開しています。

まとめ

システム開発の費用は、当社の水準で小規模300万円程度・中規模700万円程度・大規模1,500万円以上が目安です。金額を左右するのは、機能・画面の数、ユーザーの種類と権限、外部連携、UI/UXの作り込み、非機能要件、テストの範囲の6つです。

見積書を受け取ったら、金額より先に「どの工程が含まれ、何が含まれないか」「工数の根拠を説明できるか」「仕様変更とリリース後の費用はどうなるか」を確認してください。会社ごとの金額差の多くは、単価ではなく範囲と前提の違いから生まれています。

株式会社ペンタゴンは、Figmaで画面を先に固める要件定義と、FigmaをベースにしたAI駆動開発で、業務システム・Webシステムを開発しています。見積もりでは前提と含まれる範囲を明示し、仕様変更時の影響もその都度お伝えします。「この見積もりは妥当なのか」という段階からご相談ください。

» 【無料】システム開発の見積もりを株式会社ペンタゴンに相談する

\スマホアプリ制作のご相談はこちら/ お問い合わせ

Posted by 山本 真矢

無料お見積もり・お問い合わせはこちら