作業時間の見積もり方
ストーリー
上司「この作業、どれくらいかかりそう？」
「えーと...2時間くらいですかね」
先輩「（後で）実際は5時間かかったね。見積もりって難しいよね」
「全然合ってなかった...どうすれば正確に見積もれるんですか？」
先輩「コツがあるんだ。教えるね」
なぜ見積もりが大切なのか
見積もりの役割
| 役割 | 説明 |
|---|---|
| 計画の基礎 | いつまでに何ができるかがわかる |
| 約束の根拠 | 「いつまでにできます」と言える |
| リス ク発見 | 時間が足りない場合に早期に気づける |
| 信頼の構築 | 正確な見積もりは信頼につながる |
見積もりが外れる理由
よくある原因
| 原因 | 説明 |
|---|---|
| 作業の全体像が見えていない | 隠れた作業を見落とす |
| 楽観的すぎる | 「うまくいけばこれくらい」で見積もる |
| 割り込みを考慮しない | 会議や質問で中断される時間 |
| 初めての作業 | 経験がないと予測が難しい |
| 依存関係の見落とし | 他の人の作業待ちが発生する |
先輩「人間は本能的に楽観的に見積もるんだ。これを『計画の誤謬（ごびゅう）』って言うんだよ」
3点見積もり法
楽観・悲観・現実的の3パターン
1つの作業に対して、3つの見積もりを出します。
| 見積もり | 説明 | 考え方 |
|---|---|---|
| 楽観的 | すべてうまくいった場合 | 最短でどれくらい？ |
| 悲観的 | 問題が起きた場合 | 最悪どれくらい？ |
| 現実的 | 最も可能 性が高い場合 | 普通にやったらどれくらい？ |
計算式
期待値 = (楽観 + 現実的 × 4 + 悲観) ÷ 6
具体例
タスク: 「お知らせ一覧ページの実装」
| 見積もり | 時間 | 理由 |
|---|---|---|
| 楽観的 | 2時間 | APIがすぐ使えて、デザインも単純な場合 |
| 現実的 | 4時間 | 通常通り進む場合 |
| 悲観的 | 8時間 | APIの仕様不明点が多い、デザイン調整が必要な場合 |
期待値 = (2 + 4 × 4 + 8) ÷ 6 = 26 ÷ 6 ≒ 4.3時間
報告する見積もり: 約4.5時間（切り上げ）
作業分解（WBS）
大きなタスクは分解する
大きなタスクをそのまま見積もると精度が落ちます。 小さく分解してから、それぞれを見積もりましょう。
WBS（Work Breakdown Structure）とは
作業を細かい単位に分解する手法
例: 「お知らせ一覧ページの実装」を分解
お知らせ一覧ページの実装（合計: 4.5時間）
├── API仕様の確認（0.5時間）
├── HTMLの作成（1時間）
├── CSSのスタイリング（1時間）
├── APIとの接続（1時間）
├── テスト（0.5時間）
└── レビュー対応（0.5時間）
分解のコツ
| ルール | 説明 |
|---|---|
| 最小単位は30分〜2時間 | これ以上大きいと精度が落ちる |
| 動詞で書く | 「〜する」の形にすると具体的になる |
| 見落としやすい作業を含める | 確認、レビュー、修正の時間も忘れずに |
バッファの重要性
バッファとは
バッファ = 予想外の事態に備える時間の余裕
なぜバッファが必要か
見積もり通りに進まない理由:
├── 会議や割り込み作業が入る
├── 仕様の確認に時間がかかる
├── 予想外のバグが見つかる
├── 体調不良や集中力低下
└── ツールのトラブル
バッファの目安
| 状況 | バッファ率 | 例 |
|---|---|---|
| 経験のある作業 | +20% | 4時間 → 4.8時間 → 5時間 |
| 初めての作業 | +50% | 4時間 → 6時間 → 6時間 |
| 不確定要素が多い | +100% | 4時間 → 8時間 → 8時間 |
先輩「見積もりには必ずバッファを入れよう。予定通りに終わったら、次のタスクに着手すればいいだけだから」
見積もりの伝え方
上司への報告テンプレート
【タスク名】 お知らせ一覧ページの実装
【見積もり】約5時間（バッファ含む）
【内訳】
- API仕様の確認: 0.5時間
- HTML作成: 1時間
- CSSスタイリング: 1時間
- API接続: 1時間
- テスト: 0.5時間
- レビュー対応: 0.5時間
- バッファ: 0.5時間
【前提条件】
- 先輩のAPIが予定通り完成すること
- デザインデータが確定していること
【リスク】
- APIの仕様が不明確な場合、追加で1〜2時間かかる可能性あり
良い伝え方のポイント
| ポイント | 説明 |
|---|---|
| 内訳を示す | 「5時間」だけでなく、何にどれくらいか示す |
| 前提条件を明記 | 見積もりの根拠となる前提を伝える |
| リスクを伝える | 遅れる可能性がある要因を事前に共有 |
| 幅を持たせる | 「3〜5時間」のように範囲で伝えるのもOK |
見積もり精度を上げるコツ
経験を記録する
| やること | 効果 |
|---|---|
| 見積もりと実績を記録する | 自分の傾向がわかる |
| 差分を分析する | なぜずれたか理解できる |
| 次回に反映する | 精度が徐々に上がる |
記録の例:
タスク: お知らせ一覧ページの実装
見積もり: 5時間
実績: 6.5時間
差分: +1.5時間
原因: API仕様の確認に予想以上に時間がかかった
次回: API連携タスクのバッファを多めにとる
まとめ
| ポイント | 内容 |
|---|---|
| 見積もりが大切な理由 | 計画の基礎、信頼の構築 |
| 3点見積もり法 | 楽観・悲観・現実的の3パターンで算出 |
| 作業分解 | 大きなタスクは30分〜2時間単位に分解 |
| バッファ | 経験ある作業+20%、初回+50%が目安 |
| 精度向上 | 見積もりと実績を記録して振り返る |
チェックリスト
- 3点見積もり法で見積もりを計算できる
- タスクを小さい単位に分解できる
- バッファの必要性と目安を理解した
- 上司に見積もりを報告するフォーマットを知った
次のステップへ
作業時間の見積もり方がわかりました。次のセクションでは、Step 2で学んだ内容のチェックポイントに挑戦しましょう。
推定読了時間: 30分