# アプリ開発期間の目安｜納期遅延を防ぐ発注方法

- 公開日: 2026-09-02
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/mobile-app-development-timeline

スマホアプリ開発の期間は、一般的に小規模で3〜5か月、中規模で5〜9か月、大規模・複雑なものでは9〜18か月以上が目安です。納期遅延を防ぐには、実装だけでなく、要件定義、画面設計、テスト、ストア審査、発注者の確認期間まで工程表に含め、公開必須日から逆算して発注します。

## アプリ開発期間の目安を規模別に比較

**スマホアプリの開発期間は、画面数だけでなく、会員機能、管理画面、外部サービス連携、セキュリティ、対応OSなどを含む全体の複雑さで決まります。** 見た目がシンプルでも、裏側に複雑な業務処理があるアプリは短期間では開発できません。

規模別の一般的な目安は次のとおりです。

| 規模 | アプリの例 | 開発期間の目安 | 期間が延びやすい要素 |
|---|---|---:|---|
| 試作・検証 | 主要画面だけを動かす試作品、社内検証用アプリ | 1〜2か月 | 実データ連携、公開品質までの作り込み |
| 小規模 | お知らせ、店舗情報、簡易会員証、コンテンツ閲覧 | 3〜5か月 | ログイン、プッシュ通知、管理画面 |
| 中規模 | 予約、EC、マッチング、位置情報、会員向けサービス | 5〜9か月 | 決済、外部API、複数の権限、複雑な管理画面 |
| 大規模 | 金融、医療、物流、リアルタイム通信、基幹システム連携 | 9〜18か月以上 | 高いセキュリティ、監査、移行、多数の外部連携 |

API（＝異なるシステム同士がデータをやり取りする仕組み）を使った決済、地図、本人確認、既存会員基盤などとの連携が増えるほど、相手側の仕様確認や接続テストにも時間がかかります。

### 試作品の期間と公開用アプリの期間は分けて考える

1〜2か月で画面を動かせる試作品が完成しても、そのまま一般公開できるとは限りません。公開用アプリでは、次の対応が追加で必要になるからです。

- エラー発生時の処理
- 個人情報や認証情報の保護
- 複数端末・複数OSでのテスト
- 管理画面や問い合わせ対応機能
- 利用規約、プライバシーポリシーの整備
- App Store・Google Playへの申請
- アクセス増加を想定したサーバー確認

発注時には「デモが動く日」と「利用者へ公開できる日」を混同しないことが重要です。

### iOS・Androidの両対応は作業量が増える

iOS版とAndroid版を共通の仕組みで開発する場合でも、すべての作業を共通化できるわけではありません。OSごとに画面表示、権限設定、プッシュ通知、課金、ストア申請のルールが異なり、端末テストも必要です。

両方へ同時公開したい場合は、見積書に以下が含まれているかを確認してください。

- iOS・Androidそれぞれの動作確認
- 対応するOSバージョンと端末範囲
- OS固有機能の調整
- 2つのストアへの申請支援
- 審査で指摘された場合の修正対応

「1つのソースで作るため期間もテストも片方と同じ」という説明には注意が必要です。

## アプリ公開までの工程と期間

**開発会社がプログラムを作る工程は、アプリ公開までの一部にすぎません。** 発注者の意思決定、デザイン確認、テスト、ストア審査を含めた全体工程で納期を判断する必要があります。

標準的な工程と期間の目安は次のとおりです。複数の工程を並行できる場合があるため、単純にすべてを合計するわけではありません。

| 工程 | 期間の目安 | 主な内容 | 発注者が行うこと |
|---|---:|---|---|
| 企画整理 | 1〜3週間 | 目的、利用者、予算、公開日の整理 | 社内合意、責任者の決定 |
| 要件定義 | 3〜8週間 | 作る機能、対象範囲、品質条件の決定 | 優先順位の判断、仕様確認 |
| UI・UX設計 | 3〜8週間 | 画面構成と操作の流れを設計 | 画面、文章、ブランド表現の確認 |
| 基本設計・準備 | 2〜5週間 | データ、システム構成、開発環境の設計 | 外部サービスや既存資料の提供 |
| 開発 | 8〜24週間 | アプリ、サーバー、管理画面の実装 | 定期確認、未決事項の回答 |
| 総合テスト | 3〜8週間 | 端末、機能、連携、負荷などの確認 | 受け入れテストの実施 |
| ストア申請・公開 | 1〜3週間程度を確保 | 申請情報の登録、審査対応、公開 | アカウント、規約、画像の準備 |

要件定義とは「何を作り、何を作らないかを決める工程」です。UI・UX設計とは、画面の見た目だけでなく、利用者が目的を達成するまでの操作体験を設計することです。

### 発注者の確認期間も工程表へ入れる

開発のご相談を受ける立場から見ると、遅延原因は開発会社の実装だけではありません。画面の承認、文章や画像の支給、社内法務の確認、外部サービスの契約などで工程が止まるケースもあります。

例えば、開発会社が2営業日で提出した画面案について、発注者側の確認に2週間かかれば、その後の実装開始も遅れます。工程表には、次のような発注者側の所要日数も明記しましょう。

- 画面案を何営業日以内に確認するか
- 誰が最終承認するか
- 利用規約や個人情報の取り扱いを誰が確認するか
- 画像、商品情報、店舗情報などをいつ支給するか
- 受け入れテストを誰がどの端末で行うか

担当者が判断できず、会議のたびに経営者や他部署へ持ち帰る体制では、細かな待ち時間が積み上がります。決裁者と回答期限を最初に決めることが、追加費用をかけずに実行できる有効な納期対策です。

### ストア審査は開発会社だけでは管理できない

App StoreとGoogle Playでは、アプリ本体だけでなく、説明文、画像、年齢区分、プライバシー情報、アカウント削除方法なども確認対象になります。審査期間は内容や時期によって変動し、修正や再審査が必要になることもあります。

そのため、工程表では審査を1日で終わる前提にせず、一般的に1〜3週間程度の余裕を確保します。金融、医療、子ども向け、定期購入など、確認項目が多いアプリはさらに余裕を見た方が安全です。

また、契約上の「納品日」が次のどれを意味するかも確認してください。

1. 開発会社がアプリを提出する日
2. 発注者の受け入れテストが完了する日
3. ストアへ申請する日
4. ストアで一般公開される日

ストア審査は第三者の判断を伴うため、開発会社が公開日を完全に保証できない場合があります。固定した公開日があるなら、審査指摘を修正する期間まで逆算する必要があります。

## 納期から逆算する発注準備とスケジュール

**中規模アプリを特定の日までに公開したい場合、一般的には公開の8〜10か月前から社内準備と相談を始めます。** 開発期間が6か月でも、候補会社の選定、見積もり比較、契約手続きに1〜2か月かかることがあるためです。

### 中規模アプリを9か月前から準備する例

| 公開までの残り期間 | 主な作業 |
|---|---|
| 9〜8か月前 | 目的、予算、対象利用者、必須機能の整理 |
| 8〜7か月前 | 開発会社への相談、提案・見積もりの比較、契約 |
| 7〜6か月前 | 要件定義、対象OS、外部連携、品質条件の決定 |
| 6〜5か月前 | 画面・操作設計、技術設計、ストアアカウント準備 |
| 5〜2か月前 | 開発、段階的な機能確認、テスト準備 |
| 2〜1か月前 | 総合テスト、発注者による受け入れテスト、修正 |
| 1か月前〜公開 | ストア申請、審査対応、公開判定、段階公開 |

これは一般的な例であり、機能の複雑さや社内手続きによって変わります。公開日を動かせない場合は、工程の最後に10〜20％程度の予備期間を置くことが一つの考え方です。外部システムの改修や法務審査など、不確実な要素が多い場合は、さらに余裕が必要です。

### 依頼前に準備するチェックリスト

詳細な仕様書がなくても相談はできますが、次の項目が整理されていると、期間の見積もり精度が上がります。

- [ ] アプリを作る目的と解決したい課題
- [ ] 主な利用者と利用場面
- [ ] 希望公開日と、その日を動かせない理由
- [ ] 初回公開に絶対必要な機能
- [ ] 後から追加できる機能
- [ ] iOS・Androidの対応方針
- [ ] ログイン、決済、通知、カメラ、地図などの利用機能
- [ ] 管理画面や既存システム連携の必要性
- [ ] 利用規約、プライバシーポリシーの担当部署
- [ ] 画像、文章、商品データなどの支給予定日
- [ ] 社内の承認者と確認に必要な日数
- [ ] 公開後の問い合わせ、障害対応、更新体制

アプリ内の処理が実店舗や社内業務とつながる場合は、現状と導入後の流れも整理します。整理方法は[業務フロー図の作り方｜開発依頼前の準備](https://www.geek-bridge.com/column/business-flow-development-preparation)も参考にしてください。

### 納期が短い場合は機能範囲を調整する

納期を短縮したいとき、単純に開発者を増やせばよいとは限りません。仕様の共有や成果物の統合に時間がかかり、開発途中からの増員ではかえって調整負担が増える場合があります。

短納期で現実的に検討しやすい方法は次のとおりです。

| 短縮方法 | 期待できる効果 | 注意点 |
|---|---|---|
| 初回機能を絞る | 設計・開発・テストの全体を短縮 | 後続開発の計画と予算が必要 |
| 公開を段階に分ける | 必須機能だけ先行公開できる | 利用者への案内を設計する |
| 既存サービスを活用する | 認証、決済、配信などを一から作らずに済む | 月額費用、制約、サービス終了リスクを確認 |
| 対象OSを限定する | 初期の実装・テスト範囲を減らせる | 対象外利用者への対応が必要 |
| 意思決定を迅速化する | 仕様確認の待ち時間を減らせる | 承認者の時間を事前に確保する |
| デザイン規則を統一する | 画面ごとの個別調整を減らせる | 独自表現とのバランスが必要 |

重要なのは、「公開日、機能、予算、品質のすべてを固定したまま期間だけを短くする」ことは難しいという点です。公開日を固定するなら、初回の機能範囲を調整できる契約・進行方法にした方が現実的です。

## 遅延を防ぐ見積もり・開発会社の確認ポイント

**開発会社を選ぶときは、提示された納期の短さではなく、その納期を成立させる前提と工程が説明されているかを確認します。** 期間だけが短い見積もりは、テスト、発注者確認、ストア審査などが含まれていない可能性があります。

### 見積書と工程表で確認する項目

- [ ] 対象機能と対象外の作業が明記されている
- [ ] 要件定義、設計、開発、テストの期間が分かれている
- [ ] 各工程の成果物と完了条件が書かれている
- [ ] 発注者の確認日数が工程表に含まれている
- [ ] iOS・Androidそれぞれのテストが含まれている
- [ ] サーバー、管理画面、外部連携の開発期間が含まれている
- [ ] ストア申請と審査指摘への対応範囲が分かる
- [ ] 休日、担当者不在、外部サービス待ちが考慮されている
- [ ] 仕様変更時の費用と納期の扱いが決まっている
- [ ] 公開後の不具合対応と保証期間が明記されている

工程の区切りとなる重要な到達点をマイルストーンと呼びます。例えば「要件確定」「画面設計承認」「テスト開始」「ストア申請」などです。マイルストーンごとに、誰が何を確認すれば次へ進めるのかを決めておくと、遅れを早期に発見できます。

### よくある遅延原因と回避策

| 遅延原因 | 発注者側でできる回避策 |
|---|---|
| 開発開始後も必須機能が増える | 初回公開と後続公開の機能を分け、変更時に納期を再計算する |
| 画面や文章の承認が進まない | 最終承認者と回答期限を決める |
| 外部APIの仕様が未確認 | 契約、利用申請、接続テストを早期に始める |
| ストアアカウントの準備が遅れる | 法人情報や権限を確認し、開発初期に登録を進める |
| テスト終盤で重大な問題が見つかる | 開発途中から定期的に実機確認を行う |
| 対応端末が後から増える | 対応OSと検証端末を要件定義で決める |
| 審査で説明不足を指摘される | 規約、課金、アカウント削除、個人情報の説明を早期に準備する |

仕様変更を一切禁止する必要はありません。新規サービスでは、実際の画面を見て初めて気づくこともあります。ただし、変更する場合は「追加費用」「影響する工程」「公開日への影響」をその都度記録し、承認してから着手する運用が必要です。

### 開発会社へ質問したいこと

候補会社との打ち合わせでは、次の質問をすると進行管理の実力を判断しやすくなります。

1. この期間を算出した前提は何ですか。
2. 納期に最も影響する工程はどこですか。
3. 発注者がいつまでに何を決める必要がありますか。
4. 外部サービスの仕様変更や回答遅延にはどう対応しますか。
5. 開発途中のアプリをどの頻度で確認できますか。
6. 遅れが発生した場合、いつ、どのように報告されますか。
7. テストするOS・端末・利用場面はどこまで含まれますか。
8. ストアで指摘された場合の修正は見積もりに含まれますか。
9. 公開日を守るために機能を分ける判断は誰が行いますか。
10. 公開直後の障害対応はどの契約範囲ですか。

発注のご相談を受ける開発会社の立場では、希望納期そのものより「なぜその日に公開する必要があるのか」が重要な情報です。広告開始日、展示会、既存サービス終了日、法改正対応など、期限の理由によって優先すべき対策が異なるためです。

### 公開後の予定も初期計画へ含める

ストア公開はプロジェクトの終了ではありません。問い合わせ対応、障害監視、OS更新、軽微な修正、利用状況の分析が始まります。公開直後に担当者や開発会社との契約が切れる計画では、問題が起きた際に対応できません。

保守の範囲や予算は開発契約と同時期に確認し、公開後1〜3か月程度の重点対応期間を設けるか検討してください。具体的な委託範囲は[アプリ保守費用の相場｜運用範囲と外注の選び方](https://www.geek-bridge.com/column/mobile-app-maintenance-cost)で解説しています。

希望公開日からの逆算や、現在の機能案で実現可能なスケジュールを整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

## まとめ

- スマホアプリの開発期間は、小規模で3〜5か月、中規模で5〜9か月、大規模・複雑なものでは9〜18か月以上が一般的な目安です。
- 実装期間だけでなく、要件定義、画面設計、発注者確認、テスト、ストア審査まで含めて計画します。
- 中規模アプリでは、希望公開日の8〜10か月前から社内準備と開発会社への相談を始めると進めやすくなります。
- 公開日が固定されている場合は、初回機能を絞り、後続リリースへ分ける方法が有効です。
- 見積もりでは期間の短さではなく、工程、前提条件、対象外作業、確認日数、審査対応を確認します。
- 発注者側も承認者、回答期限、素材の支給日、ストアアカウントの準備時期を決める必要があります。
- 公開後の保守、問い合わせ、障害対応も初期スケジュールと予算へ含めます。

## よくある質問

### スマホアプリ開発は何か月前に発注すべきですか？

中規模アプリなら、希望公開日の8〜10か月前には社内準備と開発会社への相談を始めるのが一般的な目安です。公開日が動かせない場合や外部サービスとの連携が多い場合は、さらに余裕を持たせてください。

### iOSとAndroidの両方を開発すると期間は2倍になりますか？

必ずしも2倍にはなりませんが、設計、端末検証、ストア申請などの作業は増えます。共通化しやすい開発方式でも、OS固有の調整やテストが必要になるため、片方だけの場合より期間と費用に余裕が必要です。

### App StoreやGoogle Playの審査には何日かかりますか？

審査日数は申請内容や時期によって変動するため、一律には決められません。初回申請、不備の修正、再審査まで考慮し、工程表では一般的に1〜3週間程度の余裕を確保します。

### 希望納期が短い場合はどうすればよいですか？

人員を増やす前に、初回公開に必要な機能を絞り、後続リリースへ分けられないか検討します。公開日を固定するなら機能範囲を調整可能にし、検証済みの外部サービスや既存部品の活用も開発会社と相談してください。