システム開発の見積書の見方｜比較で確認すべきチェックポイント

システム開発の見積書は、会社ごとに書き方が違い、合計金額だけを比べても判断できません。この記事では、見積書の見方と、複数社を比較するときに確認すべきチェックポイントを説明します。「一式」表記の中身の確かめ方、人月単価と工数の根拠、見積に含まれない費用、安すぎる見積に潜むリスクを順に見ていきます。

システム開発の見積書の見方：まず全体の構成を押さえる

見積書を受け取ったら、金額より先に、何が書かれているかを確認します。比較しやすい見積書には、次の要素がそろっています。

この表の要素が欠けている見積書は、比較の前に追加の情報を求めるのが確実です。

概算見積か正式見積かを確認する

見積には、要件が固まる前に出す「概算見積」と、要件定義の後に出す「正式見積」があります。概算見積は、要件があいまいな分だけ幅を持たせた金額です。複数社を比べるときは、すべてが同じ段階の見積かを確認してください。概算と正式を並べて比べると、正式見積の方が高く見えてしまいます。

概算見積で予算を確保する場合は、要件定義の後に金額が変わる可能性を社内にも伝えておくと、稟議の手戻りを防げます。

「一式」表記の中身を工程別・機能別に分解する

見積書でよく見る「開発費 一式」という書き方は、それだけでは中身が分かりません。一式の金額は、次の2つの方向で分解してもらいましょう。

工程別に分ける

要件定義、設計、実装、テスト、リリース、プロジェクト管理といった工程ごとの工数と金額です。工程別に見ると、どこに時間をかける計画なのかが分かります。たとえばテストの工数が極端に少ない見積は、品質の確認が十分でない可能性があります。

機能別に分ける

ログイン、会員管理、検索、決済、管理画面など、機能ごとの金額です。機能別に分かれていると、予算に合わないときに「どの機能を後回しにすれば、いくら下がるか」を相談できます。

一式表記が悪いわけではありません。ただ、比較の段階では内訳がないと判断ができないため、「工程別と機能別の内訳を出してください」と依頼してかまいません。

人月単価と工数の根拠の確認方法

内訳が出てきたら、工数と単価の根拠を確認します。人月単価の意味や相場は人月単価の記事で詳しく説明しています。

確認したいのは次の点です。

• 役割ごと（PM、設計、エンジニアなど）の単価が示されているか
• 各役割の稼働割合（全稼働か、半分か）が書かれているか
• 似た規模の案件の実績と比べて、工数が大きく外れていないか
• AIを使った開発の場合、AIツールの利用料が人の工数と分けて書かれているか

複数社の見積で工数に大きな差があるときは、各社に理由を聞きます。差の理由が「作る範囲の違い」なのか「進め方の違い」なのかで、判断が変わるからです。

見積に含まれない費用（保守、インフラ、追加開発）

見積書の金額は、多くの場合、開発にかかる初期費用だけです。使い始めてからかかる費用は、別途必要になります。

• 保守・運用費: 不具合対応、問い合わせ対応、OSやライブラリの更新など。詳しくは保守運用費の記事をご覧ください。
• インフラ費用: クラウドサーバー、データベース、ドメインなどの月額料金。
• 外部サービスの利用料: 決済手数料、SMS送信、地図、AIのAPI（外部の機能を呼び出す仕組み）の利用料など。利用量によって変動します。
• 追加開発: 開発中や公開後の追加要望。範囲が大きく変わると別見積になります。詳しくは仕様変更と追加費用の記事で説明しています。
• データ移行や既存システムの改修: 既存システムからの移行は、見積の対象外になっていることがよくあります。

外貨建てのクラウドやAIサービスは、為替や利用量で費用が変わります。見積に「どの為替レートで換算したか」「どのくらいの利用量を想定したか」が書かれているかを確認しましょう。

安すぎる見積に潜むリスク

他社より極端に安い見積は、注意が必要です。安くなっている理由として、次のようなことが考えられます。

• 作業範囲が狭く、必要な機能が含まれていない
• テストやプロジェクト管理の工数が削られている
• 経験の浅い体制で、手戻りが後から発生する
• 受注後の追加見積で、最終的な総額が上がる

国の情報システム調達でも、極端な安値落札の再発を防ぐため、低い価格の入札者について積算の妥当性や技術者の配置、履行体制を調べる方針が2002年に示されています（総務省：情報システムに係る政府調達制度の見直しについて）。安さの理由を確かめずに選ぶのは、発注者にとってもリスクです。

安い見積を受け取ったら、他社の見積と範囲・工程・体制を並べて、何が違うのかを確認してください。

受託開発の現場から

開発会社が見積を出すときに気をつけていることから、見積書を読むときの観点になるものを紹介します。

• 備考欄の項目を必ず書く: ある受託開発会社の見積では、税抜表記、見積の有効期限、責任者承認前の暫定値であること、要件定義後に正式見積を出すこと、作業範囲が大きく変わる場合は別途見積になること、支払条件、契約形態を備考欄に書いています。受け取った見積書にこれらがあるかを確認してください。
• 契約形態で総額が変わる: 受託開発の現場では、請負契約の見積にはリスク分の上乗せが積まれるため、準委任契約（成果完成型）に比べて2〜3割高くなりがちだと言われます。見積を比べるときは、契約形態がそろっているかも確認しましょう。契約形態の違いは請負と準委任の記事で説明しています。
• 極端に安い見積は危うい: 要件定義に十分な予算を割かず、極端に安い金額で設計まで引き受ける開発会社には注意が必要です。そうした選び方を続けると、結果的に危うい開発会社が残りやすくなる、という指摘もあります。
• 運用時の原価まで見る: 月額で使う仕組みでは、AI利用料などの原価を利用量別に試算して示す見積もあります。開発費だけでなく、使い始めてからの費用で事業が成り立つかを確認するのが、見積の妥当性を判断する観点です。

まとめ

• 見積書は合計金額より先に、作業範囲・内訳・前提条件・含まないものを確認します。
• 「一式」は工程別と機能別に分解してもらうと、比較と金額調整がしやすくなります。
• 保守・インフラ・外部サービス・追加開発など、見積に含まれない費用を洗い出します。
• 安すぎる見積は、範囲・工程・体制のどこが違うのかを確かめてから判断します。

各社の見積を比べる前に、自社の案件の費用感をつかんでおくと判断がぶれません。FastProposal の無料AI相談なら、案件の内容と費用の目安が数分で分かります。