タスク粒度の正解はどこ？1日〜5日ルールが破綻するときの対処法

「1つのタスクは1日〜5日に収めましょう」――プロジェクト管理の入門書には必ずこう書いてあります。WBSの章でも、ガントチャートの作り方ガイドでも、何度も登場するこの「定石」。しかし、実際のプロジェクトで実践してみると、半数くらいのケースで破綻します。本記事では、タスク粒度の本質と、ルールが効かないときの実践的な対処法を解説します。

「1日〜5日ルール」はなぜ生まれたか

このルールが推奨される理由は明確です。

• 進捗が測れる: 5日以内なら「終わったか終わってないか」がすぐわかる
• 遅延が早期に検知できる: 長すぎるタスクは「ほぼ完了」と言い続けられる罠がある
• 担当者が明確: 短いタスクなら1人にアサインしやすい
• レビューがしやすい: 完了時に確認すべき項目が明確

これらは正しい理屈です。短いタスクの方が管理しやすい。だからこの粒度がデフォルト推奨になっています。

では、なぜ実務で破綻するか

現場で1日〜5日ルールが機能しないパターンを5つ挙げます。

1. 探索的なタスク

「最適なアルゴリズムを調査する」「ユーザーインタビューを実施する」など、ゴールが明確に定義できないタスクは、5日では終わらないことが多く、また「分解」もしづらい。粒度を無理に小さくすると、本質的な探索が阻害されます。

2. 待ち時間が大きいタスク

「外部ベンダーからの資料受領」「クライアント承認待ち」「ビルドが12時間かかる」など、純粋に「待つ」時間が含まれるタスク。実作業は30分でも、完了まで2週間ということが普通にあります。

3. 反復的なメンテナンス・運用

「週次レポート作成」「月次バックアップ」など、繰り返し発生する作業。これを毎週1タスクとして並べると、行数が爆発します（複数期間タスクで対処可能 → 複数期間タスクの解説）。

4. 担当者の作業時間が小さい連続タスク

「コードレビュー」「軽微な修正対応」など、1つあたり15分の作業が日に何回も発生するケース。これを1タスク化すると、無数の小タスクが並ぶカオスになります。

5. 創造的・非線形の作業

「マーケコピーを書く」「デザインを作る」など、結果が事前に予測しにくい作業。「3日で終わる」つもりが、満足できずに10日かけることもあれば、半日で完成することも。粒度の予測が困難です。

粒度を決める3つの軸

「1〜5日」を絶対視せず、以下の3つの軸で柔軟に判断します。

軸1: 「終わったか」が判定できるか

最も重要なのは「完了の定義（Definition of Done）」が明確であること。期間が10日でも、完了条件が明確ならタスクとして成立します。「90%できた」が永遠に続くタスクの方がよほど危険です。進捗報告の書き方とセットで考えると判断しやすい。

軸2: 進捗を「中間で測れるか」

10日のタスクでも、5日時点で「半分終わった」と言えるなら問題ありません。例えば「100件のデータ移行」なら50件で50%。一方「アルゴリズム研究」のような探索系では中間進捗が言えないため、短く区切るほうが管理しやすい。

軸3: 「遅延の影響が大きいか」

クリティカルパス上にあるタスクは細かく刻む価値があります。遅延が全体に波及するので、早期検知が必要。逆に余裕のあるタスクは粗くて構いません。

5つの破綻パターンへの対処法

1. 探索的なタスクの場合

時間箱（タイムボックス）化: 「2週間で調査する」と期間を区切り、その時点で結果を出す。完了条件は「2週間の調査期間が経過した」とする。スクラムのスパイク（Spike）と同じ発想。

2. 待ち時間が大きい場合

「依頼」と「受領」を別タスクに: 「ベンダーAに資料依頼（0.5日）」と「ベンダーAから受領後の確認作業（1日）」を分け、間の待ち時間は「依存関係+lag」で表現。これにより実作業の見積もりが正確になります。

3. 反復作業の場合

複数期間タスクで1行化: 「週次レポート作成」を1つのタスクとして、各回の作業期間を複数期間で表現。12週分でも1行に収まります。

4. 小タスクが連続する場合

「カテゴリタスク」+ チェックリスト: 「コードレビュー（このフェーズ全部）」を1タスクにして、タスク説明欄に個別のレビュー項目をチェックリスト化。1行で進捗0〜100%が表現でき、ガントが汚れません。

5. 創造的タスクの場合

「下書き → レビュー → 仕上げ」の3段階に分割: 創造的作業は線形ではないので、フェーズで区切る。各フェーズはタイムボックス化。これにより「いつまでに何ができていればOK」を明確化できます。

業種別の典型粒度

受託開発

2〜5日が典型。クライアント報告のサイクルに合わせて週次粒度が多い。

建設業

5日〜2週間。工種ごとに粒度を変える。基礎工事のような長期工程はサブタスクで内訳化。

製造業の新製品開発

1〜3週間。フェーズが長く、変更も少ないので粗め。

SaaSプロダクト開発

1〜3日。スプリント内消化を前提に細かく。

マーケティングキャンペーン

1〜5日。クリエイティブ作業は別途タイムボックス化。

「最初は粗く、徐々に細かく」が正解

プロジェクト開始時に詳細な粒度で全タスクを切り出すのは、しばしば過剰投資です。工数見積もりでも触れたように、先のことほど不確実性が高い。

推奨アプローチは「ローリングウェーブ計画法」: 直近2〜4週間は詳細に、それ以降は粗く、進捗とともに段階的に詳細化します。これにより、「計画作成に時間がかかりすぎる」「計画と実態が乖離する」両方の問題を回避できます。

ツールでの実践

Gantyでは、タスクの階層化（親子関係）で粒度を柔軟に調整できます。最初は親タスクだけで粗いガントを作り、近づいたサブタスクに分解する運用が可能。AIによるタスク自動生成も、入力した粒度に応じて出力を調整するため、「粗→細」のローリングウェーブと相性が良いです。複数期間タスクと組み合わせれば、反復作業も1行で表現できます。

まとめ: ルールは指針、絶対ではない

「1日〜5日ルール」は良い出発点ですが、絶対視すべきではありません。タスクの性質、進捗測定の難易度、遅延影響度の3軸で判断し、ルールが効かないパターンには適切な対処法を当てはめる。これが現場で機能するタスク粒度設計の本質です。