タスクの粒度がバラバラなチームをそろえる方法｜PM・PLのための運用中タスク調整ガイド

「Aさんのタスクは半日、Bさんのタスクは2週間」という状態のチケット管理表を見たことはないでしょうか。

タスクの粒度がバラバラだと、進捗の比較ができません。「今週どれだけ進んだか」を週次で確認しようとしても、タスクのサイズが人によって違えば、消化件数も意味をなしません。大きなタスクを持つ人の進捗は常に「0か1か」になり、実態が見えにくくなります。

この記事では、WBSを最初から作り直すのではなく、今運用しているタスクの粒度を揃えるための具体的な基準と調整方法を解説します。

タスク粒度がバラバラだと何が起きるか

進捗が比較できない——これが一番の問題です。

「今週Aさんは5件完了、Bさんは1件完了」という数字を見ても、Aさんの1件が30分作業で、Bさんの1件が1週間かかるものなら、この比較に意味はありません。

もうひとつの問題は、大きすぎるタスクが遅延を隠すことです。「2週間で対応」というタスクが1週間後に「まだ50%」という状態になっても、表面上は「進行中」のまま見えます。進捗会議で確認しても「順調に進めています」と報告されてしまい、PM側では問題を認識できません。

タスクの粒度を揃えるとき、「時間で統一する」だけでは不十分です。タスクの性質によって適切なサイズが違うためです。次の4つの基準で判断します。

完了条件が曖昧なタスクは、見た目より大きくなりがちです。「ユーザー認証機能の実装」では何が完了したら終わりかが曖昧です。「ログイン画面の実装（テスト済み・レビュー完了）」まで絞れば、完了の判断がしやすくなります。

タスクを作るとき、または受け取ったとき、「完了条件が一文で書けるか」を確認してください。書けないなら分割が必要です。

目安として、タスクは1〜3営業日で完了できる粒度にするのが扱いやすいです。これより長くなると進捗の実態が把握しにくくなります。

「5日以上かかりそうなタスク」は基本的に分割の候補です。フェーズ・成果物・担当者・確認工程で切り分けられないか見直します。

「設計書作成と顧客レビュー対応」を1つのタスクにしているケースがあります。これは「設計書の作成」と「レビュー指摘の対応」に分けたほうが進捗が見えやすくなります。1タスク1成果物を意識すると自然と粒度が揃ってきます。

依存関係が未整理のまま大きなタスクにまとめられていることがあります。「A完了後にBを開始」という依存があるなら、AとBを別タスクにして依存を明示します。依存が見えると、どのタスクがボトルネックになっているかが分かります。

現在のタスクが大きすぎる場合、次の3つの切り方を試してください。

フェーズで切る — 設計・実装・テスト・レビューのフェーズで分割する。最もシンプルな方法で、進捗報告の単位としても使いやすい。

機能・画面で切る — 対象の機能や画面単位で分割する。「一覧画面」「詳細画面」「登録画面」のように、ユーザーの視点で切ると顧客確認の粒度にも合わせやすい。

確認待ちで切る — 顧客確認や上長承認が必要な部分を別タスクにする。これにより「待ち」の状態が可視化されます。

逆に、タスクが細かくなりすぎているケースもあります。「1時間以内で終わる作業が大量に並んでいる」状態は、管理コストが上がります。

統合の基準は「同じ担当者が連続して処理するか」です。同じ担当者が同じ日に処理するタスクは、まとめてしまって問題ないことが多いです。ただし、他者の確認が入るものはまとめないようにします。

粒度を揃えても、新しいタスクを起票するたびに粒度がバラバラになれば元に戻ります。チームで共有するルールを決めてください。

最小限決めるのは次の3つです。

「ルールを作って終わり」にせず、最初の2〜3週間はPMが積極的に確認してフィードバックを返すと定着が早くなります。

タスク粒度のバラつきは、チームのスキル差の問題ではなく、「完了条件・期間・成果物・依存関係」の基準が共有されていない問題です。

基準を共有し、大きすぎるものを分割・小さすぎるものを統合するだけで、週次の進捗確認がずいぶん楽になります。WBSを最初から作り直す必要はありません。今動いているタスクをそのまま調整するだけで変わります。

タスク管理・プロジェクト運営を体系的に学びたい方は、受託開発PM向けの課題別パックや新任PM向けパックをご覧ください。