システム開発の見積もりで目指すのは、正しい金額を1回で当てることではありません。顧客が中身を見て納得し、「この内容は自分たちで選んだ」と思える状態を作ることです。明細を細かく砕くことも、松竹梅の3案を並べることも、提示後にすり合わせて出し直すことも、その状態にたどり着くための手段です。この記事では、金額の積み上げ方から、明細・松竹梅・すり合わせの進め方までを順に説明します。

合計金額1行の見積もりが通らない理由

「システム構築一式 2,000万円」という見積もりを受け取った顧客は、「高い」か「安い」かしか言えません。どこを減らせば予算に収まるのか、どれが必須でどれが後回しにできるのかを判断する材料がないからです。社内の稟議で比較資料を作ることもできず、多くの場合そこで話が止まります。

見積もりを作るたびに、次の問いを自分に向けてください。

この明細を見て、顧客は選べるか?

金額は業務フローの「量」から積み上げる

「この明細はなぜこの金額なのか」と聞かれて答えられない見積もりは、顧客にも社内にも説明できません。勘ではなく、業務フローから数えられる量(ドライバー)をもとに積み上げます。ASISとTOBEの業務フローを描いた時点で、見積もりの材料はほぼ揃っています。

数える対象の例は次のとおりです。

数えるもの 業務フローのどこを見るか 見落とすと起きること
ロール数×データの種類 レーンの数と、扱うテーブルの数 権限ごとの画面・テストが抜ける
外部システム連携 他システムとやりとりする矢印 同期や再送の例外処理が抜ける
帳票の入出力 取り込む書類、作る書類、現場のExcelシート 帳票ごとのレイアウト調整が抜ける
ロールをまたぐ処理 別のレーンへ渡る矢印 差戻し・通知・権限制御が抜ける
バッチ・非同期処理 定期実行や、時間のかかるAI処理 ジョブ管理や再実行の仕組みが抜ける

量が同じでも、関わる開発会社の数、使えるインフラの制約、連携先の仕様書の質によって工数は変わります。また、開発費とは別に、操作説明や運用ルールづくりなど現場への導入にかかる費用も別枠で見ておきます。

積み上げで総額の目安が立ったら、次はそれを顧客が選べる形に割り直します。

STEP1:明細を顧客が判断できる粒度に砕く

明細の粒度は、顧客が「これは要る/要らない」を本気で議論できる大きさにします。数千万円規模の案件なら、1明細あたり数十万〜数百万円程度が扱いやすい目安です。小さすぎる明細は誤差として扱われ、議論の対象になりません。大きすぎる明細は「丸ごと残すか、丸ごと捨てるか」の二択になり、部分的に減らす相談ができません。

明細を切り出したら、1つずつ次の3点を確認します。

  1. 粒度が揃っているか(極端に小さい・大きい明細がないか)
  2. 売上を増やすか、業務工数を減らすか、どちらの価値につながるかを説明できるか
  3. 必須とオプションの境目を顧客に説明できるか

2つ目で説明できない明細は、顧客から「なぜ必要か」と聞かれた時点で削減候補になります。

「一式」と「インフラ一括」を避ける

「〇〇機能一式」「インフラ・運用一式」は出す側には便利ですが、顧客から中身が見えません。特にインフラは、クラウド利用料・サーバ構築・ライセンス・監視・バックアップに分けて書くと、「ライセンスを年間契約にする」「監視は社内で行う」といった現実的な調整が議論に乗ります。初年度と2年目以降で分けて書くのも有効です。

STEP2:松竹梅で選択肢を並べる

松竹梅は、高い案を選ばせるための営業テクニックではありません。顧客が予算や時期に合わせて範囲を調整できるよう、選択肢を渡すために作ります。

  • 梅:業務が回る最小構成
  • 竹:必須機能に、効果の大きいオプションを加えた構成
  • 松:課題をすべて埋める理想の構成

案件の性質によって、組み方は使い分けます。

組み方 向いている案件 並べ方
機能網羅型 機能の範囲が論点になる案件 必須のみ/必須+主要オプション/全機能
オプション積み上げ型 予算の上限がはっきりしている案件 梅を土台に、オプション一覧から顧客が選ぶ
カバレッジ型 拠点数や部署数で規模が変わる案件 本社のみ/主要拠点/全拠点

注意したいのは、竹と梅も実際に運用できる構成にすることです。明らかに使えない梅を並べると、顧客は「松を選ばせたいだけだ」と見抜き、見積もり全体が信用されなくなります。

実例:顧客向けポータルの見積もり

問い合わせ受付と契約情報の閲覧ができる顧客ポータルを例に、12明細を切り出してみます(金額は説明用の例です)。

# 明細 金額 区分
1 要件定義 200万円 必須
2 ログイン・権限管理 150万円 必須
3 顧客・契約マスタ 200万円 必須
4 問い合わせ受付画面 250万円 必須
5 社内の対応管理画面 250万円 必須
6 テスト・データ移行・操作説明 250万円 必須
7 よくある質問の検索 120万円 オプション
8 メール通知 80万円 オプション
9 契約書PDFのダウンロード 150万円 オプション
10 スマートフォン対応 180万円 オプション
11 基幹システム連携 300万円 オプション
12 利用状況レポート 120万円 オプション

これを機能網羅型の松竹梅にすると次のようになります。

案 内容 総額
梅 必須の6明細 1,300万円
竹 梅+よくある質問・メール通知・契約書PDF 1,650万円
松 全12明細 2,250万円

梅と竹の差350万円は「問い合わせ件数そのものを減らす機能」の対価、竹と松の差600万円は「利用場面の拡張と社内システムとのつながり」の対価だと説明できます。差額の意味を言葉にできることが、顧客の納得につながります。

STEP3:提示はすり合わせの始まりとして行う

見積もりは、出した瞬間に決裁されるものではありません。提示の場は、顧客の優先順位を聞き出すための場です。3案を並べ、推奨案があれば理由を添えて伝えたうえで、選ぶのは顧客だという姿勢で渡します。

その場で次の3つを質問します。

  1. 予算の上限から削っていくか、必要な機能から固めて予算に合わせるか
  2. まず業務が回ればよいか、操作性まで磨きたいか
  3. 今期の予算に収める必要があるか、一部を来期に回せるか

たとえば「予算1,600万円に収めたい」と言われたら、竹から50万円を減らす選択肢を複数持っていきます。メール通知を外す、よくある質問の検索を次フェーズに回す、といった案です。そのとき、要件定義やテストを削る、単価を一律で値引くといった減らし方は避けます。前者は品質のリスクを顧客に押しつけることになり、後者は明細の意味をなくしてしまいます。減らすのは、あとから足せる軽い機能からです。

STEP4:差分を見える形にして出し直す

すり合わせで決まった内容は、出し直しの見積もりに反映します。その際、合計金額だけでなく差分を書きます。

明細 前回 今回 理由
メール通知 80万円 0円 画面上の新着表示で代替できるため次フェーズへ
よくある質問の検索 120万円 120万円 問い合わせ件数の削減に直結するため維持
契約書PDF 150万円 150万円 顧客からの依頼が多いため維持

「ご要望により減額」とだけ書くと、半年後に「なぜこの金額だったか」を誰も説明できなくなります。差分の表があれば、顧客は社内の決裁でも削減の根拠を説明できます。

1回の提示で顧客が選び切れることは多くありません。出し直しを前提に、最初からすり合わせの時間をスケジュールに組み込んでおきます。

よくある失敗

  • 一式で出す:顧客がどこを減らせるか判断できず、比較資料も作れない
  • 単価を下げて競合に合わせる:範囲は同じまま価格だけ下げ、工数が足りなくなって品質が落ちる。価格を下げるなら範囲で調整する
  • 1案だけ出す:「予算オーバー」と言われた時点で話が止まる
  • 優先順位を聞かずに松竹梅を作る:現場にとって必須の機能が竹に入っておらず、作り直しになる
  • 松だけ豪華にする:見せかけの選択肢だと受け取られ、信頼を失う
  • 削った根拠を残さない:「入っていたはず」「入っていなかった」の食い違いが後で起きる
  • 追加の相談を断る:「もう出した見積もりなので」と返すと、次からは声がかからなくなる

この記事のまとめ

  • 見積もりのゴールは、顧客が納得して「自分で選んだ」と思える状態を作ること
  • 金額は業務フローから数えられる量をもとに積み上げ、説明できる根拠を持つ
  • 明細は顧客が議論できる粒度に砕き、「一式」「インフラ一括」を避ける
  • 松竹梅は選択肢を渡すために作り、竹も梅も運用できる構成にする
  • 提示の場では優先順位を質問し、減らすならあとから足せる機能から減らす
  • 出し直しでは差分と理由を表にし、反復する前提で段取りを組む

見積もりは、ロードマップのStep 5「決める」で要件定義と並んで扱うスキルです。前提となる現状と理想の差の整理はヒアリングの記事にまとめています。落とし穴パターン集や演習付きで学ぶなら、FDEガイドの見積もりのやり方を参照してください。スライド・演習問題・テストはlecture.iplot.jpで取り組めます。概算の当たりをつけたいときは、無料ツールの楽々見積もりも使えます。