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