複数の開発会社から提案書が届いたものの、構成も用語も金額の出し方も各社バラバラで、どれが良いのか自分でも判断できない。しかも「なぜこの会社なのか」を、経営層や関係部署に説明しなければならない。そんな状況で手が止まってしまう方は少なくありません。
「提案書が各社バラバラで、どれが良いのか社内に説明できない…」
先に結論をお伝えします。提案書の出来栄えを直接比べようとすると、必ず行き詰まります。 代わりに、発注者側で「比較シート」を1枚作り、各社の提案書の中身をそのシートの同じ欄に書き写して比べてください。見た目の良さや資料の厚さではなく、「同じ質問に、各社がどう答えているか」を並べるのがコツです。
この記事では、提案書がバラバラになる理由、比較シートの作り方、評価の5つの軸、社内に説明するときの伝え方を、そのまま使える質問例とチェックリストと一緒に整理します。
提案書が各社バラバラになる3つの理由
比べにくいのは、開発会社の提案力が低いからとは限りません。多くの場合、次のような構造的な理由があります。
理由1：依頼の条件が各社に同じ形で伝わっていない
口頭の相談や、簡単なメールだけで依頼すると、各社は自社の理解で足りない情報を補って提案します。ある会社は「既存システムとの連携あり」と読み、別の会社は「連携なし」と読めば、金額も範囲も変わって当然です。
理由2：提案書に決まった書式がない
提案書は、開発会社ごとに得意な見せ方があります。画面イメージを厚く書く会社、体制とスケジュールを細かく書く会社、金額を一式でまとめる会社など、強調する場所が違うため、並べても同じ項目で比較できません。
理由3：前提条件が小さな文字で書かれている
「データ移行は含まない」「画面数は10画面まで」「テスト環境は別途」といった前提は、提案書の隅に書かれていることがよくあります。この前提がそろっていないと、金額だけを見て比べても意味がありません。見積もりの差の見方は、相見積もりの正しい比べ方でも詳しく整理しています。
比較シートの作り方（4ステップ）
比較シートとは、各社の提案を同じ項目に並べ直すための、発注者側の1枚の表です。表計算ソフトで十分です。
ステップ1：自社の「譲れない条件」を先に決める
提案書を読む前に、次の3つを書き出します。これが物差しになります。
- 必須の機能と、あれば嬉しい機能（RFP＝提案依頼書にまとめてあれば、それを使う。書き方はRFPの書き方を参照）
- 予算の上限と、いつまでに使い始めたいか
- 運用開始後に自社で担当できること（問い合わせ対応、データ更新など）
ステップ2：比較する項目を決める
次の表を縦軸にして、各社を横に並べます。
| 項目 | 見るポイント |
|---|---|
| 要望の理解 | 自社の課題・目的が、自社の言葉で書き直されているか |
| 作る範囲 | 含まれる機能・含まれない機能、画面数・帳票数、データ移行の有無 |
| 進め方と体制 | 工程、打ち合わせの頻度、担当者の役割、スケジュール |
| 金額と内訳 | 工程別・項目別の内訳か、追加費用が出る条件が書かれているか |
| 公開後の運用・保守 | 保守の範囲、障害時の連絡と対応時間、費用 |
| 前提条件・リスク | 提案書に書かれた前提、確認が必要な点、リスクへの考え方 |
ステップ3：提案書の内容を、そのままの言葉で書き写す
この段階では良し悪しの判断をしません。各社の提案書から該当する記述を拾い、書かれていない欄は「記載なし」と入れます。「記載なし」が多い会社は、悪い会社ではなく、「確認が必要な会社」です。
ステップ4：「記載なし」と「判断できない」を質問に変える
空欄は、開発会社への質問リストになります。同じ質問を全社に同じ文面で送ると、回答が同じ条件でそろい、比べやすくなります。質問のしかたは、のちほどの質問例を使ってください。
提案書を評価する5つの軸
比較シートがそろったら、次の5つの軸で見ていきます。点数は「◎・○・△・×」程度の粗いもので十分です。
軸1：自社の課題を正しく理解しているか
良い提案書は、依頼文のコピーではなく、課題の背景や目的を言い換えて確認しています。「御社の課題は〜だと理解しました。この理解で合っていますか」と書かれていれば、分かろうとしている姿勢が見えます。
軸2：範囲と前提が明確か
「何を作り、何を作らないか」が具体的に書かれている提案は、後から追加費用でもめにくくなります。逆に「一式」の記載が多いときは、内訳の確認が必要です。
軸3：進め方と体制が現実的か
担当者の顔ぶれや、打ち合わせの頻度が書かれているかを見ます。発注者側にどのような作業（資料の提供、確認の期限）が必要かまで書かれていれば、現場を知っている会社である可能性が高いといえます。
軸4：金額の根拠が説明されているか
金額の安さより、根拠が説明できるかが大切です。安い見積もりは範囲が狭い場合があり、高い見積もりは余裕を持たせている場合があります。どちらも、理由を質問して確認しましょう。
軸5：作ったあとの運用まで考えているか
システムは公開してからが本番です。性能・止まったときの復旧・セキュリティなどの「運用面の要求」（非機能要求）は、発注者と開発会社で認識がずれやすい部分として、IPAも整理のためのツールを公開しています（2023年8月時点の掲載内容）。
📰 出典：IPA「非機能要求グレード」
提案書では、保守の範囲、障害時の連絡方法、担当者が変わったときの引き継ぎなど、公開後の話に触れているかを確認します。
なお、軸の重みづけは案件によって違います。たとえば急ぎの案件なら「進め方と体制」を、長く使う基幹システムなら「運用・保守」を重くみる、といった調整をしてください。重みは提案書を読む前に決めておくと、見た目の印象に引きずられません。
社内に説明するときの伝え方
比較シートができれば、社内への説明は「なぜこの会社か」を3点で話せば足ります。
- 決め方：同じ条件・同じ項目で各社を比べたこと（比較シートを見せる）
- 決め手：自社が重視する軸（例：運用体制）で、どこが優れていたか
- 残るリスクと対策：選んだ会社にも未確認の点や弱い点があること、それをどう確認・対策するか
「全部が最高の会社はない」と最初に伝えておくと、リスクを隠している印象を避けられます。また、決定は価格の順位だけでなく、重視する軸の評価と説明できる理由で行ったと記録に残しておくと、後から経緯を振り返れます。
やりがちな失敗
- 金額だけで1位を決める：範囲や前提が違うまま比べると、後から追加費用が出やすくなります。
- 見栄えの良い資料に引っ張られる：画面イメージが美しくても、運用や体制が書かれていなければ判断材料が足りません。
- 担当者の印象だけで決める：話しやすさは大切ですが、体制や契約の中身と合わせて見ましょう。
- 質問が各社でバラバラ：会社ごとに違う質問をすると、回答の差が会社の差なのか質問の差なのか分からなくなります。
また、技術やフレームワークの提案が会社ごとに違う場合の見方は、フレームワーク提案の比べ方に整理しています。
発注者がやること チェックリスト
- ☐ 提案書を読む前に、必須条件・予算・時期・運用で自社が担当できることを書き出した
- ☐ 比較シートの項目（要望の理解・範囲・進め方・金額・運用・前提）を決めた
- ☐ 各社の提案書の記述を、評価せずにそのまま書き写した
- ☐ 空欄（記載なし）を、全社共通の質問リストにまとめた
- ☐ 評価の軸の重みを、提案書を読む前に決めた
- ☐ 社内向けに、決め方・決め手・残るリスクの3点で説明資料を作った
開発会社への質問例
「御社の提案書にある『一式』の内訳（機能・画面・工程別）を教えていただけますか？」
「今回の見積もりに含まれていないものと、追加費用が発生しやすい条件を教えてください。」
「前提条件として書かれている項目のうち、私たちが決めたり用意したりする必要があるものと、その期限を教えてください。」
「公開後の保守の範囲と、障害が起きたときの連絡方法・対応時間を教えてください。」
「担当される方の役割と、打ち合わせの頻度、私たちが確認にかける時間の目安を教えてください。」
まとめ
- 提案書が各社バラバラなのは、依頼条件・書式・前提の書き方が違うことが主な原因
- 提案書を直接比べず、発注者側の「比較シート」に同じ項目で書き写して比べる
- 評価は「課題の理解・範囲と前提・進め方と体制・金額の根拠・運用」の5軸で、重みは先に決める
- 社内には「決め方・決め手・残るリスク」の3点で説明する
提案書を比べる作業は、実は自社が何を重視するかを言葉にする作業でもあります。比較シートを1枚作るだけで、打ち合わせでの質問も、社内への説明もぐっと楽になります。
あわせて読みたい関連記事
