ECアプリのRFP/要件定義書/提案依頼書について

ECアプリの開発を外部に発注しようとするとき、多くの担当者が最初につまずくのが「何を、どこまで決めてから依頼すればよいのか」という要件定義の壁です。ネイティブアプリはECサイトと違い、iOSとAndroidの両方に対応し、App StoreとGoogle Playの審査を通し、リリース後も二つのOSを維持し続ける必要があります。この特性を理解しないままベンダーに丸投げすると、見積もりはブラックボックス化し、完成したアプリは使われず、毎年の維持費だけが残るという事態を招きます。だからこそ、発注側が主体的に要件を整理し、RFP（提案依頼書）として言語化することが、プロジェクト成功の分かれ目になります。

本記事は、ECアプリのRFP・要件定義書・提案依頼書を、発注企業の視点から実務的に解説します。要件定義の進め方のステップから、アプリ固有の機能要件と非機能要件（性能・セキュリティ・OS対応・審査対応）の洗い出し方、RFPに必ず盛り込むべき項目、そして見積もりの妥当性を見抜くベンダー選定の判断軸まで、一次データとあわせて具体的に整理します。読み終えるころには、ベンダーに丸投げせず、対等に話を進めるための準備が整うはずです。なお、ECアプリ開発の全体像をまだ把握していない方は、まずECアプリ開発の完全ガイドから読むことをおすすめします。

ECアプリ要件定義の進め方ステップ

ECアプリの要件定義は、いきなり機能の一覧を書き出すことから始めてはいけません。正しい順序は、目的とKPIの定義から始め、それを実現するための機能を逆算で導き、最後に予算と運用体制を固めるという流れです。この順序を守ることで、不要な機能で予算を浪費せず、本当に効く要件だけを盛り込めます。まずはこの進め方の骨格を押さえましょう。

要件定義の出発点は、「アプリで何を達成したいのか」を数値で定義することです。ECアプリは既存顧客のリピートとLTV（顧客生涯価値）を高める道具ですから、目的も「アプリ会員のリピート率を現状から何ポイント上げる」「アプリ会員の年間購入額を非アプリ会員の何倍にする」といった具体的なKPIで表すべきです。曖昧に「スマホ対応を強化したい」とだけ伝えると、ベンダーは何を作ればよいか判断できず、見積もりも膨らみがちになります。

このKPI設定が重要なのは、機能の要否を判断する基準になるからです。たとえば「来店を促したい」という目的があれば位置情報や会員証の優先度が上がり、「再注文を増やしたい」という目的ならワンタップ再注文やプッシュ通知が中心になります。目的が定まらないまま機能を並べると、あれもこれもと盛り込んで予算超過を招きます。リサーチノートが示すEC全般の知見でも、要件定義は目的・KGI設定から始め、そこから機能要件と非機能要件を洗い出す流れが基本とされています。アプリでもこの原則は変わりません。

目的を定義したら、次に行うべきは現場のヒアリングです。アプリを実際に運用するマーケティング担当やCS担当、店舗スタッフが、どんな業務でどう使うのかを丁寧に聞き取り、現状（AsIs）と理想（ToBe）の業務フローを描きます。この工程を飛ばすと、現場の実態と乖離したアプリができあがり、誰にも使われないまま放置されるという最悪の結果を招きます。

この教訓は、EC全般の失敗事例からも明確です。リサーチノートには、現場ヒアリングやToBeモデルの作成を怠ってベンダーに丸投げした結果、1億円をかけたBtoBサイトが現場に使われず2年放置されて廃止された事例が記録されています。アプリでも構造はまったく同じです。プッシュ通知を誰が、どんな頻度で、どんな内容で送るのか。会員証を店舗でどう運用するのか。こうした運用の実態を要件定義の段階で現場と握っておかないと、立派なアプリができても運用が回りません。要件定義は機能を決める作業であると同時に、運用体制を設計する作業でもあるのです。

機能要件と非機能要件の洗い出し方

要件は、機能要件と非機能要件の二つに分けて洗い出します。機能要件は「アプリが何をできるか」、非機能要件は「どんな品質で動くか」を定めるものです。ECアプリでは、この非機能要件にiOS・Android両対応やストア審査対応というアプリ特有の論点が加わるため、ECサイトの要件定義よりも一段複雑になります。両者を漏れなく整理することが、見積もりの精度と公平性を高めます。

機能要件を洗い出すときの鉄則は、「Webサイトと共通の機能」と「アプリ化で追加される機能」を明確に切り分けることです。商品閲覧・カート・決済・会員管理といった購入の基本機能はWebと共通でよく、すべてアプリで作り直すと開発費と維持費が無駄に膨らみます。要件定義書には、アプリ固有の機能、すなわちプッシュ通知、会員証（バーコード表示・ポイント連携）、ワンタップ再注文、お気に入り再入荷通知、オフライン閲覧、位置情報による店舗連携などを中心に、自社の目的に必要なものだけを記載します。

各機能には「なぜ必要か」を目的・KPIに紐づけて書いておくと、ベンダーとの認識合わせがスムーズになります。たとえば「プッシュ通知（目的：休眠会員の再来訪率を向上）」のように、機能と狙いをセットで記述します。これにより、ベンダーから「その目的ならこういう実装が効率的」という代替案を引き出せ、機能の過剰実装を防げます。機能ごとの役割や要否の判断材料は、機能を体系的に解説した関連記事もあわせて参照すると整理しやすくなります。

非機能要件は、ECアプリでとくに見落とされやすい領域です。まず性能面では、アプリの起動速度や画面遷移の快適さ、大量アクセス時の安定性を定めます。セキュリティ面では、決済情報や会員情報の保護、端末に保存するデータの暗号化、不正アクセス対策などを明記します。EC全般でも非機能要件として速度・セキュリティ・可用性をIPAのガイドラインに準拠して洗い出すことが基本とされており、アプリでもこの考え方は同じです。

アプリ特有の非機能要件として欠かせないのが、iOS・Android両対応とストア審査対応です。対応するOSのバージョン範囲、対応端末の範囲、毎年のOSアップデートへの追随方針を要件として定めておかないと、リリース後に「この端末では動かない」という想定外の対応費が発生します。さらに、App StoreとGoogle Playの審査ガイドラインへの適合、リジェクト時の修正対応の責任範囲、審査にかかる期間の見込みもRFPに含めるべきです。これらを曖昧にすると、ベンダーごとに前提が異なり、見積もりが比較不能になります。非機能要件こそ、アプリの見積もりブラックボックスを解明する鍵です。

RFP（提案依頼書）に盛り込むべき項目

要件を整理したら、それをRFP（提案依頼書）としてまとめ、複数のベンダーに提示します。RFPは、こちらの要望を正確に伝え、各社から比較可能な提案を引き出すための文書です。項目が不足していると、ベンダーごとに前提がばらつき、見積もりを横並びで比べられません。ここでは、ECアプリのRFPに必ず盛り込むべき項目を整理します。

ECアプリのRFPに盛り込むべき項目は、大きく次のように整理できます。
1. 事業背景と目的・KPI：なぜアプリを作るのか、何を達成したいのかを数値で
2. 機能要件：アプリ固有機能を中心に、目的との紐づけとともに記載
3. 非機能要件：性能・セキュリティ・iOS/Android対応範囲・ストア審査対応
4. 既存システムとの連携：Webサイト・会員基盤・在庫や受注管理との連携要件
5. 予算と納期：想定予算レンジとリリース希望時期
6. 運用・保守：リリース後の維持費前提、OS追随、保守体制、納品物の範囲

これらを漏れなく書くことで、各社の提案を同じ土俵で比較できます。

とくに見落とされやすいのが4番目の既存システム連携です。アプリ単体で完結することはまずなく、既存のWebサイトや会員基盤、在庫・受注管理システムと連携してこそ価値が出ます。WebとアプリでポイントやIDを一貫させる連携、注文データの統合といった要件を明記しないと、後から高額な追加開発が発生します。EC全般の失敗事例でも、連携費用をケチった結果、1日100件超の注文を手作業で基幹へ入力する羽目になり労力増とヒューマンエラーを招いた例があります。連携要件はRFPの段階で必ず固めておくべきです。

RFPで初期開発費だけを問うと、リリース後の維持費が見えず、後で採算が崩れます。ネイティブアプリはiOS・Androidの両OSを継続的に保守する必要があり、運用費が長期的に重くのしかかります。EC全般でも運用フェーズは「構築費用の3倍の年間運用費」あるいは「制作費と同額以上の運用予算」を想定すべきとされており、二つのOSを抱えるアプリでは維持負担がさらに大きくなる前提です。RFPには「初年度の保守費」「OSアップデート対応の費用ルール」「年間の想定維持費」を必ず提示させましょう。

あわせて、納品物の範囲も明記すべきです。ソースコードの帰属、設計ドキュメント、ストアアカウントの権限、テスト結果など、何が成果物として納品されるかを定めておかないと、後で別のベンダーに乗り換えたいときにソースコードを引き渡してもらえないといった事態に陥ります。RFPの段階で納品物と権利関係を明示することは、ベンダーロックインを避けるための重要な防衛策です。EC全体の費用相場や運用費の考え方は完全ガイドでも俯瞰できますので、あわせてご確認ください。

ベンダー選定と見積もりの妥当性の見方

RFPを提示して各社から提案と見積もりが集まったら、いよいよベンダー選定です。ここで多くの発注者が陥るのが、提案の見栄えや営業担当のプレゼン力に引っ張られて選んでしまう罠です。見積もりの妥当性を見抜き、実際に開発する体制を見極めることが、要件定義を成果につなげる最後の関門になります。

アプリ開発の見積もりは、同じ要件でもベンダーによって金額が大きく異なります。その差を見抜くには、見積もりの内訳を分解させることが有効です。とくに「テスト・デバッグ費」「ディレクション費」が一式でまとめられている場合は、その内訳を質問しましょう。EC全般でもディレクション・進行管理費は見積総額の約10%が一つの目安とされており、この水準から大きく外れる場合は理由を確認すべきです。アプリでは、iOS・Android双方のテスト工数が別計上になっているか、ストア審査対応の工数が含まれているかも要チェックです。

見積もりを比較するときは、安さだけで選ばないことが鉄則です。極端に安い見積もりは、非機能要件や維持費、連携工数が抜け落ちている可能性が高く、後から追加費用で膨らみます。RFPで前提を揃えておけば、各社が同じ要件に対していくらで応じるかを公平に比べられます。追加要件が発生したときの単価ルールも、契約前に取り決めておくことが大切です。これにより、開発途中での費用の青天井化を防げます。

ベンダー選定で最も注意すべきは、「提案時のエース級と実際の開発チームが違う」という落とし穴です。EC全般の失敗事例でも、エース営業のプレゼンに惹かれて発注したものの、実開発部隊の技術力が低く、リリース後に障害が多発して泥沼化した例が記録されています。これを避けるには、提案段階で体制図の提出を求め、実際にプロジェクトを担当するプロジェクトマネージャーやエンジニアと面談することが有効です。

アプリ開発では、iOS・Androidそれぞれの開発実績、ストア審査を通した実績、既存システムとの連携経験を具体的に確認しましょう。「アプリも作れます」という言葉だけでなく、過去にどんなECアプリを手がけ、どんな審査対応をしたかという実績ベースの確認が重要です。あわせて、検収基準やSLA（サービス品質保証）、ソースコードの帰属といった契約面も詰めておきます。要件定義からRFP、ベンダー選定までを発注側が主導することが、丸投げによる失敗を避ける最大の防衛策です。実際にどんな失敗が起きるのか、その回避策は関連の失敗・リスク記事で詳しく扱っています。

まとめ

ECアプリの要件定義は、目的とKPIの数値化から始め、現場ヒアリングで運用まで設計し、機能要件と非機能要件を切り分けてRFPにまとめる、という順序が王道です。アプリ特有の非機能要件であるiOS・Android両対応、ストア審査対応、既存システム連携、年間維持費をRFPに明記することが、見積もりブラックボックスを解明し、各社の提案を公平に比較する鍵になります。現場を無視した丸投げが、使われないアプリの放置という最悪の失敗を招くことは、EC全般の事例が雄弁に物語っています。

要件定義で大切なのは、「ベンダーに任せる」のではなく「発注側が主導する」という姿勢です。目的を数値で固め、現場の運用を設計し、非機能と維持の前提までRFPに書き込めば、丸投げによる失敗は構造的に避けられます。riplaはフルスクラッチ受託と国内開発を組み合わせ、目的から逆算した要件整理とRFP作成、引き継ぎ性の高い開発体制を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

▼関連記事
ECアプリの必要機能や標準機能の一覧について