システム開発会社のコンペで失敗しない方法｜3社の提案を比較するときのポイント

開発会社のコンペは、発注者にとって最も重要な判断の場の一つだ。だが、多くのコンペはプレゼンの上手さで決まってしまう。

スライドが美しい会社、話が上手い営業、その場の安心感——採択後に効くのはそこではない。3社を並べるときは、同じ質問・同じ基準・同じ表で比べる。

コンペの目的は「安い会社探し」ではなく、課題を最も正確に理解し、実行できる会社探しだ。

コンペで見るべき4つの軸

軸	見るポイント	見ないポイント
価格	スコープとの整合性	金額の絶対値
技術	課題への適合性	最新技術の羅列
体制	実際に参画するメンバー	会社の総エンジニア数
提案力	課題理解の深さ	スライドのデザイン

4軸のうち1つだけ突出していても弱い。特に価格だけが勝っている提案は、スコープか体制のどちらかが薄いことが多い。

各社に同じ質問をする

比較の公平性を保つには、全社に同じ質問リストを投げる。口頭の雑談では差が出ない。

• この課題に対して、なぜその技術選定なのか
• リスクは何か、どう対処するか
• 実際に参画するメンバーは誰か（名前と稼働）
• スコープ外と判断した機能は何か
• 納品後の保守・引き継ぎはどうするか
• キックオフ後の最初の2週間で何をするか

答えの「正しさ」より、自社の文脈に寄せて答えられているかを見る。テンプレ回答はすぐに分かる。

提案書の「赤旗」チェック

以下が見られたら、慎重に判断する。

• 課題の言い換えがない — 自社の提案テンプレをそのまま使っている
• リスクに触れない — すべて順調に進む前提のスケジュール
• 体制が抽象 — 「シニアエンジニアが対応」で名前が出ない
• スコープが曖昧 — 機能一覧がなく、工数内訳だけある
• 参考事例が合わない — 業界も規模も異なる事例ばかり
• 除外事項が極端に短い — 後から追加費用の余地を残している

赤旗が1つでも「即失格」ではない。ただし、指摘したときに具体で埋められない会社は危険だ。

現場で見た、プレゼン勝ちの落とし穴

匿名化した一例だ。3社コンペで、営業プレゼンが突出して上手いB社を採択した。課題の言い換えも上手く、経営層の納得感は高かった。

着手後に分かったのは次の事実だ。

• プレゼンに出ていたテックリードは参画せず、別チームがアサインされた
• 提案書のスケジュールは「要件確定済み」前提で、実際は要件が半分しか固まっていなかった
• リスク欄は「特になし」だったが、外部API連携で初月から遅延

結果として、コンペ時の安心感と現場の実行力が乖離した。採択前に「プレゼン登壇者が週何日入るか」を文書でもらえていれば、避けられた分岐だ。

プレゼンと実力は別物

営業プレゼンが上手い会社ほど、実際の開発体制とのギャップに注意が必要だ。

確認すべきは:

• プレゼンに出てきた人が、プロジェクトにも参画するか
• 過去の類似案件で、同じ体制で成功しているか
• キックオフ後の最初の2週間で何をするか
• 営業とデリバリーの責任分界はどうなっているか

コンペ後の判断フレーム

3社を以下のマトリクスで整理する。

1. 課題理解度 — 自社の課題を正確に言語化できているか
2. 実行可能性 — 提示した体制とスケジュールは現実的か
3. リスク管理 — 不確定要素への対処が具体的か
4. コストパフォーマンス — スコープ対比で妥当か

4項目すべてで上位の会社を選ぶ。1項目だけ突出している会社は、他で問題が起きやすい。

判断軸：このコンペ、進めてよいか

状況	推奨
全社に同じ質問リストを投げ、表で比較できる	採択判断に進んでよい
金額だけ見て上位を決めようとしている	一旦止める。スコープ表を作る
登壇者と実働メンバーが別人のまま曖昧	書面で稼働を確定するまで決めない
1社だけ極端に安く、除外事項が多い	安さより不完全見積もりの可能性を疑う

次に確認すること

1. 4軸の比較表を1枚にしたか
2. 全社への共通質問リストは送ったか
3. 赤旗への回答は具体か
4. 実働メンバーの名前と稼働は文書にあるか
5. スコープの含む／含まないは揃っているか
6. 採択理由を「金額以外」で一文言えるか

まとめ

コンペは「安い会社探し」ではない。課題を最も正確に理解し、実行できる会社探しだ。

同じ質問、同じ基準、同じ表で比較する。それだけで失敗率は大きく下がる。上手いプレゼンは歓迎するが、採択の根拠にはしない。

---

開発会社選び・コンペ支援の相談は、お問い合わせフォーム からどうぞ。