はじめに

日々の開発でタスクの見積や進捗管理をしていると、
「なんとなくこのくらいで終わるだろう」
と感覚で判断してしまうことはないでしょうか。

その結果、

といった状況に陥ることがあります。

今回は、このような問題の原因をタスク分解の観点から整理してみます

タスク分解が甘いと何が起きるか

タスクが適切に分解されていない場合、次のような問題が起きやすくなります。

この結果、

「今日終わる見込みです」

と言われ続けるものの、
実際にはいつまでもタスクが終わらないというようなケースに陥ってしまうことがあります。

これは「何が残っているのか」が正確に把握できていない状況であることが原因だと感じています。
そして、レビューに出した段階で、この機能がまだできていないと発覚することもあります。

タスクを分解する目的は、
作業内容を“見える化”することにあります。

例えば「〇〇API実装」という一つのタスクでも、実際には複数の工程が含まれていることがあります。
以下のように4つの主要な機能が含まれている際に、

というように分解すると、

が明確になります。

一方で「〇〇APIの実装」という粒度のままだと、

といった状態になります。

タスクを適切に分解すると、次のようなメリットがあります。

細分化されたタスク単位で見積もることで、
「どこに時間がかかるか」を明確にできます。
また、小さい単位に分けるため、何の対応をするかが理解しやすくなります。

「4つ中2つ完了」のように、
定量的に進捗を判断できるようになります。

途中で優先度の高い作業が入った場合でも、
未着手のタスクを他のメンバーに渡すことができます。

タスクが細かくなることで、「あとこれとこれをやれば終わる」という状態が作れます。
１日の作業の中で闇雲に作業をするのではなく、これが終わったら帰ろうというように、
目標をもって作業ができるので作業効率が上がると考えます。

個人的には、半日〜1日で終わる粒度まで分解するのが目安だと考えています。

この粒度であれば、

といったメリットがあります。

大きな機能ほどタスク分解は手間がかかるため、つい省略したくなります。

ですが、

を考えると、やはりやっておいたほうが最終的には楽になると感じています。

もし最近「見積が当たらない」「進捗が読めない」と感じている場合は、
一度タスクの粒度を見直してみると改善するかもしれません