レビューしたコードは、自分のコード

−現在行なっている業務内容を教えてください。

主に基盤刷新や機能開発に取り組んでいますが、他にもミドルウェアの運用・パフォーマンスチューニングもしますし、オンコール対応なども行なっています。社内からはSRE[※1]と呼ばれています。

幅広く業務を行なっているように見えるかもしれませんが、シンプルにまとめると「サービスの信頼性向上」「Reproの強みになる基盤構築」が求められている業務ですね。

SRE[※1] →Site Reliability Engineeringとは、Google社が提唱、実践しているシステム管理とサービス運用の方法論である。担当するエンジニアをサイトリライアビリティエンジニア（SRE）と呼ぶ。 （出典：https://landing.google.com/sre/ ）

−入社以前から現在のようなポジションの職務経験はあったのですか。

いえ、そうではないですね。今振り返ると、最初は使ったことのないツールやミドルウェアばかり扱う場面が多くドメイン知識も皆無だったので、キャッチアップがとにかく大変でした。

Reproに入社する以前は、クックパッドでRailsを使ったサービス開発をしていました。他のサービス開発エンジニアに比べると高速化や検索関連のタスク等、バックエンド寄りのことを多めにやっていましたね。人手にあまり頼らなくても正しい商品管理が行えるように、商品名を正規化するシステムを構築するようなことも行なっていました。

−Reproに入社してから初めて向き合う課題や業務も少なくなかったと思います。乗り越えていく過程で心がけていたことはありますか。

意識して心がけていたというよりは性格もあると思いますが、仕事を進める上で「納得感」は大事にしています。

例えば、コードレビューする時も 「レビューしたコードは自分のコード」 だと考えて行なっています。「書いたのは自分じゃないから…」という気持ちがどこかにあると本質的なレビューができないじゃないですか。背景や理由を理解した上で、疑問点や不明点をそのままにせず、納得できる形になるまでやり遂げることが重要だと思っています。共同開発をするような場面でも、同じですね。背景や理由をちゃんと理解した上で開発・レビューを行い、納得できる形を目指します。

−納得感を持てるところまで突き詰められず挫折してしまう人もいると思いますが、なぜそこまでやり切れるのでしょうか。

なんでなんでしょうね…。シンプルに楽しいから、だと思います。おそらく、僕は理解できなかったことが理解できるようになることが楽しくて、できることが増えていくのも同じように楽しいと感じるタイプなんでしょうね。

「なんでこうなっているのか？」「なぜこれは起きているのか？」と追求していくと、自然と理解できること・できることが増えていくので、それを楽しんでいるということだと思います。

もっというと、理解できること・できることを増やしていったその先で、「もしかしたら、これは自分だったからできたのかもしれない」と思える仕事ができた時はとても嬉しいですね。

実際にあったことでいうと、入社後に原因不明のトラブルが起きていた時期があったんですが、根気強く原因を調査し、安定稼働するところまで持っていくことができた時のことは今でも覚えています。

当時データを収集するミドルウェアを扱っていたんですが、データが流れていないように見える症状が起きていました。「プロセスは動いているはずなのに、なぜ…」と社内でもわかる人間がおらず、GitHub上でも問題として取り上げられているものの、誰も解消できていない状況でした。そのOSSの問題を解決し、安定版まで持っていくことが出来た時は嬉しかったです。

−予測不能な事態や成功プロセスが明確でない挑戦に取り組むことが多いように見えます。どのようにして解決・達成を遂げられるまで取り組んでいくのでしょうか。

ファクトをしっかりと捉えつつ、「一旦これでいい」というような状態をそのままにしないで必要であれば実験も行いながら取り組んでいきます。

その中で心がけているのは、表面的な対応をしてしまいそうな時に一度問いかけること。「本当にそれでいいのか」と。その答えがあれば先に進みますし、根拠がないのであれば実験を行い、時にはソースコードも読みながらファクトを捉えるようにしています。

とは言いつつも僕自身これが完璧にできている訳ではないですし、他チームの話を聞いていても「あの時はあの対応をとったけれど、実はこういう仮説もあって、そっちの方が根本解決に繋がった可能性があった気がする…」という声を聞くこともあります。難しいことも多く、気力、根気がいる作業です。

それでもこういう仕事って必ずしも経験があるからできるという訳ではないので、これまでに経験したことがないような挑戦・事態でもファクトを的確に捉え、一歩ずつ取り組んでいきたいと思っています。

他人には苦労をかけたくない。細かな配慮と工夫の裏側

−個人としてディープワークに取り組む場面がある一方で、チームとして取り組む場面もあると思います。チームメンバーや業務を共にする人に対して、心がけていることがありますか。

自分以外の人でも正確に情報をキャッチアップできるようにすることを常に心がけています。チーム内で行なっている勉強会は僕の提案から定期開催するようになりましたね。

勉強会を開催するようになったのは、もともとインフラチームと言われていた頃です。そのころは3人のチームだったんですが、相互でレビューしつつ、個人個人で開発にも取り組んでいるような状況でした。初めて触るAWSサービスも多かったので、開発する人もレビューする人も都度調べて対応することも多かったんです。深い技術的な知識もドメイン知識も必要で、レビュー時間が想定よりも長くなってしまうことも少なくありませんでした。そこで、それぞれに都度調べて対応するのは面倒だし時間ももったいないということで、調べた内容や互いの知識などをシェアする場として開催し始めました。それからはそれぞれのメンバーが表面的な知識・理解に止まらないよう、新メンバーも交えて定期開催しています。

周りのメンバーのできることが増えると僕の業務が楽になりますし、しっかりとした基礎知識の上で業務に取り組んでもらえると無駄なトラブルも少なく済むので、今後もこうした機会は続けていこうと思います。もし成長意欲が高い方がいれば、そういった方にとっても成長角度を上げてもらえる機会になります。ゆくゆくは、自分がいなくても回るくらいの状況を作り出せたらいいなと思いますね。

−自身の業務がある中で、メンバーに配慮した心がけや勉強会の開催が大変だと感じることはありませんか。

全く大変じゃないというわけではないですが、ここまでするのは僕自身のこれまでの経験が関係していると思います。

実は、これまでに引き継ぎという引き継ぎをきちんと受けたことがないんです。それが、結構苦しくて…。

学生時代に各部活から一名選出しなければならない統括団体に入った時は、去年の担当者の活動報告書がなくて全て一から手探りで行わなければなりませんでした。正直、「なんでだよ…」って思いますよね。活動報告書を残していてくれれば、あとを引き継ぐ人が助かるってことは誰だって気づくことじゃないですか。

働き始めてからも、どこに何が保存されているかもよくわからないデータを使ったLTVの予測を一週間以内にやってくれと突然言われたり、「これに全て書いてあるから」と200ページ以上の英語の仕様書を渡されてそれ以上の説明なしにタスクをこなす必要があったりしました。当時は何とかなりましたが、人によってはちょっと…。

そうは言いつつも、引き継ぎがなくても十分な事前説明がなくても、その場ではやるしかないわけです。もし自分がやらなかったらまた別の誰かがこの苦労をするんだと思うと、結局は自分がやった方がいいんです。

少し個人的な話になってしまいましたが、過去の経験上そういったことが多かったので「他人には苦労をさせたくない」という気持ちが強くなり、今も先ほどお話ししたような配慮と機会づくりは続けています。

−周囲への配慮と粘り強く仕事に打ち込む姿の裏側には、そのような経験があったのですね。

こうして話していると、僕はこだわりが強いというか…少し頑固なところがあり、一度始めたことは簡単には辞めないぞというところもありますね。実際には、突き詰めていけばいくほどいろんな壁と向き合う場面も多くなります。それでも納得いくまで向き合ってみて、新しい知識や経験が増えていくことはとても楽しいですよ。

納得できる仕事を積み重ねることで、技術が血肉になる

−「らしさ」が伝わる働き方や姿勢をお持ちだと感じますが、目指しておられるエンジニア像はありますか。

目指しているエンジニア像…そうですね…。目的や意図がはっきりと伝わるコミュニケーションを取れる人や周囲への配慮ができる人は素晴らしいと思いますし、趣味を持っていきいきとしている姿が伝わってくる人も魅力的だなと感じますね。

あとは、技術がしっかりと血肉になっている人は惹かれますね。具体的にいうと、表層的な理解だけではなく、一つ一つ着実に理解し、自分のものにしていくようなイメージ。僕自身もそんなエンジニアを目指して、納得できるまで一つ一つ取り組んでいきたいと思っています。

−今後、挑戦をしてみたいことはありますか。

CTOを始めとしたキーマンがいなくてもよりスムーズに進むような体制を作っていきたいですね。SREは配慮すべき点や求められることが非常に多い役割なので、僕自身を含めたチームメンバーが自分のやるべきことにより集中できる環境を整えていければ、今よりもさらにプロダクト・サービスの信頼性を高めような業務に集中していけるようになると思います。

企画・取材・執筆 = 山崎 貴大

撮影 = 賀谷 友紀