「社内業務を効率化するシステムをつくりたい」「新しいWebサービスを立ち上げたい」「使いづらい既存システムを入れ替えたい」——そう考え始めたとき、初めての発注では次のような壁にぶつかります。
この「分からない」を埋めるための最初の一手が、RFI（Request for Information／情報提供依頼書）です。仕様を固めたり正式な見積を取ったりする前に、「そもそもどんな選択肢があるのか」を開発会社から教えてもらうための資料と考えてください。
この記事では、初めてシステム開発を依頼する経営者・事業責任者の方に向けて、RFIの役割、RFPとの違い、記載項目、そのまま使えるテンプレート、開発会社の比較方法までを図解で解説します。
目次
RFIとは？ 3行でわかる位置づけ
RFIとは「Request for Information」の略で、日本語では情報提供依頼書と呼びます。システム導入を検討している企業が、開発会社やITベンダーに対して情報提供を依頼するための資料です。
依頼する内容は、たとえば次のようなものです。
- この課題を解決するには、どんな方法がありますか？
- 御社ではどのような対応ができますか？
- 似たシステムを開発した実績はありますか？
- おおよそ、どのくらいの費用と期間がかかりますか？
ひとことで言えば、RFIは「本格的に発注する前に、選択肢を知るための資料」です。発注プロセス全体で見ると、次の2番目に位置します。
- システム化したい課題が見つかる「Excel管理が限界」「紙の申請をやめたい」など、困りごとの発見
- RFIで情報を集める複数社に同じ質問を送り、実現手段・実績・概算費用の情報を収集する
- 開発方法と候補企業を比較するSaaSか、スクラッチか。どの会社が自社の課題を理解しているか
- 実現したい内容・予算・条件を整理する社内で優先順位と予算枠を決める
- RFPで提案と見積を依頼する条件を提示し、具体的な提案・見積を出してもらう
- 提案を比較して開発会社を選定する金額だけでなく、体制・保守・進め方まで含めて判断する
RFIは「選択肢を広げる」フェーズ、RFPは「条件を伝えて絞り込む」フェーズ。この2つは役割が違うため、順番に使うのが基本です。
RFIは「システムの仕様を決める資料」ではない
初めてのシステム開発では、最初から機能一覧や画面仕様を固めようとしてしまいがちです。しかしRFIの段階では、細かい仕様を決める必要はありません。むしろ決めすぎない方がうまくいきます。
たとえば「営業担当者がExcelで管理している顧客情報をシステム化したい」という課題があったとします。この課題の解決策は、ひとつではありません。
- SaaSを導入する月額課金で早く始められる。カスタマイズ範囲は限定的
- CRMをカスタマイズする既製品をベースに自社仕様へ。設定・開発費が発生
- ノーコードで作る小規模・短期に向く。運用担当のスキルに依存しやすい
- パッケージを導入する業界特化型なら業務に合いやすい。ライセンス費が中心
- スクラッチ開発する自由度は最大。費用と期間は大きくなりやすい
どれが正解かは、業務の独自性・予算・社内体制・スケジュールによって変わります。この判断材料を集めるのがRFIの役目です。
システム開発の経験がない状態で、この中から最適な方法を最初に選び切るのは簡単ではありません。だからこそ、複数の開発会社から情報を集め、「そもそも、どんな方法があるのか」を先に知る必要があるのです。
なぜ最初に情報収集が必要なのか
システム開発では、最初の方針選択によって費用も期間も大きく変わります。ここで情報が足りないまま走り出すと、後から軌道修正するコストが跳ね上がります。
開発方法が1つとは限らないから
「システムをつくりたい」と考えても、必ずしもゼロから開発する必要はありません。既存のSaaSやパッケージを使ったほうが、費用を抑えられ、短期間で導入でき、保守の負担も軽くなるケースは多くあります。
一方で、自社独自の業務フローが多い場合や、他システムとの複雑な連携が必要な場合は、スクラッチ開発が適していることもあります。RFIで複数社の見解を並べると、この判断がしやすくなります。
開発会社ごとに得意分野が違うから
開発会社には、それぞれ得意領域があります。
- 基幹業務システムに強い会社
- Webサービス・自社プロダクト開発に強い会社
- スマートフォンアプリに強い会社
- AWSなどクラウドインフラに強い会社
- AI・データ活用に強い会社
- SaaS導入支援・業務設計に強い会社
最初に問い合わせた1社だけの話を聞くと、その会社が得意な方法だけが選択肢として提示されることになります。複数社に同じRFIを送れば、より広い視点で比較できます。
費用感がわからないままでは予算が組めないから
初めての開発では、100万円で足りるのか、500万円必要なのか、1,000万円を超えるのかの感覚がありません。RFIの段階では正式見積でなくてもかまわないので、概算費用や一般的な価格帯を聞いておきましょう。社内での予算検討や稟議の材料になります。
RFIで得られる3つの成果
- 選択肢：自社が知らなかった実現手段が見つかる
- 相場観：費用と期間のレンジがつかめ、予算が組める
- 候補企業：提案を依頼する会社を、根拠を持って絞り込める
RFIが必要なケース・不要なケース
すべての案件でRFIが必要なわけではありません。判断の基準はシンプルで、「意思決定に必要な情報が、すでに社内にそろっているか」だけです。次の3つの質問で判断できます。
- 解決したい課題に対して、実現手段（SaaS／パッケージ／スクラッチなど）の当たりがついている
- 相談する開発会社の候補が2〜3社に絞れている
- おおよその費用と期間のレンジが分かっている
RFIは「必ず作らなければならない書類」ではありません。情報が足りないときの手段として使います。
RFIが特に役立つケース
- どんなシステムにすべきか決まっていない／「紙の申請業務をデジタル化したい」など、目的だけが決まっている段階
- 技術的な選択肢が分からない／クラウド、SaaS、API連携、AI、ノーコードなど、自社だけでは比較しづらい
- 開発会社の候補が決まっていない／実績・得意分野・開発体制・保守体制を横並びで確認したい
- 費用感がまったく分からない／予算枠を社内で決めるための根拠がほしい
RFIを省略できるケース
- 依頼する開発会社がすでに決まっている（過去に取引実績があるなど）
- 導入する製品・サービスが決まっている
- 開発内容が明確で、機能も固まっている
- 既存システムの小規模な改修だけを依頼する
- すでに十分な情報収集・比較検討を終えている
RFIに書く6つの項目
RFIに決まった書式はありません。目的は複数社から「比較できる形」で情報を集めることですから、各社に同じ質問を投げられる構成になっていれば十分です。一般的には次の6項目で構成します。
- 01会社概要社名・業種・事業内容・従業員数・拠点数。詳細な会社紹介は不要です。
- 02プロジェクトの背景なぜ今、システム導入を検討しているのか。きっかけと経緯を簡潔に。
- 03現在の課題困っている事実を具体的に。機能ではなく「困りごと」を書くのがコツ。
- 04実現したいこと導入後にどうなっていたいか。優先度が高いものから並べます。
- 05情報提供してほしい内容RFIの心臓部。回答してほしい項目を番号付きで明示します。
- 06回答方法と期限提出先・提出形式・回答期限・問い合わせ窓口を明記します。
05が最重要です。ここが曖昧だと、各社バラバラの形式で回答が返ってきて比較できなくなります。
3. 現在の課題は「機能」ではなく「事実」で書く
この段階でいちばん重要なのが、課題を具体的な事実として書くことです。
- Excelへの二重入力が発生しており、1日あたり合計2時間ほどかかっている
- 顧客情報が担当者ごとのファイルに分かれ、部署をまたいで共有できない
- 月末の集計に3営業日かかっている
- 特定の担当者しか手順を把握していない業務がある
「検索機能がほしい」といった機能の要望より、今どう困っているかを書くほうが、各社から幅のある解決策が返ってきます。数字を1つでも添えると、提案の精度が上がります。
5. 情報提供してほしい内容は、番号を振って具体的に
回答してほしい項目は、そのまま回答フォーマットになるよう番号付きで並べます。よく使われる質問項目は次のとおりです。
- 推奨するシステム構成・サービス
- SaaS／パッケージ／スクラッチ開発のどれが適しているか、その理由
- 類似システムの開発・導入実績（業種・規模）
- 導入・開発に必要な期間の目安
- 概算費用（初期費用・月額費用の内訳）
- 開発体制（担当者の人数・役割・自社開発か協力会社か）
- 導入後の保守・運用・サポート内容
- 想定されるリスクや課題
- 発注側で準備すべきこと
そのまま使えるRFIテンプレート
初めてRFIを作るなら、数十ページの資料は必要ありません。A4で1〜2枚、次の内容があれば情報収集は始められます。青字部分を自社の内容に置き換えてお使いください。
1. 会社概要
- 会社名：株式会社〇〇
- 事業内容：〇〇の製造・販売
- 従業員数：〇〇名／拠点数：〇拠点
- 本件の担当部署：〇〇部
2. プロジェクトの背景
現在、顧客情報および営業案件をExcelで管理していますが、担当者ごとにファイルが分かれており、情報共有と集計に時間がかかっています。営業体制の拡大にともない、情報を一元管理できる仕組みの導入を検討しています。
3. 現在の課題
- 担当者ごとにExcelファイルが分かれ、最新版がどれか分からなくなることがある
- 顧客への対応履歴が個人に閉じており、引き継ぎに時間がかかる
- 営業案件の進捗をリアルタイムに把握できない
- 月次集計に〇営業日かかっている
4. 実現したいこと
- 顧客情報の一元管理
- 営業案件の進捗管理
- 対応履歴の共有
- 売上見込みの自動集計
- PC・スマートフォンの両方からの利用
5. 情報提供をお願いしたい内容
- 推奨するシステム・サービスの構成
- SaaS導入とスクラッチ開発のどちらが適しているか、およびその理由
- 類似案件の導入・開発実績（業種・規模・時期）
- 導入までのおおよその期間
- 概算費用（初期費用・月額費用の内訳）
- 開発・導入の体制
- 導入後の保守・サポート内容
- 当社側で準備が必要な事項
- その他、検討にあたり留意すべき点
6. 回答方法・期限
- 回答期限：〇年〇月〇日
- 提出方法：メール（PDFまたはPowerPoint）
- 提出先・問い合わせ窓口：〇〇部 〇〇（メールアドレス）
- 本件は情報提供の依頼であり、正式な発注・見積依頼ではありません
要は、「課題」＋「実現したいこと」＋「聞きたいこと」の3点がまとまっていれば、RFIとして十分に機能します。
送付時のメール文例
送付から回答回収までの進め方
RFIの価値は「複数社を同じ土俵で比較できること」にあります。そのため、同じ内容を、同じ期限で、複数社に送るのが原則です。
- 1〜2週目RFI作成課題の整理と質問項目の確定。社内の関係部署にも確認
- 2週目候補企業の選定3〜5社を目安に。得意分野が偏らないよう選ぶ
- 3〜4週目送付・回答待ち回答期限は2週間程度を確保。短すぎると辞退されやすい
- 5週目回答の比較・整理比較表にまとめ、必要なら追加ヒアリング
- 6週目〜RFP作成へ方針と予算を固め、提案依頼のフェーズへ進む
期間はプロジェクト規模により前後します。年度末など繁忙期は、回答に時間がかかる点も見込んでおきましょう。
送付する社数は3〜5社が目安
1〜2社では比較になりません。逆に10社を超えると、回答の読み込みと比較だけで担当者の負担が大きくなります。得意分野が異なる3〜5社に送るのが現実的です。たとえば「SaaS導入支援に強い会社」「業務システムの受託開発に強い会社」「同業種の実績がある会社」といった具合に、あえてタイプを散らすと選択肢が広がります。
機密情報の扱いに注意
RFIは正式契約前の企業にも送るため、機密情報の書きすぎは避けます。原価率、取引先名、個人情報、詳細な財務データなどは、この段階では不要です。どうしても共有が必要な場合は、先にNDA（秘密保持契約）を締結してから送付してください。あわせて「本書の情報を第三者に開示しないこと」「本書は発注を確約するものではないこと」の2点を明記しておくと安心です。
回答の比較方法と、価格で選ばないための視点
回答が集まったら、そのまま読み比べるのではなく、比較表に落とし込みます。同じ質問をしているからこそ、この形にまとめられます。
| 比較項目 | A社 | B社 | C社 |
|---|---|---|---|
| 推奨方法 | SaaS導入 | スクラッチ開発 | SaaS＋一部開発 |
| 概算費用（初期） | 300万円 | 800万円 | 250万円 |
| 月額費用 | 8万円 | 10万円（保守） | 12万円 |
| 導入期間 | 3か月 | 6か月 | 2か月 |
| 類似実績 | 10件 | 20件 | 5件 |
| 同業種の実績 | あり | なし | あり |
| 開発体制 | 自社3名 | 自社5名 | 自社1名＋協力会社 |
| 保守・サポート | 平日9-18時 | 月次定例あり | メールのみ |
| デメリットの説明 | あり | あり | なし |
この形にすると、単に「いくらでできますか」と聞くよりも、各社の考え方の違いと得意分野まで見えてきます。上の例なら、A社とC社は同じSaaS推奨でも、体制とサポートの厚みが違うことが分かります。
価格だけで開発会社を判断しない
金額はどうしても目を引きますが、RFIの段階では前提条件がそろっていないため、金額の単純比較はほとんど意味がありません。安い見積は「対応範囲が狭い」だけかもしれず、高い見積は「リスクを織り込んでいる」だけかもしれないからです。次の観点もあわせて確認してください。
- 自社と同じ業界・同じ規模の実績があるか
- 類似システムの開発経験があるか
- こちらの課題を正しく理解した回答になっているか
- ひとつの方法を押しつけず、複数の選択肢を示しているか
- メリットだけでなく、デメリットやリスクも説明しているか
- 開発後の運用・保守まで考えた回答か
- 専門用語だけで押し切らず、分かりやすく説明しているか
特に初めての開発では、「言われたものを作る会社」ではなく「目的に合った方法を一緒に考えてくれる会社」かどうかという視点が効いてきます。RFIの回答は、その姿勢が最初に表れる場でもあります。
RFIとRFPの違い
RFIを調べると必ず出てくるのがRFPです。RFPは「Request for Proposal」の略で、日本語では提案依頼書。似ていますが、目的がはっきり違います。
「何ができるのか教えてください」
- 選択肢を広げるために使う
- 検討の初期段階
- 返ってくるのは情報
- 自社の状態：まだ方針が決まっていない
「この条件で、どう実現するか提案してください」
- 候補を絞り込むために使う
- 方針を整理したあと
- 返ってくるのは提案と見積
- 自社の状態：実現したい内容が固まっている
順番を逆にすると、前提が定まらないまま提案を受けることになり、各社の提案が比較できなくなります。
| 項目 | RFI | RFP |
|---|---|---|
| 日本語 | 情報提供依頼書 | 提案依頼書 |
| 主な目的 | 情報を集める | 具体的な提案を受ける |
| 使う時期 | 検討の初期 | 方針を整理した後 |
| 相手に求めるもの | 情報・見解 | 提案・見積 |
| 自社の状態 | 選択肢を調査している | 実現したい内容が固まっている |
| 記載の細かさ | 課題中心・A4で1〜2枚 | 要件・条件を明記・10枚以上も |
| 送付社数の目安 | 3〜5社 | 2〜3社 |
なお、価格や納期といった条件だけを提示して見積を依頼するRFQ（Request for Quotation／見積依頼書）という書類もあります。仕様がすでに固まっている場合に、RFPの代わりに使われることがあります。
RFIでよくある3つの失敗
失敗1：最初から仕様を細かく決めすぎる
まだ情報収集の段階なのに「この機能を、この技術で作る」と決め込んでしまうと、開発会社はその前提の中でしか答えられません。結果として、より安く早い選択肢を提案してもらえなくなります。RFIでは「どう作るか」より「何を解決したいか」を伝えてください。
失敗2：会社ごとに質問内容が違う
相手に合わせて質問を変えてしまうと、回答を横並びにできません。基本の質問項目を先に固定し、同じものを全社に送りましょう。追加で聞きたいことがあれば、共通質問の後ろに「任意回答」として付け足す形にします。
失敗3：概算費用だけを聞いてしまう
金額だけを聞くと、その金額になった理由が分かりません。費用は必ず、次の3点とセットで確認します。
- どの実現方式を想定した金額か（SaaSかスクラッチか）
- どの程度の期間を前提にしているか
- どこまでが対応範囲に含まれるか（要件定義・データ移行・教育・保守など）
RFIの作成が難しいときは、第三者に相談する方法もある
「そもそも何を質問すればいいのか分からない」という状態も、初めての発注では珍しくありません。その場合は、開発会社に問い合わせる前に、ITコンサルタントやシステム開発に詳しい第三者に相談する方法があります。
第三者に依頼できるのは、たとえば次のような部分です。
- 現状の課題整理と、システム化する範囲の切り分け
- 実現手段の比較（SaaS／パッケージ／スクラッチ）
- RFIの作成と質問項目の設計
- 候補となる開発会社のリストアップ
- 各社回答の比較・評価
システム開発では、実装そのものよりも「何を作るのか」「誰に頼むのか」を整理する工程が成否を分けます。ここに時間をかける価値は十分にあります。
よくある質問
RFIは必ず作らなければいけませんか？
いいえ。RFIは義務ではありません。依頼先や導入製品がすでに決まっている場合、小規模な改修の場合は省略してかまいません。判断基準は「意思決定に必要な情報がそろっているか」です。
RFIに費用は発生しますか？
通常、RFIへの回答は無償で対応してもらえるケースがほとんどです。ただし、詳細な現状調査や業務分析まで依頼する場合は有償になることがあります。無償の情報提供の範囲を超える依頼になっていないか、注意してください。
RFIを送ったら、その会社に発注しなければいけませんか？
その必要はありません。RFIはあくまで情報提供の依頼です。誤解を避けるため、書面に「本件は情報提供の依頼であり、発注を確約するものではありません」と明記しておきましょう。
回答期限はどのくらい設定すべきですか？
2週間程度が目安です。1週間を切ると、丁寧に回答したい会社ほど辞退しやすくなります。期限を明記し、あわせて問い合わせ窓口も記載しておくと回答率が上がります。
RFIとRFPは、必ず両方作るものですか？
両方作るのが理想ですが、方針と候補企業がすでに固まっているならRFIは不要です。逆に、情報が足りない状態でRFPだけを作ると、各社の提案の前提がバラバラになり比較が難しくなります。
回答をもらった会社には、結果を伝えるべきですか？
伝えることをおすすめします。無償で工数をかけてもらっているため、検討結果や次のステップの有無を簡単に連絡しておくと、今後の関係づくりにもつながります。
まとめ｜RFIはシステム開発の「情報収集」に使う資料
RFIは、開発会社やITベンダーに情報提供を依頼するための資料です。特に次のような企業にとって、有効な情報収集の手段になります。
- 初めてシステム開発を発注する
- どんな実現方法があるのか分からない
- 開発会社を横並びで比較したい
- 費用感がつかめていない
- 社内に技術的な知見が少ない
ただし、大切なのはRFIという書類を作ること自体ではありません。目的は自社の課題を整理し、それを解決するための選択肢を十分に集めることです。A4で1〜2枚でも、複数社に同じ質問が届けば役割は果たせます。
初めてのシステム開発、進め方の全体像
- RFIで「選択肢を知る」／3〜5社に同じ質問を送り、実現手段・実績・概算費用を集める
- 方針と予算を固める／集めた情報をもとに、社内で優先順位を決める
- RFPで「条件を伝えて提案を受ける」／2〜3社に絞り、提案と見積を依頼する
- 提案・見積を比較する／金額だけでなく、体制・保守・進め方まで見る
- 開発会社を決める
この流れを押さえておくと、初めてのシステム開発でも、どの段階で何を決めればよいのかが見えてきます。次の記事では、RFPとは何か、RFPには何を書けばよいのか、開発会社から提案を受けるまでの流れを詳しく解説します。
