システム開発の見積書を前にして、高いのか安いのか判断できない。この相談は、とても多いです。
結論から言うと、合計金額を見ても妥当性は分かりません。見るべきは内訳と条件です。発注側の立場で見積書をレビューするときに、必ず確認している5項目をまとめました。
1. 「一式」の行がいくつあるか
「設計一式」「テスト一式」。この書き方の行は、何をどこまでやるのかが定義されていません。定義がないということは、あとで「それは含まれていません」が成立するということです。
一式の行が3つ以上あったら、内訳を依頼してください。出てこなければ、その見積はまだ比較の土俵に乗せられません。
2. 前提条件のページを読んだか
見積書の後ろのほうにある「前提条件」「前提事項」のページ。ここに金額より大事なことが書いてあります。
- 「データ移行は貴社作業とする」→ 移行の工数は自社持ち
- 「マスタ登録は含まない」→ 登録作業は自社持ち
- 「仕様変更は別途見積」→ 要件が固まっていないと膨らむ
前提条件に書かれた「貴社作業」を全部拾い出して、自社の工数を見積もってください。システム代金の外に、もう一つのコストが隠れています。
3. 保守費の中身
保守費は、比率を見る前に中身を確認してください。
- 障害対応の受付時間と、応答までの目安時間
- 軽微な改修が保守に含まれるか、都度見積か
- OSやミドルウェアのアップデート対応の有無
「保守費に何が含まれますか」の一問で、回答の解像度からベンダーの体制が見えます。初期費用より、こちらのほうが長く効いてきます。
4. 誰が作るのか
見積書には会社名しか書いてありませんが、実際に手を動かすのが自社のエンジニアなのか、協力会社なのかで、やり取りのスピードは大きく変わります。
あるアパレル小売様の支援でも、改修依頼がコンサル会社経由で開発元に流れていた構造を、開発元との直接交渉に切り替えたことで対応速度が改善した例があります。発注前に「開発体制図をください」と伝えるだけで確認できます。
5. 検収の条件
何をもって「完成」とするか。ここが曖昧なまま発注すると、納品直前に揉めます。
- 検収期間は何日あるか（短すぎると現場で試せない）
- 検収の基準は誰が書くか
- 検収後に見つかった不具合の扱い
実データでの突合テストを検収条件に入れられると、なお良いです。ある紙製品メーカー様の案件では、新旧ロジックの128項目の突合を検証に組み込み、全項目一致・数式エラー0件を確認してから運用に乗せました。
まとめ：金額の交渉より、条件の確認
値引き交渉は、しなくていいと思っています。無理に削った金額は、品質か保守のどちらかで必ず戻ってきます。
その代わり、上の5項目は必ず確認する。曖昧な行をなくしてから判を押す。それだけで、稼働後の「こんなはずじゃなかった」の大半は防げます。
株式会社nullkyotoは、発注する側の立場で、見積書・提案書・要件定義書のレビューを行っています。契約前のレビューは、単発でも承っています。判を押す前に、一度ご相談ください。
IT CONSULTING
コメント