アプリ開発の流れとは？企画から保守まで7工程で発注側が決めることを解説

アプリ開発の流れは、企画・要件定義・設計・開発・テスト・ストア審査とリリース・保守運用の7工程で進みます。開発会社に任せれば全部やってもらえる、と考えて発注した場合、要件定義で答えを返せずに止まり、受入テストで判断がつかず、ストア審査で差し戻される、という順に遅れが積み上がっていく構造です。この記事では7つの工程それぞれについて「発注側が決めること」「用意する資料」「期間の目安」「社内で確保すべき稼働」を分けて整理し、最後に請負と準委任のどちらで契約すべきかまで言い切ります。

まとめ｜アプリ開発の流れ7工程と発注側が各工程で決めること

アプリ開発の流れを一枚で言うと、こうなります。企画で「誰の何の課題を解くか」を決め、要件定義でそれを機能の一覧に落とし、設計で画面と内部構造を固め、開発で作り、テストで受け入れ可否を判定し、ストア審査を通してリリースし、そのあと保守運用が続きます。開発会社が主導するのは設計・開発・テストの中盤で、前後の企画・要件定義・受入判定・公開後の改善は、発注側が決めなければ前に進みません。その開発会社をどう選ぶかは、アプリ開発会社の選び方は？依頼先の見極め方と見積比較の判断基準で判断条件を扱っています。

期間の目安は、小規模なアプリで3〜4か月、業務システムと連携する中規模で6〜9か月です。発注側の稼働が集中するのは要件定義と受入テストの2工程で、ここに社内の担当者を週数時間ずつ確保できるかが納期のぶれをほぼ決めます。またiOSとAndroidはリリース前にストア審査を通す必要があり、ここは開発会社の腕だけでは短縮できません。

契約形態は工程で分けるのが現実的です。要件が固まりきっていない企画・要件定義は準委任、仕様が確定した設計以降は請負、という切り分けにすると、追加費用のもめごとが起きにくくなります。

アプリ開発の流れの全体像｜7工程と各工程で生まれる成果物の対応

まず全体像を押さえます。工程の名前は開発会社ごとに多少ぶれますが、成果物で見れば各社ほぼ共通です。何が出てくるかを知っておくと、進捗の報告を受けたときに「今どこにいるのか」が判断できます。

企画から保守運用までの7工程と、工程の終わりに受け取る成果物

工程の並びと成果物の対応は次のとおりで、見積書の項目もおおむねこの単位で積み上がります。

工程	主な作業	受け取る成果物
1 企画	目的と対象の言語化	企画書・概算見積
2 要件定義	機能と非機能の確定	要件定義書
3 設計	画面設計と内部設計	画面設計書・設計書
4 開発	実装と単体テスト	動くアプリ・ソース
5 テスト	結合テストと受入検収	テスト報告書
6 審査とリリース	ストア提出と公開	公開済みアプリ
7 保守運用	障害対応と機能改善	月次の運用報告

開発会社が主導する工程と、発注側が決めないと止まる工程の切り分け

7工程のうち、開発会社が主導で進められるのは3の設計から5のテスト実施までで、ここは任せた方が早く正確に進みます。一方、1の企画、2の要件定義、5のうちの受入判定、7の改善優先度づけは、発注側が答えを出さないと前に進みません。開発が止まる原因の多くは技術の壁ではなく、この4か所での意思決定の遅れです。

もうひとつ、着手前に決めておきたい分岐があります。スマートフォンにインストールするアプリを作るのか、ブラウザから使う形にするのかです。ブラウザで足りるなら、ストア審査という不確実な工程を外せます。判断材料はWebアプリ開発とは？仕組み・種類・開発言語から費用と外注判断までで整理していますので、形態がまだ決まっていない段階なら先に目を通してください。

工程1と2｜企画と要件定義で発注側が決めることと用意する資料

アプリ開発の流れで最も成果を左右するのが、この2工程です。ここで曖昧に流した項目は、設計以降で必ず追加費用と遅延になって戻ってきます。

企画工程で言語化する4項目｜目的・対象・成功指標・公開時期の判断基準

企画で決めるのは、技術ではなく事業側の前提です。第一に目的、このアプリで何の業務や課題を解くのか。第二に対象、誰がどんな場面で開くのか。第三に成功指標、公開後に何の数字が動けば成功と見なすのか。第四に公開時期で、展示会や繁忙期など動かせない期日の有無を明示します。

この4項目を書いた紙が1〜2枚あるだけで、開発会社からの提案の精度は変わります。ここが空欄のまま見積もりを取ると各社が別々の前提で積算するため、金額を比べても意味を持ちません。機能の一覧より先に、目的と対象を固めてください。

要件定義で確定する機能要件と、見落としやすい非機能要件の範囲

要件定義は、企画で決めた目的を「作れる単位」に翻訳する工程です。機能要件は、会員登録、検索、通知、決済、管理画面といった画面と操作の一覧に落とします。「あったら便利」を全部入れると費用が膨らむため、初回リリースに入れるものと次回以降に回すものを線引きしてください。

見落としが起きやすいのは非機能要件です。同時に何人が使うのか、応答は何秒以内か、個人情報をどう扱うか、障害時に何時間で復旧するか、対応OSはどこまでか。画面には現れませんが、サーバー構成と費用を大きく動かします。決める項目の粒度と進め方はアプリ開発の要件定義とは？決める項目・進め方と発注前に固める範囲で詳しく扱っていますので、要件定義に入る前に確認しておくと社内の議論が早く済みます。

発注側が用意する資料は、現行業務のフロー図、扱うデータの項目一覧、既存システムの仕様、社内規程のセキュリティ要件です。揃っていないと開発会社はヒアリングの往復に時間を使い、そのぶん要件定義が長引きます。

工程3と4｜設計と開発で発注側が確認する範囲と関与の頻度を決める

設計と開発は開発会社の主戦場ですが、丸投げにすると完成後に「思っていたものと違う」が起きます。どこを見て、どこは任せるかを分けておきます。

画面設計は必ず見る｜内部設計は任せて構わないという線引きの判断基準

設計は、外側の設計（画面設計・UI設計）と内側の設計（データベース構造、サーバー構成、外部連携の方式）に分かれます。発注側が時間を割いて確認すべきは前者です。画面遷移図とワイヤーフレーム、あるいは実際に触れる試作を見て、業務の順番どおりに操作できるかを現場の担当者に確かめてもらいます。ここで直せば数時間で済むものが、開発後だと数十万円規模の手戻りになります。

内部設計は専門性が高く、発注側が細部を判定するのは現実的ではありません。ただし2点だけは説明を求めてください。個人情報や決済情報をどこにどう保管するか、そして将来の利用者増にどう対応する構成か。この2つは事業のリスクに直結するため、日本語で説明できる会社を選びます。

開発工程での関与は隔週の進捗確認と決裁の速さで足りるという判断基準

実装が始まると、発注側の仕事は「聞かれたことに早く答える」ことに移ります。文言をどうするか、この場合はエラーにするか通すか、といった細部の質問が必ず出るからです。関与の頻度は隔週で進捗を確認し、動く画面を触らせてもらう程度で足ります。毎日の報告を求めても進みは早くなりません。社内で即答できる決裁ラインを1人決め、質問の窓口と回答期限を置くほうが、遅延はよく抑えられます。

工程5｜テストと受入検収で発注側が判定する4つの観点と判断基準

テストは開発会社が実施するものと、発注側が実施するものに分かれます。前者は単体テストと結合テストで、機能が仕様どおりに動くかを技術的に確かめます。後者が受入テストで、業務として使えるかを判定する場です。ここは代行できません。

受入テストで見る4観点｜業務手順・データ・端末・例外の通り方

受入テストでは次の4観点で確認します。第一に業務手順で、実際の1日の流れをそのまま再現して操作できるか。第二にデータで、本番相当の件数を入れて破綻しないか。第三に端末で、社内で使う機種とOSバージョンの組み合わせで表示が崩れないか。第四に例外で、通信が切れた、入力を間違えた、途中で終了した、といった使い方をしたときの挙動です。

特に見落とされるのが4つ目です。正しく操作したときだけ試して合格にすると、公開後の問い合わせが例外系に集中します。現場の担当者へ「わざと間違えて使ってみてほしい」と依頼する時間を検収期間に組み込んでください。

検収の合否は事前に基準を決めてから｜不具合の重み付けの決め方

不具合はゼロになりません。だからこそ検収に入る前に「どの水準なら合格とするか」を開発会社と合意しておきます。実務では、業務が止まる不具合は公開前に必ず修正、代替手段がある不具合は公開後の修正で可、表示の細かなずれは次回改修に回す、という3段階が扱いやすい形です。

基準を決めずに検収へ入ると、軽微な表示崩れで公開が延びたり、逆に支障の出る不具合を抱えたまま公開してしまったりします。検収期間そのものも、小規模で1〜2週間、中規模で3〜4週間を見込んでスケジュールに書き込んでおきましょう。

工程6｜ストア審査とリリースで差し戻されないための提出前の準備

スマートフォン向けアプリでは、完成しても自由に公開できるわけではありません。App StoreとGoogle Playの審査を通す必要があり、ここは開発会社の技術力だけでは短縮できない工程です。競合記事の多くがこの工程を省いていますが、公開日を約束している案件ほど、ここで事故が起きます。

App Storeの審査で見られる5分類と、差し戻しが多い準備不足

Appleが公開しているApp Store Review Guidelinesは、2026年8月時点でSafety（安全性）、Performance（動作）、Business（ビジネスモデル）、Design（設計）、Legal（法務）の5分類で構成されています。技術的な不具合よりも、この5分類のうち書類や情報の準備不足で差し戻される例が目立ちます。

審査担当者がログインして中身を確認できるテスト用アカウントを出していない、課金の仕組みがあるのに規定の決済方式を使っていない、個人情報を取得するのにプライバシーポリシーの掲載先を示していない、といったものです。いずれも開発とは別に発注側で用意する情報が絡みます。iOS側の準備の詳細はiOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断にまとめています。

Google Playの審査日数と、新規の個人アカウントに課される追加要件

Google Playについては、公式ヘルプが「一部のデベロッパーアカウントについては、利用者保護のためより慎重に審査するため、審査に7日以上、例外的にはそれ以上かかる場合がある」と案内しています（2026年8月時点）。初回の提出ほど時間がかかる前提で、公開希望日から逆算した余裕を持たせておきます。

さらに、2023年11月13日以降に作成した個人のデベロッパーアカウントには、本番公開を申請する前にクローズドテストを実施する要件があります。同時点の公式ヘルプが示す条件は、12人以上のテスターが直前の14日間にわたり継続してオプトインしている状態です。つまり、法人アカウントではなく個人名義で登録した場合、完成してから最短でも2週間はテスト期間が必要になります。この点を知らずに個人アカウントで進め、公開が2週間以上ずれる例は珍しくありません。Android側の前提はAndroidアプリ開発とは？できること・開発の流れ・iOSとの違いで整理しています。

発注側の準備物は、ストアアカウントの名義と支払い情報、アプリの説明文とスクリーンショット、プライバシーポリシーの掲載ページ、年齢区分の申告内容です。開発会社に代行を頼む場合でも名義と規約への同意は発注側の判断になるため、審査の1か月前には着手しておきましょう。

工程7｜保守運用でかかる費用とOSの年次更新に追随する考え方

公開して終わりではありません。アプリは、置いておくだけで少しずつ動かなくなる性質があります。理由は、土台であるOSとストアの仕様が毎年変わるからです。

保守費用の内訳｜サーバー維持・障害対応・OS追随・機能改善の4本

保守運用の費用は4つに分かれます。サーバーやクラウドの維持費、不具合が出たときの障害対応費、iOSとAndroidの年次更新に動作を合わせ込む追随費、利用状況を見て手を入れる機能改善費です。前の3つは止められない支出で、4つ目だけが事業判断で増減できます。

相場は、開発費の10〜20%程度を年間保守費として見込む契約が一般的です。金額の考え方と規模別の内訳はアプリ開発の費用相場は？規模・OS・開発手法別の内訳と抑え方で扱っていますので、予算を組む段階で参照してください。

OSの年次更新に合わせた改修は、公開時点で予算に組み込んでおく

iOSとAndroidは毎年メジャーバージョンが更新され、それに伴ってストア側も、対応すべきOSバージョンの下限や必要な申告項目を引き上げていきます。機能をまったく増やさなくても年に一度は改修が発生する、と考えて予算を組んでください。ここを見込まずに開発費だけで予算を締めると、2年目にストアから警告が届いてから慌てることになります。

公開後にまず見るべき数字は、クラッシュ率、初回起動から離脱する割合、問い合わせの内容の3つ。これらを毎月確認して改善の優先度を発注側が決める運用の型を最初に作っておくと、改修の判断が感覚論になりません。

開発手法で流れはどう変わるか｜ウォーターフォールとアジャイルの差

ここまでの7工程は、上流から順に進める前提で説明しました。実際には開発手法で工程の回り方が変わるため、どちらで進めるかを発注前に握っておきます。

ウォーターフォールが向く条件と、アジャイルに切り替えるべき場面

ウォーターフォールは、要件定義から保守まで一方向に進める手法です。費用と納期を先に確定できるため予算承認を取りやすく、既存の業務手順をそのままアプリにする案件と相性がよく働きます。途中で大きく変える予定がないなら、この形で問題ありません。

アジャイルは、小さな単位で設計から実装、確認までを繰り返す手法です。利用者の反応を見ながら機能を決める新規事業や、公開後の改善を続ける前提のサービスに向きます。ただし総額を先に固定しにくく、社内の稟議で金額の提示を求められる場合は説明の工夫が要ります。

判断の言い切り｜要件が7割固まっているかどうかを分かれ目にする

迷ったときの判断基準を1つに絞るなら、着手時点で作るものが7割以上決まっているかどうかで分けてください。7割以上決まっている、つまり画面の一覧と業務の流れがすでに書けるなら、ウォーターフォールで総額を固定するほうが管理も予算取りも楽になります。決まっていない、あるいは利用者に出してみないと分からない要素が半分近くあるなら、アジャイルで小さく出しながら決めるほうが、結果的に無駄な実装を減らせます。

逆に見送るべき組み合わせも明確です。要件が固まっていないのにウォーターフォールで総額を確定させると、変更のたびに追加見積もりが積み上がり、支払額は当初の想定を超えます。既存業務の置き換えのように答えが決まっている案件をアジャイルで進めた場合は、決定済みの事項を議論し直す時間が増え、期間が伸びます。

工程ごとの期間目安と、発注側が社内で確保すべき稼働時間の見積もり

スケジュールは、開発会社の作業期間だけを並べても実際には収まりません。発注側の意思決定と確認にかかる時間を、最初から工程表に書き込んでおきます。

小規模と中規模で見る、工程別の期間と発注側の週あたり稼働の目安

目安は次のとおりです。小規模は画面数10前後の単機能アプリ、中規模は既存システムと連携し管理画面を伴うものを想定しています。

工程	小規模の期間	中規模の期間	発注側の稼働
企画	2〜4週間	1〜2か月	週4〜8時間
要件定義	3〜4週間	1.5〜2か月	週6〜10時間
設計	3〜4週間	1〜2か月	週2〜4時間
開発	1〜2か月	2〜4か月	週1〜2時間
テスト	1〜2週間	3〜4週間	週8〜12時間
審査と公開	1〜2週間	2〜4週間	週2〜4時間

合計すると、小規模で3〜4か月、中規模で6〜9か月というのが現実的な線です。表を見ると分かるとおり、発注側の稼働は要件定義とテストの2工程に集中します。この2つの時期に社内の担当者が繁忙期と重なることが、そこだけで1か月単位の遅延を発生させる要因です。逆に言えば、この2工程に人を張れる時期から逆算してキックオフの日を決めるのが、最も効く遅延対策になります。

期間が伸びる典型パターンと、工程表に先に入れておく緩衝の置き方

期間が伸びる原因は3つに絞られます。ひとつは要件定義中の関係部署の増加で、途中から別部門の要望が入って作り直しになる形。次に受入テストでの判定の遅れで、確認する人が決まらないまま検収期間に入る形。最後がストア審査の差し戻しです。

対策は、緩衝を置く場所を変えることに尽きます。全体へ一律に余裕を足すのではなく、要件定義の終わりに関係部署への合意確認を1〜2週間、公開予定日の手前に審査差し戻し用の2〜3週間を確保してください。この2か所に緩衝があるだけで、公開日の約束は守られやすくなります。

契約形態を工程で分ける判断｜請負と準委任のどちらを選ぶかの基準

ここが発注側にとって最後の、そして金額に最も響く判断です。契約形態を一律にせず、工程で分ける考え方を採ってください。

請負と準委任の違いと、工程ごとにどちらを当てるかの判断条件を整理する

請負契約は、完成したものを納品する義務を開発会社が負う形です。金額と納期が先に確定するため予算管理はしやすい一方、決めた仕様を変えるたびに追加見積もりが発生します。準委任契約は作業そのものに対価を払う形で、完成の義務は負いません。仕様が動く前提の工程で使うと、変更のたびの交渉が消えます。

工程への当て方は次のように分けます。作るものがまだ決まっていない企画と要件定義は準委任、仕様が確定した設計・開発・テストは請負、公開後の保守運用は準委任。この3段構えにすると、変更が前提の工程で請負の窮屈さに縛られず、仕様が固まった工程では総額を固定できます。

一括請負にすべき案件と、避けたほうがよい案件の見分け方を整理する

すべてを一括請負にしてよいのは、既存の業務手順をそのままアプリに移す案件か、仕様書がすでに社内で完成している案件に限られます。この条件を満たすなら、総額固定の請負が発注側に最も有利です。

一方、新規事業のアプリ、利用者の反応を見て機能を決める予定があるもの、関係部署が3つ以上にまたがるものは、全工程の一括請負を避けてください。要件が動く確率が高く、追加見積もりの応酬で当初の総額を大きく超えます。要件定義までを準委任で切り出し、固まった時点で開発以降の見積もりを取り直すほうが安く収まります。

一創では、企画段階のご相談から要件定義、設計・開発、ストア申請の代行、公開後の保守運用までを通してお引き受けしています。工程ごとの契約形態の分け方も含めて、スマホアプリ開発のページから体制と実績をご確認ください。開発会社を比較する段階であれば、選定基準を整理したAndroidアプリ開発の外注・依頼はどう選ぶ？費用相場と代行会社の選定基準もあわせてご覧いただくと、見積もりの読み解きがしやすくなります。

よくある質問

アプリ開発の流れについて、発注者からよく寄せられる質問をまとめました。

アプリ開発の流れは全部で何工程ありますか？

企画、要件定義、設計、開発、テスト、ストア審査とリリース、保守運用の7工程が基本形です。企画と要件定義をまとめて「上流工程」と呼ぶ会社や、テストを単体・結合・受入に分ける会社もありますが、成果物で見れば内容は変わりません。見積書の項目がこの7つのどこに当たるかを確認すると、抜けている工程に気づけます。

企画から公開まで、どれくらいの期間がかかりますか？

画面数10前後の小規模なアプリで3〜4か月、既存システムと連携する中規模で6〜9か月が目安で、ストア審査の期間も含みます。要件が固まっているほど短くなり、途中で関係部署の要望が増えるほど延びます。公開日を約束している場合は、差し戻しに備えて2〜3週間の余裕を手前に置いてください。

発注側は各工程でどれくらい時間を取られますか？

要件定義で週6〜10時間、受入テストで週8〜12時間が目安で、この2工程に稼働が集中します。設計は週2〜4時間、開発中は質問に答える程度で週1〜2時間。担当者を1人決めて即答できる決裁ラインを作っておくと、開発工程の待ち時間がかなり減ります。

ストア審査で落ちたらどうなりますか？

指摘された箇所を修正して再提出します。再審査に改めて日数がかかるため、公開日は後ろにずれます。差し戻しの多くは、審査用テストアカウントの不備、プライバシーポリシーの未掲載、課金の規定違反など準備不足によるもの。提出物の準備を1か月前から進めておくと落ち着いて対応できます。

要件定義の途中で仕様を変更してもよいですか？

要件定義の工程内なら、変更しても追加費用は発生しにくい形です。設計以降に入ってからの変更は、作り直しの範囲に応じて追加見積もりになります。要件が動く可能性がある案件では、要件定義までを準委任で切り出し、固まってから開発以降の契約を結ぶ進め方が向いています。

関連記事

• アプリ開発の要件定義とは？：本記事の工程2をさらに深く扱い、決める項目と発注前に固める範囲を解説しています。
• アプリ開発の費用相場：規模・OS・開発手法別の費用内訳と、見積もりを抑える考え方をまとめています。
• Androidアプリ開発の外注・依頼はどう選ぶ？：開発会社の選定基準と費用相場を、発注者視点で整理した記事です。
• スマホアプリ開発：企画から審査代行・保守運用まで通しで相談したい場合の、当社の受託開発サービスです。