アプリ開発のスケジュールは、工程ごとの日数を横に並べただけでは管理できません。
要件確定、外部審査、デザイン承認、API完成、実機試験などの依存関係と、完了を証明する成果物が必要です。
希望公開日から逆算し、遅れると全体が止まる経路と、並行できる作業を分けてください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 工程 | 完了を示す成果物 | 次工程の開始条件 |
|---|---|---|
| 要件定義 | 優先順位と受け入れ条件 | 初回範囲が合意済み |
| 設計 | 画面、データ、API、運用 | 難所の方針が決定 |
| 実装 | レビュー済みの機能 | 対象環境でビルド成功 |
| テスト | 重要ケースの結果 | 高リスク不具合が解消 |
| 公開 | 署名済み成果物とストア情報 | 審査、配布条件が準備済み |
| 運用移行 | 監視、問い合わせ、復旧手順 | 担当者が演習済み |
工程を成果物と開始条件で区切る
「設計二週間」のような期間だけでは、終わったか判断できません。
画面遷移が承認された、APIの入出力が確定した、復旧目標が合意されたという成果物で区切ります。
| 工程 | 終了条件 | 依存しやすい外部要因 |
|---|---|---|
| 企画、要件 | 初回範囲と対象外が合意 | 利害関係者の決定 |
| UI設計 | 主要動線を利用者が操作 | 利用者調査と承認 |
| API、データ | 難所の接続試験が成功 | 外部APIとデータ提供 |
| 品質確認 | 受け入れ条件の証跡がそろう | 実機とテストデータ |
| 公開 | 提出情報と審査用手順が完成 | ストア審査と登録 |
要件の完了条件を作る際は、ISO/IEC/IEEE 29148の規格案内も参考に、要求を検証可能な情報として扱います。
未決事項をタスクへ隠さず、決定者と期限を別の作業として置いてください。
公開工程はOSごとに条件が異なります。
Androidの公開準備とApp Review Guidelinesを使い、署名、テスト、ストア情報、審査対応を実装後の一日へ詰め込みません。
WBSを六段階で作り依存関係を結ぶ
WBSは作業を細かくすることが目的ではなく、担当、完了条件、依存先を見えるようにする道具です。
- 公開日と運用開始日を別のマイルストーンにする
- 要件、設計、実装、試験、公開、運用移行の成果物を置く
- 各成果物を一人が完了判断できる大きさへ分ける
- 前提タスク、外部待ち、レビュー、再作業を結ぶ
- 所要時間ではなく担当者の稼働日へ割り当てる
- 週ごとに完了成果物と次の阻害要因を更新する
「レビュー」は実装タスクの備考にせず、担当者と時間を持つ独立作業にします。
修正と再レビューも想定し、最初の承認で必ず通る計画にしないでください。
小さな変更単位で進めるなら、GitHubのPull Requestレビュー資料を参考に、コメント、承認、変更要求をタスクと証跡へ結び付けられます。
直列と並行を分けて公開日を出す計算例
次の数字は、作業日数の合計と公開までの日数が一致しない例です。
要件5日、設計4日、実装10日、テスト5日、公開準備3日の作業を考えましょう。
すべて直列なら5＋4＋10＋5＋3で27日です。
実装の後半5日とテスト準備3日を並行し、公開素材3日を実装中に進められるなら、公開までの経路は5＋4＋10＋5で24日になります。
| 作業 | 作業量 | 並行の扱い |
|---|---|---|
| 要件 | 5日 | 直列 |
| 設計 | 4日 | 直列 |
| 実装 | 10日 | 中心経路 |
| テスト | 5日 | 準備3日は実装と並行 |
| 公開準備 | 3日 | 素材は実装中に並行 |
三日短く見えても、設計が遅れると実装とテスト準備の両方が止まります。
短縮候補より先に、遅延が複数作業へ伝わる依存点を管理してください。
進捗率ではなく完成した証拠を確認する
「実装80％」は、残る20％に認証やデータ移行が含まれると判断を誤ります。
画面数ではなく、利用者が開始から完了まで通せる機能単位で進捗を見ます。
週次確認では、完了した成果物、未完了の理由、次に止まりそうな依存、必要な意思決定を扱います。
予定との差だけでなく、範囲追加、見積もり誤差、外部待ち、品質問題のどれかを分類してください。
主ブランチへ入った変更を完了基準にするなら、GitHubの保護ブランチ資料を参考に、レビューと状態チェックをマージ条件に設定できます。
ローカルで完成したがレビュー待ちの作業を、完了として二重計上しないことが重要です。
変更要求とバッファを同じ表で管理する
追加要望が出たら、元の納期へ無条件で足しません。
目的への必要性、見積もり、依存先、テスト、公開日への影響を出し、範囲、日程、要員のどれを調整するか決めます。
バッファは各担当者が隠して持つより、外部審査、未確定仕様、難しい連携など不確実性の高い場所へ置きます。
バッファを消費した理由を記録すると、次回計画の見積もり根拠になります。
遅延時は残業を最初の手段にしません。
初回範囲を減らす、依存しない作業へ移る、検証対象を絞る、意思決定を早めるという選択肢を比較します。
アプリ開発スケジュールでよくある質問
アプリ開発の期間は平均で決められますか？
画面数が同じでも、認証、決済、外部連携、データ移行、審査、品質要件で期間は変わります。
平均値を納期にせず、成果物、依存関係、担当者の稼働、再作業を積み上げてください。
WBSはどこまで細かく分けますか？
一人が完了を判断でき、数日以内に進捗を確認できる大きさが目安です。
細かすぎて管理だけが増える場合は成果物単位へまとめ、外部待ちとレビューは独立して残します。
ストア審査の日数は固定できますか？
固定の完了日として保証せず、提出準備、差し戻し対応、再提出を計画へ含めます。
審査条件はAppleの最新ガイドラインなど公式情報を確認し、公開希望日の直前に初回提出しないでください。
依存関係と完了証拠でスケジュールを更新する
現実的な日程では、楽観的な所要時間を並べるのではなく、誰が何を完成させ、何を待つかまで説明できます。
週次で完了証拠と阻害要因を更新し、変更要求が範囲、日程、品質へ与える影響をその場で判断します。
- 工程を区切る基準は日数ではなく次工程へ渡せる成果物
- WBSに必要な担当、完了条件、依存先、外部待ち、レビュー
- 公開日を決める中心経路と並行できる準備作業の違い
- 遅延時に比較する初回範囲、依存しない作業、要員、意思決定
個人の予定表だけで回せない規模なら、アプリ開発チームの役割分担と進行管理で成果物の所有者と承認者を決められます。
