「進捗を正確に把握するために、タスクをもっと細かくしましょう。」
プロジェクトでは、よくある話です。
大きなタスクを分解すれば、何をやっているのか分かりやすくなる。担当者も明確になる。進捗も細かく確認できる。
私自身も以前は、タスクは細かいほど管理しやすいと考えていました。
しかし実際には、タスクを細かくしたことで、かえって進捗管理が難しくなったことがあります。
タスクを細かくすれば、進捗が見えると思っていた
例えば、「ユーザー管理機能を開発する」というタスクがあったとします。
これだけでは大きすぎるので、次のように分解します。
- DB設計
- API設計
- API実装
- APIテスト
- 画面設計
- 画面実装
- バリデーション実装
- 単体テスト
- 結合テスト
一見すると、かなり管理しやすくなったように見えます。
「API実装は完了」「画面実装は80％」「単体テストは未着手」というように、細かく状況を確認できます。
ところが、プロジェクト全体では別の問題が起き始めました。
タスクが増えすぎて、全体像が見えなくなる
タスクを細かくすると、当然ながら管理対象が増えます。
10個だったタスクが50個になり、50個だったものが100個になる。
すると進捗会議でも、「このタスクは？」「こちらは？」「このタスクの進捗率は？」と、一つひとつ確認する時間が増えていきます。
本来はプロジェクトを前に進めるための進捗確認だったはずなのに、いつの間にかタスクの確認そのものが目的になってしまうことがあります。
「90％」が増えていく
細かいタスク管理でもう一つ問題になるのが、進捗率です。
例えば、10個のタスクがあり、それぞれが90％まで進んでいたとします。
数字だけを見ると、かなり順調に見えます。
しかし、10個すべてが最後のレビュー待ちだったらどうでしょうか。
あるいは、最後に統合テストや顧客確認が残っているのであれば、実際にはまだ完了とは言えません。
タスクを細かくすると進捗率を付けやすくなりますが、進捗率を細かく管理することと、プロジェクトの進捗を正確に把握することは同じではありません。
タスクの完了数だけでは、プロジェクトの進捗は分からない
例えば、100個のタスクのうち80個が完了したとします。
「80％完了している」と考えたくなります。
しかし、残っている20個が重要なタスクだったらどうでしょうか。
リリースに必要な最終テストや顧客承認が残っていれば、80％完了していてもリリースできません。
つまり、タスク数だけで進捗を見ると、重要度や依存関係を見落とす可能性があります。
プロジェクト管理で見るべきなのは、「何個終わったか」だけではありません。
「重要な成果物が完成しているか」「後続工程へ進める状態になっているか」「クリティカルなタスクが遅れていないか」といった視点も必要です。
タスクを細かくすると「管理コスト」も増える
タスクを追加すれば、その分だけ管理するものも増えます。
例えば、100個のタスクがあれば、担当者、期限、ステータス、進捗率、依存関係などを更新する必要があります。
さらに、期限変更や担当者変更が発生すれば、それらも更新しなければなりません。
つまり、タスクを細かくすることで得られる「見える化」のメリットと引き換えに、管理そのものにかかるコストも増えていきます。
細かくしすぎると、メンバーが実際の作業よりもタスク管理表の更新に時間を使う、という本末転倒な状態になることもあります。
では、どのくらいの粒度がいいのか
「細かくしすぎない」と言っても、ではどこまで細かくすればいいのでしょうか。
一つの考え方として、そのタスクについて進捗確認や遅延判断が必要な粒度かどうかを見る方法があります。
例えば、「ログイン機能を作る」というタスクでは大きすぎるかもしれません。
一方で、「ログインボタンのCSSを調整する」「エラーメッセージの文言を変更する」までWBSに入れると、細かすぎる可能性があります。
重要なのは、作業を細かくすることではなく、プロジェクトを管理するために必要な粒度まで分解することです。
「担当者が違う」「期限が違う」なら分ける
タスクを分ける判断基準として、担当者や期限を見るのも有効です。
例えば、一つの作業の中で担当者が変わるのであれば、分けたほうが管理しやすい場合があります。
また、期限が大きく異なる作業を一つのタスクにまとめてしまうと、遅延を把握しにくくなります。
そのため、次のような場合には、タスクを分けるメリットがあります。
- 担当者が変わる
- 完了条件が変わる
- 期限が大きく異なる
- 他のタスクとの依存関係がある
逆に、同じ担当者が連続して行う細かな作業まで一つずつWBSに登録する必要があるとは限りません。
PMOが見るべきなのは「タスク数」ではない
PMOとして重要なのは、WBSのタスク数を増やすことではありません。
大切なのは、プロジェクトの状態を正しく把握できることです。
そのためには、次のような点を見る必要があります。
- 重要な成果物は完成しているか
- クリティカルなタスクに遅れはないか
- 後続工程を止めているタスクはないか
- 判断待ちや確認待ちが発生していないか
- タスクの更新自体が負担になっていないか
タスクが100個あっても、重要な情報が見えなければ意味がありません。
逆に、タスクが20個でも、プロジェクトの状態を把握できるのであれば十分な場合があります。
「細かく管理する」と「細かく作業する」は違う
ここで混同しやすいのが、「タスクを細かく管理すること」と「作業を細かく分解すること」です。
作業自体は細かく分解して進めても、WBS上ではある程度まとめて管理することができます。
例えば、開発者の作業としては複数のステップがあっても、PMOが進捗を見る単位では「API実装」という一つのタスクで十分かもしれません。
すべての作業単位をプロジェクト管理の対象にする必要はありません。
まとめ
タスクを細かくすることにはメリットがあります。
担当者や期限が明確になり、作業内容も把握しやすくなります。
一方で、細かくしすぎると、次のような問題が起こります。
- 管理対象が増える
- 進捗確認に時間がかかる
- 更新作業の負担が増える
- タスク数に対して全体像が見えにくくなる
- 進捗率ばかりが細かくなる
大切なのは、「どこまで細かくするか」ではなく、「どの粒度ならプロジェクトを適切に判断できるか」です。
WBSを作るとき、つい「もっと細かくしたほうが管理しやすい」と考えてしまいます。
しかし、細かくするほど管理しやすくなるとは限りません。
タスクを増やす前に、
「このタスクを分けることで、何が判断しやすくなるのか？」
と考えてみる。
その視点を持つだけでも、WBSの作り方は少し変わってくるのではないでしょうか。
所属会社（エンジニア積極採用中）
ITエンジニアに、IT業界に貢献する企業
株式会社ONE WEDGE
株式会社ONE WEDGEは、Webシステム開発・SES・AI/DX支援を行うIT企業です。生成AIを活用した業務効率化や次世代システム開発にも注力しており、企業の課題解決だけでなく、エンジニア一人ひとりの成長にも本気で向き合っています。また、技術は「一人で学ぶもの」ではなく「仲間と成長するもの」と考え、社内外でのコミュニティづくりにも力を入れています。