この業界に入り数年が経ち、後輩エンジニアが入ってきて指導する機会も増え、タスクへの取り組み方について伝える機会が増えました。そこで、彼らが入ってくるたびに伝えていたことを整理しようと思います。
1. 与えられたタスクの全体感を掴む
自分が何をやらなければいけないのか、アウトプットはなんなのかということを明確に掴む必要があります。
この時、木を見て森を見ずにならないようにしなければいけません。言われたことに対してそのまま実施するというのではなく、本当に実現したいことはなんなのかという原点に立ち止まって考える必要があります。時には要求に対して断るケースもあるでしょう。あるいは少し変えた方が良いのではないかという提案をすることもあるでしょう。要求を咀嚼して最適な解を見つけ出す、これが仕事です。
アウトプットがわかったところで、そのアウトプットを出すために具体的に何をしなければいけないのかを考えます。
2. タスクの洗い出し・整理
実装や現在の仕様を把握して具体的にタスク化していきます。タスクは細かくしようと思えばいくらでも細かくできます。例えばある商品に対してレビュー機能をつけたいとなったときには、テーブルを作る、リレーションをはる、外部キー制約を考える、UIを考える・・・などです。今列挙したものの中では粒度感が違います。粒度感を揃える必要はありませんが、粒度感を把握しておく必要はあります。このタスクは１つのタスクで表現されているが、検討に入っていくとさらに見えていなかったことが見えてきてタスクが増える可能性があるということを把握しておくことは仕事を円滑に進める上で非常に重要なことです。
こうしてタスクの洗い出しができたら優先順位をつけていきます。これは必ずしも容易ではありません。私の基本方針としては、既に明確になっていることに関しては後に回し、曖昧度が高いものから取り組むようにしています。曖昧度が高いタスクを先に考えることで、最初のうちは全体の進捗は悪くなりますが、後半に行けば行くほど明確なものが増えていくので進捗が良くなったり、タスクを他の人にふることもできるようになります。一方で、曖昧度が高いタスクをやるにあたって、明確なタスクを片付ける必要があれば、それは優先度は高いものとなります。
実はエンジニアにおいてはタスクを洗い出している中で、あるいは現状を把握している中でほぼやるべき実装が部分的に終わってしまうケースがあります。私は以前転職した直後に任されたタスクで何をやらなければいけないかファイルをいじりながら整理しているうちにほぼ実装が完成していることに気づきました。あとは細かな仕様を取り込むだけで実装の大枠部分は完了していたのです。しかし、社歴が長くなるにつれこの様なケースは無くなっていきました。なぜなら、経験を積めば積むほどいちいちファイルを見なくてもタスクが整理でき、やるべきことが明確になっているからです。慣れていない環境でタスクを早く終わらせたい場合は、ファイルを触ってみる中で実装までやってしまうと良いでしょう。
3. 実装
タスクの洗い出し・整理ができたら実装に進みます。しかし、前述の様に現状を把握していく中で実装がほぼ完成している場合もあり、必ずしも2. タスクの洗い出し・整理から明確に区切りがあるわけではありません。とはいえ、2. タスクの洗い出し・整理では例えば自動テストの実装、細かな設計までは行っていないと思いますので、最後の詳細の詰めは行う必要があります。仕事というものは８割〜９割まではすぐにできるものの、残りの１割に時間がかかるというケースはよくあります。実装フェーズでは、この最後の詰めを意識して行いましょう。
4. PR作成
実装が完了したと思ったら、PullRequestを作成します。この時、とりあえずDraftないしWIP（Work In Progress）でPullRequestを作成すると良いでしょう。実装に複数日かかるケースなどは、日々の進捗をチームに共有するという意味でも、１日の仕事を終える際にはDraftないしWIPでPullRequestを作成する様にしましょう。どんなに途中で整理がついてなくて恥ずかったとしても必ず１日の最後にPullRequestを出す、他のメンバーが見て助けてくれたり、稼働日が違う人（土日や夜間稼働する業務委託の方など）が引き取ってくれたり、チームで開発するにあたって非常に大事なことだと思います。
5. セルフレビュー＆修正
PullRequestを作成したら、すぐにレビュー依頼をかけようとしてはいけません。まずは、PullRequest上でセルフレビューを行いましょう。エディタで見ていた時とは違った気づきを得られることは多々あります。diffもエディタやターミナル上でみるよりも見やすかったり、見える世界が違うことはよくありますので、PullRequest作成したら必ずセルフレビューを行う様にしましょう。セルフレビューで修正すべき箇所が見つかったら修正しましょう。場合によってはPullRequestを出した直後にセルフレビューを行い、一晩寝かせて翌朝再度セルフレビューを行っても良いでしょう。疲れてきている夜に見るのと頭がすっきりしている朝見るのでは同じ一人の人間でも指摘できるレビュー内容が違う場合があります。また、PullRequestをDraftで作成した夜お風呂の中で気づきがあるかもしれません。セルフレビューする時間をずらして一人の人間でも複数の視点で見ることが大切です。
6. レビュー依頼＆修正
PullRequestを作成し、セルフレビューも行った後はようやくチーム内にレビューを依頼します。この時に、PullRequestのDescriptionにはきちんと説明を記載する様にします。昨今ではほとんどのチームではDescriptionのテンプレートが設定されていることでしょう。先輩エンジニアを見ていると必ずしも丁寧にDescriptionを記載していないかもしれませんが、入社まもない場合は丁寧に記載する様に心がけましょう。先輩エンジニアたちはこれまで一緒に働いてきた蓄積があるので、場合によっては詳細を説明せずともPullRequestが取り組もうとした課題およびその解決方法について阿吽の呼吸で把握できたりします。入社まもない場合はその蓄積がありませんので、どういうことを考えてこのPullRequestを作ったのかということをしっかりと伝えていく必要があります。しばらく経てば周りからもこの人はこういう考えをするんだということがわかる様になり、一定の信頼を得られる様になれば仔細にDescriptionを書かなくても伝わる様になります。