RFP（提案依頼書）が必要だと分かっても、実際にどう書けばいいのか分からず、手が止まってしまうことがあります。「フォーマットを調べても、企業向けの分厚いテンプレートしか出てこない」「専門用語が多くて、自分の状況にどう当てはめればいいか分からない」という声もよく聞きます。この記事では、個人でも書ける、簡易RFPの型を、実際に埋められるテンプレート形式で紹介します。
この記事で分かること
簡易RFPは、厳格な様式を覚える必要はなく、いくつかの項目を箇条書きで埋めるだけで作成できます。この記事では、そのまま使える型を紹介します。
結論を先に示すと、簡易RFPに含めるべき項目は、次の6つです。
- 解決したい課題
- 想定している利用者
- 必須の機能／あればよい機能
- 予算感
- 希望するスケジュール
- その他の制約事項
企業のRFPには、この6項目のほかに、会社概要・選定基準・提案書の提出形式・評価方法など、さらに多くの項目が並ぶことがあります。しかし、個人・複業でのサービス立ち上げの場面では、それらの項目は多くの場合不要です。開発会社が「何を作るべきか」「いくらで、いつまでに」を判断できるだけの情報があれば、十分に機能します。
なぜ「簡易」でよいのか
個人が発注者になる場面で本格的なRFPを書こうとすると、次のような壁にぶつかりがちです。
- 項目数が多く、書き始める前に挫折してしまう
- 「評価基準」「提案書の体裁」など、社内選定プロセスを前提にした項目が自分の状況に当てはまらない
- 完璧に書こうとして、結局何も出せないまま時間だけが過ぎる
簡易RFPは、これらの壁を取り除くために、本当に必要な情報だけに絞った型です。企業のRFPが「社内の複数の関係者を説得し、公平に会社を選定するための文書」であるのに対して、個人の簡易RFPは「自分の頭の中にある構想を、開発会社に正確に伝えるためのメモ」だと考えると分かりやすいでしょう。目的が違うので、フォーマットも簡略化してよいのです。
簡易RFPの型：そのまま使えるテンプレート
以下の項目を、それぞれ2〜3行程度の箇条書きで埋めていくことをおすすめします。文章としてきれいにまとめる必要はありません。開発会社の担当者が読んで理解できれば、それで十分です。
1. 解決したい課題
「誰の、どんな悩みを解決したいか」を、一文で書きます。例：「個人で活動している整体師が、予約の管理と顧客カルテの記録を、紙とスプレッドシートで別々に管理していて、二重入力の手間がかかっている」
課題を書く際のポイントは、「誰が」「何に困っていて」「今どうやって回避しているか」の3点を入れることです。この3点があると、開発会社側は、単なる機能要望ではなく、業務の全体像を理解した上で提案を組み立てられます。
具体例をもう一つ挙げます。「フリーランスの写真家が、撮影後の写真選定と納品を、メールとクラウドストレージのリンク共有で行っており、クライアントごとに操作方法を説明する手間がかかっている」というように、業種が異なっても同じ型で書けます。
2. 想定している利用者
このサービス・ツールを、誰が使うのかを書きます。例：「利用者は自分自身（1人）。将来的には、同業の知人数名にも使ってもらうことを想定」
利用者の人数と属性は、システムの設計に直接影響します。1人で使うツールと、数十人が同時に使うサービスでは、必要な機能もセキュリティ要件も大きく異なります。「今は自分だけだが、将来は他の人にも使ってもらいたい」という見通しがあるなら、それも書いておくと、開発会社側が拡張性を考慮した設計を提案しやすくなります。
逆に「利用者は自分1人だけで、他の人に使わせる予定はない」という場合も、その旨を明記しておくと、過剰な設計（例えば複数アカウント管理の仕組みなど）を避けられ、予算を抑えられる可能性があります。
3. 必須の機能／あればよい機能
必ず必要な機能と、あれば嬉しいが必須ではない機能を、分けて書きます。
- 必須：予約の記録、顧客ごとのカルテ記録、予約と顧客の紐付け
- あればよい：予約のリマインドメール送信、売上の自動集計
この項目が、簡易RFPの中でもっとも重要です。多くの個人発注者は、思いついた機能を全部「必須」に入れてしまいがちですが、それでは開発会社側が優先順位をつけられず、見積もりが膨らみやすくなります。「これがないと、そもそもサービスとして成立しない」機能だけを必須に絞り、それ以外は「あればよい」に振り分けることを意識してください。
判断の目安としては、「その機能がなくても、最初のバージョンをリリースできるか」を自問することです。リリースできるなら「あればよい」、リリースできないなら「必須」、という基準で仕分けると迷いにくくなります。
4. 予算感
具体的な金額を1点で示すのではなく、幅を持たせて書きます。例：「50万円〜100万円程度を想定」
予算感を先に伝えることに抵抗を感じる人もいますが、開発会社側からすると、予算のレンジが分からないまま提案を作るのは、的外れな提案になるリスクが高い作業です。予算に幅を持たせて早めに共有することで、開発会社側も「その予算でできること」を前提にした、現実的な提案を返しやすくなります。
もし予算がまったく決まっていない場合は、次の「埋められない項目」の章で説明する対応方法を参考にしてください。
5. 希望するスケジュール
いつまでに、どういう状態にしたいかを書きます。例：「3ヶ月後には、最低限の機能で自分が使い始められる状態にしたい」
スケジュールを書く際は、「いつまでに」だけでなく、「その時点でどういう状態になっていればよいか」もセットで書くのがポイントです。「3ヶ月後に完成」という書き方だと、開発会社側は「完成」の定義を推測するしかありませんが、「3ヶ月後には最低限の機能で使い始められる状態にしたい」と書けば、必須機能だけを先に仕上げるという優先順位も自然に伝わります。
6. その他の制約事項
既存のツールとの連携や、特別な事情があれば書きます。例：「現在使っているスプレッドシートのデータを、新しいツールに移行したい」
この項目には、他の5項目に当てはまらない、個別事情をまとめて書きます。よくある例としては、既存データの移行、特定の決済サービスとの連携、業界特有の法規制への対応、家族や共同経営者との合意事項などが挙げられます。小さな事情でも、後から発覚すると見積もりや期間に影響することがあるため、思いつく限り書き出しておくことをおすすめします。
この型を、どう使うか
この6項目を埋めた資料を、複数の開発会社に、同じ形で共有することをおすすめします。この資料があることで、開発会社側も、要望を正確に理解した上で、提案や見積もりを作成しやすくなります。
相見積もりを取る際、条件をそろえるための伝え方については、別記事でも詳しく解説していますが、この簡易RFPは、その「条件をそろえる」ことを、具体的な形にしたものと言えます。同じ資料を、同じタイミングで、複数の会社に渡すだけで、比較の土台がそろいます。
実際の使い方としては、次のような流れが典型的です。
- 6項目を箇条書きで埋め、1枚のドキュメント（Googleドキュメントやテキストファイルで十分）にまとめる
- 相談したい開発会社2〜3社に、同じ資料を共有する
- 各社からの初回ヒアリングや見積もりを受け取り、比較する
- 資料に書いていなかった疑問点が出てきたら、資料自体を更新していく
この資料は、一度作って終わりではなく、相談を重ねる中で少しずつ更新していくものだと考えておくとよいでしょう。開発会社からの質問に答えるたびに、資料の内容が具体化していきます。なお、資料を渡した後の実際のヒアリングの場でどう話せば要件定義が正確に伝わるかについては、要件定義のヒアリングのコツでも取り上げられている。
埋められない項目があっても、無理に完成させなくてよい
6項目のうち、まだ決まっていない項目（特に、予算感やスケジュール）がある場合、無理に埋めようとせず、「まだ決まっていません」と正直に書いておくことをおすすめします。開発会社側は、その項目について、相談の中で一緒に検討してくれることが一般的です。
特に予算感については、「相場が分からないので、まずは概算を教えてほしい」と書いてしまってもかまいません。多くの開発会社は、初回の相談やヒアリングを無料で行っており、その場で概算のレンジを提示してくれます。何も分からない状態で無理に数字を書くよりも、正直に「分からない」と書いた方が、結果的にスムーズに話が進むことが多いです。
スケジュールについても同様です。「特に期限は決めていないが、できるだけ早く始めたい」という書き方でも問題ありません。重要なのは、項目を空欄のまま黙って渡すのではなく、「未定である」ということ自体を明示的に伝えることです。
簡易RFPを作成する際の、よくある失敗
失敗1：必須の機能と、あればよい機能を分けずに書いてしまう
すべての機能を「必須」として書いてしまうと、開発会社側は、その全部を実現する前提の見積もりを出すことになり、予算に見合わない金額になることがあります。優先順位を分けて書くことを、意識することをおすすめします。
たとえば、予約管理ツールを作りたい場合に、「予約管理」「顧客管理」「売上集計」「リマインドメール」「口コミ機能」「多言語対応」を全部「必須」と書いてしまうと、見積もりは当然大きくなります。実際にサービスを始めるために本当に必要なのは、最初の2つだけだったというケースは少なくありません。まず必須を絞り、残りは「あればよい」または「将来的に追加したい機能」として分けて書くことで、初期の見積もりを現実的な範囲に収められます。
失敗2：課題の背景を書かず、機能だけを列挙してしまう
「予約管理機能が欲しい」と機能だけを書くよりも、「なぜその機能が必要なのか」という課題の背景も書くことで、開発会社側が、より適切な提案をしやすくなります。
機能名だけを並べたリストは、一見詳しく見えますが、実際には開発会社側にとって解釈の余地が大きすぎます。「予約管理機能」という言葉だけでは、1日に何件の予約を想定しているのか、予約の変更やキャンセルにどう対応したいのか、複数の担当者で予約を共有するのかなど、実装に関わる多くの判断が開発会社側に委ねられてしまいます。課題の背景（誰が、どう困っていて、今どう回避しているか）を添えることで、こうした解釈のずれを事前に減らせます。
失敗3：予算感を一切書かず、見積もり任せにしてしまう
「予算は特に決めていないので、御社の見積もりを見てから考えます」という進め方も可能ですが、これを複数社に対して行うと、各社の提案の前提条件がそろわず、比較がしづらくなります。前述のとおり、予算が本当に未定であれば「未定」と明記した上で、「概算のレンジを提示してほしい」と一言添えるだけでも、後の比較がしやすくなります。
失敗4：スケジュールの希望を、後出しで伝えてしまう
見積もりを受け取ったあとに、「実は来月中に使い始めたい」と伝えると、開発会社側の体制やスケジュールの都合で、対応できなかったり、追加費用が発生したりすることがあります。スケジュールの希望は、簡易RFPの段階で最初から明示しておくことで、そもそも対応可能な開発会社を早い段階で絞り込むことができます。
失敗5：資料を作り込みすぎて、共有が遅れてしまう
簡易RFPという名前の通り、この資料は簡潔でよいものです。デザインを整えたり、図表を追加したり、文章を練り上げたりすることに時間をかけすぎて、共有するタイミングが遅れてしまうケースも見られます。箇条書きのメモ程度の完成度で十分なので、まずは6項目を埋めて、早めに開発会社に見せることを優先しましょう。内容は、相談を重ねる中で修正していけば問題ありません。
簡易RFPの完成度を確認するチェックリスト
資料を共有する前に、以下の項目をセルフチェックすると、抜け漏れを減らせます。
- [ ] 「解決したい課題」に、誰が・何に困っていて・今どう回避しているかの3点が入っているか
- [ ] 「想定している利用者」の人数と、将来的な拡張の見通しを書いたか
- [ ] 「必須の機能」と「あればよい機能」が、明確に分かれているか
- [ ] 「必須の機能」は、それがないとサービスとして成立しない機能だけに絞られているか
- [ ] 「予算感」は、1点ではなく幅で示しているか（未定なら「未定」と明記したか）
- [ ] 「希望するスケジュール」に、期限だけでなく、その時点で目指す状態も書いたか
- [ ] 「その他の制約事項」に、既存データの移行や外部サービス連携など、個別事情を書き出したか
- [ ] 専門知識を要するツールの場合、専門用語の説明や用語集への参照を追加したか
- [ ] 同じ資料を、複数の開発会社に、同じタイミングで共有できる状態になっているか
このチェックリストをすべて満たさなくても、共有を始めてかまいません。あくまで「最低限、これくらいは埋まっているか」を確認するための目安として使ってください。
専門知識を活かしたツールの場合、追加したい項目
専門分野の業務ロジックを含むツールの場合、この6項目に加えて、「専門用語の説明」または「用語集への参照」を追加しておくことをおすすめします。専門用語が多い業界の発注で、事前に用語集を渡すべき理由については、別記事で詳しく解説しています。
たとえば、整体・治療系のサービスであれば「施術」「カルテ」「初診・再診」といった業界特有の言葉、士業向けのツールであれば「案件」「期日管理」「顧問先」といった言葉が、業界の外の人には正確に伝わらないことがあります。専門用語を一つひとつ説明するのが難しい場合は、簡易RFPの中に「詳細は別紙の用語集を参照」と書き、用語集を別ファイルとして添付する形でもかまいません。
ケーススタディ：業種ごとの簡易RFP記入例
抽象的な説明だけでは、実際に自分の状況に当てはめにくいという人も多いため、業種別の記入例を3つ紹介します。それぞれ、同じ6項目のフォーマットに沿って書かれています。
ケース1：オンライン英会話講師（個人事業主）
- 解決したい課題：個人でオンライン英会話講師をしており、生徒とのレッスン予約・教材共有・レッスン後のフィードバック送付を、LINEとメールに分散して行っている。生徒が増えるにつれ管理が煩雑になってきた。
- 想定している利用者：自分1人が管理者として使用。生徒（現在12名、今後30名程度まで増える見込み）は予約と教材ダウンロードのみ利用。
- 必須の機能：レッスン予約カレンダー、生徒ごとの教材共有ページ、フィードバック記録
- あればよい機能：決済機能（現在は銀行振込）、レッスン録音の自動保存
- 予算感：30万円〜60万円程度を想定。相場が分からないため、概算を教えてほしい。
- 希望するスケジュール：2ヶ月後の新学期開始に合わせて、最低限予約と教材共有ができる状態にしたい。
- その他の制約事項：現在Googleカレンダーで予約管理をしているため、可能であれば連携したい。
ケース2：個人経営の学習塾（複業で運営）
- 解決したい課題：会社員をしながら複業で小規模な学習塾を運営しており、生徒の出席管理・保護者への連絡・月謝の請求書発行を、すべて手作業で行っている。生徒が増えるとミスが起きやすくなってきた。
- 想定している利用者：自分（塾長）1人が管理者。保護者（現在8世帯）は連絡確認と請求書の閲覧のみ利用。
- 必須の機能：出席記録、保護者への一斉連絡、月謝請求書の自動作成
- あればよい機能：オンライン授業の録画配布、成績の履歴管理
- 予算感：40万円〜80万円程度を想定。
- 希望するスケジュール：特に期限は決めていないが、次の学期（3ヶ月後）から使い始められると助かる。
- その他の制約事項：現在Excelで管理している生徒データを、新しいシステムに移行したい。保護者は年齢層が高く、操作が簡単なものにしてほしい。
ケース3：ハンドメイド作家（複業でネット販売）
- 解決したい課題：本業をしながら複業でハンドメイドアクセサリーを販売しており、在庫管理と受注管理を、SNSのDMと手書きノートで行っている。在庫の把握が難しく、売り切れ後の受注を受けてしまうミスが発生している。
- 想定している利用者：自分1人。将来的には、同じ活動をしている友人にもツールとして使ってもらうことを検討中。
- 必須の機能：在庫数の管理、受注時の在庫連動、売り切れ表示の自動化
- あればよい機能：売上グラフの自動集計、複数人での在庫共有
- 予算感：未定。相場が分からないため、まずは概算を知りたい。
- 希望するスケジュール：特に急いでいないが、半年以内に導入できればよい。
- その他の制約事項：現在Instagramで注文を受けているため、DMや投稿と連携できると理想的だが、必須ではない。
このように、業種がまったく異なっていても、6項目のフォーマット自体は変わりません。自分の状況を、この3つの例と同じ形式に当てはめて書き出してみると、取り掛かりやすくなるはずです。
簡易RFPを書く前に、頭の中を整理する方法
いきなり資料に書き始めようとすると、何から書けばいいか分からなくなることがあります。その場合は、次の順序で頭の中を整理してから、資料に書き出すことをおすすめします。
ステップ1：現状の困りごとを、時系列で書き出す
「朝、予約の確認をする」「顧客が来店したら、紙のカルテを取り出す」「施術後、次回予約を紙に書き込む」など、業務の流れを時系列で書き出します。この時系列の中で、「ここが手間だ」「ここでミスが起きやすい」と感じる箇所に印をつけます。この印をつけた箇所が、そのまま「解決したい課題」の材料になります。
ステップ2：印をつけた箇所を、機能に翻訳する
「予約の確認に時間がかかる」という困りごとは、「予約一覧をまとめて確認できる機能」という機能要望に翻訳できます。このように、困りごとを一つずつ機能の言葉に置き換えていく作業を行います。
ステップ3：翻訳した機能を、必須とあればよいに仕分ける
ステップ2で書き出した機能の一覧を見て、「これがないとサービスが成立しない」ものと、「なくても始められるが、あると助かる」ものに仕分けます。この仕分けが、簡易RFPの「必須の機能／あればよい機能」の項目にそのまま使えます。
ステップ4：予算とスケジュールの制約を確認する
最後に、自分が使える予算の上限と、使いたい時期を確認します。厳密に決まっていなくても、「このくらいまでなら出せる」「この時期までに使えないと困る」という、ざっくりとした感覚があれば、それを幅を持たせて書けば十分です。
この4ステップを踏んでから資料に書き始めると、6項目がスムーズに埋まりやすくなります。
簡易RFPを渡すタイミングと、渡し方
資料ができたら、いつ、どうやって開発会社に渡すかも重要です。ここでは、実務上のタイミングと渡し方の工夫を紹介します。
初回相談の「前」に渡す
多くの開発会社は、最初に無料相談やヒアリングの場を設けています。この初回相談の前に、簡易RFPを事前に送っておくと、当日の打ち合わせ時間を、資料の読み上げではなく、資料に対する質問や深掘りに使えるようになります。結果として、同じ1時間の打ち合わせでも、得られる情報の量が変わってきます。
事前に送る際は、メールやチャットの本文に「簡易的にまとめた資料を添付します。当日はこちらをもとにお話しできればと思います」といった一言を添えるだけで十分です。
資料の形式は、テキストで十分
簡易RFPは、デザインされた資料である必要はありません。Googleドキュメント、Word、あるいはメール本文に直接貼り付けたテキストでも、内容が伝わればまったく問題ありません。PDF化や体裁の調整に時間をかけるよりも、内容を早く共有することを優先しましょう。
複数社に渡す場合は、同じ文面・同じタイミングで
相見積もりを取る場合、A社には詳しく書いた資料を、B社には簡単なメモだけを送るというように、渡す情報量に差をつけてしまうと、返ってくる見積もりや提案の精度にも差が出てしまい、公平な比較ができなくなります。可能な限り、同じ内容の資料を、同じタイミングで、すべての会社に共有することを心がけてください。
簡易RFPがあることで、発注者側にもメリットがある
簡易RFPは、開発会社のためだけの資料ではありません。作成する過程そのものが、発注者自身にとっても大きな意味を持ちます。
一つ目は、自分の考えの整理です。頭の中でぼんやりと考えていた構想を、実際に文章として書き出してみると、「実はここがまだ決まっていなかった」「この機能は本当に必要なのか」といった発見が生まれます。この気づきは、開発会社に相談する前の段階で得られるほど、後の手戻りを減らすことにつながります。
二つ目は、判断のブレを減らせることです。複数の開発会社と話をしていると、それぞれの担当者の説明に影響されて、自分の要望が少しずつ変わってしまうことがあります。最初に作った簡易RFPという「基準」があれば、話をしているうちに軸がぶれてしまったときも、資料に立ち返って確認できます。
三つ目は、時間の節約です。同じ説明を何度も口頭で繰り返す必要がなくなるため、複数社と並行してやり取りする際の負担が大きく減ります。個人や複業でサービスを立ち上げる場合、時間そのものが最も限られたリソースであることが多いため、この効果は決して小さくありません。
この記事の次に読みたい記事
簡易RFPの型を理解したら、次は実際に開発会社に相談する準備を進めましょう。あわせて次の記事も参考にしてください。
