小さな会社のためのRFP（提案依頼書）の書き方

システム開発を複数の会社に相談したいが、「何を伝えればよいか分からない」「毎回同じ説明を繰り返している」。そんな状況で役に立つのが RFP（Request for Proposal、提案依頼書）です。大企業が使う分厚い文書を想像して構えてしまう方もいますが、小さな会社の RFP は数ページで十分です。この記事では、最低限の項目と書く手順、要件定義（システムに必要な機能や条件を決める作業）との関係、避けたい書き方を整理します。

RFP とは何か、小さな会社にも必要な理由

RFP は、「こういう課題があるので、解決策を提案してください」と開発会社に依頼する文書です。仕様書ではなく、提案を引き出すための依頼書です。

小さな会社でも RFP を書く利点は三つあります。

• 複数社の提案を同じ土俵で比較できる
• 社内で「何のために、何を作るのか」の認識がそろう
• 開発会社が前提を誤解したまま見積を出すことを防げる

想定例：口頭で「顧客管理を作りたい」と伝えたところ、ある会社は名刺管理程度の提案、別の会社は営業支援まで含む提案を出してきた、という状況です。前提が違うので、見積の差が何に由来するのか分からなくなります。RFP に「現状は表計算で管理しており、困っているのは重複と更新漏れ」と書いてあれば、提案の方向がそろいます。

RFP に入れる項目

小さな会社の RFP に入れる項目を、必須と任意に分けて示します。

一つひとつは短くて構いません。合計で数ページに収まる分量が、書く側にも読む側にも現実的です。

RFP を書く手順

難しく考える必要はありません。次の順に書き進めれば、2〜3ページの文書としてまとまります。書きながら決めきれない項目が出てきたら、「未定」と明記しておけば十分です。

ステップ1：目的と背景を一段落で書く

最初に「何のために」を書きます。「受注処理の転記作業をなくし、ミスと残業を減らしたい」のように、業務上の目的で書きます。機能名から入らないのがコツです。

ステップ2：現状の業務と困りごとを整理する

業務の流れを、順番に箇条書きにします。誰が、何を使って、何をしているか。そのどこで困っているか。ここが具体的なほど、提案の質が上がります。現在使っている表計算ファイルや帳票があれば、見本として添付します（個人情報は伏せます）。

ステップ3：必須要件と希望要件を分ける

要望をすべて「必須」にすると、費用が膨らむか、提案側が優先順位を判断できなくなります。「これがないと導入しない」ものだけを必須にし、それ以外は希望に回します。判断に迷うものは希望にしておき、提案を見てから決めます。

ステップ4：制約条件を書く

予算については、上限や幅を書くか、書かずに提案を受けるかを決めます。書いたほうが現実的な提案が集まります。ほかに、希望する稼働時期、既存のサーバーやドメイン、連携が必要な既存システム、利用する端末（スマートフォンでも使うか）を書きます。

ステップ5：提案してほしいことと評価の観点を書く

「システム構成」「進め方と体制」「費用の内訳」「導入後の保守内容」「想定するリスク」など、提案書に含めてほしい項目を列挙します。加えて、選定で重視する観点を書いておくと、提案側が焦点を絞れます。契約形態（請負契約か準委任契約か）の考え方も、提案に含めてもらうと比較しやすくなります。

ステップ6：送付先を選び、質問期間を設ける

送付先は、読み比べられる数に絞ります。質問を受け付ける期間を設け、ある会社からの質問と回答は全社に共有します。前提がそろうことで、提案の比較が公平になります。

要件定義との関係

RFP と要件定義は、役割が異なります。

RFP の段階で細かな仕様まで書き切る必要はありません。むしろ、書き切ろうとすると時間がかかり、提案側の工夫の余地も狭まります。RFP には「困りごと」と「必須の条件」を書き、「どう解決するか」は提案と要件定義に委ねるのが、小さな会社にとって現実的な分担です。

要件定義の後には基本設計・詳細設計（画面や処理の具体的な設計）が続きます。RFP は、その入り口にあたる文書だと位置づけてください。

避けたい書き方（想定例）

想定例として、提案側が困りやすい RFP の書き方を挙げます。

• 機能の羅列だけで目的がない：「顧客一覧、検索、CSV 出力、権限管理」とあっても、何を解決したいのか分からず、提案が的外れになりやすい
• 「使いやすく」「柔軟に」「最新の技術で」といった曖昧な言葉：受け取り方が会社ごとに違い、比較できない
• 他社のサービス名で要件を示す：「○○のような画面」は伝わりやすい反面、その仕組みの前提まで引き継いでしまう
• すべてが必須要件：優先順位がなく、費用の調整ができない
• 制約を隠す：予算や時期を伏せると、規模の合わない提案が集まる
• 現状の業務を書かない：提案側が業務を想像で補うことになり、要件定義でやり直しになる

書き直すときは、各項目を「誰が、何に困っていて、どうなれば解決か」の形に置き換えると、伝わる文章になります。

書く過程そのものが、社内の課題整理になる

• RFP は数ページでよく、目的・現状・必須要件・制約・提案してほしいことが書けていれば機能します
• 手順は、目的 → 現状 → 必須と希望の区別 → 制約 → 提案してほしいこと → 送付と質問期間、の順です
• RFP は要件定義の前段であり、細かな仕様は提案と要件定義に委ねます
• 曖昧な言葉と機能の羅列を避け、困っている業務を具体的に書きます

RFP を書く過程そのものが、社内の課題整理になります。書き上げた RFP を 業務効率化システム開発 の相談に持ち込んでいただければ、そこから要件定義へつなげられます。書き方に迷う場合も お問い合わせ からご相談ください。