Androidアプリの開発を発注しようとするとき、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくにAndroidは、世界中で数千種類もの端末が流通する「端末の断片化（フラグメンテーション）」、iOSとは審査基準も期間も異なるGoogle Playの公開フロー、そしてKotlinかFlutterかといった言語・技術形態の選定といった、Android固有の論点を要件として正しく整理できるかどうかが、現場で安定して動くアプリになるか、リリース後にクラッシュ報告に追われるアプリになるかの分かれ目になります。曖昧な要件のままベンダーへ丸投げすれば、予算超過と納期遅延を招くと各所で警告されています。
本記事は、Androidアプリ開発のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。対応端末・OSバージョンの範囲をどこまで要件に書くか、Google Play審査やストアポリシーを要件にどう織り込むか、ネイティブ（Kotlin）かクロスプラットフォーム（Flutter）かを要件段階でどう指定するか、機能要件と非機能要件の整理、Must/Wantの社内合意形成、そしてRFPに盛り込むべき項目までを、Androidの実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずAndroidアプリ開発の完全ガイドから読むことをおすすめします。
対応端末・OSバージョンの範囲を要件に明文化する
Androidアプリの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。Androidに固有の出発点は、「どの端末で、どのOSバージョンで、どの画面サイズで動かすのか」という対応範囲の明文化です。iOSがアップル一社の限られた端末しか存在しないのに対し、Androidは多数のメーカーが多様な端末を出荷しており、画面サイズも解像度もOSバージョンも千差万別です。この「端末の断片化」を要件で線引きしないまま発注すると、開発・検証の範囲が無限に広がり、見積りも品質も定まりません。
端末断片化を踏まえた対応範囲の決め方
対応範囲を決めるには、自社アプリのターゲットユーザーが実際にどんな端末を使っているかを起点にします。一般消費者向け（BtoC）であれば、流通量の多い主要メーカーの中位機種を中心に、想定される画面サイズの幅を要件に書きます。物流・製造・小売の現場で使う業務端末であれば、現場が支給されている特定機種・特定OSバージョンを名指しで要件に書くべきです。Androidは業務用ハンディ端末やタブレットで広く使われており、ここを曖昧にすると「手元の端末では動くが現場の端末で動かない」という典型的な失敗につながります。
具体的には、(1)対応する最小OSバージョン（古い端末をどこまで切り捨てるか）、(2)対応する画面サイズ・解像度の範囲、(3)タブレットや折りたたみ端末への対応有無、(4)実機検証を行う代表機種のリストを、要件として明記します。古いOSまで広くサポートするほど検証工数とコストは膨らみます。「ユーザーの何%をカバーできれば事業上十分か」という線引きを、開発前に自社で意思決定しておくことが、断片化に振り回されないための第一歩です。この対応範囲の定義こそ、Android要件定義がiOSと決定的に異なる点です。
iOSとの同時開発か、Android先行かを要件で決める
Androidアプリの要件定義では、「iOSも同時に作るのか、Androidだけ先行するのか」というOS優先判断も明確にします。一般に日本国内はiOSのシェアが高く、世界全体ではAndroidが高いとされますが、この一般論だけで決めてはいけません。ターゲットがF1層（若年女性）中心ならiOS先行が合理的な場合もありますが、物流・製造・建設といった現場の業務端末はAndroidが主流のため、Android先行が明確に合理的なケースが多くあります。自社のターゲット属性と利用シーンから、どちらのOSを先に検証すべきかを要件として定めます。
片側先行リリースを選ぶ場合は、「Androidで仮説検証し、効果が確認できたらiOSへ展開する」という段階的な計画を要件に書き込みます。両OSを同時に作ると費用は単純に増えるため、まずAndroid一本で市場の反応を見て、本当に両OS必要かを検証してから投資を広げる進め方は、無駄な投資を避ける有効な手段です。要件定義の段階でOSの優先順位と検証の順序を決めておくことが、後の予算配分と技術選定の前提になります。実装したい機能から技術形態を逆算する考え方は、機能の関連記事もあわせてご覧ください。
Google Play審査とストアポリシーを要件に織り込む
対応端末の範囲を決めたら、次に要件へ織り込むべきはGoogle Playの審査とストアポリシーへの適合です。iOSのApp Store審査が比較的厳格で時間もかかる一方、Google Playは初回審査こそ慎重なものの、その後の更新は比較的速いといった特徴の違いがあります。ただし「Androidは審査が緩いから後で何とかなる」と考えるのは危険です。権限の扱いやデータ取り扱いの申告など、要件段階で押さえておかないとリリース直前に差し戻され、計画が崩れる項目が複数あります。
権限・ターゲットAPIレベル・データセーフティの要件化
Google Playのポリシーで特に要件化すべきは、(1)アプリが要求する端末権限（位置情報・カメラ・連絡先など）とその利用目的の説明、(2)Googleが定める「ターゲットAPIレベル」の要件（新規・更新アプリは一定以上の新しいAPIレベルを満たす必要がある）、(3)ユーザーデータの収集・共有を申告する「データセーフティ」の内容です。これらは技術仕様であると同時に、プライバシーポリシーや個人情報の取り扱いに直結する経営判断でもあります。要件定義の段階で「どんなデータを、何のために収集するか」を整理しておけば、審査でつまずきません。
とくに業務アプリでバックグラウンドでの位置情報取得や、他アプリと連携する権限を使う場合は、Googleの審査で厳しく目的を問われます。要件定義で「なぜその権限が必要か」を業務上の根拠とともに言語化しておくことが、後のスムーズな審査通過につながります。逆に、過剰な権限を要求する設計のまま開発を進めると、リリース直前にポリシー違反で差し戻され、設計のやり直しという大きな手戻りが発生します。Google Play審査への適合は、後付けではなく要件定義の必須項目として組み込むべきものです。
配布方法（一般公開・限定公開・内部配布）の要件化
Androidならではの要件として、配布方法の選択があります。iOSが原則App Store経由に限られるのに対し、Androidは一般公開のほかに、特定ユーザーだけに配る「限定公開（クローズドテスト・内部テスト）」や、自社の業務端末にだけ配布する「内部配布」といった選択肢があります。社内業務アプリであれば、必ずしも一般公開する必要はなく、Google Playの内部配布や、企業端末管理（MDM）経由での配布を選ぶこともできます。この配布方針を要件で決めておくことが、審査の重さや運用方法を左右します。
配布方法によって、必要な準備も変わります。一般公開ならストア掲載用の説明文・スクリーンショット・プライバシーポリシーの整備が必要ですが、内部配布中心なら審査の負担は軽くなります。要件定義書には「誰に、どの経路で配布するのか」を明記し、それに応じてストア掲載素材の準備や、テスト配布の段取りを盛り込みます。配布方針が曖昧なまま開発が進むと、リリース直前になって「ストア掲載素材が足りない」「テスト配信の体制がない」と慌てることになります。Androidの柔軟な配布の選択肢を、要件段階で自社の目的に合わせて選び取ることが重要です。
Kotlinネイティブかクロスプラットフォームかを要件で指定する
対応端末と審査要件を整理したら、いよいよ技術形態と開発言語の選定を要件に落とし込みます。Androidネイティブの標準言語はKotlinで、iOSのSwiftと別々に開発する方式と、FlutterやReact Nativeで単一コードから両OS対応するクロスプラットフォーム方式の、大きく二つの道があります。この選定を「ベンダーにお任せ」にしてはいけません。技術形態は、性能・コスト・内製化のしやすさ・将来の保守体制に直結する経営判断だからです。
対応OS範囲と内製化方針から技術を逆算する
技術選定の要件化は、まず「対応OSの範囲」から逆算します。当面Androidだけで、iOSの予定がないのであれば、Kotlinによるネイティブ開発が素直な選択です。OSの新機能や端末固有の機能をいち早く使え、性能面でも有利だからです。一方、iOSも将来的に必要で、コードの共通化でコストを抑えたいなら、Flutterなどのクロスプラットフォームが候補になります。ただしクロスプラットフォームは、Android固有の細かな端末対応で結局ネイティブのコードを書く必要が出る場面もあり、断片化の激しいAndroidでは検証範囲が広がる点も要件検討時に踏まえます。
もう一つの判断軸が、内製化を見据えた採用市場です。riplaの一次情報によれば、エンジニアの採用難易度は「React Native ＞ Swift/Kotlin ＞ Flutter ＞ KMP」の順で、左ほど採用しやすいとされます。将来チームを社内に持ちたいなら、採用しやすい技術を選ぶことが運用リスクを下げます。年収相場ではKotlinが約873万円、Swiftが約868万円とほぼ同水準で（2022年・出典：ripla）、ネイティブ人材の確保はクロスプラットフォーム専業より市場が厚いのも利点です。要件定義書には「ネイティブ（Kotlin）希望」「クロスプラットフォーム可」といった方針と、その理由（対応OS・内製化・採用）を明記し、ベンダーが前提を揃えて見積れるようにします。
ベンダーロックインを避ける要件の書き方
技術選定を要件化するときに見落とされがちなのが、特定のフレームワークやベンダーへの「ロックイン」リスクです。たとえばFlutterは生産性が高い一方、2026年時点でもFlutterエンジニアの採用は難しく、開発を担う技術者が退職したときのリカバリーを経営リスクとして考慮すべきだとされます。要件定義書には、ソースコードの著作権が発注者に帰属すること、技術ドキュメントの納品、特定の独自ライブラリに過度に依存しない設計といった、引き継ぎ可能性を担保する条項を盛り込みます。
こうした自衛策を要件段階で明記しておけば、将来ベンダーを変更したり内製に切り替えたりするときに、ゼロから作り直す事態を避けられます。技術選定は「今いくら安く作れるか」だけでなく、「数年後に誰が保守できるか」までを見据えて要件化することが肝心です。riplaはフルスクラッチ受託と国内開発の立場から、ソースコードの著作権帰属を明確にし、引き継ぎを前提とした透明な開発を重視しています。技術選定の良し悪しは、リリース時点ではなく、その後の数年間の保守で初めて顕在化するのです。
機能要件と非機能要件の整理・社内合意形成
端末範囲・審査・技術選定を整理したら、機能要件と非機能要件を網羅的に定義します。機能要件は「何ができるか」、非機能要件は「どれだけの品質で動くか」を定めるものです。Androidアプリでは、機能要件に目が行きがちですが、断片化した多様な端末で安定して動かすために、性能・電池消費・セキュリティといった非機能要件もおろそかにできません。
Must/Wantの仕分けと社内合意形成
機能要件は、ただ列挙するのではなく、優先度を付けて分類することが重要です。「これがないと業務が成立しない」必須機能（Must）と、「あると望ましいが初期になくても運用できる」要望機能（Want）に仕分けます。ここで発注企業を悩ませるのが社内政治です。現場は「あれもこれも欲しい」と多機能を求め、経営層は「コストと短期リリース」を求めて板挟みになる、という構図はアプリ開発でよく起きます。Must/Wantの仕分けは、この対立を交通整理する社内合意のプロセスそのものです。
合意形成を進めるには、各機能について「それがないと何が困るのか」「事業のKPIにどう効くのか」を判断軸に据え、現場の要望と経営の制約を同じ土俵で比較します。すべてをMustにすると予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。まずMust機能だけでMVP（実用最小限の製品）としてAndroid版をリリースし、効果を見ながらWant機能を追加する段階的なリリース計画を立てれば、無理なく投資できます。Must/Wantの仕分けと社内合意は、要件定義書の中でも投資判断に直結する核心部分です。技術形態・言語選定の判断基準は、メリデメの関連記事もあわせてご覧ください。
非機能要件（性能・電池消費・セキュリティ）
非機能要件では、性能・電池消費・セキュリティを定義します。性能は、断片化したAndroidで特に重要です。最新の高性能端末では快適に動いても、対応範囲に含めた中位・下位の端末で画面遷移がもたついたりクラッシュしたりすれば、ユーザーは離れます。「対応最小スペックの端末でも一定の応答速度を保つ」という性能要件を明記し、検証対象機種も定めます。電池消費も、バックグラウンドで位置情報を取得するような業務アプリでは現場の不満に直結するため、要件として意識すべき項目です。
セキュリティは、端末内に保存するデータの暗号化、通信の暗号化、認証の方式などを定義します。Androidは配布の自由度が高い反面、提供元不明アプリのインストールやマルウェアのリスクも語られる環境のため、IPA（情報処理推進機構）のガイドラインなどを参照しつつ、端末紛失時のデータ保護や不正アクセス対策を要件化します。可用性については、サーバーと連携するアプリであれば、通信障害時の挙動（オフライン時の動作・再送制御）も定めます。非機能要件を曖昧にすると、リリース後に「特定機種で遅い」「電池がすぐ減る」「情報が漏れる」というトラブルが起き、現場の信頼を一気に失います。機能要件と同じ熱量で非機能要件を詰めることが、Androidアプリの品質を担保します。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。Androidアプリは手法・対応OS・機能規模で費用が数十万から数千万まで大きく振れるため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
AndroidアプリのRFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI、対応端末・OSバージョン・画面サイズの範囲、iOS同時開発の有無とOS優先方針、技術形態・言語の方針（Kotlinネイティブ／クロスプラットフォーム）、機能要件（Must/Wantの分類付き）、非機能要件（性能・電池・セキュリティ）、Google Play配布方針と審査対応、既存システム・API・サーバーとの連携要件、予算とスケジュールの目安、そして開発・運用の体制要求です。Android固有の対応端末範囲と審査対応は、ここで具体的に記述することで、見積りの前提が揃います。
とくに見落とされがちなのが、体制要求とソースコードの権利です。「コンペにエース級の担当者が出てきたが、実際の開発は技術力の低い下請けが行い、リリース後に障害が多発した」という失敗を避けるには、RFPで体制図の提出を求め、誰が実際に開発するのか、PMは誰かを明記させることが有効です。あわせて、納品物にソースコードと技術ドキュメントを含め、著作権が発注者に帰属することをRFPに明記します。プレゼンの上手さではなく、実開発体制と引き継ぎ可能性を確認できる項目をRFPに盛り込むことが、ベンダー選定の防衛策になります。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、まず発注先別の人月単価の相場観を持つことです。一次データでは、フリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円が目安とされます。この差は、中間マージン・組織維持費・多重下請けの保険料に起因します。見積りの総額だけでなく、何人月で、どの単価帯のベンダーが、どこまでを担うのかを分解して見れば、価格の妥当性が見えてきます。安すぎる見積りは検証範囲（対応端末）が狭すぎる可能性、高すぎる見積りは不要な要件が含まれる可能性があります。
コストを抑える発注の工夫も判断材料になります。riplaの一次情報では、市場相場700〜1,500万円（13〜18人月）の案件を、AIによるコード自動生成と「フリーランス＋小規模専門会社」の分割発注によって、実質8人月・500万円に圧縮した事例があります。見積りを精査するときは、ベンダーがこうした効率化をどこまで織り込んでいるかも確認します。また「テスト・デバッグ費」「ディレクション費」が一式でまとめられている場合は内訳開示を求めます。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と見積り内訳の明示を重視しています。
まとめ
Androidアプリの要件定義・RFP・提案依頼書は、機能の列挙からではなく、端末断片化を踏まえた対応端末・OSバージョン・画面サイズの範囲を明文化することから始めるのが鉄則です。そのうえで、Google Playの審査・ストアポリシー（権限・ターゲットAPIレベル・データセーフティ・配布方針）を要件に織り込み、Kotlinネイティブかクロスプラットフォーム（Flutter）かを対応OS範囲・内製化・採用市場から逆算して指定します。機能要件はMust/Wantで仕分けて社内合意を作り、非機能要件（性能・電池・セキュリティ）も詰める。これらをRFPに体制要求・ソースコード著作権・連携要件まで明記すれば、ベンダーの提案を横並びで比較でき、発注先別単価の相場に照らして見積りの妥当性も判断できます。
Androidは端末の多様性という他にない特性を持つため、要件定義の質がそのままプロジェクトの成否に直結します。自社のターゲット端末と運用体制を正確に映した要件こそが、現場に使われるアプリを生みます。riplaはフルスクラッチ受託と国内開発、元事業会社（ラクスル/LINEヤフー）出身の知見を組み合わせ、対応端末範囲の決定からToBe設計、技術選定、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。