アプリ開発期間は、画面数や「小規模」という言葉だけでは決まりません。
要件の未確定、外部連携、データ移行、対応OS、レビュー、実機試験、ストア審査の依存関係で公開日が変わります。
平均期間へ当てはめる前に、主要成果物と前提タスクを並べて中心経路を出してください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 工程 | 期間を増やす条件 | 短縮の方向 |
|---|---|---|
| 要件 | 決定者不在、対象業務が不明 | 初回範囲と対象外を合意 |
| 設計 | 難所と例外が未検証 | PoCと利用者評価を先行 |
| 実装 | OS、機能、連携が多い | 縦に一本完成して反復 |
| テスト | 端末、権限、品質条件が多い | 自動化とリスク優先 |
| 公開 | 署名、登録、審査情報が未準備 | 実装中から並行準備 |
| 導入 | 移行、教育、旧手順が複雑 | 限定導入と段階展開 |
工程別の期間を成果物から見積もる
要件二週間、実装二か月という期間だけでは、完了を判断できません。
各工程で次へ渡す成果物と承認者を決めます。
| 工程 | 完了成果物 | 次工程を止める未決事項 |
|---|---|---|
| 要件 | 初回範囲、受け入れ、対象外 | 誰が何を決めるか |
| 設計 | 画面、データ、API、運用 | 難所と例外 |
| 実装 | レビュー済みの機能 | 外部APIとデータ |
| 品質 | 重要ケースの結果 | 実機とテストデータ |
| 公開 | 署名版、ストア情報、手順 | アカウントと審査回答 |
要求の完了条件を作る際は、ISO/IEC/IEEE 29148の規格案内も参考に、検証可能な受け入れ条件を用意します。
「仕様検討中」を実装期間へ含めず、決定タスクとして担当と期限を持たせてください。
利用者調査も後で行う追加作業ではありません。
デジタル庁の利用者中心ガイドブック実践編を参考に、仮説と試作を早期に確認して大きな手戻りを避けます。
公開までの中心経路を七段階で作る
作業量の合計ではなく、依存関係により最も長くなる経路が公開日を決めます。
- 公開日と運用開始日を別のマイルストーンにする
- 要件、設計、実装、テスト、公開、導入の成果物を置く
- 各成果物の前提、担当、レビュー、完了条件を結ぶ
- 外部API、素材、データ、ストア登録の待ち時間を加える
- 並行できる作業と同じ担当者で並行できない作業を分ける
- 中心経路の難所へ調査、PoC、再作業の余白を置く
- 毎週、実績と未決事項を反映して公開日を再計算する
レビューを即日で終わる前提にしません。
GitHubのPull Requestレビュー資料が示す承認や変更要求を、担当者と再作業時間を持つタスクとして計画します。
同じ担当者がUI、実装、レビューを行う場合、表上で並行に置いても実際には同時に進みません。
稼働可能時間と休暇、他案件、会議を考慮してください。
直列と並行から公開日数を出す計算例
次の数字は、中心経路を説明するための仮定です。
要件5日、設計7日、実装20日、テスト8日、公開準備5日の作業を考えます。
すべて直列なら5＋7＋20＋8＋5で45日になるでしょう。
公開準備5日を実装中に並行し、テスト準備3日を実装後半へ重ねても、実行テスト8日は実装完了後なので中心経路は5＋7＋20＋8で40日です。
| 作業 | 日数 | 中心経路 |
|---|---|---|
| 要件 | 5日 | 含む |
| 設計 | 7日 | 含む |
| 実装 | 20日 | 含む |
| テスト実行 | 8日 | 含む |
| 公開準備 | 5日 | 実装中に並行 |
| 公開まで | 5＋7＋20＋8 | 40日 |
作業量は45日分あっても、並行により経過日数は40日です。
ただし公開素材の元になる画面が遅れれば並行できないため、前提をWBSへ明記します。
初回範囲を縦に切って期間を短縮する
全画面のデザイン後に全APIを作る横割りでは、利用者が操作できる版が最後まで出ません。
登録から主要操作の完了までを一つの縦切りとして、画面、API、DB、テストを通します。
初回版では、一つの利用者、一つの重要課題、一つの主要動線へ絞ります。
管理画面、多言語、分析、高度な通知などを後へ回す場合も、手作業で代替できる条件を決めてください。
短縮してはいけないのは、重要な権限、データ整合、決済、安全性、復旧の確認です。
機能範囲を減らし、品質条件を曖昧にして期間を作らないことが重要です。
外部連携の難所は小さなPoCで先に確認します。
成立しない技術を長期間の実装後に見つけるより、数日から数週の検証で成立性を先に判断できます。
ストア公開と導入の待ち時間を別管理する
実装完了日と利用者が使い始める日は一致しません。
署名、ストア情報、プライバシー、テストアカウント、審査、段階公開、社内教育、データ移行を別工程にします。
Androidの公開作業は公式の公開準備で、リリース設定、署名、テスト、配布を確認します。
iOSはApp Review Guidelinesを実装中から照合し、差し戻し対応の余白を置いてください。
審査に何日かかるかを一つの固定値へせず、提出準備、質問回答、修正、再提出を計画します。
公開希望日の当日に初回提出する日程を避けます。
業務導入では、データ移行の照合と利用者教育も中心経路になり得ます。
限定部署で操作と問い合わせを試し、全社展開前に手順を更新してください。
アプリ開発期間でよくある質問
アプリ開発の平均期間はどれくらいですか？
機能、OS、外部連携、品質、移行、審査で変わるため、平均を自社の納期に使えません。
同じ成果物と受け入れ条件を持つ類似案件の実績があれば参考にし、現在の依存関係から再計算します。
人を増やせば期間は半分になりますか？
独立した作業は並行できますが、要件決定、共通設計、レビュー、統合、引き継ぎの連携時間が増えます。
中心経路上で分割できる作業と、同じ判断を待つ作業を分けてから増員します。
ストア審査期間を短縮できますか？
審査時間は保証できませんが、未完成機能をなくし、テストアカウントと操作手順を整え、該当条件へ事前に対応できます。
iOSでは最新の審査ガイドラインを実装と提出情報へ照合してください。
中心経路の範囲を減らして品質を守る
期間短縮は工程を省くことではなく、初回範囲を絞り、難所を先に試し、独立作業を並行することです。
中心経路と完了成果物が見えれば、遅延時に何を調整すべきか説明できます。
- 工程期間を決める成果物、未決事項、担当、レビュー、外部待ち
- 公開日を支配する中心経路と同時に進められる準備作業
- 初回版を縦に切る利用者、課題、主要動線、代替手順
- 別管理するストア審査、データ移行、教育、段階公開
期間と費用の両方を持続可能にするには、アプリ開発予算の初期費用と運用費で年間の支出時期と予備費を決められます。
