システム開発コンペの進め方｜比較条件と提案依頼で失敗を防ぐ

システム開発会社をコンペで選ぶなら、参加社数を増やすより先にやることがある。全社へ同じ判断材料を渡し、同じ比較軸で評価できる状態を作ることだ。

今回は、証拠と条件を集めて比較する僕、れむ3号と、発注担当者の不安や使う人の体験を拾うリディで整理する。

れむ3号「うむん。『良い提案をください』だけでは、提案書の豪華さを競うゲームになる。開発後に必要なのは、きれいな資料より動く仕組みだよ」

リディ「でも初めての発注やと、何を同じ条件にしたらええか分からへんよね。質問しやすさや、説明の分かりやすさも含めて一緒に見ていこ」

この記事では、中小企業がシステム開発コンペを行う際の準備、参加会社への情報提供、評価方法、費用比較、契約前の確認事項を実務順に解説する。

システム開発コンペが向いているケース

コンペは、複数社の考え方や提案を比較したいときに役立つ。ただし、すべての案件に向くわけではない。

向いているのは、次のような案件だ。

• 解決したい業務課題と予算上限がある程度整理されている
• 複数の実現方法を比較する価値がある
• 評価担当者と選定期間を確保できる
• 発注後の運用まで含めて提案を見たい

一方、障害対応など着手を急ぐ案件、数日で終わる小規模改修、要件が固まっていて価格だけを比較したい案件では、相見積もりや候補会社との直接協議のほうが合う場合もある。

リディ「コンペって聞くと本格的で安心しそうやけど、準備にも参加会社さんの工数にも負担がかかるんやね」

れむ3号「その通り。候補を増やせば精度が上がるとは限らない。評価できる人数と期間から逆算する。盤面に石を置きすぎると、見るべき角を見失うからね」

募集前に社内で決める7項目

提案依頼書を配る前に、発注側で次をそろえる。

1. 解決したい業務課題
2. 対象となる利用者と業務範囲
3. 必須要件と希望要件
4. 予算の上限または想定範囲
5. 希望時期と動かせない日程
6. 既存システム、データ、外部連携
7. 評価者、評価項目、決定方法

要件を完全に決める必要はない。ただし、決まっていること、提案してほしいこと、未確認のことは分けて書く。

れむ3号「『未定』は悪ではない。未定を確定事項のように隠すほうが危険だ。各社が別の前提で見積もると、金額を並べても比較にならないよ」

リディ「現場の人に一回見てもらうのも大事やで。経営側では簡単に見えても、毎日使う人には『ここが抜けたら仕事にならへん』って操作があるからな」

提案依頼書で全社に伝える内容

提案依頼書、いわゆるRFPには、会社紹介だけでなく判断に必要な背景を含める。

区分	記載内容
背景	現在の業務と困っていること
目的	導入後に改善したい状態
対象	利用者、拠点、業務、データ
要件	必須機能、希望機能、非機能要件
制約	予算、納期、既存環境、社内規程
依頼事項	提案範囲、見積内訳、体制、実績
選定	日程、質問方法、評価項目、連絡先

特に重要なのが、提案範囲だ。要件定義だけか、設計・開発・移行・研修・保守まで含むのかを明示する。データ移行や外部サービス利用料が別料金なら、後から総額が変わる。

機密情報を渡す場合は、秘密保持契約の要否、閲覧者、返却・削除方法も決める。個人情報を含む実データを、そのまま提案段階で共有する必要はない。匿名化した例や項目一覧で代替できることが多い。

コンペの進め方

比較可能性を保つため、質問回答と評価の手順を先に固定する。

候補会社を絞る

実績の業界名だけでなく、今回に近い規模、連携、移行、運用体制を確認する。候補数は、全社と十分に質疑できる範囲にする。参加条件、辞退期限、提案書の利用範囲も案内する。

質問と回答を公平に扱う

質問窓口と締切を一本化する。一社の質問が全社の前提に影響するなら、質問者を特定しない形で回答を共有する。ただし、各社固有の技術や提案内容まで他社へ開示しない。

提案説明会の条件をそろえる

説明時間、質疑時間、参加人数、デモの可否をそろえる。デモを求めるなら、全社が同じ業務シナリオを説明できるようにする。画面の美しさだけではなく、登録、修正、承認、取消、履歴確認まで見る。

リディ「使う人の目線やと、成功操作だけやなくて、間違えたときに戻れるかも見たいな。ボタンの場所が分からへん画面は、毎日ちょっとずつしんどいで」

れむ3号「良い観点だ。正常系だけのデモは、オセロで自分の打ちたい手だけ並べるようなもの。例外処理、権限不足、通信失敗も質問しておこう」

提案を比較する評価表の作り方

評価項目は提案を受け取る前に決める。後から項目を変えると、気に入った会社へ点数を合わせる形になりやすい。

一例として、次のように分ける。

評価軸	見るポイント
課題理解	現状と目的を正しく捉えているか
実現方法	必須要件、例外、連携に対応できるか
利用体験	現場が迷わず使い続けられるか
進行体制	担当、責任者、会議、変更管理が明確か
セキュリティ	権限、ログ、バックアップ、事故対応
移行と教育	データ移行、テスト、研修、並行運用
費用	初期、月額、追加条件、保守を含む総額
継続性	保守範囲、問い合わせ、改修方法

点数だけで決めず、評価理由と確認事項も残す。重み付けをするなら、たとえば業務適合性を重くし、デザインや会社規模だけで逆転しないようにする。

れむ3号「合計点が同じでも中身は違う。必須要件の欠落を、プレゼンの上手さで相殺してはいけない。必須条件は足切り、比較項目は加点と分ける方法もある」

リディ「評価する人によって点がばらついたら、平均だけ出す前に理由を聞こうな。現場と経営で見えてる不安が違うだけかもしれへん」

見積金額は総額と前提条件で比べる

初期費用が安い提案でも、要件定義、データ移行、外部サービス、研修、保守、追加改修が別なら総額は変わる。少なくとも次を同じ期間で比較する。

• 要件定義、設計、開発、テスト
• データ移行と移行リハーサル
• クラウドや外部サービスの利用料
• 操作研修とマニュアル
• 保守、監視、問い合わせ対応
• 契約範囲外の追加作業単価
• 解約、データ出力、引き継ぎの費用

また、固定価格か準委任か、見積もりの有効期限、数量や画面数の前提も確認する。要件が未確定なら、幅のある概算を一つの数字に見せないことが重要だ。

提案書だけでは分からない確認事項

優先交渉先を決めた後も、すぐ契約書へ判を押さない。提案時の担当者が開発時も関わるか、再委託はあるか、仕様変更をどう承認するかを確認する。

さらに、成果物、知的財産権、ソースコード、利用するOSS、検収条件、瑕疵対応、データ返却、セキュリティ事故時の連絡を契約へ落とす。法的な判断が必要な契約条項は専門家へ相談する。

リディ「提案してくれた人がすごく話しやすくても、実際の窓口が別の人なら印象が変わることあるよね。普段だれと話すのか、先に会えると安心やで」

れむ3号「そして口頭回答は議事録か契約資料へ戻す。『言ったつもり』は確定石にならない。記録され、双方が確認して初めて判断材料になる」

参加会社への配慮も選定品質を上げる

提案作成には工数がかかる。過度に詳細な無料試作を求めたり、各社の独自提案を別会社へ横流ししたりすれば、信頼を損なう。結果通知の時期、選定結果、可能な範囲の理由を伝える。

発注側が誠実に情報を出すほど、参加会社も現実的なリスクや代替案を提案しやすい。コンペは一方的な審査ではなく、長く一緒に進められる相手かを双方で確認する場でもある。

まとめ

システム開発コンペで失敗を防ぐ鍵は、候補会社の数ではない。課題、範囲、制約をそろえ、共通の評価軸と質問ルールで比較することだ。

れむ3号「ファイナルラスト。必須条件を満たすか、前提がそろっているか、記録で確認できるか。この三つを押さえれば、雰囲気だけの選定から離れられるよ」

リディ「うちは、使う人が無理なく続けられるかも最後まで見てほしいな。分からんことを質問できて、難しい話を分かる言葉で返してくれる相手なら、導入後も一緒に進みやすいで」

最初に作るべきなのは、立派な提案依頼書ではなく、現状、目的、必須条件、未確定事項を分けた一覧だ。それをもとに評価表を作り、同じ条件で提案を受ける。発注準備に不安があれば、業務整理や要件定義の段階から外部の支援を利用する選択肢もある。

提案依頼と見積もりの準備を相談する

コンペの比較条件や提案依頼書を自社だけでまとめるのが難しい場合は、ドリーミへシステム開発の見積もりをご依頼ください。現在の業務と必須条件を整理し、開発会社が見積もりやすい発注資料づくりから支援します。見積もり相談・お問い合わせフォームから、検討中の業務と予算感が分かる範囲でお知らせください。