コードレビューするときに考えること
開発チームもコードベースもプロジェクト規模も大きくなってきたので、もはや実装上の設計の細かい点まで指摘することが難しくなった。個人的な趣味で、自分が直接関わっていないプロジェクトの issues も全部眺めているが、それでも内容を把握しきるのは無理。なので、コードそのものに対する指摘は少なくなり、その代わりに「第三者があとでこのコードを見たとき、意味がわかるだろうか」と考えて、わからなそうだなと思ったらたとえ自分には意図が理解できたとしても「意図がわからないのでコメント書いてくれ」とか指摘するようになった。コードレビューをしているのに、コードレビューをしていない人の気持ちになる、みたいな感じ。ちょっと幽体離脱っぽい。違うかもしれない。
仕事のやり方について考えること
一般に、能力が高い人ほど仕事が増えがちだし、責任感の強い人ほど仕事を抱えてしまいがちだ。どちらも本人に悪意はないが、結果的にその人がボトルネックになってしまう。これを「仕事を減らす努力を怠っていて良くない」ことだと考えるようになった。仕事を減らす工夫はいろいろできる。ルーチンワークがあるなら手順を文書化して他の人でもできるようにして引き継ぐとか。でもむしろ、そういう風にちゃんと準備して引き継ごうと思っている時点でダメだと思う（追記: その人がすべきなのは「やるべき仕事を減らすこと」なのに、「引き継ぎ資料を作る」という余計な仕事を自ら作り出してしまっていて本末転倒だから。本当に資料が必要なのか、必要だとしてどの程度の情報量が必要なのか、それは後任者が誰なのかによって異なるはずで、それもわからないうちに資料を作り始めたらたいてい作りこみすぎてしまう）。そこまで真面目な人であればそもそも雑な丸投げ引き継ぎなどできやしないので、思い切って丸投げするつもりで放り出しても、なんだかんだいってある程度整備済みだからたいした苦労もなく引き継げる。というか多少の不明瞭な点は後任者に自力で解決する努力をさせて育てる、くらいのほうがよい。至れり尽くせりで過保護にしすぎるのは後任が育つ芽を摘むことに繋がるのでやはり良くない。
追記: 後任の候補者がいない場合はどうするのか、という反論がありえると思う。それについては、見込みのある誰かを後任にするように巻き込む（重要度も緊急度も低い仕事を何かのついでに頼むとか）、後任を見つけるよう上司に掛け合う（頼むだけじゃなくて同じポジションができそうな人を見つけてきて異動や転職をそそのかし、相手を本気にさせて上司が無視できないようにもっていくとか）、自分のキャパシティではこれ以上の仕事はうけられないよと言って断る（誰も文句は言えないだろうし、もし文句を言われたらそんな無理解な職場は辞めたほうがよい）、などの手を使って、自分から仕事を手離れさせる努力をすべきだ、という立場です。
