アプリ開発の要件定義とは？決める項目・進め方と発注前に固める範囲を解説

アプリ開発の要件定義は、設計や実装に入る前に「このアプリで何を達成し、どの端末で何をどこまで動かすか」を文書で確定させる工程です。業務システムと同じ手順で進めると、対応OSバージョンやストア審査、オフライン時の挙動といったアプリ固有の論点が抜け落ちます。この記事では、対応OSと端末範囲、開発方式、画面一覧、認証、プッシュ通知、課金、端末権限、API連携まで、何をどの粒度で書くのかを整理しました。公開後のOS更新への追随を要件に織り込む手順と、発注前に固め切るべき案件の線引きまで扱います。

まとめ：アプリ開発の要件定義で先に決める論点と発注者の担当範囲

先に結論を述べます。アプリ開発の要件定義で発注者が自分で決め切る必要があるのは、目的と数値目標、対象ユーザーと利用場面、対応OSバージョンの下限、公開後の更新体制の四つ。自社の事情と利用実態でしか決まらないため、開発会社に投げても返ってきません。逆に開発方式、画面遷移、通信方式、権限設計、性能やセキュリティの水準は、発注者が「業務上どう困るか」を伝えれば開発会社が要件の形に翻訳できます。

アプリ案件で見落とされやすいのは、公開してからの費用です。Google Play は2026年8月31日から新規アプリとアプリ更新に Android 16（API level 36）以上を要求し、App Store は2026年4月28日以降のアップロードに Xcode 26 以降と iOS 26 SDK を求めています。年1回のOS更新に追随する改修は、機能追加がなくても発生する。運用要件として費用と担当を決めていないと、公開の翌年に想定外の見積もりが出てきます。要件を先に固め切るか段階的に確定するかを分ける軸は、画面数ではなく発注方式と外部システム連携の有無です。

アプリ開発の要件定義で決める範囲と、要求定義・仕様書との境界線

要件定義という言葉は、前後の工程と混ざったまま使われがちです。範囲を先に切ると、書く文書の量が見えます。

要件定義で確定させる項目と、基本設計以降に送ってよい項目の線引き

要件定義で確定させるのは「何を作るか」であり、「どう作るか」ではありません。達成したいこと、対象ユーザー、画面の一覧、各画面でできること、対応OSと端末の範囲、性能とセキュリティの水準、公開後の運用体制までが範囲です。

逆に、画面の詳細なレイアウト、テーブル定義、APIのパラメータ名、ライブラリの選定は基本設計以降に送って構いません。判断の基準は「決めておかないと見積もり金額が変わるか」の一点。変わる項目は要件定義で握り、変わらない項目は設計工程に渡してください。工程全体の位置づけはシステム開発の流れと各工程のポイントで整理しています。

発注者が自分で決め切る四項目と開発会社が要件へ翻訳できる項目

発注者が単独で決めるのは、目的と数値目標、対象ユーザーと利用場面、対応OSバージョンの下限、公開後の更新体制の四つ。たとえば「屋外の現場で片手で入力する」という利用場面は社内にしかない情報で、これが決まらないと画面設計もオフライン要件も決まりません。

一方、開発方式やAPI設計、暗号化の水準は開発会社が要件の形に直せます。発注者側は「社外秘の図面を扱う」「通信が不安定な倉庫で使う」といった業務上の制約を伝えれば足りる。技術的な水準を発注者が独断で指定すると、実現に不要な構成が見積もりに乗ります。要求と要件の境目そのものは要求定義と要件定義の違いで扱っています。

対応OSバージョンと端末範囲・開発方式というアプリ固有の前提要件

アプリの要件定義がWebシステムと最も違うのが、この前提要件です。決めないまま機能の話に進むと、見積もりが二倍近く動きます。

対応OSバージョンの下限を実データから決めるための具体的な手順

対応OSの下限は、感覚で決めず実データから決めます。社内向けの業務アプリなら資産管理台帳から社給端末のOS内訳を取り、一般公開アプリなら既存サイトのアクセス解析からOSバージョン別の比率を取る。そのうえで、切り捨てる比率の上限を先に合意しておきます。

下限を1世代上げるだけで、検証端末の台数と互換対応の工数が減ります。逆に古いOSを1世代残すと、その世代でしか起きない不具合の調査に工数が張り付く。2026年8月時点で iOS は26系、Android は16系が最新の系列であり、業務アプリなら「最新から3世代前まで」を出発点に、実データで外れる利用者の比率を見ながら調整するのが現実的な線です。

ネイティブとクロスプラットフォームの採用条件と見送るべき場面

開発方式は、要件定義の段階で決め切ったほうが見積もりの精度が上がります。判断は次の条件で分かれます。

• ネイティブ開発が向く：カメラや位置情報を常時使う、端末性能を引き出す描画がある、OSの新機能へ早期に追随したい
• クロスプラットフォーム開発が向く：両OSで同じ画面と機能を出す、更新頻度が高い、画面数が多い
• いずれも見送る：閲覧と入力が中心で端末機能をほぼ使わない。この条件ならWebアプリで足り、ストア審査も不要

見送りの判断を明文化しておくのが要点です。「アプリにする」と決めた案件が、要件を並べると端末機能を1つも使っていないというのはよくある話。その場合はWebへ倒したほうが費用は下がります。Webへ倒す場合の要件整理はWeb制作の要件定義で決める項目が参考になります。

対応端末と画面サイズ・タブレット対応をどこまで含めるかの決め方

対応端末は「機種名の列挙」ではなく「画面サイズの範囲」と「動作確認する代表機種」の二段で書きます。機種名を並べると台帳の更新が追いつかず、書いた瞬間から陳腐化する。代表機種は各OSで2〜3機種、画面サイズは最小幅と最大幅を数値で指定します。

タブレット対応は、要件定義で明示的に「含む」「含まない」を書いてください。曖昧なまま進むと、実装後に表示崩れの指摘が出てレイアウトの作り直しが発生します。含める場合は、スマートフォンと同じ画面を拡大表示するのか、専用レイアウトを作るのかまで指定する。両者では画面実装の工数が大きく変わります。横向き表示の対応可否も同じ場所に書きます。

機能要件の書き方は画面一覧・認証・プッシュ通知・課金の四つで固める

機能要件は書き出すと際限がなくなります。アプリでは四つの塊に分けると漏れが減ります。

画面一覧と画面遷移図を要件定義の段階でどの粒度まで書き切るか

画面一覧は、画面名・目的・表示する情報・その画面でできる操作の4列で足ります。レイアウトの詳細は不要です。画面数が確定すれば見積もりの土台ができるため、粒度を上げるより網羅性を優先してください。

画面遷移図は、正常系だけでなく「ログインしていない状態で通知から起動した場合」「入力途中でアプリが背面に回った場合」を含めます。アプリ特有の事故はこの二つの経路で起きる。通知タップからの起動時に該当画面へ直接遷移させるのか、ログイン画面を挟むのかは、実装後に変えると影響範囲が広い。

アカウント登録とログイン方式・権限階層を決めるときの判断基準

認証は、方式・保持期間・権限階層の3点を決めます。方式はメールアドレスとパスワード、SMS認証、外部アカウント連携、社内認証基盤との連携から選ぶ。業務アプリで社内認証基盤があるなら、そこへ寄せるのが管理面で有利です。

見落とされやすいのがログイン状態の保持期間と、機種変更時のデータ引き継ぎ。「一度ログインしたら90日間は再入力なし」といった水準を数値で書くと、後の議論が減ります。権限階層は、閲覧のみ・入力可・承認可・管理者の4段階から必要なものだけを残す形が扱いやすい。階層を増やすほど検証項目も比例して増えます。

プッシュ通知は配信条件と到達しない前提を要件として書き分ける

プッシュ通知は、要件として書く分量の割に実装と運用の負荷が大きい機能です。決めるのは、誰に・どういう条件で・何を送るか、そして通知の許可を得る画面をいつ出すか。利用者が拒否した場合に業務が回らなくなるかどうかも書いてください。

通知は必ず届くものではありません。端末の設定で拒否されていれば届かず、電源が落ちていれば遅延します。「通知で伝えるが、アプリ内にも一覧として残す」という二重化を要件に入れておくのが実務的な形。通知の文面を運用側が管理画面から編集できるようにするかどうかでも費用が変わります。

アプリ内課金と外部決済の分岐を要件定義の段階で確定させる理由

アプリで金銭のやり取りが発生するなら、要件定義の段階で決済の分岐を確定させます。デジタルコンテンツや機能の解放をアプリ内で売る場合と、実店舗の商品や役務の対価を受け取る場合とで、使える手段とストア側の扱いが変わるためです。ここを設計以降に持ち越すと、審査で差し戻されて公開日が動く。

要件には、扱う商材の種類、課金の形態（都度・定額）、解約と返金の処理、領収書の発行方法を書きます。定額課金なら、更新のタイミングと解約後の利用可能期間も明記してください。実装そのものより、解約と返金の運用フローの担当のほうが後から揉めます。

オフライン動作と端末権限・API連携というアプリ特有の非機能要件

非機能要件は IPA の「非機能要求グレード2018」で可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6大項目に整理されていますが、アプリでは端末側の論点が加わります。

オフライン動作を三段階に分けて要件の水準を決めるための考え方

オフライン対応は「する・しない」の二択で書くと認識がずれます。次の三段階に分け、画面ごとにどれを適用するかを指定してください。

1. 第一段階：通信がないときは明示的なメッセージを出して操作を止める（実装費用は最小）
2. 第二段階：直前に取得した情報を読み取り専用で表示する（キャッシュの保持期間を数値で決める）
3. 第三段階：オフラインでも入力を受け付け、通信の回復時にサーバーへ反映する（競合時の処理が要る）

第三段階を選ぶと、同じ情報が複数端末で同時に更新されたときの扱いを決める必要が出てきます。「後から届いた更新で上書きする」「先勝ちで後の更新を差し戻す」「両方を残して人が選ぶ」のいずれかを明記してください。全画面を第三段階にすると費用が跳ね上がるため、入力が止まると業務が止まる画面だけに絞ります。

カメラや位置情報など端末権限の取得タイミングと説明文の決め方

端末の権限は、使う権限の一覧、要求するタイミング、拒否されたときの挙動の3点を要件に書きます。起動直後にまとめて要求する作りは拒否率が上がるため、機能を使う直前に要求する形へ倒してください。

権限の要求ダイアログに表示する説明文も、要件定義の段階で文案を決めておきます。「位置情報を許可してください」だけでは利用者が判断できず、拒否につながる。何のために使い、拒否すると何ができなくなるかを一文で書きます。手入力などの代替手段を用意するかも、ここで決める論点。取得した情報の保存先と保存期間は、社内の個人情報の取り扱い規程と突き合わせてください。

サーバーAPIとの連携で旧バージョン共存をどう要件に書き込むか

アプリはWebと違い、利用者の端末に古いバージョンが残ります。サーバー側を更新しても、全員が即座に新しいアプリへ入れ替わるわけではありません。旧バージョンをどれだけの期間サポートするかを決めてください。

実務的には、APIにバージョン番号を持たせて旧仕様を一定期間並走させる形になります。並走期間を「新バージョン公開から90日」のように数値で決めておけば、サーバー側の保守範囲が確定する。起動時にサーバーへ最低動作バージョンを問い合わせ、下回る場合は更新を促す仕組みを入れるかも要件に書きます。連携先が社内の基幹システムなら、改修範囲と担当も同じ表に載せてください。

ストア審査とOS更新への追随を公開後の運用要件として先に決める

アプリの費用は公開時点で終わりません。要件定義に入れるかどうかで、翌年以降の予算の立てやすさが変わります。

Google PlayとApp Storeのストア要件を費用に織り込む手順

両ストアとも、提出するアプリのOS対応水準を定期的に引き上げています。Google Play は2026年8月31日から、新規アプリとアプリ更新について Android 16（API level 36）以上を対象にするよう求める。既存アプリが新規ユーザーへ配信され続けるには Android 15（API 35）以上が必要で、満たさない場合は自身の対象バージョンより新しい Android 端末で新規ユーザーが入手できなくなります。対応に時間を要する場合は2026年11月1日までの延長申請ができます。

Apple 側は2026年4月28日以降、App Store Connect へアップロードするアプリを Xcode 26 以降でビルドし、iOS 26・iPadOS 26 などの各SDKを使うことを求めています。いずれも機能追加とは無関係に発生する作業。要件定義では「年1回のストア要件対応を保守に含めるか、都度見積もりにするか」を明記してください。

強制アップデートとサポート対象OSの更新ルールを要件に含める

対応OSの下限は一度決めて終わりにせず、更新ルールまで書きます。「毎年◯月に見直し、利用者比率が◯％を下回ったバージョンを外す」という形で、判断の基準と時期を決めておく。ルールがないと、下限を上げる提案が毎回ゼロから議論されます。

強制アップデートの仕組みも、公開後に追加すると旧バージョンには届きません。最初のリリースに含めるかを要件定義で判断してください。含める場合は、更新を促す画面で操作を完全に止めるのか、後回しを許すのかまで決めます。法令対応の改修が入り得る業務アプリなら、止める形が無難です。

ストア掲載と審査対応の分担・開発者アカウント名義の決め方の基準

意外に揉めるのが、開発者アカウントの名義です。開発会社の名義を借りると、開発会社を変える際に移管手続きが必要になり、レビューや利用者を引き継げない場合がある。原則として発注者名義で取得し、開発会社には作業権限だけを渡す形を推奨します。

審査で差し戻された場合の対応も、担当と回数の扱いを決めておきます。ストア掲載用の説明文、スクリーンショット、プライバシーの申告内容を誰が用意するかも分担表へ。ここを空白にしたまま開発が終わり、公開が数週間止まる例があります。

目的の確定から優先度づけまで要件定義を進める五工程と期間の目安

要件定義にかかる期間は、機能の数より関係部門の数で決まります。

アプリで何を達成するかを利用場面から数値目標へ落とし込む進め方

最初に決めるのは、アプリで何を達成するか。ここが「業務効率化」で止まっていると、以降の判断がすべて曖昧になります。誰が、どの場面で、いまどうしていて、アプリで何が変わるのかを一文で書いてください。

そのうえで数値目標を置きます。「現場からの報告にかかる時間を1件あたり10分から3分へ」といった水準。この数値が、機能の優先度を決めるときの判断材料になります。数値がないと、要望が出るたびに機能が増え続ける。

機能の優先度を三群に仕分けて初回リリース範囲を確定させる手順

集めた要望は、目的に直結するもの、あると良いもの、今回は見送るものの三群に仕分けます。部門を回って要望を集める前に叩き台を作り、それへの反応を集めるほうが早く終わります。

1. 目的と数値目標、対象ユーザー、利用場面の仮案を1枚にまとめる
2. 関係部門へ個別に当て、仮案への異論と部門固有の要望を集める
3. 集まった要望を数値目標への寄与で三群に仕分ける
4. 見送りにした要望は、理由と再検討の時期を添えて一覧に残す
5. 仕分け結果を各部門へ返し、異議のある項目だけを対面で議論する

見送った要望を記録に残すところに意味があります。記録がないと、公開直前に同じ要望が別の担当者から再提出される。初回リリースは第一群だけに絞り、第二群は公開後の改修枠として予算を分けておく形が扱いやすい進め方です。

見積もりの精度を上げる要件の書き方と、数量の上限を決める方法

見積もりの幅は、要件の曖昧さの幅そのものです。精度を上げるには数量に上限を書きます。「マスタ登録画面は5種類まで、1画面あたり入力項目20個まで」のように書けば、詳細が未定でも金額は動きません。

上限のない「柔軟に対応」という書き方だけは避けてください。開発会社は最大値を見込んで積むか、最小値で受けて後から追加見積もりを出すかのどちらかになり、どちらも発注者に不利に働きます。要件定義の目的と成果物そのものの整理は要件定義とは何かと進め方の全体像で扱っているため、この記事はアプリ固有の論点に絞りました。

要件を発注前に固め切るアプリ案件と段階的に決めてよい案件の条件

要件定義は「必ず全部を先に決める」ものではありません。案件の性質によって、先に固め切るべき場合と、段階的に確定させたほうが総費用の下がる場合に分かれます。

発注前に要件を確定させ切るべきアプリ案件の条件と見極めの手順

次の3条件のうち2つ以上に当てはまるなら、要件を発注前に固め切ってください。第一に、複数社の相見積もりで発注先を決める案件。前提が揃っていない見積もりは比較になりません。第二に、予算承認が年度単位で追加発注の余地がない案件。第三に、基幹システムや外部サービスとのAPI連携がある案件です。連携仕様は後から変えると双方の改修が必要になり、費用が二重に発生します。

見極めの手順は単純で、予算の追加申請にかかる日数を経理・購買部門へ先に確認するだけ。3か月かかる組織なら、要件は先に固め切る一択です。

段階的に確定してよい条件と、契約・見積もりを書き分けるやり方

逆に、発注先が既に決まっていて予算に一定の幅があり、外部システム連携がない案件では、要件を段階確定にしたほうが総費用は下がります。実際の画面を触ってから機能の要不要を判断できるためです。全部を先に決めると、使われない機能に費用を払うことになる。

この場合は、契約と見積もりの書き方を分けます。対応OSの範囲、画面数、公開予定日、非機能要件は固定要件として契約に含め、各画面の入力項目数や通知の種類は「上限を決めた変動要件」として別立てにする。ただし対応OSと開発方式、認証方式、決済の有無の四つだけは最初に固定してください。後から変えると作り直しになり、段階確定の利点が消えます。

要件定義の段階から開発会社に任せる判断基準と委託範囲の決め方

開発会社に要件定義から任せるべきかの判断基準は、社内に「アプリ全体の画面構成を描ける人」がいるかどうかの一点。いなければ要件定義を工程として切り出し、有償で依頼したほうが結果的に安くつきます。自力で書いた要件定義書が実現不能な水準を含んでいると、その分の見積もりを払うことになるためです。

委託する場合でも、目的と数値目標、対象ユーザーと利用場面、対応OSの下限、公開後の更新体制の4点は発注者が決めます。ここを含めて丸ごと委託すると、自社の事情が反映されないアプリができあがる。業務要件パートの書き方は業務要件定義の記載項目と作り方にまとめました。要件の整理段階から相談したい場合はスマホアプリ開発で対応しています。

よくある質問

発注者から実際に寄せられる質問をまとめました。

アプリ開発の要件定義書は何ページくらいになりますか？

画面数20〜30程度の業務アプリで、本文20〜40ページに収まる案件が多い形です。ただし分量は品質の指標になりません。画面一覧と機能一覧を別ファイルの表で持てば、本文は10ページ台でも十分に機能する。保留項目と決定期限が明記されているかを確認してください。

要件定義は開発会社に依頼できますか？費用はどれくらいですか？

依頼できます。要件定義だけを別工程として切り出す形が一般的で、その成果物を使って別の会社に相見積もりを取ることも可能です。費用は画面数と関係部門の数で幅が出るため、ヒアリング回数と成果物の範囲を先に決めたうえで見積もりを取ってください。

iOSとAndroidの両方に対応すると費用は単純に二倍になりますか？

二倍にはなりません。要件定義、画面設計、サーバー側の実装は共通で、増えるのは端末側の実装と動作確認の分です。クロスプラットフォーム開発を選べば端末側の実装も大部分を共通化できる。ただし通知や課金、端末権限まわりはOSごとの差が残ります。片方から先に出す判断もあり得るため、利用者のOS比率を実データで確認してから決めてください。

要件定義の段階で画面のデザイン案は必要ですか？

完成度の高いデザイン案は不要です。要件定義で要るのは、画面の一覧と、各画面で何ができるかの記述、それに画面遷移の経路。線画レベルの画面イメージがあれば認識のずれは十分に減らせます。配色や書体などの表現面は、要件が固まってから設計工程で詰めるほうが手戻りが減る。

要件定義にはどのくらいの期間を見ておけばよいですか？

1部門主導で画面数20程度なら3〜5週間、3部門以上が関わり基幹システム連携があるなら8〜12週間が目安。期間の大半は承認待ちに消えるため、レビュー締切と「期限までに返答がなければ承認とみなす」運用を最初に合意しておくと短縮できます。

関連記事

• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：目的と成果物の全体像。
• 要求定義と要件定義の違い：要望を要件へ落とす前段の工程。
• 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説：業務要件パートの書き方。
• Web制作の要件定義とは？決める項目・進め方と発注者の作業範囲を解説：Webへ倒す場合の要件整理。
• システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説：前後の工程の全体像。