アプリ開発は、企画・要件定義・設計・開発・テスト・リリースという6つの工程で進みます。手順の一般論は多く出回っていますが、実務で迷いやすいのは、各工程が何を決め、何を成果物として残すのかが分からないまま次へ進んでしまうことです。企画からリリースまでを6工程の地図にします。外注を検討している方は見積書の項目の意味が分かるようになり、個人開発の方は省略していい工程と、省略すると事故る工程の見分けがつくようになります。
「アプリ開発の流れ」は工程ごとの意味を知ると進め方に迷わなくなる
アプリ開発の流れを解説する記事は数多くありますが、多くは「まず企画、次に開発」といった手順の紹介で終わっていて、各工程が何を決め、何を成果物として残すのかまでは触れていません。個人開発でも外注でも、詰まりやすいのはこの「工程の意味」を知らないまま次に進んでしまうことです。
企画からリリースまでを6つの工程に分けて、それぞれが「何を決める工程で、何が成果物になるか」を地図として整理します。外注を検討している方は、見積書に並ぶ項目の意味が分かるようになります。各工程の成果物は、外注ではそのまま納品物として受け取るものにあたります。個人で開発している方は、省略してよい工程と、省略すると後で事故る工程を見分けるための材料になります。
工程は分かりやすさを優先して順番に書いていますが、実際のアプリケーション開発の現場では、設計と開発を小さく繰り返す進め方をとるチームも珍しくありません。順番通りに一度で仕上げるやり方と、小さく回すやり方のどちらが優れているというより、規模や体制に応じて選ぶものだと捉えてください。
①企画──誰のどんな課題を解決するかを決める工程
企画は、「誰の、どんな課題を、どう解決するか」を言葉にする工程です。ここでの成果物は、機能のリストではなく、コンセプトと、そのコンセプトを裏づける需要の根拠の2つです。作りたいものが先にあるのは自然なことですが、それを誰が求めているかまでセットで言語化しておくと、後工程の判断がぶれにくくなります。
需要の根拠というと大がかりな市場調査を思い浮かべるかもしれませんが、実務ではもっと軽いもので十分です。想定しているジャンルが、どんな言葉で検索されているか、関連してどんな言葉が探されているかを確認するだけでも、企画の解像度は大きく上がります。「ある程度探されている」と分かっているだけで、開発の途中で不安になったときに立ち返れる支えにもなります。
この確認にはAppLupeのようなASOツールが使えます。キーワードごとの検索ボリュームや関連キーワードを、メール登録だけ（カード不要）で毎日3回まで無料で調べられるので、企画メモの段階で数字を見ながらアイデアを固める使い方ができます。
②要件定義──作る機能・作らない機能を文字にする工程
要件定義は、企画で決めたコンセプトを、「作る機能」と「作らない機能」のリストに落とし込む工程です。決まったテンプレートがあるわけではなく、機能の一覧とそれぞれの優先度が分かる状態になっていれば形式は自由です。大事なのは、後で見返したときに「これは作る/作らない」の判断がついた記録として残っていることです。迷った機能は「最初のバージョンでは作らない」側に倒しておくと、リストは自然と引き締まります。
個人開発の場合、企画と要件定義を1枚のメモに圧縮してしまって構いません。誰のどんな課題を解決するか、そのために作る機能は何かを、数行でもいいので言葉にしておく、という程度で十分です。ただし、この工程をゼロにしてしまうと、開発の途中で「結局何を作っていたんだっけ」と迷子になりがちです。
外注する場合、要件定義はそのまま見積もりの土台になります。「要件定義に時間とお金がかかる」という声を聞くことがありますが、これは手抜きではなく、後工程での手戻りを防ぐための保険だと捉えると納得しやすいはずです。
③設計──画面とデータの構造を決める工程
設計は、要件定義で決めた機能を、「どの画面で」「どんな操作で」実現するかに落とし込む工程です。成果物としては、画面同士のつながりを示す画面遷移図や、各画面のレイアウトを示すワイヤーフレームが一般的です。
あわせて、アプリが扱うデータの構造もこの段階で整理しておきます。ユーザー情報やコンテンツをどんな単位で持つか、どの画面でどのデータを表示・更新するかを決めておくと、開発に入ったときに「この項目はどこから持ってくるんだっけ」という迷いが減ります。紙のスケッチでも図示ツールでも構いません。粒度は「1週間後の自分が見て思い出せる」程度で十分です。
個人開発だと設計を頭の中だけで済ませがちですが、画面遷移図だけでも書き出しておくと、後から見返して機能の抜け漏れに気づきやすくなります。外注の場合は、この設計書がそのまま開発側との認識合わせの資料になります。
④開発と⑤テスト──作って、他人の目で確かめる工程
開発は、設計までの内容を実際に動くアプリとして組み立てていく工程です。工程としてやることは実装そのものですが、前工程で決めたことが曖昧なほど、この段階で手戻りが増えるという関係にあります。企画・要件定義・設計を飛ばして進めた場合のしわ寄せは、たいていここに集まります。
テストは、できあがったものが想定どおりに動くかを確かめる工程です。個人開発だと自分の端末だけで確認して終わりにしがちですが、自分以外の端末やOSバージョンで触ってもらうだけで見つかる不具合は少なくありません。画面サイズの違いや、自分では踏まないであろう操作の順番で問題が出ることはよくあります。身近な人に5分だけ触ってもらい、操作に迷った場所を横で観察する。それだけでも立派なユーザビリティテストになります。
外注の場合、テストは進行報告の中で「動作確認フェーズ」として区切られることが多い工程です。ここで見つかった不具合の修正が、要件定義の段階で決めた仕様に対する差分なのか、新たな要望なのかを分けて考えると、追加の話になったときにも認識がずれにくくなります。
⑥リリースと運用──公開して終わりではなく、始まりの工程
リリースは、App StoreやGoogle Playへの申請と公開作業を指します。申請時の審査基準やガイドラインは変わることがあるため、最新の内容は必ず公式で確認してください。ここまでの5工程をきちんと踏んでいれば、申請自体で慌てることは少なくなります。ストア掲載情報（アプリ名・説明文・スクリーンショット）の準備もこの工程の一部として最初から工数に入れておくと、公開直前に慌てずに済みます。
そして、公開した瞬間はゴールではなく、運用工程の始まりです。レビューの内容や、ダウンロード・検索順位といった数字を見ながら、機能や説明文を少しずつ直していくのがこの工程の中身になります。企画で立てた「誰のどんな課題を解決するか」という仮説が、実際に合っていたかを確かめる工程でもあります。
6つの工程を振り返ると、開発以外の工程がその前後を支えていることが分かります。どの工程を厚くして、どの工程を軽くするかは、個人開発か外注か、アプリの規模によって変わって当然です。ただ、工程そのものの意味を知らずに省略するのと、意味を分かったうえで意図的に圧縮するのとでは、後で受ける手戻りの大きさが変わってきます。
よくある質問
Q. アプリ開発の流れは何工程に分かれますか？
大きく分けると、企画・要件定義・設計・開発・テスト・リリースと運用の6工程に分かれます。呼び方や区切り方はサービスによって多少違いますが、「何を作るか決める」→「形にする」→「作って確かめ、公開する」という流れ自体はどのアプリ開発でもおおむね共通しています。
Q. 要件定義書はどんな形式で書けばいいですか？
決まったテンプレートはありません。作る機能と作らない機能の一覧、それぞれの優先度が分かる状態になっていれば、箇条書きのメモでも表計算ソフトでも十分です。後から見返して「作る/作らない」の判断がついた記録として残っていることが重要で、形式そのものにこだわる必要はありません。
Q. webアプリとスマホアプリで開発の流れは違いますか？
大枠の6工程（企画・要件定義・設計・開発・テスト・リリース）は共通しています。違うのは主に配布方法で、スマホアプリはストア審査を経て公開しますが、webアプリはブラウザからそのまま公開できます。工程の意味自体は同じように考えて問題ありません。
Q. アプリ開発の手法や進め方に種類はありますか？
大きく分けると、工程を順番に進めて一度で仕上げる進め方と、設計から確認までを小さく繰り返す進め方の2つがあります。ここで示すフローは前者の形ですが、どちらが優れているという話ではなく、規模と体制で選ぶものです。個人開発なら、6工程を一巡させたうえで、機能単位で小さく回すやり方が現実的な落としどころになります。
AppLupe（アップルーペ）運営ツールこのブログを運営しているAppLupeは、App Store対応のASOツールです。「作ったアプリが検索で見つからない」を解決するために、キーワード調査から順位計測までを1つにまとめています。
- キーワードの検索ボリューム（AppLupe指数）と関連キーワードを確認
- 競合アプリがどのキーワードから流入しているかを実測
- AIがタイトル・サブタイトル・スクリーンショットの改善案を自動生成
- 狙ったキーワードの検索順位を毎日自動トラッキング