僕はよく手が早いと言われるのだけど、そんな中で気をつけてることを整理してみた。大きくは下記の３点につきる。
- 複数タスクは抱えるが、並列で進めない
- イベント駆動で動くことを原則として、探索行動をしない
- 暫定対応ではなく、最初から必殺する
複数タスクは抱えるが並列で進めない
僕はだいたい平時2〜4くらいのタスクを抱えている。しかし、だいたい1個〜2個に集中して片付けて、次に手を付けるっていう感じで進めている。
この2つをさばくときは、例えば1つ目のタスクのコードを書ききってしまって、レビュー待ちとかの問に、2つ目のタスクの設計を考えたり、あれこれ進めて、レビューコメントが付いたらまた1つ目に戻ってぐわーってやる感じ。もう少し小さいスキマ時間、例えばchefのapplyとかコンパイルだとSlackで適当に人に絡んでわけのわからないことを言って去るという感じのことをしている。
ともあれ、これの利点は基本的に小刻みにバリューが出るので自身のモチベーション管理もしやすいし、基本的には終わらせることを原則に持つことでリズム感も出るし、何よりコンテキストスイッチが少ないのが僕にあっている。
あとは長期スパンの仕事を持っているときはそれをやる時間っていうのは予め一日ないし、一週間で決めておいて、決められた時間で取り組むことで、2〜3日で終わるものと数ヶ月かかるものは進め方を変えたり、そもそも数ヶ月のものを2〜3日で区切って進めていくみたいなことをやる。完了までが遠すぎるとなかなかバリューが出なくて、モチベーション管理がしづらいのでそこは自分と相談しながら進め方を変えている。
イベント駆動で動くことを原則として、探索行動をしない
これはGithubの通知、カレンダー、Slackの通知をなどをしっかり設定して、何かがあれば通知をベースに動くということや、ログなどもダラダラ見たりせずに特定のメッセージが出現したら通知というように設定して、自分から探索行動をすることなく、何かがあってから動くというふうにしている。
こうすることで無駄な探索時間が省けるし、通知がある＝アクションが必要となるので必要なことを漏らすことも少ない。
これは一日とかですぐできるものじゃなくて、都度都度しっかりリマインダーを入れたり、コード化することで積み重ねていくものなので、日々の積み重ねが効いてくると思う。
またこの運用だと通知のノイズが死活問題になるので必要以上の通知を極端に嫌って、そういうのを見かけたら仕組みの改善、人の仕事のやり方や、情報の非対称性などを洗い出し、すぐ改善するようにしている。
暫定対応ではなく、最初から必殺する
これは主にインシデント時や、プログラムに不具合が発生した場合に徹底しているのだけど、僕は基本的には暫定対応というものをやらない。これはなぜかというと暫定対応というのはもちろん時と場合によってというか、多くの場合ベターな対応になりうるが、一方でそれらが何かしらの因果をもって再発する可能性がそれなりにあって、結果的に断続的に自分の時間を奪うことになる。
そして再発は多くの場合、優先度マックスで降り掛かってくる。
さらに、暫定対応は多くの場合、何かとトレードオフされているのでそういった状態でサービスが動くことをあまり良いことだと思わない信条もある。
では、最初から根本対応するためにどうするかというと、これは元も子もないのだけど普段から書籍を読んだり、人に教えを請うたり、自分で手を動かすことで自分の引き出しを増やしておくに尽きる。人類が暫定対応している時間で、根本対応をすることができれば、上記のリスクも減らせるし、結果的に多くの時間を得ることができると信じている。
最後に
こういうことを書いてみたものの、僕自身もかなり無駄があって、それこそ今日rspecを書いていて、1行mockコードを書いてはRubyを実行して例外メッセージを見て、直して、また実行してみたいなことをやっていた。
頭ではこんなん100行位書いてから一気に実行してまとめて例外直せばええやんみたいなの思うんだけど、なんか詰まってくるとそういうの置いてしまって、効率悪い進め方をしてしまうこともある。
大事なのはこういう自分の良い特性、悪い特性みたいなのを理解して、自分にとってどういう進め方が一番効率よくできるのかを知りつつ、効率良さそうな人から色々テクニックを聞いたりしてそれをいい感じに取り入れていくのが結構大事じゃないかなって思うわけ。