RFP システム開発の書き方｜仕様が固まらない新規事業向け

この記事では、仕様が固まりきらない新規事業で、提案依頼書（RFP）に何を書き、何を書かずに残すかを整理します。細かな機能を埋めるのではなく、目的、確かめたいこと、制約、提案してほしい範囲を書くことで、開発会社から比べやすい提案を引き出せます。

RFPとは何か、新規事業で書きにくい理由

RFPは「Request for Proposal」の略で、日本語では提案依頼書といいます。システム開発を外注するとき、発注する側が開発会社に「こういう課題があるので、解決の提案と見積もりを出してほしい」と伝える文書です。複数の会社に同じ内容を渡すことで、提案を同じ条件で比べられるようになります。

一般に流通しているRFPのひな形は、基幹システムの入れ替えのように、すでにある業務を前提にした案件を想定しています。現行の業務フローがあり、必要な機能も洗い出せるため、機能一覧や性能要件を細かく埋める書き方が成り立ちます。

新規事業では前提が違います。誰がどの場面で使うのか、どの機能が事業の成否を分けるのかは、まだ仮説の段階にあることがほとんどです。そこで無理にひな形の欄を埋めると、推測で書いた仕様が各社の見積もりの前提になります。あとから実際の姿とずれ、「話が違う」という事態につながります。見積もりの前提による違いについては、システム開発の見積もりの違い｜金額より先に見る前提と範囲でも整理しています。

つまり、新規事業のRFPで求められるのは「決まっていることを正確に書く」ことと、「決まっていないことを決まっていないと書く」ことの両方です。

先に整理したい、固定する部分と開いておく部分

RFPを書き始める前に、情報を2つに分けておくと作業が進めやすくなります。

固定して書く部分は、次のようなものです。

• 事業の目的と背景
• 確かめたい仮説と、その判断の基準
• 想定する利用者と使う場面
• 期限や体制などの制約条件

開いておく部分は、次のようなものです。

• 画面や機能の細かな仕様
• 使う技術やインフラの具体的な選定
• 開発の進め方の細部
• 将来の拡張範囲

ここで大切なのは、開いておく部分を空欄のまま放置しないことです。「未定」と書くだけでなく、なぜ未定なのか、いつ・何を見て決めるのかまで添えます。たとえば「決済方法は利用者の反応を見て決めたい。最初は1つの方法で始め、検証後に追加するか判断する」と書けば、提案する側も、変更を見込んだ進め方を考えやすくなります。

仕様が決まっていない段階での相談そのものについては、仕様が決まってないシステム開発の相談は可能かで詳しく扱っています。

新規事業のRFPに書く8つの項目

ここからは、実際に書く項目を順に見ていきます。すべてを厚く書く必要はなく、A4で数枚に収まる程度でも、提案の質は大きく変わります。

1. 背景と目的

なぜこの事業に取り組むのか、システムは事業の中でどんな役割を担うのかを書きます。「会員向けサービスを作りたい」ではなく、「新しい顧客層に向けたサービスを始めたい。そのサービスの中心となる体験を、システムで提供したい」のように、システムの先にある事業の狙いまで伝えます。

システム自体が事業の中核になる新規事業では特に、この部分が提案の方向を決めます。目的が伝わっていれば、開発会社は機能の指示を待つだけでなく、事業の形を踏まえた提案をしやすくなります。

2. 確かめたい仮説と判断の基準

新規事業の最初の開発は、完成品を作ることよりも、仮説を確かめることに意味があります。「どんな利用者が、どんな場面で使うと考えているのか」「何が確認できたら次に進み、何が確認できたら見直すのか」を書きます。

判断の基準を数字で書けるなら書き、まだ数字にできなければ、観察したい行動として書いても構いません。指標の決め方はMVP検証の指標を先に決める方法｜判断基準の作り方が参考になります。

3. 想定する利用者と使う場面

誰が、いつ、どこで、何のために使うのかを書きます。利用者の人物像を細かく作り込む必要はありません。「現場の担当者がスマートフォンで使う」「運営側が管理画面で確認する」といった程度でも、画面の方針や優先順位を考える材料になります。

管理画面をどこまで作るかは、新規事業で判断が分かれやすい点です。考え方は新規事業の管理画面開発｜最初に作る範囲の見極め方にまとめています。

4. 現時点で決まっていること・決まっていないこと

この項目が、新規事業のRFPでもっとも効果を発揮します。表のように、次の3つに分けて書きます。

• 決まっていること（変えられない前提）
• 仮の案があるが、変わる可能性があること
• まったく決まっていないこと

仮の案には「仮」と明記します。仮の案を確定した要件のように書くと、見積もりの前提として固定されてしまいます。逆に、決まっていない部分を正直に書いておけば、変更が起きたときの扱いも事前に話し合いやすくなります。変更への向き合い方は、システム開発の仕様変更への対応｜追加要望の扱い方で整理しています。

5. 制約条件

仕様が決まっていなくても、制約は書けることが多いものです。

• 公開や検証開始の希望時期
• 既存システムとの連携の有無
• 扱うデータの種類（個人情報を含むかどうかなど）
• 守る必要のある社内ルールや業界の規制
• 使いたい、または使えない外部サービスや技術

特に個人情報を扱う場合は、設計の前提が大きく変わります。確認すべき点は新規事業の個人情報とシステム設計｜設計前に確認する点にあります。既存システムとの関係は、新規事業は既存システムと切り離して作る理由と進め方も参考になります。

6. 提案してほしい範囲と進め方

何を提案してほしいのかを明確にします。画面や機能の案だけなのか、開発の進め方やスケジュールも含めるのか、運用や改善の体制まで求めるのかで、返ってくる提案の幅が変わります。

新規事業では、「最初に何を作って何を確かめるか」の提案を求めると、各社の考え方の違いが見えやすくなります。最初に作る範囲の考え方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準で扱っています。

7. 発注側の体制と意思決定

誰が窓口になり、誰が最終判断をするのか、連絡や確認にどれくらいの時間を割けるのかを書きます。開発が遅れる原因は、技術ではなく発注側の判断待ちにあることも珍しくありません。役割の考え方は発注側のプロダクトオーナーとは｜役割と判断のしかたが参考になります。

8. 秘密保持と提出に関する事項

RFPには、事業のアイデアや想定顧客といった機密性の高い情報が含まれます。RFPを渡す前に、秘密保持契約（NDA）を結ぶのが一般的です。決める項目はシステム開発のNDA｜秘密保持で決める8つの項目にまとめています。

あわせて、提案の提出期限、質問の受付方法、提案を評価する観点、選定までの流れも書いておきます。

機能は「必須」「できれば」「未定」に分けて書く

機能を書かずに提案を求めるのは難しいため、機能を書く場合は書き方を工夫します。

おすすめは、機能を3つに分ける方法です。

• 必須：これがなければ仮説を確かめられない機能
• できれば：あると検証の質が上がるが、なくても始められる機能
• 未定：検証の結果を見て決める機能

判断のよりどころは「仮説の検証に必要かどうか」です。便利かどうか、あれば嬉しいかどうかではなく、確かめたいことに直結するかで分けます。この基準で整理すると、必須の機能は意外に少なく収まることが多いものです。

機能の説明は、「〜ができる」という書き方よりも、「利用者が〜できるようになることで、〜を確かめたい」と、目的とセットで書きます。目的が添えられていれば、開発会社は、同じ目的を満たすより簡単な方法を提案できます。

言葉で作りたいものを伝える手順は、AI開発の仕様の伝え方｜作りたいものを言葉にする手順にも書いています。要件定義全体の進め方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。

提案に答えてほしい質問を用意する

RFPでは、開発会社への質問を用意しておくと、提案の中身を比べやすくなります。新規事業なら、次のような質問が役に立ちます。

• 仕様が固まっていない部分を、どう進めるつもりか
• 最初に何を作り、何を確かめる計画か
• 実際に動くものを、いつの時点で見られるか
• 見てから方向を変えたくなった場合、どう対応するか
• 見積もりの前提は何か、どの範囲が含まれ、どの範囲が含まれないか
• 開発後の修正や機能追加は、どのような形で対応できるか
• 成果物の権利や、ソースコードの扱いはどうなるか
• 開発にAIを使う場合、どの工程で使い、人はどこを確認するか

とくに「実際に動くものをいつ見られるか」は、新規事業では大きな分かれ目になります。文書や図だけで合意して進める方法もあれば、先に動く試作品を作って確かめながら進める方法もあります。どちらが優れているというより、事業の不確実性に合うかどうかで考えます。企画書だけで判断を求められる難しさは、新規事業の決裁を企画書だけで取るのが難しい理由で触れています。

権利の扱いは、費用を払えば自動的に移るとは限りません。確認したい点はソースコードの著作権譲渡｜費用を払っても自動では移らないにあります。

提案を比べるときの見方

提案が届いたら、金額だけで比べないようにします。新規事業では、次の視点が役に立ちます。

前提と範囲がそろっているか

見積もりの金額が違う理由の多くは、前提と範囲の違いです。どこまでが含まれ、何が含まれていないのかを、各社の提案で確認します。RFPで「仮」「未定」と書いた部分を、各社がどう扱っているかを見ると、考え方の違いがはっきりします。

不確実な部分の扱いが具体的か

「柔軟に対応します」という言葉だけでは、何も判断できません。決まっていない部分を、いつ、どんな材料で、誰が決めるのかが示されているかを見ます。

契約の形と進め方が合っているか

契約の形は、請負契約と準委任契約が代表的です。請負は完成した成果物に対して責任を負う形、準委任は業務の遂行そのものを委ねる形です。仕様が固まっていない段階で請負契約を結ぶと、仕様変更のたびに協議が必要になります。反対に準委任では、成果物の完成が約束されるわけではありません。違いは受託開発とは？メリット・デメリットと依頼の流れ・契約の違いで整理しています。

公的な資料としては、経済産業省が公開している「情報システム・モデル取引・契約書」があります。契約の考え方や、段階的に契約を結ぶ進め方の参考になるため、契約条件を検討する際に確認するとよい資料です。内容の詳細は、最新版を公式の資料で確かめてください。

質問への答え方に誠実さがあるか

提案の途中で質問を投げたとき、どのくらい具体的に、わかりやすく答えてくれるかも、判断材料になります。開発が始まってからのやり取りの質を、先に見られる機会でもあります。会社選びの視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点にまとめています。

書きすぎ、書かなさすぎで起きやすい失敗

最後に、RFPでよく起きる失敗を見ておきます。

書きすぎの失敗は、推測の仕様を確定事項のように書いてしまうことです。細かく書けば安心できるように思えますが、あとで事実と違うことがわかったとき、変更の協議が増え、関係がぎくしゃくします。

書かなさすぎの失敗は、目的も制約も書かず、「こういうサービスを作りたいので見積もりがほしい」とだけ伝えることです。各社が自由に前提を置くため、提案の内容も金額もばらばらになり、比べることができません。

もう1つ、見落とされやすいのが、RFPを書くこと自体が目的になってしまう失敗です。書いているうちに、自分たちの中で目的や判断の基準がまだそろっていないことに気づくことがあります。それ自体が、RFPを書く価値の1つです。社内で認識をそろえたうえで、外に出すようにします。

なお、RFPを完璧に仕上げることよりも、開発会社と早めに話し始めることが役に立つ場面もあります。小規模な案件の相談の仕方は、小規模なシステム開発を依頼できる？断られにくい相談のしかたを参考にしてください。外注全体の流れは、システム開発の外注｜メリット・デメリットと失敗しない進め方で扱っています。

まとめ

仕様が固まりきらない新規事業のRFPでは、細かな機能を並べるよりも、決まっていることと決まっていないことを分けて書くことが大切です。ポイントを整理します。

• 目的、確かめたい仮説、判断の基準、制約条件は固定して書く
• 機能の細部や技術の選定は、「仮」「未定」と明記し、決める時期や材料も添える
• 機能は「必須」「できれば」「未定」に分け、仮説の検証に必要かで判断する
• 動くものをいつ見られるか、不確実な部分をどう扱うかを、開発会社への質問に入れる
• 提案は金額だけでなく、前提・範囲・契約の形・質問への答え方で比べる

RFPは、開発会社に条件を渡す文書であると同時に、私たち自身が事業の前提を整理する道具でもあります。完璧な仕様書を目指すより、わかっていることとわかっていないことを誠実に書くほうが、結果的に良い提案を引き出せます。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。RFPの形になる前の構想でも、整理するところから一緒に考えられますので、詳しくはJustFitのサービス紹介をご覧ください。