デバッグフェーズでのToDoとの向き合い方

某月某日

現在開発しているサービスの実装が一区切りし、メンバーがテストケースを作成してくれた。なかなか大きなサービスなので作成したテストケースもなかなかに大きい。
数人で手分けしてそのテストケースを実行していくと、最初のテストだったこともあって、結構な量の未実装箇所やバグなどやらなければいけないことが炙り出されてきた。
これをToDoリストに追加していく。

この段階ではToDoリストはなかなかに大きく、最初は少し圧倒されてしまう。

僕はこのような状況でToDoリストを消化するとき、いつも1つのシンプルなルールに従うようにしている。

それは、

簡単なものから手を付ける

である。

この段階ではToDoリストは数十から１００を超える場合もあるので、ToDoリストを見たり、管理したりすること自体が大変である。
プロジェクトマネージャーやプログラマーがToDoリストを見たり・管理するエネルギーをいち早く減らすために、簡単なものから手を付け、ToDoの数をできるだけ早く縮小していく。

数が少なくなればプロジェクトマネージャーの負担が劇的に減る。

例えば、1ヶ月かかるToDoが1個あるのと、
1日でかいけつできるToDoが30個あるのでは、開発量は同じかもしれないが、プロジェクトマネージャーにとっては、前者のほうが管理が楽なのは言うまでもない。

このすごくシンプルなルールにそってToDoを消化していくと個人もチーム全体もストレスが少なくなるので、やっていない人は試していただきたい。

ただ、このルールを適用する前提条件が1つあって、それは、

ToDoが他の組織と依存関係がないとき

である。

もし、他の組織に依存するToDoがある時、例えば、
「画面Aの要件をまとめてデザイナーさんに送る」
のようなToDoが合った場合、これは、早く送れば早くおくっただけ、依存する組織（この場合はデザイナーさん）の人が早く仕事を終わらせられるため、このルールとは別に考えないと行けない。

今回僕のプロジェクトの例で言うとテストフェーズで出てくる未実装箇所やバグなどのToDoは自分たちの問題・仕事であり、他の組織に依存するものがないので、全ToDoに対して「簡単なものから手を付ける」ルールを適用したが、

依存するToDoがある場合は、それは別に分けて、プライオリティを考えていただきたい。

依存のないToDoと、依存のあるToDoにリストを分けて、依存のないものは簡単なものから消化していく。
すごく簡単なことで「もうやってるよ」と思われるかもしれないが、昔の僕はどちらかというと難題にまず挑戦する癖があったので、そういう昔の僕のような人にはアドバイスになるのではないかと思って今回紹介しました。

つづく