システム開発の見積もりは妥当？発注前に確認する5項目と判断手順

システム開発やAI導入の提案を受けて、見積書が出てきた。金額は500万円。高いのか安いのか、この機能にこの金額が妥当なのか、社内では誰も判断できない。——中小企業で頻繁に起きる場面だ。エンジニアがいないから判断できない、と思われがちだが、原因はもう少し構造的なところにある。この記事では、なぜ判断できないのか、何を見れば判断に近づくのか、外部の目を使うならどう使うのかを整理する。

判断できない本当の理由

技術知識がないから判断できない、というのは半分しか合っていない。より本質的な理由は提案側と発注側で持っている情報の量が違いすぎることにある。

提案する側は、その要件を実現するのに何人が何か月かかるかを知っている。どこが難しくてどこが簡単かも分かっている。発注側は、その情報を持たないまま金額の妥当性を判断するよう求められる。これは知識の差ではなく、立場の差だ。だから勉強しても埋まらない。

加えて、見積書だけでは「何が含まれないか」が読み取れないことがある。要件定義、移行、受入支援、運用準備などの扱いが案件ごとに違うためだ。意図を決めつけず、対象外と前提を質問票にして確認する必要がある。

相見積もりでは解決しない

3社に声をかけて、300万・500万・800万と出てきたとする。真ん中を選べばいい、とはならない。各社が想定している範囲が違うからだ。

開発工程ごとの内訳と、予算を決める前の整理手順は「アプリの開発費用はどう決まる？見積内訳と予算を決める5ステップ」で詳しく解説している。

• 300万の会社は、要件定義は発注側がやる前提かもしれない
• 500万の会社は、テストとマニュアルを含んでいるかもしれない
• 800万の会社は、1年間の保守と障害対応を含んでいるかもしれない

この状態で金額だけを比べると、一番安いところを選んだ結果、後から追加費用が積み上がって最終的に一番高くなるということが起きる。相見積もりが意味を持つのは、前提を揃えてからだ。

見積書で確認する5つの観点

1｜含まれないことが書かれているか

最初に見るのはここ。要件定義・設計・テスト・データ移行・マニュアル作成・操作研修・保守運用。これらが含まれるのか、含まれないのかを一つずつ確認する。書かれていなければ、書いてもらう。

この作業をするだけで、300万と800万の差の大半が説明できることが多い。

2｜工数の内訳があるか

「一式500万円」では判断のしようがない。機能ごと・工程ごとに人日や人月が出ているか。内訳を出せない見積もりは、根拠が薄いか、出したくない理由があるかのどちらか。

内訳が出てきたら、極端に重い項目に理由を聞く。納得できる説明が返ってくるかどうかで、相手の理解度も分かる。

3｜追加費用が発生する条件が明記されているか

仕様変更が起きたとき、どこからが追加費用になるのか。この線引きが曖昧なまま契約すると、進行中に揉める。「軽微な変更は無償」の"軽微"が定義されているかを見る。

4｜納品後の保守条件

作って終わりではない。不具合が出たときの対応期間、対応時間帯、費用。そして保守を頼まない選択をしたとき、自社で直せる状態になっているか。ソースコードと資料が手元に残るかは必ず確認する。

5｜成果物の権利がどちらに残るか

作ったシステムの著作権、利用許諾、ソースコードや設計書の引渡し条件を確認する。著作権が受注側に残っていても、契約上の利用・改変・再委託の許諾があれば別会社へ保守を頼める場合がある。反対に、権利が発注側へ移っても、資料や環境情報が渡されなければ引継ぎは難しい。権利帰属だけでなく、実際に移管できる条件をセットで見る。

見積もりの妥当性を判断する比較表

各社の総額を横に並べる前に、次の7行を同じ質問で埋める。空欄がある会社は失格という意味ではない。未確定事項を誰が、いつ、どの費用で決めるかを見えるようにするための表だ。

契約前に止まって確認する赤信号

• 「開発一式」だけで、工程・成果物・対象外が分からない
• 要件の未決事項が多いのに、変更手順と再見積条件がない
• 検収条件が「問題なく動くこと」など抽象的なまま
• データ移行の件数・品質・照合責任が決まっていない
• 公開後の障害窓口、対応時間、保守終了時の移管条件がない

赤信号が1つあっても直ちに不適切な提案とは限らない。回答を文書で追加し、金額と責任分界へ反映できるかを確認する。

それでも残る「実現方法が妥当か」の問題

上の5つは、発注側だけでも確認できる。一方で確認できないことが残る。

• そもそもこの作り方が適切か。もっと簡単な方法はないか
• 既製のサービスを使えば済む話ではないか
• 提案されている技術は、5年後も保守できるものか
• この規模の会社が、これを持ち続けられるか

これらは技術の中身が分からないと判断できない。しかも提案側に聞いても、自社の提案を否定する答えは返ってきにくい。ここが外部の目を入れる価値のある領域になる。

セカンドオピニオンの使い方

タイミングは「契約前」

提案書と見積書を受け取った後、発注を決める前。契約後だと、指摘が出ても条件を変えにくい。着手後ならなおさらで、止めると違約金の話になる。

渡す資料は4点

1. 提案書
2. 見積書（内訳があるもの）
3. 要件のメモ（何を実現したいか。箇条書きで十分）
4. 既存システムの情報（今何を使っているか、連携が必要か）

この4点は最終判断に十分という意味ではなく、確認を始めるための入口だ。まず不足資料、未決事項、ベンダーへ返す質問を洗い出し、必要に応じて業務フロー、データ件数、契約案、非機能要件を追加する。

聞くのは「妥当か」ではなく「どこが判断の分かれ目か」

「この見積もりは妥当ですか」と聞くと、答える側も断定しにくい。実務で有効なのは、「この提案で、後から問題になりそうなのはどこか」「削れる範囲はどこか」「聞き返すべき質問は何か」と聞くこと。そのまま相手への質問に使える形で返ってくる。

ベンダーとの関係を壊さないために

セカンドオピニオンを取ることを、相手を疑う行為だと感じる必要はない。むしろ質問の質が上がることで、相手も提案しやすくなることが多い。

伝え方としては「社内で判断材料を整理したいので、いくつか確認させてください」で十分。第三者に見せたことを言う必要もない。返ってきた質問に丁寧に答える会社かどうかで、その後の付き合い方も見えてくる。

まとめ

見積もりが判断できないのは、知識が足りないからではなく情報の量が対等でないから。だから勉強で埋めようとせず、確認する項目を決めて聞き返すほうが早い。「含まれないこと」から見る。相見積もりは前提を揃えてから。そして実現方法の妥当性だけは、外の技術者の目を借りる価値がある。