タスクの分解と見積もり
ストーリー
「渡辺さん、新機能の実装タスクなんですが、 どのくらいかかるか聞かれて『3日くらいですかね』と答えたら、 実際には1週間かかってしまいました......」
渡辺マネージャーは穏やかに言った。
「見積もりが外れるのはよくあることだ。 問題は、なぜ外れたかを分析していないことだ。 タスクが大きすぎると見積もりの精度は下がる。 分解の技術を身につければ、見積もりも正確になる」
なぜタスクを分解するのか
大きなタスクには3つの問題があります。
大きなタスクの問題
大きなタスク: 「ユーザー検索機能を実装する」
問題1: どこから始めればいいかわからない
→ 手が止まる（分析麻痺）
問題2: 見積もりが不正確になる
→ 「3日くらい」と言ったが実際は7日
問題3: 進捗が見えない
→ 3日経っても「まだやってます」としか言えない
分解後のメリット
分解後のタスク:
1. 検索APIのエンドポイント設計（2h）
2. DBクエリの実装（3h）
3. 検索結果のページネーション（2h）
4. フロントエンドの検索UI（4h）
5. 検索結果の表示コンポーネント（3h）
6. テスト作成（3h）
7. コードレビュー対応（2h）
メリット:
✓ 各タスクが明確で着手しやすい
✓ 合計19hという具体的な見積もり
✓ 「5/7タスク完了」と進捗が伝えられる
タスク分解のテクニック
1. 作業工程で分解する
ソフトウェア開発の一般的な工程に沿って分解します。
機能実装のタスク
├─ 設計
│ ├─ API仕様の定義
│ └─ DB スキーマの設計
├─ 実装
│ ├─ バックエンド実装
│ ├─ フロントエンド実装
│ └─ APIの結合
├─ テスト
│ ├─ ユニットテスト
│ ├─ 結合テスト
│ └─ E2Eテスト
└─ レビュー・修正
├─ PR作成
├─ レビュー対応
└─ ドキュメント更新
2. 機能単位で分解する
ユーザーの操作や機能ごとに分解します。
「ユーザープロフィール編集機能」
├─ 名前の変更
├─ メールアドレスの変更（メール確認あり）
├─ パスワードの変更（現在のパスワード確認あり）
├─ アバター画像のアップロード
└─ プロフィール公開設定の変更
3. 分解の粒度の目安
| 粒度 | 目安の時間 | 適切さ |
|---|---|---|
| 粗すぎ | 1週間以上 | 見積もりが不正確。さらに分解が必要 |
| やや粗い | 1〜3日 | スプリント計画レベル。可能なら分解 |
| 適切 | 2〜8時間 | 1日以内で完了可能。見積もりも正確 |
| 細かすぎ | 30分未満 | 管理コストが高い。まとめても良い |
目安: 1つのタスクが半日（4時間）以内で完了する粒度
見積もりの基本
なぜ見積もりは外れるのか
| 原因 | 説明 |
|---|---|
| 楽観バイアス | 「うまくいけば」の最短ケースで見積もる |
| 隠れた作業の見落とし | テスト、レビュー、ドキュメント、デプロイを含めない |
| 未知の問題 | やってみないとわからない技術的課題 |
| 割り込みの未考慮 | 1日8時間全てを実装に使えるわけではない |
見積もりを改善する3つのコツ
コツ1: 実稼働率を考慮する
1日8時間の勤務でも、実際にコーディングに使える時間は限られます。
1日8時間の内訳（一般的なエンジニア）
実装・コーディング: 4〜5時間 (50〜60%)
ミーティング: 1〜2時間 (15〜25%)
コミュニケーション: 1時間 (12%)
レビュー: 0.5〜1時間 (6〜12%)
その他（休憩等）: 0.5〜1時間 (6〜12%)
→ 「3日分の実装」= 実カレンダーで4〜5日
コツ2: 3点見積もりを使う
楽観値、最頻値、悲観値の3つで見積もり、期待値を計算します。
期待値 = (楽観値 + 4 x 最頻値 + 悲観値) / 6
例: API実装タスク
楽観値（問題なし）: 4時間
最頻値（普通）: 8時間
悲観値（問題発生）: 16時間
期待値 = (4 + 4x8 + 16) / 6 = 52/6 ≒ 9時間
コツ3: 過去の実績と比較する
同じようなタスクに以前どのくらいかかったかを参考にします。
過去の実績:
CRUD API実装: 実績 6時間（見積もり 4時間 → 1.5倍）
検索機能実装: 実績 12時間（見積もり 8時間 → 1.5倍）
認証機能の追加: 実績 20時間（ 見積もり 10時間 → 2倍）
→ 自分の見積もりは1.5〜2倍になる傾向
→ 次回から補正をかける
見積もりの伝え方
悪い例と良い例
| 場面 | 悪い例 | 良い例 |
|---|---|---|
| 期限を聞かれた | 「3日でやります」 | 「順調なら3日、問題があれば5日です。3日目に進捗報告します」 |
| 不確実性がある | 「わかりません」 | 「調査に半日ください。その後正確な見積もりを出します」 |
| 無理な期限 | 「頑張ります......」 | 「この期限では品質を下げるかスコープを減らす必要があります」 |
見積もりを伝えるテンプレート
「このタスクの見積もりですが、
- スコープ: [何をやるか / 何をやらないか]
- 見積もり: [最短X日〜最長Y日]
- 前提条件: [○○の仕様が確定していること]
- リスク: [△△の部分は技術的に不確実]
- 報告タイミング: [中間報告をZ日に行います]」
まとめ
| ポイント | 内容 |
|---|---|
| 分解の目的 | 着手しやすく、見積もりが正確で、進捗が見える |
| 適切な粒度 | 半日（4時間）以内で完了する単位 |
| 分解方法 | 作業工程で分解、機能単位で分解 |
| 見積もりのコツ | 実稼働率の考慮、3点見積もり、過去実績との比較 |
| 伝え方 | 範囲、前提、 リスクを含めて伝える |
チェックリスト
- 大きなタスクを適切な粒度に分解できる
- 3点見積もりの計算方法を理解した
- 実稼働率を考慮した見積もりができる
- 見積もりの不確実性を含めて伝えられる
次のステップへ
Step 1の内容を理解度チェックで確認しましょう。タスク管理の基本がしっかり身についているか、クイズで確かめます。
推定読了時間: 20分