システム開発の見積書の見方｜損しないためのチェックポイント

システム開発の見積書を受け取ったものの、「この金額が妥当なのかわからない」「項目の意味がよくわからない」と困った経験はありませんか。

見積書の読み方を知らないまま契約してしまうと、後から追加費用が発生したり、想定と異なるシステムが納品されたりするリスクがあります。

この記事では、システム開発の見積書に含まれる主要な項目の意味と、損しないためのチェックポイントを解説します。

システム開発の見積書に含まれる主な項目

開発会社によって書式は異なりますが、一般的な見積書には以下のような項目が含まれます。

各工程の詳しい内容についてはシステム開発の流れ完全ガイドを参照してください。

見積書の形式：「一式見積」と「工数見積」の違い

見積書の形式は大きく2種類あります。それぞれの特徴を理解しておきましょう。

中小規模のシステム開発では工数見積が一般的です。一式見積の場合は、必ず内訳の提示を依頼しましょう。

「人月」と「人日」の読み方

システム開発の見積書では「人月（にんげつ）」や「人日（にんにち）」という単位がよく使われます。

• 人月 -- 1人のエンジニアが1ヶ月（約20営業日）稼働する作業量
• 人日 -- 1人のエンジニアが1日稼働する作業量

例えば「開発工程 3人月」と書かれていれば、1人のエンジニアが3ヶ月間、または3人のエンジニアが1ヶ月間かかる作業量を意味します。

エンジニアの単価相場

単価が安いからといって必ずしも得とは限りません。経験の浅いエンジニアが多いと工数が増え、結果的に総額が高くなるケースもあります。

損しないための7つのチェックポイント

1. 要件定義の費用が含まれているか

要件定義はシステム開発で最も重要な工程です。見積書に独立した費用項目として含まれている場合は、その内容と工数が妥当かを確認しましょう。一方、要件定義を別途費用として計上せず、開発プロセスの中に組み込んでいる会社もあります。どちらの場合でも、「要件をどのタイミングで、どのように固めるのか」を事前に確認しておくことが重要です。

2. テスト工程の費用が明記されているか

テスト工程が見積書に含まれていない、または極端に少ない場合は要注意です。テストを省略すると、リリース後にバグが大量に見つかり、修正コストが膨らむことになります。全体の15〜20%程度がテスト費用の目安です。

3. 「含まれないもの」が明記されているか

見積書で特に注意すべきは「何が含まれていないか」です。以下の項目が別途費用になっていないか確認しましょう。

• サーバー・インフラ費用
• ドメイン・SSL証明書の費用
• データ移行の費用
• 操作マニュアルの作成費用
• 操作研修の費用
• リリース後の保守・運用費用

保守費用の相場についてはシステム保守の費用相場も参考にしてください。

4. 仕様変更時の費用ルールが記載されているか

開発中に仕様変更が発生することは珍しくありません。その場合の追加費用の算出方法や、承認フローが見積書または契約書に含まれているかを確認しましょう。「仕様変更は別途見積」としか書かれていない場合は、具体的なルールを事前に取り決めることをおすすめします。

5. 納品物が明記されているか

「システム一式」だけでなく、具体的に何が納品されるかを確認しましょう。

• ソースコード
• 設計書（基本設計書、詳細設計書）
• テスト仕様書・テスト結果
• 操作マニュアル
• 環境構成図

特にソースコードの著作権・所有権がどちらに帰属するかは重要なポイントです。

6. 瑕疵担保期間が設定されているか

瑕疵担保期間とは、納品後にバグ（瑕疵）が見つかった場合に無償で修正してもらえる期間です。一般的には1〜3ヶ月程度が設定されます。この期間が極端に短い、または設定されていない場合は交渉しましょう。

7. 複数社の見積もりを比較しているか

最低でも2〜3社から見積もりを取り、比較することをおすすめします。ただし、単純に金額だけで比較するのではなく、以下の観点で総合的に判断しましょう。

• 同じ要件に対して、工数の見積もりに大きな差がないか
• 含まれている・含まれていない項目に違いがないか
• エンジニアのスキルレベルと単価のバランスは妥当か
• 過去の実績や対応体制は信頼できるか

FUNBREWが大切にしていること

FUNBREWでは、見積書に「要件定義」を独立した費用項目として計上しないケースが多くあります。要件定義の資料だけ作成して実際の開発に入らないまま時間が経つと、当初の要件と現実が食い違ってくることが一般的に起こり得るからです。だからといって要件定義をしないわけではなく、プロトタイプを作りながら要件を固めていくスタイルを採用しています。「資料を作る」のではなく「動くものを作りながら要件を確認する」ことで、見積もりと実際の開発のズレを最小限に抑えています。

見積書で「高い」と感じたときの対処法

機能の優先順位を見直す

すべての機能を一度に作る必要はありません。「絶対に必要な機能」と「あれば嬉しい機能」を分け、最小限の機能で最初のバージョンをリリースする方法もあります。段階的な開発についてはプロトタイプ開発の記事も参考にしてください。

既存のサービスで代替できないか検討する

すべてをスクラッチ（ゼロから）開発する必要があるか再検討しましょう。一部の機能はSaaSツールで代替できるかもしれません。

見積もりの前提条件を確認する

金額が高い場合、過剰な要件が含まれている可能性があります。「この機能にこの工数は妥当か？」と一つずつ確認していくことで、不要なコストを削減できます。

関連記事として、契約形態の選び方ガイドもあわせてご覧ください。

まとめ

システム開発の見積書を正しく読むために、以下のポイントを押さえましょう。

• 工数見積で内訳を確認する。一式見積の場合は内訳を依頼
• 要件定義とテストの費用が適切に含まれているか確認
• 「含まれないもの」を明確にし、後から予想外の追加費用が出ないようにする
• 仕様変更のルールと瑕疵担保期間を事前に取り決める
• 複数社から見積もりを取り、金額だけでなく内容で比較する

見積書の内容に不明点があれば、遠慮なく開発会社に質問しましょう。良い開発会社であれば、丁寧に説明してくれるはずです。

「見積書をもらったけど、妥当かどうか判断できない」という方は、お問い合わせからセカンドオピニオンとしてご相談いただくことも可能です。