RFPを何社かに配って、提案書と見積書が返ってきた。ここからが本番なのですが、いざ束を前にすると手が止まります。金額は違う、ページ数も違う、書いてあることも微妙に違う。どこから読めばいいのか分からない、という声をよく聞きます。

提案書の読み方は、実は決まっています。読む場所は、見積の内訳、体制に載る人、前提条件、除外事項の4か所です。この順番で読むと、金額の差がどこから来ているのかが見えてきます。逆に金額から入ると、安いほうが良さそうに見えて判断を誤ります。

この記事では、そもそも提案書に何が書かれているのかを章立てから確認したうえで、届いた提案書のどこを読むか、複数社をどの順番で読み比べるかを整理します。提案書を作る側の書き方ではなく、受け取る側の読み方の話です。

この記事のポイント

  1. 提案書を読む場所は見積の内訳・体制・前提条件・除外事項の4か所
  2. 金額差の理由は「やること」より「やらないこと」の欄に書いてある
  3. 前提条件に並ぶのは自社がやる作業で、そこが隠れた工数になる
  4. 読む順番は前提条件から。金額から入ると判断を誤る
目次
  1. システム開発の提案書に何が書かれているか
  2. 提案書はRFPへの回答として届く
  3. 提案書に入っている章立て
  4. 見積の内訳がどこまで割れているか
  5. 体制図に載っている人が本当に入るか
  6. システム開発の提案書を読み比べるときの観点
  7. 前提条件に書かれた「発注側がやること」
  8. 除外事項は「書かれていない作業」を読む欄
  9. 危険サインになる4つの表現
  10. 提案書を読み比べる順番
  11. 総括:システム開発の提案書は前提と除外から読む

システム開発の提案書に何が書かれているか

厚みのある提案書の冊子を開き、章立てのページを指で追って中身を確かめている場面
まず提案書に何の章があるかを押さえると、比べる場所が決まります

読み方の前に、書類そのものの中身を確認しておきます。提案書は会社によって体裁が違いますが、入っている章はだいたい共通しています。

提案書はRFPへの回答として届く

提案書は、発注側が出したRFP(提案依頼書)に対する回答です。ですから提案書を読むという作業は、自分たちが出した問いに対して、相手がどう答えたかを確かめる作業になります。RFPで聞いていないことは、当然どの提案書にも書かれていません。

ここが最初の分かれ目です。RFPが曖昧だと提案書も曖昧になり、比較ができない束が返ってきます。逆にRFPで前提や範囲をはっきり示していれば、各社の差がそのまま提案書に出ます。RFPの書き方や章立てそのものはRFPテンプレートの項目と章別のサンプルで扱っているので、これから配る段階の方はそちらを先に見てください。

もう1つ、届き方も見ておきます。提案書と見積書が一体になっているか、別紙で来るかで読む順番が変わります。別紙の場合、提案書の本文には「やります」と書いてあるのに、見積書の費目には載っていない作業が出てくることがあります。私の感覚では、この本文と費目のズレは意外と多いです。

提案書に入っている章立て

一般的な章立てと、それぞれの章で発注側が見る点を並べておきます。「提案書のサンプルが見たい」という場合、探しているのはこの一覧だと思います。

書かれること 発注側が見る点
提案概要 提案の全体像と狙い 自社の言葉で書かれているか、汎用文でないか
課題認識 発注側の課題をどう理解したか RFPの写しではなく、独自の指摘があるか
システム構成 方式・構成図・使う技術 既存システムとの接続がどう書かれているか
機能一覧 作る機能の一覧と概要 RFPの要求と1対1で対応しているか
スケジュール 工程と期間、マイルストーン 受入テストと自社の確認期間が入っているか
体制 担当者と役割、体制図 肩書きだけでなく稼働率が書かれているか
見積 費目と金額、工数 工程別に割れているか、一式が多くないか
前提条件・除外事項 提案が成り立つ条件と、やらないこと ここが最重要。後述します

章の数が多いか少ないかは、提案の質とあまり関係ありません。ページ数が厚い提案書が丁寧とも限らず、会社紹介と実績で半分埋まっていることもあります。見るのは厚みではなく、上の右列です。

見積の内訳がどこまで割れているか

見積の章で最初に確かめるのは、金額そのものではなく粒度です。要件定義・設計・実装・テストといった工程別に割れているか、それぞれに人月と単価が書かれているか。ここが「システム開発一式」でまとまっていると、比較の材料になりません。

粒度が粗いこと自体は、必ずしも手抜きではありません。ただ、割れていないというのは、作る範囲がまだ決まっていないという意味でもあります。決まっていない部分は、後から追加費用の相談になります。だから粒度の粗さは、そのまま追加費用のリスクの大きさだと考えたほうが安全です。

粒度の違いは、並べると一目で分かります。仮想例ですが、同じ規模の提案でこういう差が出ます。

費目の書き方 A社の提案書 B社の提案書
要件定義 システム開発一式に含む 1.5人月・単価100万円
設計・実装 システム開発一式に含む 5.0人月・単価95万円
テスト 記載なし 1.5人月・単価85万円
データ移行 別途お見積り 0.5人月・単価85万円

A社の書き方でも金額が妥当なことはあります。ただ、この状態では「テストはどこまでやるのか」「移行はいくらになるのか」を提案書から読み取れません。B社の書き方なら、人月が妥当かどうかを工程ごとに議論できます。なお人月単価はあくまで一般的な目安で、実際の判断は個別の見積もりで確認してください。

もう1つ見たいのは、テストと移行の扱いです。この2つは金額が読みにくいので、提案の段階では薄く積まれがちです。単体テストしか書かれていない、データ移行が1行だけ、という提案書は、後で工数が膨らむ側に寄っています。

体制図に載っている人が本当に入るか

体制の章は、肩書きが並んでいるので読み飛ばしがちですが、金額と同じくらい効いてきます。確認したいのは3点です。名前と役割が書かれているか、稼働率が書かれているか、再委託があるかどうか。

とくに稼働率です。プロジェクトマネージャーが載っていても、稼働20%なら実質的に週1日です。技術的な判断が必要な場面で捕まらない、ということが起こります。稼働率の記載がない体制図は、聞けば教えてもらえるので、提案の段階で確認しておくといいです。

再委託も同じで、書いていない会社が悪いというより、聞かないと出てこない情報です。体制図そのものの読み方はシステム開発の体制図に載る役割と発注側の確認点で詳しく扱っています。

システム開発の提案書を読み比べるときの観点

2社から届いた提案書を机に並べ、前提条件のページを指しながら2人で見比べている場面
複数社を並べると、金額差の理由は前提条件と除外事項に出ます

ここからが、発注側にしか読めない部分です。提案書で本当に差が出るのは、機能一覧ではなく後ろのほうの地味な欄です。

前提条件に書かれた「発注側がやること」

前提条件は、この提案が成り立つ条件を並べた欄です。読むと、その多くが発注側の作業だと気づきます。移行元データの整備、テストに出す現場要員、既存システムを触っている業者との調整、社内の承認を何日以内に返すこと。

実際の提案書によく並ぶ前提条件を挙げておきます。

  • 移行元データは発注側が指定形式で整備して提供する
  • 受入テストの実施と合否判定は発注側が行う
  • 既存システムを保守している業者との調整は発注側が窓口になる
  • 設計内容の確認・承認は提示から5営業日以内に返す
  • 現地作業が必要な場合の場所と回線は発注側が用意する

これは自社の工数です。しかも見積書には載りません。提案書の金額が800万円でも、前提条件に自社側の作業が10項目並んでいたら、実際にかかるのは800万円と社内の何百時間です。ここを数えずに社内稟議に出すと、稼働してから「こんなに手間がかかるとは聞いていない」という話になります。

あわせて、前提が崩れたときにどうなるかが書かれているかも見ます。「前提条件に変更が生じた場合は再見積とする」と書いてあるのは、不親切ではなく誠実です。何も書いていないほうが、後で揉めます。

除外事項は「書かれていない作業」を読む欄

除外事項は、この提案でやらないことを並べた欄です。提案書のなかで一番読まれていないのに、金額差の理由が一番はっきり出るのがここです。

複数社の提案書を並べると、だいたい同じ構図が見えます。A社が安いのは、能力が高いからでも企業努力でもなく、除外事項に書いてある分だけ作っていないからです。データ移行が除外、初期データの投入は発注側、マニュアル作成は範囲外、既存帳票の改修は別途。これを足し戻すと、B社の金額に近づく、ということがよくあります。

数字にすると分かりやすいので、仮想例で書きます。A社が800万円、B社が1,050万円だったとします。A社の除外事項にはデータ移行・マニュアル作成・既存帳票の改修が並び、B社にはどれも書かれていません。移行に80万円、マニュアルに40万円、帳票改修に120万円かかると見れば、A社は実質1,040万円です。差は250万円ではなく、ほぼ横並びだったということになります。

ですから読み比べるときは、各社の除外事項を1枚に書き出して重ねるのが早いです。A社にしか書かれていない除外項目は、他社が黙って含めている作業か、A社が意図的に外した作業のどちらかです。どちらなのかは聞けば分かります。

危険サインになる4つの表現

提案書には、そのままだと意味が広く読めてしまう表現が出てきます。よく出る4つを、発注側の言葉に翻訳しておきます。

提案書で確認したい4つの表現

  • 「〜等」「〜を含む」— 範囲が閉じていない。何が入って何が入らないかを一覧にしてもらう
  • 「別途お見積り」— 金額が決まっていない項目が残っている。概算のレンジだけでも聞く
  • 「貴社にてご用意」— 自社の作業。誰が何日かけるのかを自分で見積もる
  • 「標準機能の範囲で対応」— 何が標準かの定義がどこにもない。標準の一覧を出してもらう

どれも、書いた側に悪意があるわけではありません。提案の段階では決められないことが本当にあるからです。ただ、決まっていないという事実を発注側が認識しているかどうかで、後の展開が変わります。曖昧な表現を見つけたら、消してもらうのではなく、内容を確定させて追記してもらうのが正しい対応です。

提案書を読み比べる順番

私が勧める順番は、前提条件、除外事項、見積の内訳、体制の4段です。金額は最後です。

理由は単純で、金額から入ると安い提案が良く見えてしまい、その後に読む前提条件や除外事項を「まあ許容範囲か」と甘く判定してしまうからです。順番を逆にすると、各社が実際に引き受ける範囲がそろったところで金額を並べられます。同じものを買う条件になってから値段を見る、というだけの話です。

読み比べた結果を点数にして社内で説明する段になったら、評価項目の決め方や配点、選定理由の残し方はベンダー選定の評価基準と比較表・選定理由の残し方にまとめてあります。本記事は書類の読み方、そちらは評価の仕組みという分担です。ベンダー選定比較表テンプレート(10カテゴリ100項目)を使うと、スコープ設計や見積の透明性といった軸で採点まで進められます。

Q. 提案書は何社からもらうのが適切ですか?
A. 3社前後が扱いやすいところです。2社だと比較の基準が作れず、5社を超えると読み比べる時間が確保できません。声をかける段階でRFIを使って候補を絞っておくと、提案書を受け取る社数を無理なく調整できます。
Q. 提案書の内容は、そのまま契約書に反映されますか?
A. 自動では反映されません。提案書は契約前の書類なので、機能範囲・前提条件・除外事項を契約書か仕様書に書き写す必要があります。提案書に書いてあるから大丈夫、という前提で進めると、後から範囲の認識違いが出ます。
Q. 金額が飛び抜けて安い提案書は、どう扱えばいいですか?
A. まず除外事項と前提条件を読んで、他社が含めている作業が外れていないかを確認します。範囲がそろっているのに安いのであれば、実績のある領域で工数を圧縮できている可能性があります。範囲が違うだけなら、足し戻して比べ直します。
Q. 提案書に有効期限が書かれていました。気にする必要はありますか?
A. 見ておいたほうがいいです。社内の稟議に想定より時間がかかると、期限切れで再見積になることがあります。決裁のスケジュールを伝えたうえで、期限をいつまで延ばせるかを提案の段階で確認しておくと安全です。