SREとは、もっとも顧客が身近にいるエンジニアではないか――　ファインディ株式会社下司さんに聞く“今のキャリアを選んだわけ”

ITエンジニアと一口に言ってもフロントエンド、サーバーサイド、インフラ、QA、マネジメント……など、ポジションやキャリアにはさまざまなルートが。使う技術やツールはもちろんのこと、面白さや考え方も異なります。「なぜ、どういうきっかけでその道に進むことになったのか」「何がやり甲斐なのか」には、人それぞれの答えがあるものです。

いろいろな人から自分なりのキャリアの選び方を伺うことで、テックの世界の知見を共有する本企画。今回はファインディ株式会社の下司宜治さん（@gessy0129）にLT形式で発表していただきました。

speakerdeck.com

自己紹介

ファインディの下司宜治（げしよしはる）と申します。会社ではプロダクト開発部のSREのチームリーダー、およびCTO室の開発推進チームリーダーをやっています。

今回はSREをやっている理由と、前職の株式会社アンドパッドで約5年間VPoEを務めていてた理由についてお話します。

経歴、スキル

まずは私の経歴から。新卒でヤフーに入社し、キャリア初期はガラケー版のサイトやParseを作ったり、ECサイトを作ったり。また、データセンターやAWSといったところでバックエンド、インフラ系の作業もしていました。

技術としてはPerl、PHP、Ruby、Pythonといったライトな言語で開発することが多かったのですが、必要に迫られてコンパイラ系の言語を触ることもありました。PHPの拡張機能を作るためにC++、アドネットワークのデバッグ用アプリを作るためにObjective-C、といった具合です。

自分の持っているスキルについてもお伝えしたいのですが、対外的に発表するにあたって「好き」「苦手」のような直接的な表現はかえって誤解を招くかもしれないので、絵文字を使ってニュアンスだけ表現してみます。

😆なのは障害対応や深夜メンテナンス、制度設計。このあたりが自分の中でのアセットになっています。

😆だけどちょっと😦なのは、プログラムを書くこと。上には上がいる、上がいすぎるところなので、なかなか😤という感じにはなりません。

😫なのは、プロダクトマーケティングやプロダクトセールス、UI/UXデザイン。あと、台本通りに物事を進めるのも😫です。結婚式の2次会の司会を3～4回やりましたが、1回も台本通りに進めたことがなく、いつも「台本にないことを言うんじゃない」と怒られています（笑）。

ここで大切なことをひとつ。私はEmacsとREALFORCEが好きです。テック系イベントなどでプレゼント企画があると、だいたいHHKBが景品になりますよね。許せません。なぜでしょうか。「自分はこんなにREALFORCEが好きなのに！」という気持ちを、この場を借りてお伝えいたします。

VPoEになった理由

なぜ私がVPoEになったのかについてお話しします。

実を言うとVPoEを目指していたわけではありません。会社や事業をまわすために動いていたら、いつの間にかそうなっていた形です。

当時はエンジニアが数名しかいなくて、「これから採用を加速させよう」「社内外で影響力を出すためには役職があったほうがいいよね」ということで、VPoEを名乗りはじめました。世間一般的に“マネジメントのスペシャリスト”のようなVPoE像があると思うのですが、コードレビューしたり、メンテナンスに同席したり、障害対応をしたりとさまざまなことをやっていました。

5～6年やっていましたがVPoEの役職にこだわりがあったわけではなく、「必要であればその役職になりますよ」というような感じです。

SREになった理由

今はSREという仕事をやらせてもらっています。その理由を改めて、自分の中で深堀りしてみました。

私は社会人1年目のころ、データセンターに出入りできる環境にいました。そのころはWindowsサーバーを使うサービスを扱っていたのですが、オペレーションチームが対応してくれるのはLinux系、BSD系のサーバーだけだったので、自分たちでサーバーの面倒を見ていたんですね。私は自宅用のサーバーも作っていたので、あまり抵抗感なくインフラ領域を触れることができました。

その後、AWSが出てきたときには「自分が持っているインフラの知識とバックエンドの知識が融合できるんじゃないか」と感じました。「バックエンドもインフラも両方やっていくぞ」と意気込んで、DevOpsをやってどんどん改善を進めていたら、いつの間にかSREになっていた、という流れです。

SREのやりがい

私は、顧客が身近にいるところで働くのが好きなのですが、SREの顧客は誰なのかというと社内のエンジニアになるのかな、と。こんなに顧客が身近にいるエンジニアは他にないと思います。整備されていない部分を整備していくと、開発チームの生産性が劇的に変わるのは楽しいですね。

「SREはルーティンワークが多そう」と思われがちですが、実際には未知の領域の仕事がすごく多いです。そこも魅力のひとつですね。SREがいらなくなるくらい自動化やトイル削減を進められたら理想的なのですが、技術革新は日々起きていて、やること、学ぶことが無限にあります。常に最新のデータを追いかけなければならずハードルが高い面もありますが、そこもやり甲斐につながっているなと思います。

特に、伸びている会社だと常に新しいことがやれる、「それやったことないですね」と仲間と日々ディスカッションしながら進めていける。そういったところがめちゃくちゃ楽しいですね。

私のキャリアの本質は「目の前のことにがむしゃらに取り組み、必要なスキルをどんどん身につけていった」というものだと思います。

SREは守りの領域だからこそ、やる人が少なかったのかなと感じています。SRE領域では会社の弱い部分が放置されがち。私はこれからも、会社の弱いところを強くしていくエンジニアとして活動していければと思っています。