アプリ開発の際に作成されるRFPとは「Request for Proposal」のことをいい、発注する側の要件を書き記した「提案依頼書」を意味します。受注側である開発会社にこのRFPを提出することで、発注側の要望や情報を正しく伝えることができ、自社の要望に合った提案を引き出すためには欠かせない書類となっています。似た言葉にRFIというものがありますが、これは「Request for Information」の略で「情報依頼書」を意味します。これは開発会社の技術や製品、会社概要などの情報を依頼するものですで、RFPとRFIの違いはしっかりと理解しておきましょう。
RFPは無ければプロジェクトが進められないものではありませんが、受注者に依頼内容を分かりやすく伝え円滑に進めるためには便利な書類です。具体的にどのようなメリット・デメリットがあるのかを紹介していきます。
RFPの作成過程において、抑えておいてほしいポイントなどの洗い出しを行うことになるでしょう。これにより発注元としての情報も整理することができ、課題抽出や全体的な設計の把握などが可能になります。
RFPを作成していくことで、開発中のスケジュール感はもちろんその後の運用体制までも見据えた発注ができるようになります。自ずと今後の流れが明確になり、その想定スケジュールや運用体制に沿えるベンダーの選定が可能になるでしょう。
RFPを用いることで、各発注先候補に対して同様の提案要請を行うことができます。これにより、同じ条件で提案を要請したという環境が構築されますので、同じ条件における見積り・提案の比較がしやすくなります。
口頭でのやり取りだけに終止したりメールなど文書上だけのやり取りになった場合、すれ違いや確認漏れといったコミュニケーションエラーに繋がる可能性があります。RFPという形にして打ち合わせを重ねることで、コミュニケーションエラーを減らせる可能性が高くなります。
RFPの作成を正確に行えなければ、読み手であるベンダーが意図しない理解をしてしまうというリスクも顕在します。作成したRFPを一方的に送り付けてしまうだけではこのような行き違いが生じる可能性もありますので、目に見える形として残すこと、より正確に情報を伝えることを目的としたツールとしてRFPを活用するようにしましょう。
資料を作成するということは、当たり前ですが工数がかかります。この作成に時間を要するという点は、強いて言うならデメリットといえるでしょう。
アプリ開発やシステム開発では紛争が起こりがちで、RFPが原因となったトラブル事例も過去に存在しています。これまでの判決からするとRFP自体に単独での法的効力を求めることは難しいとされていますが、以下のような判例も存在します。
ベンダー企業は、本件電算システム開発契約の締結に当たり、ユーザ企業と契約書を取り交わしている上、契約締結に先立ち、本件電算システム提案書を提出し、その内容に基づくシステム開発を提案し、これを了承したユーザ企業と本件電算システム開発契約を締結したものであるから、本件電算システム提案書は、契約書と一体を成すものと認められる。
（東京地裁平成16年3月10日判決）
また、開発したアプリやシステムにバグなどの瑕疵があった場合、どのような場合でも契約解除ができるのかというとそうではありません。ベンダー側が最後の工程までを終えている場合、基本的には請負代金を支払う必要があるのです。しかし成果物の瑕疵に基づく契約解除としては、以下のような判例で認められたケースが存在します。
・現行ホストコンピュータの保守期限が９月３０日に満了するはずだった
・新システムについては再納入後の検収期間終了時である６月１６日時点で補修未了の不具合・障害が３１件
・補修工数は93.4人日を要する規模
・新システムの本番稼働までにさらに少なくとも5カ月の導入支援期間が必要
・さらにその先に現行ホストコンピュータとの並行稼働が必要
→現行ホストコンピュータの保守期間が、満了後もなお長時間を要する状態になっていたものと認められることから、新システムの瑕疵のためにソフトウェア開発個別契約をした目的を達することができないと判断
（東京高裁平成26年1月15日判決）
RFPは作成することによって直接的に法的トラブルを避けられるものでもなければ強固な法的拘束力を持つ証拠書類ではありません。しかしながら相手に対して適切に要件などを伝えることで行き違いによるトラブルリスクを軽減できるほか、裁判に発展してしまった場合の参考資料や判断のための資料として採用されている事例はありますので、適切に作成しておくことがよいといえるでしょう。
参照元https://www.softic.or.jp/semi/2015/4_151015/op.pdf
アプリ開発を行うことになった経緯や、当該プロジェクトに取り組むことになった背景を記載しましょう。これにより、ベンダー側がニーズをくみ取った提案を行ってくれる可能性があります。
アプリ開発を行ううえで達成したい目的を明確に記載しておきましょう。ここを明確にしておくことで、アプローチのための手段として活用されるアプリの機能や仕様が変わる可能性もあります。
「どれくらいの効果を期待するか」という点については、その機能にどの程度注力するかが大きく変わる要素となります。そのため、何を目標とするのか、どの程度の成果を期待するのか、といったポイントも明確に記載しておきましょう。
全体的なスケジュール感を示すことで、ベンダー側の開発体制などが検討されます。アプリ開発はマンパワーが必要になるプロジェクトですから、ここをはっきりと伝えておくことでより明確な費用感が提案に織り込まれるでしょう。
アプリはさまざまな環境で使用されますから、「たくさん利用されるアプリ」を作ろうと思うと想定しているターゲットの情報は不可欠です。ターゲットとなる層にアプリを利用してもらうために、どのような開発手法を取るのかが検討できますから必ず記載するようにしましょう。
競合他社がどのような企業かという情報も記載しておくとよいでしょう。競合他社で不足している機能や競合他社との差別化など、よりたくさんのターゲットにアプリを利用してもらうための戦略を織り込んだ提案を作成してもらえる可能性が高くなります。
アプリ開発プロジェクトにおいて、RFPを提出するベンダーにどの範囲の業務を依頼したいのかも明確にしておきましょう。これによりベンダー側では工数や対応人員を検討することができ、見積り・提案を提出することができるようになります。
RFPの提出段階において予算を伝えておくことで、かけられる予算の中からできることの提案を受けることができます。手をかければかけるだけコストはかかりますから、投資と想定されるキャッシュフローのバランスを考えて設定しましょう。
アプリを開発するうえで、必要となる機能の要件についても記載するようにしましょう。後から「これを入れたらどうなる？」などといって細かな相談を重ねていては時間がかかってしまいます。主要なものについてはRFPで伝えておきましょう。
アプリ開発については、発注元と発注先で成果物の認識に齟齬が出てしまう可能性があります。そのためあらかじめRFP上に必要となる成果物を記載しておきましょう。アプリ一式・要件定義書、マニュアルなど、自社で必要なものは漏れなく書いておきましょう。
開発の手法や規格なども、コストを大きく左右する要素の一つです。自社の構想段階においてマストとなる手法や規格がある場合もあるでしょうから、RFPに記載することで提案に織り込んでもらうようにしましょう。
アプリをローンチしてから、どのような形で運用するのかについてもRFPに記載しておきましょう。自社で運用を行うのか、あるいは運用までをワンストップで依頼するのかによって内容が若干変わる可能性があります。
アプリ開発においてはどのようなチーム体制で進めるかも非常に重要です。発注元がどのような体制で対応するのか、また発注先にどのような体制を求めるのかも記載しておくことで、より具体的な提案が受けられるでしょう。
その他検討が必要な事項についても、RFP段階で記載しておくとよいでしょう。希望や要望、検討してほしい事項を含めた提案を受けることができるようになるため、後からの追加コスト発生や行き違いの防止にも貢献します。
アプリ開発において、もっとも分かりやすい判断基準が「どのようなアプリを作ったことがあるのか」です。実績の提示をしてもらうことで、ざっくりとしたできあがりのイメージを想定することができるでしょう。
対応窓口を明確化しておくことで、やり取りやトラブルの際の対応などが適切に図れます。チーム内で情報が飛び交い、誰が誰に言ったか分からないような状況はさらなるトラブルリスクとなりますので、対応窓口は決めておくのがよいでしょう。
選定を行うにあたってのスケジュールも記載しておきましょう。それぞれのステップに期限を設定しておくことで、遅滞なく提案書の提出を受けることができます。このスケジュールをきちんと守れるかどうかも選定のポイントになり得ます。
選定基準も記載しておくことで、発注先としてはある程度優先順位をつけながら提案を作成してくれるでしょう。自社において、アプリ開発プロジェクトのどこに重きを置いているかとほぼイコールになりますので、明確にしておきましょう。
不明な点や疑問点についても、RFPに記載しておくとよいでしょう。提案段階でどのような回答やソリューションを用意してくれるかどうかという点も、発注先の選定においては重要なポイントとなり得ます。
契約条件についてもRFPに記載します。ここを明確にしておかなければ、ローンチ後に発生したバグの一部について対象外と言われてしまうケースもあるようです。当社の権利や検収・支払条件、瑕疵担保責任などは記載しておきましょう。
アプリ開発に際しては自社の機密情報をたくさん取り扱ってもらうことになるでしょう。そのため、守秘義務や秘密保持といった契約によって情報漏えいリスクを担保しておくことは非常に重要です。
RFPそのものをどう取り扱うのかについても記載しておくとよいでしょう。ここを明確に決めておくことで、ベンダーとしての提案の作り込みが大きく変わってくる可能性もあります。
守秘義務や秘密保持の契約を巻いたからといって、必ずしも情報が漏えいしないとは限りません。善意・悪意を問わず万が一情報が漏えいしてしまった時に、どのような対応を取ってくれるのかについては把握しておく方がよいでしょう。
HP：https://dmc.i-studio.co.jp/download/rfp/
ダウンロード方法：専用フォームからメールアドレスを入力することで、そのままダウンロードが可能になります。
HP：https://www.webtanguide.jp/oyakudachi/rfp-template/
ダウンロード方法：専用フォームに氏名や会社名などを入力することで、ダウンロードが可能になります。
HP：https://web-kanji.com/posts/prepare-rfp
ダウンロード方法：上記URLの記事にあるダウンロードボタンから、Word形式のファイルがダウンロードできます。
HP：https://it-koala.com/rfp_lecture-709
ダウンロード方法：上記URLにある記事の最下部に、ダウンロードフォームへのリンクが添付されています。
HP：https://tact-info.com/column.html
ダウンロード方法：上記URLのページの最下部にある「サンプルPDFダウンロード」から資料をダウンロードすることができます。
HP：https://www.itra.co.jp/webmedia/rfp_point_1.html
ダウンロード方法：ダウンロードできる資料はありません。
HP：https://getting-better.jp/start-from-rfi-160627/
ダウンロード方法：上記URLの記事本文内に、「オリエンシート（RFP）のテンプレート」をダウンロードできるリンクがあります。
HP：https://webtan.impress.co.jp/e/2008/02/04/2370
ダウンロード方法：上記URLの記事内に「サンプルRFP」のリンクがあります。
HP：https://www.nttdata-bizsys.co.jp/column/2019/000599.html
ダウンロード方法：記事内「まとめ」の項目に、RFPサンプルがダウンロードできるリンクが添付されています。
HP：https://service.plan-b.co.jp/blog/creative/1098/
ダウンロード方法：RFPのテンプレートがダウンロードできるリンクはありません。
ここではRFP作成にはさまざまなメリットがあることを解説しました。ユーザー側の要望をベンダーに対して正確に伝えられる適切なRFPの作成は、アプリ開発プロジェクトを成功させるための重要なポイントです。よりよりアプリ開発を行うためにも、RFP作成や業者選定などは丁寧に行いましょう。