ゴールは段階的に | 株式会社キャリッジリターン

タスクの量が多すぎて前が見えなくなったことはありませんか？

私は以前、ちょっとした大炎上プロジェクトに携わっていた時頻繁にそのような状況に陥っていました。

特に結合試験のフェーズがひどく、モジュール間のやりとりはままならない、また珍しく上手く疎通できたと思えばその先で単体試験レベルのバグが上がりまくったりとメインで修正担当をしていた私は焦りに焦っていました。

さて、そんな状況をどう切り崩したかと言うと、それは二つのゴールを設けることでした。

一つ目は「モジュール間の疎通を完全にする」こと。
上述したように、画面遷移できない、ダイアログが出て来ない…など起動さえもできないレベルの致命的なバグが多く、そのためテスト担当者の手は止まりがちになっていました。
まずは(仮にバグ地獄だとしても)動きさえすれば打鍵することは可能だろうと、そこを目指すことにしたのです。

物によってはほぼ作り直しとも言えるようなことをしつつ、ある程度アプリケーションとしての体裁が整ってくるとテスト担当者の試験は進み、バグの粒度は単体レベルかそれに毛が生えた程度のものに均一化されてきました。

二つ目は「不具合の重さや影響範囲に応じて１つ１つ優先順位をつける」こと。
至極当たり前のことと言えばそうなのですが、これをやると順番が整理でき、かつ自然とバグの難度も分かってきます。
軽いものは他の人にお願いしたりなどメンバーの手も借りやすくなり、何とか結合試験フェーズは収束に向かうことができました。

この経験を振り返ってみて思うことは、来たものに片っ端から手をつけるのではなく、全体を通しての何段階かの着地点、つまりゴールを設けておけば後はそこを目指して注力するだけとなるのでオススメです。
今自分がどのくらいの進捗なのかも見えやすく、これは精神衛生上非常に良いです。(作業する上でメンタルの健全さは何より大事です。本当に)

まとめると下記のような感じでしょうか。
・ゴールは明確に、かつ段階的にすることで自分が何をするべきかと今どのくらいの位置にいるかが見えやすくなる

※しかしこの後未実装の機能が発覚したりでまた一波乱あったのですが、それはまた別のお話…。