開発スケジュールの立て方｜工数見積もり・バッファ・AI活用の実践手順
「実装は終わったのに、確認や修正が残って公開できない」「AIを使えば早く終わると思ったのに、予定を超えてしまった」。開発のスケジュールを立てるときは、コードを書く時間だけでは見通しが立ちません。
開発計画では、必要な作業、確認待ちの時間、予期せぬ問題への備えを分けて考えることが大切です。この記事では、小規模なWebアプリ開発を例に、工数の見積もり方、バッファの設け方、AIを使った計画の見直し方を解説します。
目次
１．開発スケジュールは「コードを書く時間」だけで決めない
開発には、仕様の確認、設計、実装、テスト、レビュー、修正、公開準備などの作業があります。どこまで終われば完成とするのかによって、必要な時間は変わります。
まずは「実装が終わる日」と「利用者が使える状態になる日」を区別しましょう。公開するアプリなら、公開先での動作確認や、問題が起きたときに戻す方法も計画に含めます。
工数と、完成までの期間を分ける
工数は作業に必要な量、期間は着手から完了までにかかる時間です。例えば、作業量が８時間でも、１日に確保できる開発時間が２時間なら、作業だけで４日分の枠が必要になります。
さらに、担当者の確認やアカウントの発行を待つこともあります。待っている間に別の作業を進められる場合もありますが、待ち時間がなくなるわけではありません。
| 項目 | 意味 | 例 |
|---|---|---|
| 作業工数 | 実際に手を動かす作業量 | 画面作成２時間、テスト１時間 |
| 待ち時間 | 返答や手続きの完了を待つ時間 | 仕様確認、レビュー依頼、利用申請 |
| 依存関係 | 先に終わらないと次へ進めない関係 | 仕様を決めてから判定処理を実装する |
| バッファ | 見積もりのばらつきや想定外の問題に備える余裕 | 公開環境で追加調査が必要になった場合への備え |
２．最初に、作る範囲と完了条件を決める
「クイズアプリを作る」という表現だけでは、問題数や保存機能、対応する端末が分かりません。機能を増やすほど必要な作業も変わるため、見積もる前に今回の範囲を決めます。
例えば、最初の公開では「３問を順番に表示する」「正誤と解説を表示する」「最後に正解数を表示する」までに限定します。ログインや成績保存を後回しにするなら、そのことも記録しておきましょう。
「できた」を判断できる形にする
完了条件は、画面や操作で確かめられる形にします。「使いやすくする」だけでは判断が分かれるため、具体的な動作へ置き換えます。
- 問題文と選択肢が表示される。
- 回答すると正誤と解説が表示される。
- 回答後は同じ問題に重ねて回答できない。
- 次の問題へ進み、最後に正解数が表示される。
- 対象とするスマートフォンとパソコンで、文字やボタンを確認できる。
- 公開先のURLで一連の操作が完了する。
このような条件を先に決めると、必要なテストも考えやすくなります。途中で機能追加が出たときも、当初の範囲との差を確認できます。
３．作業を分け、分からない部分を先に調べる
次に、完成までの作業を確認可能な単位に分けます。細かくする目的は、項目数を増やすことではなく、何が終わり、何が残っているかを判断できるようにすることです。
クイズアプリなら、問題データの準備、画面作成、正誤判定、問題の切り替え、結果表示、動作確認、公開という分け方ができます。初めて扱う処理は、実装とは別に調査や試作の時間を設けます。
未知の部分は、短い検証で見通しを作る
例えば、公開サービスを初めて使う場合は、完成してから公開方法を調べるのではなく、簡単なページを先に公開してみます。必要な設定や制限が分かれば、本番の作業を見積もりやすくなります。
ただし、簡単なページが公開できても、アプリ全体の動作まで確認できたことにはなりません。検証で分かったことと、まだ確認していないことを分けて残しましょう。
見積もりには前提を書く
「画面作成に２時間」と書く場合は、「デザイン案が決まっている」「画像素材を用意できている」といった前提も添えます。前提が変われば、時間の見積もりも見直す必要があります。
経験の少ない作業は、無理に１つの数字に決めなくても構いません。「２〜４時間の仮見積もり。試作後に更新する」のように、不確実な状態を明示します。この幅は、必ず収まる保証や統計的な確率を意味するものではありません。
４．バッファは、必要な工程と分けて確保する
テストやレビューは、最初から必要と分かっている作業です。これらをすべて「余裕時間」に入れてしまうと、問題が起きたときにテスト時間を削って調整する計画になりかねません。
まず通常の作業を見積もり、そのうえで不確実性への備えを考えます。通常見込まれるレビュー後の修正も、必要な作業として扱いましょう。
一律の倍率より、何に備えるかを明確にする
すべての開発で「見積もりの1.5倍」「必ず２日」と決められるわけではありません。慣れた画面の修正と、初めて使う外部サービスとの連携では、分からない部分が異なります。
過去の実績、変更範囲、技術の経験、確認相手の状況などを材料に、どの問題へ備えるかを整理します。作業ごとに余裕を含めている場合は、全体にも同じ理由の余裕を重ねていないか確認してください。
小規模アプリの計画例
以下は考え方を説明するための仮の例です。標準的な工数や、初心者が必ずこの時間で完成できるという目安ではありません。
| 工程 | 仮の作業時間 | 確認すること |
|---|---|---|
| 仕様と問題データの確認 | １時間 | 問題・正解・解説と、今回の機能範囲 |
| 画面と動作の実装 | ４時間 | 表示、回答判定、問題切り替え、結果表示 |
| テスト・レビュー・通常の修正 | ３時間 | 操作の確認、コードの見直し、修正後の再確認 |
| 公開と公開後の確認 | ２時間 | 公開先での動作、表示、ファイルの読み込み |
| 予定する作業の合計 | 10時間 | １日２時間なら、作業枠として５日分 |
この例では、公開環境への対応に不確実性が残ると仮定し、別途２時間の予備枠を設ける案が考えられます。ただし、この２時間は一律20％の確保を勧めるものではなく、検証結果や経験に応じて変更する仮の設定です。
また、仕様の承認待ちや休日があるなら、作業枠とは別に日程へ反映します。関係者へ伝えるときは、必要な工程と予備枠を分け、何を前提にした計画かを説明しましょう。
５．AIは、作業の洗い出しと確認観点の整理に使う
AIには、必要な作業の候補、仕様の不足、テストで確認したい条件などの整理を依頼できます。自分で作った計画を渡し、抜けている工程を探す使い方もできます。
ただし、AIは担当者の経験や実際の作業速度を正確に把握しているわけではありません。AIが示した時間を、そのまま納期の根拠にせず、過去の実績や試作結果で確かめます。
開発計画を見直すための依頼例
AIを使っても、レビューとテストを省かない
AIは不具合の候補を指摘できますが、見落としや誤った指摘もあります。GitHubの公式ドキュメントでも、Copilotによるコードレビューに人によるレビューを組み合わせることが案内されています。
また、AIへの依頼、出力の読み取り、修正、動作確認にも時間がかかります。効率を振り返るときは、生成にかかった時間だけでなく、利用できる状態にするまでの合計時間を見ましょう。
AIが生成したコードを採用する前に、何を確認すればよいのでしょうか。仕様・テスト・保守性の観点から、レビューの進め方を整理しています。
AI生成コードのレビュー方法｜仕様・テスト・保守性を確認する実践手順 記事を読む →６．遅れが見えたら、残りの作業と前提を更新する
進捗は、「何時間頑張ったか」だけでなく、完了条件をどこまで満たしたかで確認します。例えば「実装は終わったがスマートフォンで未確認」なら、動作確認が残っている状態です。
遅れが見えたときは、原因を本人の努力不足と決めつけず、仕様の追加、調査不足、作業の抜け、確認待ちなどを分けて整理します。そのうえで、残りの作業量と完成見込みを更新します。
- 範囲を調整する：今回必要な機能と、次回に回せる機能を関係者と決める。
- 順序を調整する：待ち時間の間に進められる作業があるか確認する。
- 支援を依頼する：仕様確認や技術調査など、詰まっている部分を具体的に伝える。
- 期限を相談する：現状と残作業、変更案を示し、早めに相談する。
バッファを使った場合は、何に何時間使ったかを簡単に残しましょう。毎回同じ作業で消費しているなら、その作業を通常の見積もりへ含める必要があるかもしれません。
エラー調査は、試したことを残す
不具合対応では、思いついた修正を繰り返すと、何が原因だったか分からなくなることがあります。再現手順、確認したログ、試した変更、その結果を残し、調査の状況を共有できるようにします。
AIや他の人へ相談する場合も、確認できた事実と原因の候補を分けると伝わりやすくなります。ログを共有する前には、APIキーや個人情報などが含まれていないか確認してください。
不具合の原因を絞り込むには、ログの内容と発生条件を整理することが役立ちます。調査の進め方と、安全に相談するための情報のまとめ方を紹介しています。
エラーログの読み方｜原因を絞り込む調査手順と、安全な記録・共有の方法 記事を読む →７．開発スケジュールに関するよくある質問
バッファは何％にすればよいですか？
どの開発にも当てはまる割合はありません。過去の見積もりと実績の差、未知の技術、外部サービスへの依存などを確認し、必要な備えを考えます。経験が少ない場合は、先に小さく試して見積もりを更新しましょう。
AIを使う前提なら、最初から納期を短くできますか？
同じような作業で、確認や修正を含めた時間の短縮を確かめられているなら、その実績を参考にできます。実績がない段階では、AIを使うことだけを理由に一律で短縮せず、試作の結果を見て調整します。
タスクは必ず半日以内に分けるべきですか？
半日や１日という単位は、運用上の目安にはなりますが、必須ではありません。完了条件を確認できるか、詰まったときに原因を説明できるかを基準に分けます。長い調査では、途中の確認地点を設ける方法もあります。
バッファを使わずに終わったら、機能を追加してよいですか？
自動的に追加する必要はありません。機能を増やすと、テストや保守の対象も増えます。まず当初の完了条件と残っているリスクを確認し、追加する場合は目的・作業量・公開への影響を改めて検討します。
８．次の開発では、見積もりと実績を１つずつ残す
開発スケジュールは、最初に立てて終わりではありません。実際に分かったことを反映し、残りの作業と完成見込みを更新するための道具です。
まずは次の機能について、作る範囲、完了条件、必要な工程、分からないことを書き出してみましょう。完了後に見積もりと実績を比べると、自分やチームの開発に合った計画へ改善しやすくなります。
- コード作成以外に、テスト・レビュー・公開確認も含めたか。
- 作業時間と、確認待ちの時間を区別したか。
- 未知の部分を先に試せるか。
- バッファの理由と、重複計上の有無を確認したか。
- AIの出力を確認・修正する時間も含めたか。
- 変更や遅れが生じたとき、見通しを更新できるか。
参考資料
スケジュール管理の考え方とAIレビューの位置付けについて、以下の資料を参照しています。本文のクイズアプリの工数や予備枠は、説明用に作成した仮の例です。
- U.S. GAO：Schedule Assessment Guide ― 信頼できるスケジュールの作成・維持と、変更やリスクの評価に関する資料。
- GitHub Docs：GitHub Copilot code review ― AIによるコードレビューと、その結果を検証する際の考え方。
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法