トップ > はてな > はてなで働き始めてからほぼ5年になるので振り返ってみる

はてなで働き始めてからほぼ5年になるので振り返ってみる

はてな

そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。

NTT CS研 => 株式会社はてな

基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。

割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単独出せる価値よりもデータのライフサイクルを含めて考えるほうがより価値が出せると思っての転職だった。転職することを決めたときに何だかんだ言われることも多少あったような気もするが*1、転職してはてなでしばらく働いてもこの思いは強くなる一方なので、いい転職だったんだろうなと思ってる。文系から理転したときも、筑波を退学してNAISTに入学したときもそうだけど、他人が何言おうが自分が心の底から納得できることが大事なんだろうなって思う。他人は自分の人生に責任を取ってくれるわけじゃない。

もちろん、職種が変わったこともあって、以下にも書くように最初はキャッチアップがめちゃくちゃ大変だった...。

チーム開発への適応

入社前も研究職としてコードは書いていたし、gitでリポジトリ管理していたが、基本的にコードは一人で書いていた。チームメンバーと共同でタスクをやることも当然あったが、共通インターフェイスはテキストファイル(tsvやjson)をNFSファイル上に置いてやり取りする、というような世界観。論文は先輩からたくさん添削していただいたが、コード自体を見てもらうことは特になかった(いい悪いとかじゃなくてそういう職業)。

はてなに入社してからは日常がチーム開発になったが、入って一年くらいはめちゃくちゃ四苦八苦していた。一人で開発していたときよりリポジトリはでかいから全体像がそもそも見えてないし、コードリーディングする力も弱いし、今だったら絶対レビューしたくないような行数のPull Requestは送り付けてたし、全体の手順をうまく考えられていなかったので、時間かけて書いたコードもバンバン手戻り発生していた。ダメなエンジニアの典型例。

どうやって解決していったかを思い出すと、チームメンバーや技術グループのメンターの人にレビューで指摘してもらったり、こうしてみるといいではないかというアドバイスをもらいながら、少しずつマシになっていったかな...という感じ。環境に恵まれていたとしか言いようがなく、エンジニアとしての基礎体力をかなり上げてもらったなと思う。

インフラ苦手意識の克服

入社してからとにかくインフラ方面への苦手意識があった。障害が起きても何が起きているのか最初は全然分からなかったし(戦力以前の問題)、何か実現したいと思ったことがあってもインフラ方面だとそもそもどう動くといいのかも全然分からなかった。Webアプリケーションエンジニアとして働いていく上で、これはどう考えてもヤバイ。しかし、会社の本番環境はまあまあでかいし、試行錯誤するのも大変。

そこで、自分で全てを把握できる小さい砂場環境を作ることにした。これは(元も含む)同僚のid:a-knowさんやid:aerealさんが同じようなことを先にやられていたのに刺激されたり、当時メンターだったid:shiba_yu36さんにアドバイスもらったことがきっかけ。

この活動は完全にやって正解だった。サーバーが5xxを返そうがDBが吹き飛ぼうが、痛いのは自分だけなのでいくらでも失敗できる。構成も一発で正解に行き着く必要がなく、あえて遠回りして馴染がなかったコンポーネントで遊んでも誰にも迷惑をかけない。仕事と違って全てを一人でやる必要があるので*2、必然的に全体のアーキテクチャを考える経験もできる。締切があるわけでもないので、自分の好きなペースでできたのもよかった。

後述する異常検知の機能を作るときに、この経験は血肉となってとても役に立った。過去の自分と比べてインフラ方面への全体の理解度が上がったし、以前と比べるとSREやインフラ方面の人と話すときにビクビクすることがなくなった*3。

教師なし機械学習の本番環境での運用

Mackerelに「ロール内異常検知」という機能をPoCから実際の開発、運用、機能改善とほぼ全てのフェイズにメイン開発者として関われる機会に恵まれた。

これは今考えてもめちゃくちゃチャレンジングな内容で、アラートというセンシティブな形でユーザーが目にするものを機械学習でリアルタイムに、しかもそれを教師なし学習*4でやるというハードな内容。ユーザーはたくさんいるので誰にでも使えるモデルを事前に作り込むのは困難であり、ある種のAutoML的な側面もありさらに難易度も高かった。

PoCの段階では色んなモデルや競合ツールをたくさん試した。時系列ベースの異常検知は結構パラメータ設定が難しく、ある程度頑張ったくらいだと誤検知があまりも多く、これだと使われないだろうなという感触があった。機械学習に詳しくない人をペルソナにしているので、そもそもハイパラ設定をユーザーにさせたら負けくらいに思っておかないといけない(当時のプロダクトオーナーであるid:sugiyama88さんやid:Songmuさんからも要望があった)。

異常検知自体を扱うのがそもそも自分は初めてで、自分のアプローチは筋がいいのか全く自信がなかった。異常検知ナイトという東京のイベントに登壇してアドバイスをもらったり、そのイベントの帰りで偶然一緒になったPFNの人(工場のデータで異常検知をやっている人だったのでラッキーだった)とラーメン食べつつあれこれ教えてもらったりしたのもいい思い出。

異常検知自体はSaaSなどでも当たり前に提供される時代になってきていて、機械学習にかけれる開発人員工数を考えると「Mackerelで」異常検知ができることの価値って何だろうか...というのを大分悩んだ。異常検知の開発より少し前に機械学習サブ会という社内の技術的なグループを立ち上げていたが、機械学習というある程度専門性が必要な内容(今でいうMLOpsとか)を相談できる場所があることに大分救われていた。

悩みに悩んだ末、Mackerelの基本的な概念である「サービス」「ロール」に戻ってきた。同一のロール内であれば、サーバーの挙動はある程度統一的になるし、理想的なMackerelの利用をしてもらえればもらうほど予測もしやすくなる。Mackerelをいい感じに使ってもらえば、異常検知も勝手にいい具合になることが期待できる。すごく単純な仕組みではあるが「Mackerelで」異常検知ができることの価値が自分の中でも腑に落ちた。実装面でも混合ガウスモデルという非常に枯れた*5モデルで実装することができた。

ベイズ的な確率的生成モデルであるということも地味に効いた。異常検知でサーバーのアラートを出す際に「どのメトリックが特におかしいかも知りたい」という要望に対して、周辺確率を使って一つのモデルでアラートの要因になったメトリックも提示できる。「このくらいのメトリックの揺れはアラートして欲しくない」という要望に対して、インフラ監視の職人的な知恵を生成モデルの事前分布として与えることができる。前職は機械学習の研究者だったが、その知識や知見を実サービスに生かす仕事がようやくできたかなと思う。

ロール内異常検知を開発する頃にはようやく人並みに開発やインフラのことを見れるようになっていたのも大きかった。はてなに転職してきていきなりこれを任されていたら、絶対爆死していたに違いない...。

データ基盤とCustomer Reliability Engineerへの挑戦

ロール内異常検知が一段落した頃、次はどうするかなと悩んでいた。ちょうどその頃、同僚であるCREのid:missasanさんが「カスタマーサクセスを今後より進めるために、データ分析が必要になってくる」という話を社内勉強会でしているのを聞いた。自分はアプリケーションエンジニアをやっていたからドメイン知識は頭の中にあるし、データ分析は多少経験あるから多少の力になれるかも、ということで一緒にカスタマーサクセスのためのデータ分析をやっている。

異常検知に引き続き、初めはデータ基盤も何も分からない状態だった(この状態でよく突っ込んでいったな自分...とは思う)。何から始めるといいか分からないことは詳しい人に聞きに行こうということであれこれ動いた。同僚(だけど東京)のid:polamjagくんに根掘り葉掘り聞いて回ったり、東京のイベントの翌日に(当時Rettyで)データ基盤をバシバシやっていたid:tkngueさんにランチでお話を聞いたり、関西の機械学習のイベント関連で仲良くなったリブセンスのid:yubessyさんにオフィスランチでお話を聞いたりして、とにかくどうやるとデータ基盤がうまく回りそうか自分の頭の中で多少なりとも描ける状態を作るようにした。データ基盤は技術の問題だけではなく文化やコミュニケーションの問題も考える必要があり、オンラインではなかなか聞けない部分も大きく、対面であれこれ知見を聞けたのは本当にありがたかった。

最初は「SaaSのKPIってそもそもどう定義すればいいんだっけ...」というところからスタートした。何とか定義をしたのはいいものの「今だとそれを出せるデータがないから業務フローという名のスプレッドシートパイプラインを整備しましょうか...」というデータ整備も一緒に進めた。あちこち未整備かつ全容を把握している人が誰もいないということもあり、大分大変だった...。

CREのサポートをしていたら、いつの間にか自分もCREになっていて、人生面白いなって思った。「歩く信頼性」ことid:a-knowさんにCREに誘ってもらったのは嬉しかったし、プロダクトサクセスの仕事を一緒にやらせてもらって「カスタマーサクセスとは何なのか」を日々背中で教えてもらっている。

id:missasanさんは自分の割と苦手な業務フローの整備や他職種とのコミュニケーションがすごく上手で、一方自分はMackerelのドメイン知識(DBのスキーマとかデータどこ見ればいいとか)やSQLはある程度できた。お互いの得意と不得意をうまく補完しながら、二人三脚で走れたかなと思う。一緒に走ったことでid:missasanさんは今ではSQLバリバリ書けるし、自分も業務フローの整備や他職種とのコミュニケーションが多少うまくなった(ような気がする)ので、一緒に仕事できてとてもよかった。

事業のKPI以外の普段のCREの活動でもデータを見たい場面が多々あるということで、BigQueryを中心としたデータ基盤の構築も行なった。データ転送するだけではデータ分析者にとって使いやすいものではないので、メタデータを中心としたデータウェアハウスの整備を行なった。id:missasanさんと一緒にデータ分析をしたおかげで、どういったところが分析のときに困りやすいか勘所ができていたし、フィードバックをもらいながら仕事をできたので大分仕事がしやすかった。

また、データ基盤の開発者も主に自分一人だったので、壊れにくいデータ基盤になるような仕組みを整備していった。ある程度データ基盤も整備できてきた後は、よりチーム内外でデータ活用をより進めるための活動を始めた。

特によかったなと思う活動は「突撃! 隣のダッシュボード」とSQLレクチャー会。需要サイドの企画系や営業系の人と供給サイドのエンジニアが同じ場に集まって、データ活用を進めていくためにどうあるといいか(To-Be)を考える機会を持つことができた。機械学習サブ会はある程度うまくいったがどうしてもエンジニア内で閉じてしまいがちなところがあったが、「突撃! 隣のダッシュボード」ではむしろエンジニアのほうがマイナー職種と思えるくらい色んな人を巻き込んで活動できたのは自分の中でとても大きな経験になった。ちょっと矛盾しているかもしれないけど、自分はコミュニケーション能力は低いが、人を巻き込んで仕事をする活動が割と好きなのかもしれない*6。

今後はデータエンジニアリング

冒頭にも書いたけど、NTT CS研から転職したときに思っていた「(アルゴリズム以外を含めて)データを丸っと見れるようになりたい」というのは今も変わっていない。データは生成 / 蓄積 / 活用というライフサイクルがぐるぐる回ることで価値が出るものと思っている。その中でデータの蓄積や活用へのサポートを特にやりたいと思っているので、今後はしばらくデータエンジニアリングを頑張っていきたい。

*1:大抵の人は応援してくれました。ありがとう

*2:仕事だと「ここは得意な人にお任せしよう」ができてしまう

*3:最初は「何やってんだこいつ...」とあきれられるんじゃないかと思ってビクビクしていた気がする。はてなは心理的安全性はめっちゃ高い職場で、一度もそんなことを言われたことはないが...

*4:障害は頻発するものではなく、障害の定義もユーザーによって異なるため教師あり学習でやるのは問題設定として難しい

*5:機械学習に詳しいメンバーが多くはないため、枯れていることや仕組みが直感的に分かりやすいことは重要であった

*6:このままだと巻き込まれる側が迷惑なので、もうちょっとコミュニケーション能力は上げていきたいとは思ってる...