最近の技術イケメン観察日記 Tips 4選

　継続して、技術イケメンの振る舞いを観察して、メモしておきたいなと思ったので、最近気づいたことを残しておきたいと思ってノートを書くことにしました。

技術イケメンはリプロの腰が軽い

　ある時お客さんから、ある技術の問い合わせが別チームから来たのだけど、自分のカバー範囲ではあるけど、自分はその部分やったことない分野だったので、彼のhelm chart を読んで、自分は正直しらないけど、サンプルやドキュメントを見るとこの部分が違うよという指摘だけをした。私はそのサンプルと、チュートリアルのポインタを渡してあげた。自分の心の底では、「多分これ、あれこれの単純設定ミスだから、このチュートリアルなぞればできないはずないで」と思っていた。そんで多分他の技術イケメンはこれを知ってて解答してくれるだろうと期待した。

　すると、技術イケメンはどう行動したかというと、彼はその私が渡したチュートリアルを流して、「この方法でやったらちゃんと出来たよ」とレポートした。つまり、その分野に関して彼も知らなかったのだ。つまり、私とまったく同じ状態だったわけだ。自分はリプロに時間をかけるのをめんどくさがったが彼はやった。結果として、私には何も残らなかったわけだが、技術イケメンは自分が知らない分野を体験することが出来た。

　このことを自分のメンターに話してみると、彼が言ってくれたのは「自分が知らない時はリプロするんだよ。効率がいいから」と教えてくれた。確かに知ってることはリプロしなくていいから。
　ああ、相手にとってのアウトカムと自分の時間の投資を天秤にかけて考えてる自分だと、こういう発想にならないが、少なくともエンジニアの場合、「自分が知っているか」に焦点を当てて考えるというのは思いもしなかった。問い合わせは正直面倒だなぁと思うこともあるが、こう考えてみると自分の成長のきっかけだし、中長期の貢献を考えると、自分のカバー分野のリプロやデバッグをいかに腰を軽くする、出来るようにするという投資はとても良いのかもしれないという学びを得た。

アーキテクチャを理解するときのコードリーディングは時間をかける

　今は珍しく研究プロジェクトに参加している。現状のアーキテクチャを理解して、新しいアーキテクチャの PoC をするとい類だ。自分も一生懸命コードリーディングして、大体の構造や振る舞いは理解してるつもりだった。そのコードを読んだことない技術イケメンの頭脳を借りてアーキテクチャのディスカッションをするときに、結構質問に答えられないことがあって、一緒にコード読もうという話になった。

　技術イケメンと一緒にコードを読んでいる時に気づいたのだが、彼はその技術にたけているので私よりずっとコードを読んで理解するスピードが速いのだが、自分なら、「ここはだいたいこんな雰囲気になってんじゃね？」みたいに読み飛ばすところでも、彼がさっと理解できない時は、私よりもずっと、ものすごーく時間かけて、サンプルの数値を書いてみて、理解している様子だった。その後ディスカッションに戻ると彼はものすごーく正確にアーキテクチャを理解してアイデアを沢山だしてくれた。

　自分はコードを読むのが遅いので早くすることばかり考えていたけど、そうではなくて、「早くなるもの」と考えて、コードのロジックを読むのではなく、コードの意図とその背後のアーキテクチャを理解するために読んでいる感じだった。つまり、自分がそれを理解できない場合はコードを理解できていないのだ。時間をかけるのを恐れてはいけない。

時間をブロックすることの重要さ

　最近は、組織が変わったこともあって、技術エリアの引継ぎが多くて、同僚からの質問対応とかでの中断が物凄く多くて、自分のプライオリティが高いタスクの進捗が悪いと感じていた。ある日一日のどんなタスクにどれぐらい時間を使っているかをトラックしてみると、なんとメインの仕事に1.5H しか使えてないことがわかって衝撃的だった。

　自分のマネージャに相談してみた。彼女は、自分が Individual Contributor だった頃のメソッドを教えてくれた。そのメソッドは自分からするとスーパーイケメンのあの人も、この人もやってる方法だと教えてくれた。単純な話で、毎日４時間をブロックして、Teams も閉じて、自分の作業だけをする。

　そういえば、Teams でチャットをしたときに、すぐに返してくれる人と、１日に１回ぐらいしか返してくれない人がいる。自分はすぐ返してくれた方がありがたいのでそうしていたけど、キャリアが長い人になればなるほど、基本的に１日に１回ぐらいしか返答が返ってこない。彼らはみんないい成果を出している。しかし、自分はレスポンシブな人に助けられていたので、レスポンシブにしていた。

　だけど、彼女は教えてくれた「There is no magic. It's ok to book your time 」マジックは無い。自分が物事を進めたければ、そういうことをするのは全然ＯＫよ！と。正直レスポンシブでなくなることに罪悪感があったが、思い切ってやってみることにした。

　すると、進捗するする。全然ちゃうやん。多分キャリアが長くなればなるほど、他の人のサポートの仕事も増える。なぜなら自分がコンテキストを持っている分野が増えるから。それを他の人にシェアしてあげるのは立派な仕事なのだけど、自分の一番のプライオリティの仕事が進まないのであれば、それは意味がない。

　だから１日に４時間ブックして、そのほかの時間はそういう対応に充てる。という時間割は本当にうまくいくように感じている。全部をブックしているわけではないので、ブックしている時間以外はレスポンシブに返しているし、それ以外の時間で、GitHub の Issue やら、メールをまとめて返す時間を作っている。多分これは自分には合っているアプローチだ。

引継ぎを想定することが生産性を上げる

　これは、ある技術イケメンを観察して見つけたことなのだが、ある技術イケメンは、開発スピードも速いのだが、問い合わせ解答はレスポンシブではないのだが、解答が必ず１発で的を得たものが返ってくるという凄い人がいる。他の技術イケメンに彼女の秘訣を聞くと、「彼女はいつもメモをとっているね」と言っていた。彼女のドキュメントは常に正確で、的を得ており、社内のOneNote を検索すると、聞こうと思っていたことが解決することも多い。

　まだその境地にたっしていないし、秘密もわからないのだが、自分の体験のなかで、ふとこれじゃないか？と思ったのが、いつ自分が引継ぎをすることになっても問題ない状態をキープすることでは？と思い当たっている。

　というのも、先ほどお話したとおり、自分が開発するだけではなく、他の人からの問い合わせ対応、障害の調査などにも時間は割かざるを得ない。また、引継ぎは定期的に発生するもので、特殊ではない。引継ぎは特に労力のかかるものだ。

　それならば、最初から引継ぎを想定して、日ごろから、何かの構造や機能追加の方法を理解しやすいプルリクエストやコードポインタを自分が調べたときに保存して置いたり、障害の調査に便利なクエリーを整理しておいて、すぐに引き出せるようにして置いたり、アーキテクチャの全体の構造を整理しておいてすぐに思い出す、もしくは、すぐにコードを見直せるようにしておくと、いろいろな物事の省力化が進むのではないか？という仮説だ。これに関しては、もしよい Tips をお持ちの方がおられたらシェアしていただきたいなぁ。