基幹システムの刷新を開発会社に依頼するとき、最後の関門になるのがRFP（提案依頼書）と、ベンダーへの質問である。何を作りたいのか、何を重視するのかが伝わらないと、各社から返ってくる提案を正しく比べられない。逆に、論点を整理したRFPと的を射た質問があれば、提案の差が見え、自社に合う開発会社を選びやすくなる。

本記事は連載のまとめとして、刷新のRFPに入れるべき項目と、開発会社への質問集を整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。これまでの連載で扱ってきた、刷新の判断、現状把握、移行方式、費用、体制、運用といった論点を振り返りながら、発注前の準備として何を固めておくべきかをまとめる。

結論：論点を整理したRFPと質問で、提案を比べられる形にする

刷新のRFPとベンダー選定で、GXOが重視するのは次の3点である。

  • 目的・範囲・前提をRFPに明記し、各社が同じ土俵で提案できるようにする
  • 移行方式・費用・体制・運用まで含めて質問し、技術以外も見極める
  • 金額の安さより、前提の明確さと進め方の現実性で開発会社を選ぶ

RFPは、要望を網羅することより、論点を整理して伝えることが大切である。これまでの連載で見てきた論点を、発注前にRFPと質問へ落とし込むことで、提案を比較できる形になる。費用面の比較は基幹システム刷新の進め方｜移行の費用構造と見積の読み方、体制面は基幹システム刷新の進め方｜移行プロジェクトの体制とPMも合わせて参照されたい。

なぜRFPと質問が成否を分けるのか

RFPと質問が曖昧だと、ベンダー選定はうまくいかない。各社から集まる提案を比べる土台が揃わず、結局は印象や金額の安さで選ぶことになりがちである。発注前に、その背景を理解しておきたい。

  • 比較できなくなる：各社が異なる前提で提案すると、金額も内容も比べられない。
  • 後から食い違う：伝えていない前提が、契約後にずれとなって表面化する。
  • 技術以外を見落とす：移行方式や運用、体制への問いが抜け、稼働後に困る。
  • 安さだけで選ぶ：前提の違いに気づかず、安く見える提案を選んで後悔する。

これらは、RFPと質問で論点を整理すれば避けられる。発注前の準備が、刷新全体の精度を左右する。

RFPに入れるべき項目

RFPには、開発会社が提案を組み立てるために必要な情報を、過不足なく盛り込みたい。連載で扱った論点が、そのまま項目になる。

RFPの項目含めたい内容関連する論点
目的・背景なぜ刷新するか、何を解決したいか刷新の判断
現状既存システムの概要・課題現状の棚卸し
対象範囲刷新する業務・しない業務移行の進め方
移行の要望段階移行か一括か、停止の許容度移行方式・切替
データ移行移行対象データ・現状の品質データ移行
費用・期間予算の目安・希望時期費用構造
運用・保守稼働後の保守・内製化の希望運用保守

すべてを細かく決める必要はない。決まっていない部分は「未確定」と明記し、提案の中で一緒に詰める前提にすればよい。重要なのは、各社が同じ情報をもとに提案できる状態にすることである。

連載の論点を振り返る

これまでの連載で扱ってきた論点は、RFPと質問の土台になる。発注前に、自社の状況を各論点に当てはめて整理しておきたい。

刷新するかどうかと、現状の把握

そもそも今刷新すべきかの判断は、連載の第1回「いつ刷新すべきか」で扱った。刷新を決めたら、現状システムの全体像を把握する。仕様書のない属人化したシステムでは、引き継ぎの準備も欠かせない。

移行の進め方を決める

どう移すかは、いくつもの選択が絡む。段階移行か一括かは、連載の第5回「段階移行か一括移行か」で整理した。作り方をパッケージ・スクラッチ・SaaSのどれにするか、データをどう移し検証するかも、移行方式と合わせて決めていく。

費用・体制・運用を見据える

費用は初期開発だけでなく、移行・並行稼働・運用まで含めて総額で見る。体制は、意思決定者と窓口役を発注側に置くことが要になる。稼働後の運用保守と内製化も、計画段階から見据えておきたい。これらの論点を踏まえると、RFPと質問に何を盛り込むべきかが定まる。

開発会社への質問集

提案を受けたら、技術だけでなく、移行・費用・体制・運用まで踏み込んで質問したい。次の問いが、開発会社を見極める手がかりになる。

質問確認したいこと
仕様書がない場合、どう進めますか現状調査の進め方
段階移行と一括移行のどちらを勧めますか移行方式の考え方
データ移行の検証はどう行いますか移行の品質管理
見積に含まれる範囲と前提は何ですか費用の透明性
発注側に求める体制は何ですか進め方の現実性
稼働後の保守と内製化は支援できますか運用の継続性

「全部お任せください」という説明には注意したい。発注側に何を求めるか、何が含まれて何が含まれないかを具体的に語れる会社のほうが、進め方が現実的なことが多い。開発会社を選ぶ視点はAI開発会社の選び方の判断基準の考え方も参考になる。

RFP・選定でよくある失敗

RFPとベンダー選定では、次のような失敗が起きやすい。

  • 要望を盛り込みすぎる：細かく書きすぎて論点がぼやけ、各社の提案が比べにくくなる。
  • 前提を伝えない：データの状態や運用の希望を伝えず、提案と実態がずれる。
  • 技術だけで選ぶ：移行や運用への問いが抜け、稼働後に困る会社を選んでしまう。
  • 金額だけで決める：前提の違いを見ずに安い提案を選び、後から追加が積み上がる。

これらは、連載で扱った論点をRFPと質問に落とし込めば避けられる。発注前の整理が、刷新全体を支える土台になる。

提案を受けてからの進め方

RFPを出して提案が集まったら、その先の進め方も大切である。提案を受け取った段階で終わりにせず、内容を擦り合わせる場を持ちたい。

  • 前提を確認する：各社が置いた前提を聞き取り、実態と合っているかを確かめる。
  • 不明点を質問する：分からない点はその場で質問し、提案の中身を正しく理解する。
  • 同じ土俵に揃える：含まれる範囲や前提を揃え、金額と内容を比較できる形にする。
  • 進め方を見る：提案の良し悪しだけでなく、やり取りの中での説明の丁寧さや反応の早さも見る。

提案の比較は、書面だけで完結しない。やり取りを通じて、この会社と一緒に進められそうかを感じ取ることも重要である。刷新は長い付き合いになるため、技術力に加えて、コミュニケーションの取りやすさや、こちらの事情をくみ取ってくれるかも判断材料になる。

提案を比べる際は、社内の関係者にも内容を共有し、意見を聞いておきたい。意思決定者だけで決めず、現場や推進担当の視点も入れることで、稼働後に「聞いていない」という事態を防げる。発注は組織の判断として進めるのが望ましい。

相談前に整理しておくとよい情報

RFPづくりや開発会社選びについて相談する前に、連載で扱ってきた論点に沿って自社の状況を整理しておくと、準備が一気に進む。すべてを決めきる必要はなく、現時点の考えが見えていれば十分である。

  • なぜ刷新したいのか、何を解決したいのかという目的
  • 現行システムの概要と、感じている課題
  • 刷新の対象にしたい業務と、対象外にする業務
  • 移行や費用、稼働時期について現時点で希望すること
  • 稼働後の運用や内製化について考えていること

これらが整理されていなくても相談は可能である。むしろ、目的と課題が言葉になっていれば、そこからRFPの骨子や、開発会社への質問を一緒に組み立てられる。連載で振り返った論点を、自社の状況に当てはめて整理することが、発注前の準備の出発点になる。

よくある質問

Q1. RFPはどこまで細かく書くべきですか

すべてを細かく決める必要はない。目的・現状・対象範囲・主な要望が伝わり、各社が同じ前提で提案できれば十分である。決まっていない部分は「未確定」と明記し、提案の中で一緒に詰める形にすると、現実的に進められる。

Q2. 複数社から提案を取るとき、何に気をつければよいですか

同じRFPと同じ前提で提案してもらうことが大切である。前提が揃っていないと、金額も内容も比較できない。提案を受けたら、含まれる範囲と前提を各社に確認し、同じ土俵に揃えてから比べるとよい。

Q3. 開発会社を見極める一番のポイントは何ですか

技術力だけでなく、移行の進め方や、発注側に求める体制を具体的に語れるかである。「全部お任せ」ではなく、何が必要で何が含まれるかを明確に説明できる会社は、進め方が現実的なことが多い。前提の明確さを判断材料にしたい。

刷新のRFPづくりから、開発会社選びまで一緒に整理しませんか

GXOでは、刷新の目的整理からRFPの作成、提案の比較、開発会社への質問の組み立てまでをご支援します。移行・費用・体制・運用まで含めて、発注者が判断しやすい形に論点を整理します。

基幹システム刷新の相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。