提案書で読むベンダー選定の失敗——発注側が見逃しやすい5つのサイン

提案書を読むとき、多くの発注担当者は「価格」と「機能」から評価を始める。しかし選定後にトラブルになったプロジェクトを振り返ると、失敗の兆候はたいてい提案の段階にすでに表れていた。費用の高低ではなく、「誰が・何を・どこまでやるか」が書面に残っていないという構造的な曖昧さだ。

提案段階で見えやすい兆候を5つ整理する。

提案書に担当者の名前がない

最初の確認ポイントは、「実際にプロジェクトに入る人間の名前が書面にあるか」だ。

提案書に会社概要と実績は並んでいるが、担当者欄は「弊社専任チームが対応いたします」で終わっている——そういう提案書は珍しくない。プロジェクトが始まってから初めて担当者と顔合わせをし、その人物が数か月後に交代する、というのはシステム導入の現場でよく起きる話だ。

確認すべき点:

• 担当者の名前・役割（PM・エンジニア・ディレクターなど）が明示されているか
• その担当者がヒアリングや説明会に実際に参加しているか
• 担当者の交代ルールと引き継ぎ体制が記載されているか

提案説明会にも気をつけたい。説明会に実務担当者が来ず、営業担当だけが対応するケースでは、「技術的な詳細は持ち帰って確認します」が繰り返されやすい。質問に即答できる人間が来ているかどうかも、確認の材料になる。

書面に出てこない担当者は、人員配置が流動的に扱われている可能性を示す。選定後のコントロールが難しくなる前兆と見ていい。

「できます」の範囲が書面になっていない

口頭のヒアリングでは「もちろん対応できます」「そこは問題ありません」という返答が続く。しかしその合意が提案書や仕様書のどこにも書かれていない——これが後のトラブルの温床になる。

注意が必要な「できます」のパターン:

1. カスタマイズの可否——「柔軟に対応できます」が、追加費用ゼロなのか有償なのかが書かれていない
2. 既存システムとの連携——「連携できます」が、どの程度の工数を前提にしているか書面にない
3. データ移行の範囲——「お任せください」が、どこからどこまでを含むか確認できない

口頭の「できます」は合意ではない。書面に落ちていない約束は、契約後に「そういう話はしていない」と言われる余地を残す。

AI導入の見積でも同じ構造が起きやすい。「できます」の前提を問い返す視点は、AI導入の見積書で確認する5つの観点でも整理している。

見積の前提条件が空欄のまま提出されている

提案書の見積には「前提条件」が存在する。何台の端末を対象にするか、何人のユーザーを想定しているか、データ量はどの規模か。これが書かれていない見積は、後から「前提が変わったので追加費用が発生します」と言われる構造になっている。

発注側がチェックすべき前提条件の項目:

• 対象ユーザー数・端末数の上限
• 納期に影響する発注側の作業（情報提供・承認フローなど）
• 保守・運用フェーズの費用と範囲（初期費用に含まれるか否か）
• 不測の事態における追加費用の発生条件

前提条件が空欄のまま提案を出してくるベンダーは、費用計算の根拠を持っていないか、後から条件を変えやすい構造で提案している可能性がある。どちらにしても、発注側にとってリスクだ。

選定の評価軸そのものをどう設計するかはベンダー選定の基準は比較表より先に決まるで整理している。

兆候を見つけたら、採点より先に質問する

上記の兆候を見つけたとき、すぐに採点を下げるのではなく、「文書で質問を送る」という手順を踏むことをすすめる。

「提案書のP○に記載のない△△については、どのように対応いただけますか」と文書で問い、回答が口頭だったら「書面で確認させてください」と返す。回答が曖昧だったら、その曖昧さ自体を評価情報にする。

ベンダーへの質問への応答ぶりは、プロジェクトが動き始めてからの仕事ぶりをよく映す鏡だ。選定は「正しいベンダーを選ぶ」作業であると同時に、「後から言った言わないにならないための構造を作る」作業でもある。提案段階で曖昧さを残したまま進むと、プロジェクト中盤での認識のずれは避けにくい。

選定作業全体が重くなってきたと感じたら、しぼる（DX伴走支援）のように外部の目を入れることも選択肢になる。