アプリ開発の流れ：企画からストア公開まで

アプリ開発で大切なのは、コードよりも判断です。どの課題を解決するのか、最初のバージョンに何を入れるのか、どの技術が合うのか、公開後は誰が何を所有するのか。このガイドでは、最初のアイデアからApp StoreとGoogle Playでの公開、その後の保守まで、アプリ開発の流れを一つずつたどります。現実的な計画を立て、自信を持って開発チームに依頼できるようになるはずです。

要点

最初のアプリは小さく作るのが最善です。1つの課題をしっかり解決するMVPを、多くの場合はクロスプラットフォームで開発します。顧客が時々しか使わないなら、WebサイトやPWAで十分なこともあります。プライバシーとストア審査は最初から設計に組み込み、コードとデータが自社のものであり続けるよう自社の開発者アカウントで公開し、公開後の保守の予算も確保してください。

課題、MVP、プロトタイプを決める

アプリ開発の最初のステップは、アプリが解決する課題を定義することです。MVPとクリック可能なプロトタイプはそこから決まります。機能を並べる前に、次の3つを書き出してください。

誰のためのアプリで、その人は何をしようとしているのか。 「数回のタップで再注文したい常連客」は課題です。「メニュー、ポイント、チャットのあるアプリ」は機能の一覧です。
なぜアプリなのか。 Webサイトやメッセージアプリではなく、アプリをインストールして繰り返し使ってもらえる理由は何か。社内の定型作業を減らすことが目的なら、業務自動化ツールで足りることもあります。
成功とは何か。 リピート注文、電話の減少、スタッフを介さない予約など、測定できる指標を選びます。

次にMVP（Minimum Viable Product：実用最小限の製品）を定義します。中心となる課題を、実際の人が使えるレベルで解決できる最小のバージョンです。「登録 → 閲覧 → 注文 → 支払い → 通知を受け取る」のような中心となる利用の流れを1〜2本書き出し、それ以外はすべて「後で」リストに移します。MVPは半分壊れたアプリではなく、狭い範囲の中で完成度を高めたアプリです。

コードを書く前に、その流れをFigmaなどのツールでクリック可能なプロトタイプにし、数人の対象ユーザーにスマートフォンで操作してもらいましょう。プロトタイプの段階で画面を変えるコストは、完成したコードを変えるよりはるかに小さく済みます。通信できない、決済が拒否された、権限が許可されなかった、といった「うまくいかない場合」もプロトタイプで設計しておきます。

ネイティブ、クロスプラットフォーム、それともWebアプリ？

ほとんどの業務用アプリでは、クロスプラットフォーム開発が妥当な第一候補です。重いグラフィック、カメラ、音声処理が必要ならネイティブに価値があり、顧客が時々しか使わないならWebアプリやPWAで十分なことがよくあります。3つの選択肢を比べると次のとおりです。

ネイティブ： プラットフォームごとに別のアプリを、iOSはSwift、AndroidはKotlinで開発します。端末の機能を最大限に使えますが、2つのコードベースを保守する必要があります。
クロスプラットフォーム： FlutterやReact Nativeなどのフレームワークで、iOSとAndroidのコードの大部分を共通化します。Flutterのドキュメント（英語）は、その目的を「単一のコードベースからマルチプラットフォームのアプリを構築する」ことと説明しています。注文、予約、会員、カタログ、社内ツールといった一般的な業務用アプリでは、これが妥当な第一候補です。重いグラフィック、高度なカメラや音声の処理、最新のプラットフォーム機能への依存がある場合は、ネイティブが有利になることがあります。
WebアプリまたはPWA： プログレッシブWebアプリ（PWA）はブラウザで動き、ホーム画面に追加でき、ストア審査も不要です。顧客が時々しか使わない場合や、アイデアをまだ検証している段階なら、これで十分なことがよくあります。トレードオフは、ストアに掲載されないこと、端末機能との連携が難しいこと、iOSでのPWAのサポートが限られることです。

簡単な判断のしかたがあります。ユーザーは毎週使うのか、年に数回なのか。プッシュ通知、オフライン利用、バックグラウンドでの位置情報は必要か。信頼のためにストアに掲載されていることが重要か。答えのほとんどが「いいえ」なら、高速でモバイルファーストのWebサイトやPWAのほうが、最初の一歩として適しているかもしれません。ホームページの作り方はWix・WordPress・フルスクラッチの比較で解説しています。

バックエンド、管理画面、API

ほとんどの業務用アプリは、より大きなシステムの先端にすぎません。画面の裏側には、バックエンド、管理画面、そして決済、配送、既存システムとの連携があります。

バックエンド： アカウント、注文、コンテンツ、通知を扱うサーバーとデータベースです。Firebaseのようなマネージドサービスを使えばMVPを早く作れます。独自のバックエンドなら、成長に合わせてデータ、連携、運用コストをより細かくコントロールできます。
管理画面： 商品、注文、ユーザー、通知を管理するために、チームが毎日使うWebの画面です。管理画面は計画から漏れやすいため、早めに定義し、誰が顧客データを見られるか、誰が返金できるかといった役割と権限も決めておきます。
APIと連携： 決済、地図、配送、メッセージ、そしてECサイト、ERP、CRM、会計ソフトといった既存のシステムとの連携です。どの連携も相手側のドキュメント、アクセスの承認、利用上限に左右されるため、計画を確定する前に確認してください。ERPやCRMそのものを作るか既製品を使うかは、ERP・CRMのスクラッチ開発とパッケージの比較で解説しています。

データをどこでホスティングするかも早めに決めましょう。リージョンはプライバシー関連の法律に関わります。アプリ内でデジタルコンテンツやサブスクリプションを販売する予定なら、各ストアの最新の決済ルールを確認してください。ルールは地域によって異なり、変わり続けています。

プライバシーとデータ保護

プライバシーは最初から組み込みます。必要なデータだけを集め、どの法律が適用されるかを把握し、トラッキングの前に同意を得て、ストアでデータの使い方を申告し、ユーザーがアカウントを削除できるようにします。プライバシーは法的義務であると同時にストアの要件でもあり、後から付け足すより最初から設計に組み込むほうがはるかに簡単です。

必要なものだけを集める。 すべての入力項目と権限（位置情報、連絡先、カメラ）は、説明できる機能に対応している必要があります。
適用される法律を把握する。 EU域内のユーザーがいる場合はGDPRが適用されます。欧州データ保護会議（EDPB）の中小企業向けデータ保護ガイド（英語）は、欧州経済領域（EEA）外の組織であっても、域内の人々に商品やサービスを提供していれば対象になることを確認しています。GDPRは、データの利用ごとの法的根拠、わかりやすい情報提供、利用者の権利、データを処理する委託先との契約を求めています。日本を含む他の多くの国や、米国のいくつかの州にも独自のプライバシー法があります。
トラッキングの前に同意を得る。 EUでは、厳密に必要ではない分析・広告用のSDKには原則として事前の同意が必要で、第三者のSDKが収集するデータにも責任を負います。iOSでは、他社のアプリやWebサイトをまたいでユーザーを追跡するには、AppleのApp Tracking Transparency（ATT）の許可が必要です。
ストアで申告する。 AppleはApp Store の「App のプライバシー」の詳細を、Google Playは「データセーフティ」セクションを求めます。どちらもプライバシーポリシーが必要で、申告内容はアプリの実際の動作と一致していなければなりません。
アカウントを削除できるようにする。 AppleのApp Reviewガイドライン5.1.1は、「アカウントの作成に対応したアプリの場合は、アプリ内でアカウントの削除もできるようにする必要があります」と定めています。Google Playのアカウント削除要件はさらに、アプリの外からアカウントと関連データの削除をリクエストできるWebリンクの提供を求めています。

テスト、ストア審査、自社の開発者アカウント

公開前のアプリには3つのことが必要です。実機でのテストとベータ版、AppleとGoogleのストア審査の通過、そして自社の開発者アカウントでの公開です。

テスト。 実機を使います。古い端末と新しい端末、小さな画面と大きな画面、対応するすべてのOSバージョンです。そのうえで、AppleのTestFlightとGoogle Playのテストトラックでベータテストを行います。Google Playのテスト要件では、2023年11月13日以降に作成された個人用デベロッパーアカウントは、製品版へのアクセスを申請する前に、12人以上のテスターが少なくとも14日間連続でオプトインした状態でクローズドテストを実施する必要があります。このルールは個人用アカウントにのみ適用されます。

ストア審査。 AppleはApp Reviewガイドラインに、GoogleはGoogle Play デベロッパープログラムポリシーに照らしてアプリを審査します。Appleのガイドライン4.2は、「Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するように」求めています。よくあるつまずきは、クラッシュ、不完全な掲載情報、プライバシー情報の不足、アカウント削除機能がないこと、審査担当者用のデモログインがないこと、Webサイトを包んだだけに近いアプリです。リジェクト（却下）と再申請の時間もスケジュールに見込んでおきましょう。

自社のアカウント。 開発会社のアカウントではなく、自社の開発者アカウントで公開します。Apple Developer Programには年会費が、Google Play Consoleには1回限りの登録料がかかります。どちらも組織アカウントにはD-U-N-S番号と本人確認が必要なので、早めに準備を始めてください。ドメイン、ホスティング、コードリポジトリ、署名用の認証情報も自社名義で管理しましょう。

公開前後の費用と期間を左右するもの

アプリの費用と期間は、主にプラットフォームとユーザーの役割、機能の複雑さ、連携、デザインへのこだわり、法令対応の要件、発注側の対応の速さ、そして公開後の保守によって決まります。範囲が明確でなければ、誠実なチームはアプリの金額を出せません。次の要素で大きく変わるからです。

プラットフォームと役割： iOS、Android、Web、管理画面のそれぞれに作業が増えます。顧客向けアプリ、スタッフ向けアプリ、管理画面は、1つではなく3つのプロダクトです。
機能の複雑さ： リアルタイムチャット、リアルタイムの位置情報、動画、オフライン同期、予約のルールは、重い機能の代表例です。
連携： 外部システムが1つ増えるごとに作業が増えます。良いAPIを持たない古いシステムは特にそうです。
デザインへのこだわり： 標準のコンポーネントは、独自のビジュアルやアニメーションより早く作れます。
言語、市場、法令対応： 翻訳、現地の決済手段、データ移行、厳しいセキュリティ要件。
発注側の対応： 判断がどれだけ早く出るか、文章、画像、商品データが期日までに用意できるか。

公開は予算の終わりではありません。AppleとGoogleは毎年新しいOSバージョンをリリースし、ストアの要件もそれに合わせて変わります。ライブラリにはセキュリティアップデートが必要で、サーバーには運用コストがかかり、実際の利用状況が次に作るべきものを教えてくれます。

開発会社への依頼のしかた

開発会社には、課題、中心となる利用の流れ、プラットフォーム、連携、制約をまとめた短い文書で依頼します。それがあって初めて、意味のある見積もりが出せます。次の内容を含めてください。

課題、対象ユーザー、成功の測り方。
中心となる利用の流れ、MVPの機能リスト、「後で」リスト。
プラットフォーム、対象国、言語。
アプリと連携が必要な既存のシステムとデータ。
管理画面を誰が、何のために使うのか。
気に入っているアプリと、その具体的にどこが良いのか。
制約：目標の日程とその理由、予算の幅、誰が決裁するのか。

そのうえで、開発チームに次のことを尋ねましょう。作業をどう段階に分けるか。コード、デザイン、アカウントは誰のものになるか。範囲の変更はどう扱うか。保守はどのような形になるか。

よくある質問

ネイティブアプリとクロスプラットフォーム、どちらで開発すべきですか？

注文、予約、会員、社内ツールなど、ほとんどの業務用アプリでは、1つのコードベースでiOSとAndroidの両方に対応できるクロスプラットフォームが妥当な第一候補です。アプリが重いグラフィック、高度なカメラや音声の機能、最新のプラットフォーム機能に依存する場合は、ネイティブのほうが理にかなっています。

アプリ開発の費用はどれくらいかかりますか？

価格表ではなく範囲で決まります。プラットフォーム、画面数とユーザーの役割、連携、デザインへのこだわり、法令対応の要件、そして公開後の保守です。信頼できる見積もりを得る最善の方法は、明確なMVPの要件をまとめることで、見積もりは段階ごとに分けてもらうのが理想です。

AppleとGoogleの開発者アカウントは自社で用意する必要がありますか？

はい、強くおすすめします。自社のアカウントなら、掲載情報、レビュー、アップデートを自社で管理でき、アプリを移管せずに開発チームを変えることもできます。Appleは年会費、Google Playは1回限りの登録料がかかり、組織アカウントにはD-U-N-S番号が必要です。

UsualMatrixは、世界中のお客様に向けて、iOS・Androidアプリとその裏側のバックエンド、管理画面を設計・開発しています。やり取りは中国語・スペイン語・英語で行います。アプリ・システム開発サービスをご覧いただくか、アイデアについてお問い合わせください。

重要： 本記事は、公開時点のアプリ開発、ストアのルール、プライバシー関連の法律に関する一般的な情報であり、法的助言ではありません。ルールは変わるため、最新の要件を確認し、個別のケースについては弁護士またはデータ保護の専門家にご相談ください。