トップ ／ コラム ／ 見積もりの読み方

システム開発の見積もりの読み方｜発注前に確認したい10項目

開発会社から見積書が届いたものの、「どの項目が何を指しているのか分からない」「複数社の金額が大きく違うけれど、どちらが妥当なのか判断できない」。社内にエンジニアがいない発注担当者の方から、よく聞かれる悩みです。このページでは、システム開発の見積もりの読み方と、発注前に確認したい10項目を整理します。

見積もりを読む前に知っておきたいこと

システム開発の見積もりは、完成品の値札ではなく、「この前提なら、この作業にこれだけかかる」という見立てです。同じ依頼をしても会社によって金額が違うのは、多くの場合、想定している作業の範囲や前提条件が違うためです。

そのため、合計金額だけを見て「高い」「安い」と判断すると、発注後に「この作業は含まれていなかった」「追加費用が必要になった」ということが起こりがちです。見積書を読むときは、金額よりも先に、何が含まれていて、何が含まれていないかを確かめることが大切です。

見積書によく出てくる項目の意味

見積書の書き方は会社ごとに異なりますが、おおむね次のような項目で構成されています。名前が違っても、中身が同じことはよくあります。

「一式」とまとめて書かれている項目がある場合は、中身を分けて説明してもらいましょう。内訳が分かると、どこに費用がかかっているのか、削れる部分はどこかを一緒に考えやすくなります。

発注前に確認したい10項目

見積書を受け取ったら、次の10項目を順番に確認してみてください。答えがあいまいな項目ほど、発注後のずれにつながりやすい部分です。

1〜3：範囲と前提を確かめる

1. 1

   作る機能の一覧があるか

   「会員管理システム一式」ではなく、「会員の登録」「会費の入金管理」「名簿の出力」のように、機能が一覧で示されているかを確認します。

2. 2

   含まれない作業が明記されているか

   データ移行、操作説明、サーバーの用意など、見積もりの対象外になっている作業を確かめます。書かれていなければ、質問して文書で残してもらいましょう。

3. 3

   発注側の作業が何か

   要件定義書の作成、画面の確認、テストへの参加、データの準備など、発注側に求められる作業を確認します。社内で対応できる量かどうかも見ておきましょう。

4〜7：進め方と確認の機会を確かめる

1. 4

   要件の決め方

   誰が、どの資料をもとに要件をまとめるのかを確認します。既存システムや規程、今使っている管理表を材料にしてもらえるかも聞いてみましょう。

2. 5

   画面を確認できる時期

   完成直前まで画面を見られない進め方だと、「思っていたのと違う」に気づくのが遅れます。画面イメージや試作品を確認できる時期を確かめます。

3. 6

   仕様が変わったときの扱い

   途中で「やはりこうしたい」と思ったとき、どこまでが見積もり内で、どこからが追加費用になるのか。判断の基準と手続きを確認します。

4. 7

   スケジュールと区切り

   全体の期間だけでなく、どの時点で何ができあがるのか、途中の区切りが示されているかを確認します。

8〜10：完成後と費用の変わり方を確かめる

1. 8

   完成後にかかる費用

   保守、サーバー、外部サービスの利用料など、毎月・毎年かかる費用を確認します。初期費用が抑えられていても、運用費用が大きいこともあります。

2. 9

   不具合があったときの対応

   完成後しばらくの間に見つかった不具合を無償で直してもらえるか、その期間と範囲を確認します。

3. 10

   引き継ぎのしやすさ

   将来、別の会社に保守を頼む可能性もあります。設計資料や操作マニュアルが納品物に含まれるか、データを取り出せる形になっているかを確かめておきましょう。

複数社の見積もりを比較するときのポイント

同じ依頼内容で見積もりを取る

会社ごとに違う説明をしていると、見積もりの前提もばらばらになります。困りごと、作りたい機能、今の業務の流れ、渡せる資料を1枚にまとめ、全社に同じものを渡しましょう。まとめ方は要件定義を発注側で抱え込まない進め方の「5つの準備」が参考になります。

金額ではなく「範囲」をそろえて比べる

比較するときは、前の章の項目を横に並べた表を作り、各社の見積もりに含まれている作業に印をつけていくと違いが見えてきます。安く見える見積もりは、データ移行や操作説明が含まれていないだけ、ということもあります。

説明の分かりやすさも判断材料にする

見積もりについて質問したとき、業務の言葉で答えてくれるかどうかは、発注後のやりとりのしやすさを表しています。開発中に起こる「ずれ」の多くは、言葉の行き違いから生まれます。詳しくはシステム開発が失敗する5つの理由と発注側の対策でも解説しています。

質問への答えを一覧にして残す

各社への質問と回答は、1つの表にまとめておきましょう。発注後に「言った・言わない」の行き違いを防げるだけでなく、社内で決裁を取るときの説明資料としても使えます。

老朽化したシステムの置き換えで見積もりを取る場合は、老朽化した業務システムの置き換え費用を抑える進め方で、置き換えならではの確認点を整理しています。内製と外注のどちらで進めるか迷っている段階の方は、内製と外注の考え方もご覧ください。

pegの進め方：見積もりの前に「何を作るか」をそろえる

見積もりが読みにくい原因の多くは、発注側と開発側で「何を作るか」がそろっていないことにあります。pegは、発注側にエンジニアがいなくても、ヒアリングと既存の資料だけで要件を整理し、作る範囲を業務の言葉で確認しながら進めます。

たとえば日本眼科医会の会員管理システムの置き換えでは、既存システムとヒアリングをもとに新しいシステムを構築しました。発注側で要件定義書を新たに作ることなく進めた事例です。ほかにもドローン操縦士協会の講習・実技時間管理システム、官公庁の予防接種LINE AIチャットの事例があり、一覧は導入事例にまとめています。

中小企業の方向けの進め方は中小企業向けのご案内、官公庁・自治体の方は官公庁・自治体向けのご案内をご覧ください。作りたいものの概算の目安を手元で確かめたい場合は、見積シミュレーターもご利用いただけます。

よくあるご質問

費用の規模感を先に知りたい方は、「業務システムの開発費用はいくらかかるのか｜規模別の目安と、金額が決まる仕組み」をあわせてご覧ください。

見積書の「保守」が何を指しているのかを分けて読む方法は業務システムの保守・運用は誰がやるのか｜納品後に止まらない体制の決め方に整理しています。