ホーム/ インサイト/ システム開発の相見積もり比較|提案書の評価軸と「安い見積もり⁠」の読み方

システム開発の相見積もり比較|提案書の評価軸と「安い見積もり⁠」の読み方

RFPを出して複数社から提案が集まったあと⁠、多くの発注者が突き当たるのが「どう比べればいいのか分からない⁠」という問題です⁠。各社の提案書は構成も粒度もバラバラで⁠、見積金額は倍以上開くことも珍しくありません⁠。勝負は提案が届く前⁠、評価軸を決めた時点でほぼついています⁠。

評価軸はRFPを出す前に決めておく

大原則として⁠、評価軸は提案が届いてから考えるものではありません⁠。届いてから作ると「印象の良かった会社に合わせた軸⁠」ができてしまいます⁠。RFPに評価の観点を明記しておけば⁠、ベンダー側も的を絞った提案を出せます⁠。

標準的な評価軸の例(配点は目的に応じて調整⁠):

  • 要件理解度(25点⁠) — こちらの業務・課題を正しく理解しているか⁠。RFPの言葉をなぞっただけの提案は要注意
  • 実現方法の妥当性(20点⁠) — 技術選定の理由が説明されているか⁠。流行語の羅列ではないか
  • 体制と実績(20点⁠) — 実際に手を動かす人は誰か⁠。類似案件の実績はあるか
  • 価格(20点⁠) — 金額そのものより「内訳の透明性⁠」を評価する
  • 保守・運用(15点⁠) — 納品後の体制・費用・対応時間⁠。ここが空欄の提案は後で困ります

見積書で必ず確認する項目

確認項目見るポイント
前提条件「◯◯はお客様支給⁠」「△△は含まない⁠」の一覧⁠。ここが追加費用の火種です
工数の内訳設計・実装・テストの配分⁠。テストが1割未満の見積もりは品質リスクあり
体制単価誰が(PM/シニア/ジュニア⁠)何人月か⁠。総額だけの一式見積もりは比較不能
検収条件何をもって完成とするか⁠。曖昧なままだと検収でもめます
変更管理要件変更時の扱い⁠。単価と手続きが書いてあるか
保守費用月額と対応範囲⁠。初年度無償でも2年目以降の金額を確認

「安い見積もり⁠」に潜む3つのパターン

1. スコープを狭く読んでいる

RFPの曖昧な箇所を最小解釈で見積もると金額は下がります⁠。契約後に「それは含まれていません⁠」が始まるパターンで⁠、最終的な総額は高い方の見積もりを超えることがよくあります⁠。曖昧さはRFP側の責任でもあるため⁠、発注前に質疑で潰しておくのが防御策です⁠。

2. 若手中心の体制で単価を下げている

単価の安さは体制表に表れます⁠。設計をリードする経験者が誰か⁠、その人は何%この案件に入るのかを必ず確認してください⁠。

3. 戦略的な赤字受注

初回案件を安く取り⁠、保守や追加開発で回収するモデルです⁠。それ自体は悪ではありませんが⁠、保守の単価と拘束条件(他社に引き継げるか⁠、ソースコードとドキュメントは納品されるか⁠)を契約前に確認する必要があります⁠。

質疑応答は「無料の実力テスト⁠」

提案前の質疑応答(Q&A⁠)は⁠、ベンダーの実力が最もよく見える場面です⁠。質問の質が高い会社は⁠、業務を理解しようとしている会社です⁠。逆に⁠、質問がゼロのままRFP通りの提案を出してくる会社は⁠、契約後に認識齟齬が噴き出すリスクが高いと考えてください⁠。

まとめ|比較できる状態を作るのが発注者の仕事

相見積もりの成否は⁠、提案が届く前⁠、つまりRFPの品質と評価軸の設計でほぼ決まっています⁠。シャノンでは⁠、開発会社としての相場観をもとに⁠、評価軸の設計・見積もりの妥当性チェック・ベンダーへの技術的な質疑対応を発注者側でお手伝いしています⁠。自社が候補に入る場合は評価から外れる形を取るので⁠、中立的なセカンドオピニオンとしてもご利用いただけます⁠。

ご相談・お問い合わせ

お問い合わせをいただいてから⁠、営業日2日以内にご返信いたします⁠。