システム開発の見積り、金額だけ見てませんか？発注前に見る5項目

システム開発の見積書をもらったとき、最初に見るのは金額だと思います。

自分でも見ます。100万円なのか、30万円なのか。予算に入るかどうかは当然大事です。

ただ、SEとして15年やってきて、ココナラでも販売実績270件まで対応してきた中で、見積書を見るときに一番怖いのは「高い金額」ではなくなりました。

本当に怖いのは、何が入っていて、何が入っていないのか分からない見積りです。

はい。

30万円だから安い、100万円だから高い。そこだけで決めると普通に危ないんですよね。

100万円でも、要件・テスト・本番反映・データ移行・納品後の対応まで含まれていれば判断しやすいです。逆に30万円でも、「開発一式」の4文字だけで中身が見えなければ、あとから追加費用が積み上がる可能性があります。

自分は開発する側なので、これは発注者だけの問題ではありません。

以前は自分も「このくらいなら入れておこう」と軽く考えて、見積りの範囲を広く取りすぎたことがあります。結果、細かな追加修正が重なって、当初想定より作業が増える。価格はそのまま。自分で首を絞めるやつです（何度かやりました）。

それ以来、見積りでは金額より先に「境界線」を見るようになりました。

発注する側でも、ここを見るだけでかなり事故を減らせます。

■ 1　「どこまで作るか」ではなく「どこまで含むか」

たとえば、見積書に「管理画面作成」と書いてあったとします。

この一文だけだと、実はほとんど分かりません。

ログインはあるのか。

管理者と一般ユーザーで権限を分けるのか。

一覧表示だけなのか、検索や絞り込みまであるのか。

CSV出力はあるのか。

スマホ対応は含むのか。

削除したデータを戻せるのか。

全部「管理画面」の中に見えますが、作る側からすると別の作業です。

PDF出力も同じです。

「PDFを出したい」だけなら簡単そうに聞こえます。でも、帳票レイアウト固定、複数ページ、添付資料の連結、ファイル名ルール、保存先、印刷時の余白まで入ると一気に話が変わります。

見積りを見るときは、機能名より「その機能の終点」を確認した方がいいです。

■ 2　前提条件が書かれているか

見積り金額は、前提条件が変わるとかなり変わります。

既存データがきれいに揃っている前提なのか。

古いExcelやCSVの取り込みまで含むのか。

利用者は1人なのか20人なのか。

Windowsだけなのか、Macやスマホも対象なのか。

外部サービスとの連携はすでに使える状態なのか。

自分が実案件でよく確認するのも、この部分です。

最初は「Excelを直したい」という相談でも、実際に見ると複数ファイルに分かれていたり、入力ルールが人によって違ったりします。そこを見ずに金額を決めると、後半がクッッッソしんどくなります。

前提条件は、細かい注意書きではありません。

見積金額を成立させている土台です。

■ 3　例外処理と実際の運用が入っているか

システムは正常なデータだけで動けばいいわけではありません。

空欄だったらどうするか。

同じ番号が入ったらどうするか。

確定後に修正したくなったらどうするか。

担当者が退職したらどうするか。

月をまたいだデータはどう扱うか。

このあたりは仕様書の最初には出にくいんですよね。

実際に使う人の頭の中にはあるけど、依頼文には書かれていない。

自分も案件を進めるとき、想定外データや入力揺れを確認することがあります。半角と全角、空欄、重複、列のズレなど、「そんな入力する？」というものほど本番では入ります。

システムは人間が使います。

そして人間は、きれいに入力してくれるとは限りません。自分も含めてです。

■ 4　追加費用になる条件が決まっているか

ここは発注前に絶対見ておきたいです。

「軽微な修正は何回まで」

「仕様変更は別見積り」

「外部サービスの仕様変更は対象外」

「納品後○日間は不具合対応」

こういうルールがあるかどうかです。

特に注意したいのが、「修正」と「仕様変更」が同じ言葉で扱われているケースです。

ボタンを押したらエラーになる。これは不具合です。

当初1人承認だったものを、3人承認に変えたい。これは仕様変更です。

見た目はどちらも「直してほしい」ですが、開発側の作業量は全然違います。

自分も昔はここを曖昧にして、無料で受けすぎたことがあります。

最初は「これくらいなら」と思うんですよ。でも、それが3回、5回と続くと普通に終わります。

今は追加対応になるものは、できるだけ別見積りとして切り分けるようにしています。お互いにその方が分かりやすいです。

■ 5　納品後の状態まで書かれているか

システムは納品日で人生を終えません。

むしろ、そこから使い始めます。

ソースコードは渡されるのか。

設定ファイルはあるのか。

操作方法は残るのか。

不具合が出た場合の対応期間はあるのか。

外部サービスの仕様が変わったらどうするのか。

業務で使うシステムほど、運用後に「ここをもう少し変えたい」が出ます。

それ自体は悪いことではありません。使ったから分かる改善点です。

ただ、そのときに誰へ頼めるのか、いくらかかるのか、元のデータやソースを引き継げるのかが分からないと、後で困ります。

■ 2社の見積りを比べるなら、総額ではなく条件を横に並べる

もし複数社から見積りを取っているなら、金額だけを縦に並べるのではなく、次を横に並べてみてください。

・対象機能

・対象外の機能

・データ移行

・テスト

・本番反映

・スマホ対応

・マニュアル

・保守

・仕様変更時の扱い

これをやると、「A社は80万円、B社は120万円」という比較から、「A社にはデータ移行と保守が入っていない」という比較に変わります。

ここまで見て初めて、金額の妥当性が見えてきます。

■ 発注者が技術を全部理解する必要はありません

よくあるのが、「自分はITに詳しくないから判断できない」という状態です。

でも、PythonなのかJavaなのか、データベースが何なのかを全部覚える必要はありません。

発注者が確認したいのは、技術そのものより、何ができて、何ができなくて、どこから追加になるかです。

自分はSEとして15年、ココナラでも小さなExcel修正からWebシステムまで幅広く対応してきました。

その中で強く感じるのは、開発の失敗はコードを書く前から始まっている、ということです。

仕様が曖昧なまま始める。

完成条件が決まっていない。

変更時のルールがない。

ここがズレると、技術力が高くても揉めます。

逆に、最初の境界線が見えていれば、多少の変更が出ても話し合えます。

見積書や提案書を受け取ったものの、「このまま発注していいのか分からない」という方向けに、第三者目線で内容を確認するサービスも出しています。

金額だけではなく、要件の抜け、追加費用のリスク、確認しておいた方がいい質問まで整理します。

■ 発注前に10分だけやってほしいこと

ここまで読むと、確認項目が多くて面倒に見えるかもしれません。

でも、発注前に全部を仕様書へ書き起こす必要はないです。

自分なら、まず紙でもメモでもいいので、

・今回絶対に必要なこと

・できれば欲しいこと

・今回はやらなくていいこと

この3つに分けます。

それだけで見積書の読み方が変わります。

「この機能は絶対必要なのに入っていない」「これは今回はなくてもいいのに含まれている」が見えやすくなるからです。

もう一つ、現在使っているExcelやCSV、紙の帳票、画面キャプチャがあるなら、発注前に見せた方がいいです。文章で「こんな感じです」と説明するより、現物1枚の方が伝わることがあります。

自分も相談を受けるとき、元データが見られる案件は判断が早いです。列数、入力の揺れ、ファイル構成、現在の運用が見えるので、必要な処理を具体化できます。

発注前の10分で全部解決するわけではありません。ただ、ここを飛ばして開発後に何時間も修正するよりは、かなり安い10分です。

システム開発の見積りチェックはこちら

#システム開発

#見積り

#IT相談

#業務改善