こんにちは、エンジニアリングマネージャーの 
id:onk です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの 
id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する 
id:y_uuki さんこと、坪内佑樹さんです。
2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSREとして携わりつつ、採用や技術情報発信などにおいてもご活躍をいただきました。
2018年にはてなを卒業後、2019年2月にさくらインターネット研究所に研究員としてご入社、現在は京都大学大学院情報学研究科博士候補生、株式会社Topotal テクノロジーアドバイザーなど、幅広く活躍するid:y_uukiさんに、研究員・研究者としての活動やエンジニアから研究員へのキャリアの変遷、はてなを離れてみての印象など、いろいろお話を伺いました。
坪内佑樹さん（
2013年12月-2018年12月 はてな在籍
site: https://yuuk.io
X: https://twitter.com/yuuk1t
Blog: https://blog.yuuk.io
- さくらインターネットの研究者として、SREをテーマに研究
- 研究テーマの主軸は「システム監視」
- SRE NEXT での発表とそれに関連するSRE論文・AlOpsについて
- 技芸から工学へ。エンジニアから研究者へ。
- Embedded SREとは？
- チーム内での孤独を解消するには？
- Topotalでテクノロジーアドバイザーとして活動
- y_uuki wareの話
- はてなで一番印象深かった仕事
- OpenTelemetryやオブザーバビリティの話
さくらインターネットの研究者として、SREをテーマに研究
id:onk（以下「」） 今回のゲストは、さくらインターネット研究所のy_uukiさんです。今日はよろしくお願いします。y_uukiさんは2011年にはてなインターンに参加、その後、システムプラットフォーム部でのアルバイトを経て、ご入社でしたね。
id:y_uuki（以下「」）そうですね。2013年に新卒でWebオペレーションエンジニアとして入社しました。当時はそういう職種名でしたが、のちにSREという名称に変わりました。はてなで5年、その後、さくらインターネット研究所に転職して5年です。
id:y_uuki こと、さくらインターネットの坪内佑樹さん まずは研究所のお話から聞かせてください。働き方というか、どういう風に過ごされているのでしょう。
さくらインターネットの事業部とは組織的にも独立した組織内研究所で、SREの研究をしています。
未来の選択肢を増やす研究所 | さくらインターネット
さくらインターネット研究所 – SAKURA Internet Research Center
事業側から具体的な要求があるというわけではなく、研究員自身がやりたいと思える研究を見つけてやっているという感じです。自由な感じに聞こえますが、実は何でもありの枠組みだとやることって結構難しいんですよね。
自分の研究の行く先を自分で決めるんですね。
企業から研究で取り組むべきことを、ある程度与えられているという研究者の方もいますが、研究所の場合は研究員が自分で決めます。会社や大学などによって全然違いますね。
枠組みのない中で自分の研究の行く先を決めていく研究者の思考は、エンジニアというよりプロダクトオーナーに似てるかもしれません。僕は研究者として、博士の学位みたいなものが一つの能力の証になると考えて、博士課程を取ることをマイルストーンにして研究に取り組んでいます。自分の研究を進めていっても、すぐに事業側に反映とかはされないし、結局何も反映されなくてボツになる研究もあるかもしれないけれど、そこも含めて認めてもらっています。
2023年3月に博士課程（京都大学 大学院情報学研究科 知能情報学専攻 メディア応用講座ネットワークメディア分野）で3年の標準年限を終えて、研究指導認定退学をして、博士号取得に向けた研究を続けています。博士課程の研究とさくらインターネット研究所での研究は扱うものが一緒なので、特に分けて考えていません。博士課程では、月に一度、先生とのMTGで研究の進捗を話すくらいでした。あとはひとりで研究を進めている日々です。
研究テーマの主軸は「システム監視」
研究の具体的な内容について聞かせてください。
研究テーマの主軸は、はてな時代もMackerelのSREとして仕事で取り扱ってきたシステム監視にしました。
博士課程での研究まとめ 2023年1月版 / Summary of my research in the PhD course - Speaker Deck
システム監視には、大きく3つやることがあります。1つは計装（Instrumentation）、2つ目がデータを取得して保存する、3つ目にそれらのデータを解析することですね。それらの負荷に着目しています。
例えば計装するとなると、データを取るための処理に負荷がかかります。たくさんデータが取れたとしても、それをデータベースに保存するのも大変です。データがたくさんあっても、エンジニアは見きれないですし、障害が発生した際のデータの絞り込みも困難になります。いきなり全部機械学習のアルゴリズムに押し込むと、莫大な時間がかかったりします。
システム監視のこれら3つのそれぞれの負荷課題について解決するような研究に取り組んできて、ちょうど今月一段落したところです。最後の研究についてはつい最近、国際ジャーナル「IEEE Access」に採録されました。
この論文では、障害発生時のデータを解析する負荷の課題にはじめて着目しました。その課題に対して、障害に関連するメトリクスのみを教師なし機械学習を用いて抽出することにより、負荷を下げるというものです。
ちょうどMackerelはオブザーバビリティの Primary Signals の中で、メトリクスに特化しているということもあって、データの負荷の価値と向き合っています。
メトリクスってトレースとログから生成できるじゃないですか。生成可能なメトリクスとして保存する価値って何だろうと考えたときに、スケーラビリティ、データの量が大きくなりすぎないし、負荷が小さいので、保存しやすい。保存した後にそれを集計するのも数値になっているから簡単です。
可視化するのも数値なので、数値から可視化ダッシュボードを考えるのは割と容易で、その辺のイージーさや量的なことが効くんだろうなと考えながら、僕らもMackerelを開発している感じです。
そうですよね。自分が一番得意なメトリクスで絞り込むというのを発展させて、ログとかトレースをいかに絞り込むかとか、計装のところでうまく省くみたいな手法も論文で書いています。今後はそういう負荷に機械学習などを活用して、どう上手くさばくといいかといったようなことも博士論文を書いた後にやろうかと考えています。
SRE NEXT での発表とそれに関連するSRE論文・AlOpsについて
その研究過程で考えたこととかわかったことを、「SRE NEXT」などで発表していますよね。
AIOps研究録―SREのための システム障害の自動原因診断 / SRE NEXT 2022 - Speaker Deck
全部はできてないけど、なるべく発表するようにしています。
ここ2～3年は、自分がそれ以前にやっていたSREやソフトウェアエンジニアリングと、新しく取り組んでいる機械学習の知識体系にかなり乖離があるため、SREのコミュニティで機械学習のアルゴリズムの話をすることに苦戦していますね。ギャップがあるので、アルゴリズムの話は抑えつつ、コミュニティにはできるだけ出していきたいと思っています。
でも、ペパボ研究所さんのなめらかなシステムみたいに、SREと機械学習はもっと近くにいるべきだと研究している人たちもいらっしゃいますよね。
ペパボ研究所さんは以前は SREと機械学習に関する研究にも取り組まれていましたね。日本ではあまり印象にないですね。居たら僕にぜひ紹介してください。世界レベルで言えば、Datadog社や中国の大学の研究室とかがあると思いますが。
なるほど。じゃあy_uukiさんの研究成果などを取り入れながら、リアルワールドで試されているところというのは？
まだないですね。さくらの中でもできてないです。それができていたら、すごい大成功だと思います。
自分がはてなでエンジニアをやっていたころは、自分で作ったものをプロダクトで試すようなことをやってみたりしたこともありましたけど...
でも最近、メトリクスを絞り込むと結構応用が効くので、社内で「こういうの興味ありますか」と、ぼちぼち提案しています。まあ、社内に限らずですけど。
SRE NEXTでは、基調講演とセッションに登壇されていますね。2020年に登壇された基調講演もすごく良かったです。ブログと合わせて、SREといえば、y_uukiさんという印象です。
ありがとうございます。僕的には、基調講演やり直したいですけども（笑）。ちょっと自分が研究している内容に寄せすぎたなと思って。
そこからは論文紹介もされていますね。
論文は何か必ず新しいことが書いてあるので、読んでいて面白いですね。僕がエンジニアだったときに取り入れてた情報は、ある程度実績があるようなものが多かったですが、論文はどこにもないはずのアイデアを書いているというおもしろさがあります。
過去の論文であっても同じ内容を新しくは書けないので、その時点では絶対新しいこと、新しく考えていることが書いてある。みんな新しいこと考えてるなーと感じるこの感覚は面白いなと思っています。
でも、論文ってエンジニア目線だと当然ながらなかなかすぐ実務につながることにはらないので、少しでも紹介したいというようなモチベーションでやっています。
技芸から工学へ。エンジニアから研究者へ。
もう完全に技芸の世界から工学の世界になってしまっているお話を伺っていますけど、この「技芸から工学へ」という言葉をy_uukiさんが使っていたのがすごく好きで。
そういえば、その言葉は最近そんなに使ってなかったので久々に思い出しました。
でも、だいぶアドホック、ちょっと言い方を変えると、カウボーイ開発的なものから、体系な考え方にソフトウェア系の人たちもなってきていると思います。Four Keysとかもありますけど、Leanとdevopsの科学とか論文がベースになっているような知識がみんなのものになって、それを当たり前に使っているという感じはしますね。
もう今ではそれが普通になっていますね。でも技芸から工学へという言葉が出たおかげで、僕はSREとは何かというのが考えやすくなったんですよ。
今までは技芸を持って勘と経験で、いいものにする、どんどん上げていくのが目標だと思っていたんだけど、コントロールする、バランスを取るものという考え方に変えられるし、そこにはちゃんと、元になる数字がある。これを見ていくんだみたいなのは、すごいわかりやすくて良かったです。
SREがエンジニアリングっぽいことをサービスレベルで定量的に定義し、それに対して客観的にアクションを進めていくのが、すごく工学的だという話がありました。そういう論文的な考え方は、工学的な、客観的なアプローチですよね。
それをやっていきたいと思って、はてなでのいわゆるインフラエンジニアの名前を、当時y_uukiさんがWebオペレーションエンジニアからSREに変えていった。実際はてなでは、そこから徐々にSRE寄りになっていったけど、職種を変えようとしたきっかけってなんだったんですか？
結局変えたはいいけど、僕がそれから何ヶ月かではてな辞めちゃったんですよね。考え方だけはブログで残してたんですけど。
きっかけというかはてなに対して長らく何で困ってるのかな？と思っていたことの一つが、はてなって、当時はすごく高い信頼性を要求されるサービスじゃないものが多かったことなんですね。今はBtoBのサービスも増えていて、僕がいたときよりは高いレベルになっているんですけど、当時はユーザーの信頼性よりも優先することがあるなと思っていました。
お金や命にはあまり関わらない、無料で使える個人向けのUGCサービスが中心でしたからね。
だから、SREってはてなにフィットするじゃんと考えてたんですよね。
当時のはてなは、高い信頼性で勝負しようという会社じゃないというのもあるし、SREの中ではオペレーションのミスした人を責めないというBlamelessの考え方がありますけど、それも最初からあるし、相性が良いですよね。
あと、高度なサービスSLO管理とかはしなかったけど、ふわっとした数値の計測とかはやりつつあったのでやってみて、インフラのチームだけでは、この数字だったらまだ攻めてよさそうみたいな会話をしてたんですよ。
本当はそれを全体に広げる必要があるんですけど、インフラチーム中ではもう既に割とSREの原型みたいな会話ができたんで、これからSREもやっていこうと話していて、
id:wtatsuruさん（当時のインフラチーム責任者 / 現在Mackerelプロデューサー）に言って、SREに職種名を変えてもらいました。
職種は変わったんですが、そこから1年ちょっとぐらいは、はてなの中でもSREを単なるインフラエンジニアの言い換えだと思っている人もいたんですよね。その間に「SREとは何なのか」という資料を社内で作って、本部長とかマネージャーとか相手に説明して回ったことで、職種の目標が変わっていることがやっと広まったみたいな感じでした。
それは、id:wtatsuruさんとか
id:masayoshiさん（チーフエンジニア）がすごい頑張ってやってくれて、僕は考え方だけ広めてたみたいな。
でも、何度もSREとは何かというブログを書いてくれたので、それが参照しやすくて本当に良かった。
その頃はSREに興味を持った人たちも、「良さそうなんだが、これをどういうふうに自分たちが捉えたらいいのか」ってことがわかってなかったんですよね。
インフラエンジニアからSREの言い換え、正確には言い換えではないんだけど、どう説明しようかという課題があったと思います。今はもうクリアされてきてますけど。
Embedded SREとは？
SREをやるには、組織的な構造変化みたいなのも必要です。SREチームが全部リライアビリティやりますだと、基本的にはうまくいかないので、リライアビリティもサービスの機能の一つと捉える。そのサービスの中で、ライフサイクル全体を組織的にもやりやすい形でSREをEmbedded SREという形で派遣する。
その中で、同じようなチーム内だったらいいんですけど、そういう信頼性が高い・低いみたいな議論が早くできる部署ばっかりじゃないので、なかなかコンテキストがとれなかったりもする。エンジニアリング組織をどうしようという話も同時に進んでいたので、SREがうまくそこにフィットして、今の体制になっているのかなという感じがしますね。
はてなもそうですが、世の中的にも、Embedded SREとPlatform SREという分け方をしているところが多くなってきましたね。Embedded SREをちゃんと作っておくとチームの中でうまく回せる、改善するなというのが僕らも思っていることです。
SRE座談会 - 採用情報 - 株式会社はてな
はてな「Mackerel」のSREに学ぶ、開発パフォーマンスと信頼性のベストバランスとは？【デブサミ2021夏】 (1/2)|CodeZine（コードジン）
最初はシスプラ（インフラチーム）にSREが全員いたので、そうではなくてプロダクト開発チームに1人ずつというふうに組織を変えてから、うまく根づき出したなとは思います。
退職前に、派遣したいけど全チームには無理だとか言ってやっていたんですけど、はてなって、業界ではEmbedded SREをだいぶ早くやっていたんじゃないですか？
僕の前職やほかのWeb系、ソーシャルゲームの会社などのほうがもっと早かったイメージです。あとははてなでは割とDevとOpsが分断されていたところから始まっているので、これをDevOpsにしようという段階を踏んだ。昔は「DevOpsエンジニア」として採用していた頃もありました。
ありましたねー。いまとなってはアンチパターンだけど（笑）
だけど、Embedded SREのようにチームの中に入り込んで、ちゃんとDevOpsを自分たちでチームの中で回していくんだみたいなのは、DevOpsが分断されていたからこそ、考えていった内容かもしれません。
そうですね。DevOpsも解釈がありすぎて... その時の感覚だけど、できてるのかな？って思ってました。
はてなってインフラチームもあるけど、インフラチームがかなりサービスチームの方に寄ってインフラ全部やりますって、一緒にやってるという感じでしたよね。ただサービス的にはサービスや信頼性に明確に責任持ってないというような状況で、インフラの人はなんか浮いていて、宙ぶらりんな状態。DevOpsの資料を見ても、これがDevOpsできている状態なのかはわからない感じでした。
何かサービスをやってるからできると思ったんですけど、サービス主体でDevOpsのサイクルを全部責任持ってやるというのが本当のDevOpsだということですよね。当時はわからなかったです。
あの頃のはてなだと、基盤タスクいわゆるインフラの作業は全部お任せしていて、サービス開発チームに寄っていると言ってもスクラムの中からは外れていた。いつまでにやらなければいけない目標ともあまり考えてなかった感じで、丸投げ状態だったかもしれません。
そうなんですよ。でも、それが褒められたところでもあったんですよね。サービス開発チームからすると、全部任せたらやってくれるし、楽もできました。それが少なくとも僕が入社したぐらいだとアイデンティティというか、自分たちの良さだよねみたいな話をしていたけど、だんだんそうではないという感じや文化が、僕が入社して3～4年でできたみたいな感じでした。
チーム内での孤独を解消するには？
最近、Embedded SREも難しいなと思っていて。チームに1人しか置けないことが多い。インフラ系のエンジニアって、チームが10人いたら1人ぐらいがたぶんバランスいいと思ってるんですよね。
はてなでは20人の開発チームほど大きいケースはほぼなくて、10人ぐらいの開発チームになるのが普通ですが、そうなると1人しかいないので、1人で全部決めなきゃいけない。従ってインフラ領域のテックリードができる人しか、Embedded SREになれないみたいな問題があります。
やっぱり発展すると次の段階の課題が見つかってしまいますよね。
はてなに入社して、最初Mackerelを担当することになって、新卒なのでプロダクションシステムの運用経験はないけど、これ全部自分で責任を負って決めるみたいな感じでしたね。
インフラエンジニアの育成とか、その孤独みたいなのは、組織としてどう改善していこうかなというのを今試行錯誤してるところですね。
当時、Embedded SREのまだ名前が広まってなかったですけど、5年前にそういうことが起きるよねって話はしていたんですよね。id:masayoshiさん がそういうのを早く気づくので、たぶん孤立するからうまくサブ会（※ はてな内で特定のテーマに興味を持ったメンバーが、互いに学びを深め、社内に共有していくための集まり）で吸収できるかとかは考えてて、やっぱりそういう問題を起きたなって思いましたね。
はい。徐々に組織設計をして、SREチームで当たるように取り組んできたけど、まだ箱にはなっていないので、そういう問題が起きつつあるところです。組織図上の箱を作って、プロダクト開発チームに所属しているけどSREチームにも所属しているみたいな。やっぱりマトリックスの状況を作っていかないと、厳しいんじゃないかな。
はてなの人とはよく喋りますけど、こういう現場の話を聞いて、それを研究者としてみると、なんか自分はDevOpsから外れたところでやってるなという感じがあって。そこにリサーチャーはどうしていくんだろうなとか思ったりしますね。
OpenAI社とかはうまくやってるって、少し前のブログで読みました。プロダクトチームの機能に、プロダクト、デザイン、エンジニアリングだけでなく、リサーチ（研究）が組み込まれている形ですね。
なるほど、チームに入っているみたいな感じなんですか。
そうですね。研究を事業に活かすための組織をどう設計するかはさくらの研究所ではまだこれからです。
Topotalでテクノロジーアドバイザーとして活動
さくらさんでは仕事としても完全に分断されていて、事業の方には関わってないという話だったんですけど、副業でテクノロジーアドバイザーをされているTopotalさんの話も聞こうかな。どういう関わりをされてるんですか。
基本的に週1～2回ミーティングで、一応アドバイザーという肩書きで、アドバイスをするということになっています。基本的に一緒にディスカッションするという感じですね。
Topotalには二つの事業があって、一つはインシデントマネメントサービスのSaaSである「Waroom」の開発、もう一つはSRE as a Serviceという名前なんですけど、開発から運用の過程で生じる課題をソフトウェアエンジニアリングで解決するサービスです。Embedded SREをサービス化したみたいな感じで、優れたエンジニアと一緒にその会社に入って、そこでSREをうまく回していくのをサポートするシステムを動かすコンサルです。
単なるコンサルじゃなくて、手も動かす。どちらのサービスでもアドバイスというかディスカッションさせてもらっているという感じですね。
研究しながら、そういうリアルワールドで起こっている課題や現場を両方見ているからか、y_uukiさんからはバランスよく、両方の話題がブログに書かれるなみたいなところがあってすごくいいです。
onkさんにそう言ってもらえるのは嬉しいですね。
SREの「研究」といっても、結局そこはリアルワードとは絶対切り離せないので、ライフサイクルが遅いというのはあるけど。自分がやったことが即反映されるかもっと長くかかるのか。自分がやったこと、副次的成果、ソフトウェアでなくても考え方みたいなものがプロダクションに入る。そんな感じでリアルワードとは接点があるので、そこがなくなるとやばいなって常々思っていますね。
Topotalさんには、そういうことを考えていた時にちょうど誘ってもらったので、やるようにしました。
よりよい研究のためってのもあるんですけど... 研究って基本孤独だと思うことがあるんですね。
博士号取得の図ってあるじゃないですか。
人類の英知の先端のとこまで行って、そこを押し続けるような研究をしている人って、孤独そうじゃないですか（笑）。端っこにいるし。そこの端っこの人類の英知とギリギリのところのやつを、カジュアルに喋って伝わる人ってなかなかいない。
特に僕が研究しているAIOpsについてはやっぱり機械学習の知識が入ってくるので、なかなか難しい。機械学習の人にもSREの人にもしゃべるのは難しいというのはあります。
ただ僕は幸いエンジニアを5年はてなでやらせてもらったという経験があるので、その経験を使うと、現場の話はまだ何とかついていける。そこで何とか接点を持って孤独を回避しているというのはありますね。
なるほど。孤独があるのか、僕はあの図を社内でも時々引用していて、サブ会のミッションというかたちで使っているんですよね。どこかで話したことあるかな。
Backyard Hatena で聞きました。
はてなのポッドキャスト Backyard Hatena #7 - id:onk に聞くエンジニア組織とアウトプットを配信中です - Hatena Developer Blog
はてなの常識に対して、新しい目線をとにかく持ち込んで、円を広げてくれというのを期待してるよという話をしていました。
円というのは、はてなの英知ですよね。めっちゃいいですね。
専門性のある集団であるサブ会の目的は、専門性を獲得していくことにもあると思うので、専門性をちゃんと広げて、はてなの共有知を広げていくというのが、ミッションとしてあるのかなみたいなことを考えていました。
いいですね、いい取り組みだと思います。
y_uuki wareの話
y_uuki ware の話をしよう！
そんな掘り下げがいありますか？（笑）
※ y_uukiウェアとは：
github.com/yuuki 以下にある、droot, , gokc, grabeni, lstIE といったソフトウェアたち
はてなにいるときは、何か息をするように個人アカウントに何かを作って、社内で運用してみたいと持ち込むというのを、ずっとやっていましたよね。
そんなやってましたかね。やれたのはほんのごく一部だという意識です。たぶん比べているのが カヤックの@fujiwaraさんとかだからそう思うのかもしれません。
僕がこの業界に入ったのって2011年ぐらいなので、00年代のWebのハッカー気質みたいなものの名残を受けている世代なんです。やっぱりハッカーはOSSでサクッと、自分が思うツールなり何なりを書いて、プロジェクトで即入って何かクールにやるみたいなのがあると思うんですけど、それには憧れていたというのがあります。
もう一つはSREという言葉がなかったときでも、インフラエンジニアはコードを書かないと死ぬみたいなのがあったと思うけど、コードを書くのは面白いですし、僕はそのハードウェアが好きというより、ソフトウェアで何か複雑なシステムをつくったり、コントロールするというのが好きなタイプ。業務時間ではコードを書く時間を取るのは難しかったですね。そこでなんとかがんばってやったのがこれです。
個人ツールだけど、y_uuki wareは社内のEC2セットアップスクリプトに組み込まれていて、EC2を立てたら、そこにバイナリが入っている状況になっていましたよね。
そのときは自分で入れるだけだから、すぐ入れてましたね。その辺のプロダクションのデータに触れることができたら、今ならデータをあれこれ送って機械学習でかなり遊ぶだろうな。
さくらさんのデータには触れてないんですか？
触れてないですね。データって、原油みたいなもので、原油が日本の家庭の石油ストーブで使われるまでには長い道のりがある。原石みたいなものがあるけど、それを使いやすくするための道のりを考えると、「どうしよっかなー」みたいな気持ちになって。
テキストデータをLLMに食わせて、障害のデータを出したりもしているけど、利用できるようになるまでにはまだまだという感じだと思います。
そこに日和らずに入っていくこともできますけど、博士課程を理由にやれてないですね。仲のいいさくらの人たちとそういう話をすることはあります。
最近は、プロダクションに関わってないから、コードもあまり書いていないんですか？
研究用のコード、実験用のコードは書いてます。昔はコードを書く方がいいって思っていたんですが、今は作るより考える方が多くなっています。
作るのももちろんいいんですけど、元々僕はOSSってやってくというより、ブログでやってくような感じだったじゃないですか。ブログがより発展して、論文になったみたいな感じで。書くというのは基本的考えていることだと思うので、考える機会は結構好きですね。
じゃあ考えて、その考え方を人に伝えるというのをメインでやっていると。
新しいアイディアを考えてるみたいな感じですね。
SaaSは事業を世の中に提案するということだと思ってて。論文も情報系の論文って、必ず「In this paper, we propose ...」って、「我々はこれを提案する」という内容が書いてありますよね。既存のものに対して何か新しいものを提案する。考えて提案するみたいのが好きなんです。
そこまでいく過程には、既存のものを知るためにたくさんの知識を得る必要があるので、それをコミュニティに伝えていくのを同時にやっているという感じです。
なるほど。y_uukiさんのブログといえば、当時は書いたら400ブクマみたいな。そんな感じでしたね。
狙ってましたからねぇ（笑）
当時はブログ書いたら、読まれたいと思っていました。承認欲求は隠していないタイプです。ただ、読まれることだけを考えてると、だんだん自分にとって面白くなくなってくるんですよね。自分が読んで、面白いって思えるやつを書きたい。自分が読んで面白いのは、今で言うと論文っぽいかんじです。
書いたものが多くの方に読まれると、イベントとかでお会いした人から感想をもらえたりして嬉しかったので、モチベーションになってましたね。読まれた数値と自分の書きたい内容というのを何とか両立するために、あれこれはてなブックマークをひたすら検索しまくって、このエントリーはなぜこんなにブックマークついてるのかというのを研究したり、一番読まれやすい投稿時間は何時かとかを試したりしてました。
すごい（笑） はてな社内では、書いたエントリーに一番ブックマークがついた人は特上寿司が食べれる制度がありましたが、y_uukiさんは3か月連続特上寿司を獲得していた覚えがあります。
はてなで一番印象深かった仕事
id:y_uukiさん はてなの思い出話で、はてなの仕事で一番印象深かった仕事の話をお願いします。
やっぱり「Mackerel」の時系列データベースで、社内のコードネーム「Diamond」の開発がやっぱ一番印象深いですね。
僕がほぼフルコミットしたのは1年ぐらいですが、5年居た間の1年なので、それなりに思い入れがあります。プロジェクトを任されて、終わらせるというのを経験したのもそれが初めてでした。プロジェクトリーダーみたいな感じだったんですけど、初めてそういうリーダー経験みたいな面でも思い出深いって感じですね。
Diamondはブログでもまとめられてるし、論文にもなってますね。
時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
時系列データベースの論文を書いた - ゆううきブログ
はい。たいていのことは書いちゃいましたけど、書いてないところで頑張っていたのは、プロジェクト管理の苦労やプレッシャーですかね。
当時のはてなでは、エンジニアがリードしていたプロジェクトって見積もりを外して遅れてるケースが多かった印象なんです。
プロデューサーが集まる会議の議事録が社内に公開されているので、それを読んでいたら、「Mackerelの移行はオンスケで」って書いてあって、プレッシャーを感じてやっていたのを覚えてます。
当時Mackerelチームにいた 
id:daiksyさんとかから、見積もりの仕方とか教わって、参考になる本とかも教わり、ストーリーポイントをつけて見積もって、タスクもなるべく細かく出してました。
アジャイル開発でもそこまで細かくやらないというのがセオリーだった気がするんですが、そのときは全部細かくなるべく出して、バッファの計算もその本に書いてあるようなのを参考にして計算して、進捗管理もストーリーポイントのバーンレートを引いて、がっちりやってましたね。
ストーリーポイントをずっと思い浮かべながら、その一方でアーキテクチャの設計もしていた。他に、特にコストに対する不安が結構ありました。
事前に試算したコストシートとにらめっこしていて、それを当時のAWSのSAの方に見せたら、「ここまでやってる人初めて見ました」って言われました。
コンポーネントのネットワークの転送量を細かく出したり、いろいろやりましたね。時系列データをどの単位でまとめるか、DynamoDBではこのサイズでまとめるか、もうちょっと小さくするなど、最適化ポイントを真剣に検討していました。
プレッシャーもありましたけど、やっぱり技術とかに結構深く向き合っていればよかったというのがあって、そこが面白かったですね。
そのあたりはブログには書けてない話ですけど、楽しかったです。
OpenTelemetryやオブザーバビリティの話
OpenTelemetryになってくると、どんなオブザーバビリティバックエンドでも同じデータを受け取れるようになってしまった。そうするとそのインフラコストが競争力に繋がるので、保存のうまさをやっていかなきゃいけないなというのが「Mackerel」の課題なんですよね。
ですよね。たぶん僕の当時の課題感といまは変わってて、当時はEmbedded SREとかがいなかったんですよね。そうすると、運用できるのかという問題があって。基本マネージャーサービスベースのアーキテクチャにしたんですけど、それを分散DBとか使ってやるかとか。
なんなら自分でミドルウェア書いてみたいな話もあるんですけど、ミドルウェア書く時間はないし、そんな自作のオレオレ分散DBで運用できんのみたいな話もあって、運用できるのかというのが結構強くなっていました。
今も当然それがあると思うんですけど、コストで勝負というよりも、そもそもデータの保存期間でもDatadogに圧倒的に負けているというような状況でした。コストはすごいシビアではなくて、何ができるかというのと、Datadogとかと勝負できるかという。
いまはコストで勝負すると難しいのでは？
Honeycombも、S3は使ってるけど他はたぶん自作でデータフォーマットもオリジナル、うまくデータを圧縮して保存できるようにしてると思うので、例えばこういうアーキテクチャになるようなというイメージです(笑)。
そこは研究者として真面目に考えてみてもいいかなって思っているところもあります。オブザーバビリティデータって、全体的にいらないデータがいっぱいあるような気がしていて。
一生参照されないようなのが無限にあるかんじなので、そもそも最初から取らないようにするみたいなのが、そろそろいるんじゃないかなって考えています。
それでうまくできたらすごい競争力になると思うんですよ。保存しなくていい。お金かかるし。ミドルウェアのゴリゴリシステムソフトウェア勝負って、世界レベルで戦おうとするとなかなか大変だと思うんですよね。
一時期そういう研究も面白いと思っていたけど、世界に強い人が多すぎるなーと。
あとデータベースとかって、既存の知識体系がすごいあるので、トランザクションや分散アルゴリズムがあるので、これやっていけるのかなって。SREを対象にした方が、もっと全体を扱った人間的な要素も含まれるので、その方が多様な要素を扱う方がたぶん向いているみたいな感じでやってますけど。
SaaSでオブザーバビリティバックエンドやるのを、もっとうまく安くできないかなみたいなことを思っています。入口でサンプリングせずに全部送ってしまうと、ものすごい金額かかるじゃないですか。
でも1日経ったらだいぶ間引かれるとか、1週間1か月だったらどんどん間引かれるというので、全体のコストを安くするというSaaSはあんまりないなみたいな。
ある意味、その考え方は時系列データベースの基本のRRDtoolですよね。
そういうのを細かくコントロールさせてくれるSaaSは、僕自身が欲しいので、Mackerelもそういうのもあるのかなって考えたりします。
そうですよね。あとデプロイまでの頻度はどんどん速くなっていて、システムの状態はどんどん変わっているわけで。1年前のデータがそんなに役に立つのかみたいな話は出てくるはずです。
Slackがオブザーバビリティのデータベースに関する論文を出していましたね。この論文によると、メトリクスについては直近30日間しか保存していないようです。ログは７日間、トレースは14日間。Slackって、おそらく変更頻度が早いので、そんな古いデータを見ないということなんでしょう。
なるほど。面白いですね。
こういう話は無限にできますね（笑）
最後に、今のはてなを外から見て、感じることなどがあれば、ぜひ聞かせてください。
たぶん内部的な労力の割き方みたいなのは変わっていると思うんですけど、事業ポートフォリオは僕がいたころのままですし、基本的にはさほど変わってないのかなという印象ですかね。
たぶん社内のインフラ面は相当とか変わっているのではないかと。
あとソフトウェアのバージョンアップとかも、Mackerelとかは、何ヶ月かに1回バージョンアップをしっかりやってたりとか、その辺のソフトエンジニアリングの成熟度というのは、おそらく僕はいたころより相当上がっているんじゃないかなって思っています。
これからもっとすごいのが出せそうだなという感じはありますけど、外から見えるブログやアウトプットを読むだけでは、ここまでは感じ取れなかったと思います。私はいまでもはてなのメンバーとは会話するので、そこで聞いた話とかを踏まえると、かなり変わっているなって思います。
はてなSLOモデルってありましたよね。id:masayoshi さんが考えたモデル。あれはかなり面白いと思うし、もっとフィーチャーしたらいい面白いですよ。SLOとFour Keysとを結びつけるのはそんなにない気がするし。
... なんか、批判的な指摘も求められてますかね？（笑）
もちろんもちろん（笑）
そうだなぁ。主体的な個別の事業もそうだし、全体の事業の物語みたいなのがあんまり見えない印象があります。僕がいた頃からだけど。ここでいう物語は、何かいろんな人間が集まった中で一緒にやっていこうとなると、共通の信じているものの軸となる、ミッションとかビジョンとか。あとはこうなったらこう成長していくぞとか、あるいは成長じゃなくても、何らかの志向性も物語も見えないなと。
Mackerel単体とかで見たときも、OpenTelemetryでやっていこうというのもすごくいいんですけど、ユーザーが根本的な体験がたぶんそれで変わるわけではないと思うので、ユーザーの根本の体験をどう変革させていくのか、そういうのがあんまり見えないかなという感じです。
これはどの会社でも難しいんですけどね。さくらは、田中さんが物語を語るのが上手いと思います。
でも、
id:chris4403さんが社長になったとき、BtoCで培ったアセットをBtoBに還元する、コンテンツプラットフォームサービスからテクノロジーソリューションサービスへの技術変換の話を「Amazonモデル」だと説明していて。そこにはストーリーを感じましたけど、それ以降あんまり把握できてないです。
ご意見ありがとうございます。ちょうど僕がテクノロジーソリューション本部全体のエンジニアリングマネージャーをやってるので、まさにそういう物語を作っていきたいと思います。
そうなんですね！それは期待してます。
あと、やっぱり、みんな言ってるけど、はてなの文化は面白いなと思います。横の情報共有はすごい強いし。onkさんはエッセイって呼んでるんでしたっけ。僕が知る限りは、ああいうエッセイをいろんな人が書いてるような会社はほかにないと思う。
その文化をもっと活かせないかなというふうに思っています。例えば物語を作るには、個別のエピソードが必要じゃないですか。そういうエッセイって本当は使えるんじゃないかとか思ったり。従業員それぞれの気持ちが書かれてる参考文献のある会社はほかにない。そういうはてな独特の文化を使って、物語を構成していくみたいな話があると、すごく面白い会社になっていくのではないでしょうか。
そうですね。ボトムアップでみんなが考えてるところは書いてもらったり、あとは1on1で聞いたりしてます。そこで得たものをマネージャーや役員がどう活かしていくかですよね。
さくらの場合、田中さん（代表取締役社長 田中 邦裕氏）のリーダーシップがすごい一方で、ボトムアップというよりトップダウンでどう浸透させていくかという課題があるように思うので、その違いはおもしろいですね。
その違いはy_uukiさんにどんな影響を与えてますか？
自分でエッセイ書かなくなります（笑）
田中さんが毎月考えをしゃべる会があって、その感想をSlackの#times_tanakaに投げるみたいなのがあって。僕も最初は頑張ってたけど、ほかに続くひとが多くないとなかなかしんどい。
ただ、研究所単位では、最近入った小田さん（ 研究所 ソフトウェアエンジニア 小田知央氏）が日誌を書こうという活動を推進してくれてるんです。日誌というか考えたことを書くというムーブですね。
日報を書くのがいいよというのは、ソラの桜井 政博さんがYouTubeでお話していて。もともとはてな社内にあったテキスト文化ですが、この社外コンテンツをきっかけに、改めて社内のアウトプットが盛り上がっている状態です。
おもしろいですね。研究所もそういう感じで日誌が盛り上がっていくといいなと思ってます。
今日はありがとうございました！エッセイという強みを活かしつつ、はてなならではの物語を作っていきたいと思います。
id:y_uuki さん、ありがとうございました！id:y_uukiさんこと坪内さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2024年6月頃更新予定、担当はid:onishiです。
id:onk
2018年4月 中途入社(3社目)。アプリケーションエンジニアとしてマンガビューワ「GigaViewer」や、Web小説サイト「カクヨム」「魔法のiらんど」の開発を担当。2019年4月よりチーフエンジニアとして技術組織全体のマネジメントにも携わる。
Twitter: @onk
GitHub: onk
blog: id:onk のはてなブログ
