システム開発コンペの評価表｜技術・体制・見積を採点する基準

2026/10/19

システム開発コンペでは、提案書の見栄えや総額だけで選ぶと、契約後に前提条件の違いが表面化します。必要なのは、各社を同じ観点で比べ、採点の根拠を説明できる評価表です。

れむ3号「うむん。僕はまず、点数より証拠を見るよ。『対応できます』ではなく、誰が、いつ、何を、どの前提で実行する提案なのかを確認したい」

Λ-51「ワレワレは技術と運用の整合性を担当する。地球の提案比較では、機能一覧が同じでも、非機能要件、移行、保守の責任範囲が異なることが多い」

この記事では、システム開発コンペの評価表をつくり、技術、体制、進め方、見積、リスクを公平に採点する方法を解説します。

評価表をRFP配布前に作る理由

システム開発コンペの評価表は、提案書を受け取る前に完成させるのが基本です。

提案を受け取ってから評価項目を考えると、印象のよい会社に合わせて基準が動きます。RFPを出す前に、次を決めます。

れむ3号「オセロで言えば、角に見える提案が本当に確定石かを先に決める。後から盤面を変えると、公平な比較にならないよ」

Λ-51「価格を先に見ると、技術評価が引っ張られる可能性がある。可能なら、技術評価と価格評価を分けて実施する方法も検討できる」

評価会議では、最初から平均点を出さない。担当者が個別に採点し、点差の理由を共有してから調整する。声の大きい人の印象で決まるのを避けるためです。

配点は一例です。事業停止の影響が大きければ非機能要件と移行を重くし、PoCなら検証計画と学習速度を重くします。合計点だけでなく、必須項目に最低点を設定します。

機能を言い換えただけの提案ではなく、現在の業務と導入後の変化を説明しているかを見ます。

れむ3号「ここは営業トークより、仮説の置き方を見る。確認できないことを『できます』で埋める会社より、質問と検証方法を出す会社のほうが読みやすい」

Λ-51「要件理解は技術以前の航法装置である。目的がずれた高性能システムは、正確に別の場所へ到着する」

技術名の新しさだけで評価しません。想定利用者数、データ量、可用性、セキュリティ、外部連携、将来変更に合っているかを確認します。

特定製品名だけで加点せず、自社条件との適合を見ます。クラウドだから安全、AIだから効率化できる、といった無条件の説明は根拠になりません。

会社全体の実績と、実際に担当する人の経験は分けて確認します。

プロフィールの年数だけでなく、今回と似た規模や制約でどの役割を担当したかを聞きます。未確定メンバーが多い場合は、確定時期と代替条件を評価します。

費用の詳細が気になりますか？

ご要件を入力するだけで、あなたのプロジェクトに合った概算見積もりが出ます

しつこい営業はしません

開発方式の名称より、各段階で何を確認し、誰が承認するかを見ます。