基幹システムの刷新を開発会社に依頼するとき、最後の関門になるのがRFP（提案依頼書）と、ベンダーへの質問である。何を作りたいのか、何を重視するのかが伝わらないと、各社から返ってくる提案を正しく比べられない。逆に、論点を整理したRFPと的を射た質問があれば、提案の差が見え、自社に合う開発会社を選びやすくなる。
本記事は連載のまとめとして、刷新のRFPに入れるべき項目と、開発会社への質問集を整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。これまでの連載で扱ってきた、刷新の判断、現状把握、移行方式、費用、体制、運用といった論点を振り返りながら、発注前の準備として何を固めておくべきかをまとめる。
結論：論点を整理したRFPと質問で、提案を比べられる形にする
刷新のRFPとベンダー選定で、GXOが重視するのは次の3点である。
- 目的・範囲・前提をRFPに明記し、各社が同じ土俵で提案できるようにする
- 移行方式・費用・体制・運用まで含めて質問し、技術以外も見極める
- 金額の安さより、前提の明確さと進め方の現実性で開発会社を選ぶ
RFPは、要望を網羅することより、論点を整理して伝えることが大切である。これまでの連載で見てきた論点を、発注前にRFPと質問へ落とし込むことで、提案を比較できる形になる。費用面の比較は基幹システム刷新の進め方｜移行の費用構造と見積の読み方、体制面は基幹システム刷新の進め方｜移行プロジェクトの体制とPMも合わせて参照されたい。
NOCODE EXIT
Bubble／kintone の限界、スクラッチ移行で解消しませんか？
ノーコードの肥大化・応答遅延・カスタマイズ限界を Laravel+Vue 移行で根治。概算費用・移行期間・データ移行設計・並行稼働プランをその場で確認できます。
なぜRFPと質問が成否を分けるのか
RFPと質問が曖昧だと、ベンダー選定はうまくいかない。各社から集まる提案を比べる土台が揃わず、結局は印象や金額の安さで選ぶことになりがちである。発注前に、その背景を理解しておきたい。
- 比較できなくなる：各社が異なる前提で提案すると、金額も内容も比べられない。
- 後から食い違う：伝えていない前提が、契約後にずれとなって表面化する。
- 技術以外を見落とす：移行方式や運用、体制への問いが抜け、稼働後に困る。
- 安さだけで選ぶ：前提の違いに気づかず、安く見える提案を選んで後悔する。
これらは、RFPと質問で論点を整理すれば避けられる。発注前の準備が、刷新全体の精度を左右する。
RFPに入れるべき項目
RFPには、開発会社が提案を組み立てるために必要な情報を、過不足なく盛り込みたい。連載で扱った論点が、そのまま項目になる。
横にスクロールして確認できます
| RFPの項目 | 含めたい内容 | 関連する論点 |
|---|---|---|
| 目的・背景 | なぜ刷新するか、何を解決したいか | 刷新の判断 |
| 現状 | 既存システムの概要・課題 | 現状の棚卸し |
| 対象範囲 | 刷新する業務・しない業務 | 移行の進め方 |
| 移行の要望 | 段階移行か一括か、停止の許容度 | 移行方式・切替 |
| データ移行 | 移行対象データ・現状の品質 | データ移行 |
| 費用・期間 | 予算の目安・希望時期 | 費用構造 |
| 運用・保守 | 稼働後の保守・内製化の希望 | 運用保守 |
すべてを細かく決める必要はない。決まっていない部分は「未確定」と明記し、提案の中で一緒に詰める前提にすればよい。重要なのは、各社が同じ情報をもとに提案できる状態にすることである。
連載の論点を振り返る
これまでの連載で扱ってきた論点は、RFPと質問の土台になる。発注前に、自社の状況を各論点に当てはめて整理しておきたい。
刷新するかどうかと、現状の把握
そもそも今刷新すべきかの判断は、連載の第1回「いつ刷新すべきか」で扱った。刷新を決めたら、現状システムの全体像を把握する。仕様書のない属人化したシステムでは、引き継ぎの準備も欠かせない。
移行の進め方を決める
どう移すかは、いくつもの選択が絡む。段階移行か一括かは、連載の第5回「段階移行か一括移行か」で整理した。作り方をパッケージ・スクラッチ・SaaSのどれにするか、データをどう移し検証するかも、移行方式と合わせて決めていく。
費用・体制・運用を見据える
費用は初期開発だけでなく、移行・並行稼働・運用まで含めて総額で見る。体制は、意思決定者と窓口役を発注側に置くことが要になる。稼働後の運用保守と内製化も、計画段階から見据えておきたい。これらの論点を踏まえると、RFPと質問に何を盛り込むべきかが定まる。
開発会社への質問集
提案を受けたら、技術だけでなく、移行・費用・体制・運用まで踏み込んで質問したい。次の問いが、開発会社を見極める手がかりになる。
横にスクロールして確認できます
| 質問 | 確認したいこと |
|---|---|
| 仕様書がない場合、どう進めますか | 現状調査の進め方 |
| 段階移行と一括移行のどちらを勧めますか | 移行方式の考え方 |
| データ移行の検証はどう行いますか | 移行の品質管理 |
| 見積に含まれる範囲と前提は何ですか | 費用の透明性 |
| 発注側に求める体制は何ですか | 進め方の現実性 |
| 稼働後の保守と内製化は支援できますか | 運用の継続性 |
「全部お任せください」という説明には注意したい。発注側に何を求めるか、何が含まれて何が含まれないかを具体的に語れる会社のほうが、進め方が現実的なことが多い。開発会社を選ぶ視点はAI開発会社の選び方の判断基準の考え方も参考になる。
RFP・選定でよくある失敗
RFPとベンダー選定では、次のような失敗が起きやすい。
- 要望を盛り込みすぎる：細かく書きすぎて論点がぼやけ、各社の提案が比べにくくなる。
- 前提を伝えない：データの状態や運用の希望を伝えず、提案と実態がずれる。
- 技術だけで選ぶ：移行や運用への問いが抜け、稼働後に困る会社を選んでしまう。
- 金額だけで決める：前提の違いを見ずに安い提案を選び、後から追加が積み上がる。
これらは、連載で扱った論点をRFPと質問に落とし込めば避けられる。発注前の整理が、刷新全体を支える土台になる。
提案を受けてからの進め方
RFPを出して提案が集まったら、その先の進め方も大切である。提案を受け取った段階で終わりにせず、内容を擦り合わせる場を持ちたい。
- 前提を確認する：各社が置いた前提を聞き取り、実態と合っているかを確かめる。
- 不明点を質問する：分からない点はその場で質問し、提案の中身を正しく理解する。
- 同じ土俵に揃える：含まれる範囲や前提を揃え、金額と内容を比較できる形にする。
- 進め方を見る：提案の良し悪しだけでなく、やり取りの中での説明の丁寧さや反応の早さも見る。
提案の比較は、書面だけで完結しない。やり取りを通じて、この会社と一緒に進められそうかを感じ取ることも重要である。刷新は長い付き合いになるため、技術力に加えて、コミュニケーションの取りやすさや、こちらの事情をくみ取ってくれるかも判断材料になる。
提案を比べる際は、社内の関係者にも内容を共有し、意見を聞いておきたい。意思決定者だけで決めず、現場や推進担当の視点も入れることで、稼働後に「聞いていない」という事態を防げる。発注は組織の判断として進めるのが望ましい。
相談前に整理しておくとよい情報
RFPづくりや開発会社選びについて相談する前に、連載で扱ってきた論点に沿って自社の状況を整理しておくと、準備が一気に進む。すべてを決めきる必要はなく、現時点の考えが見えていれば十分である。
- なぜ刷新したいのか、何を解決したいのかという目的
- 現行システムの概要と、感じている課題
- 刷新の対象にしたい業務と、対象外にする業務
- 移行や費用、稼働時期について現時点で希望すること
- 稼働後の運用や内製化について考えていること
これらが整理されていなくても相談は可能である。むしろ、目的と課題が言葉になっていれば、そこからRFPの骨子や、開発会社への質問を一緒に組み立てられる。連載で振り返った論点を、自社の状況に当てはめて整理することが、発注前の準備の出発点になる。
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。
実務判断のポイント
この記事は、経営者、情シス、業務責任者、発注担当向けです。要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。基幹システム刷新の進め方｜刷新のRFPと開発会社への質問に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
Q1. RFPはどこまで細かく書くべきですか
すべてを細かく決める必要はない。目的・現状・対象範囲・主な要望が伝わり、各社が同じ前提で提案できれば十分である。決まっていない部分は「未確定」と明記し、提案の中で一緒に詰める形にすると、現実的に進められる。
Q2. 複数社から提案を取るとき、何に気をつければよいですか
同じRFPと同じ前提で提案してもらうことが大切である。前提が揃っていないと、金額も内容も比較できない。提案を受けたら、含まれる範囲と前提を各社に確認し、同じ土俵に揃えてから比べるとよい。
Q3. 開発会社を見極める一番のポイントは何ですか
技術力だけでなく、移行の進め方や、発注側に求める体制を具体的に語れるかである。「全部お任せ」ではなく、何が必要で何が含まれるかを明確に説明できる会社は、進め方が現実的なことが多い。前提の明確さを判断材料にしたい。
刷新のRFPづくりから、開発会社選びまで一緒に整理しませんか
GXOでは、刷新の目的整理からRFPの作成、提案の比較、開発会社への質問の組み立てまでをご支援します。移行・費用・体制・運用まで含めて、発注者が判断しやすい形に論点を整理します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
