こんにちは、エンジニアリングマネージャー の 
id:onk です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの 
id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:onk が担当する第15回のゲストは、教育プラットフォームを提供するClassi株式会社でエンジニアとして活躍している
id:aereal さんこと、中澤亮太さんです。
aerealさんは、2012年にはてな入社後、「はてなブログ」のHTTPS化などの大きなプロジェクトや「はてなブログ タグ」の開発、課金システムのAWS移行やお客様サービスの開発協力など、幅広くご活躍いただきました。
現在は、Classi株式会社でチームやサービスの技術的な課題の解決や新しい機能の設計支援だけでなく、技術ブログの編集長などさまざまな領域を担当されています。今回はそんなaerealさんに、最近取り組まれているプロジェクトやアプトプットへの考え方などについて、お話を伺いました。
中澤亮太さん（
2012年3月～2020年8月 はてな在籍
X：https://x.com/aereal
site：aereal.org
- Classiでの現在の役割と働き方
- プラットフォームからプロダクトへ
- 導入する技術に血を通わせる
- 仕事の変化とOpenTelemetryの取り組み
- 技術ブログ復興の舞台裏
- YAPC::Hiroshima 2024に登壇して
- はてな時代のゲームチームでの学び
- いまのはてなはどう見える？
Classiでの現在の役割と働き方
id:onk（以下、） 今日はClassi株式会社のid:aerealさんにお越しいただきました。イベントなどではお会いしてるので、そこまで久しぶりというわけではないのですが、今日はお話をお伺いできるのが楽しみでした。よろしくお願いします。
id:aereal（以下、） こちらこそ楽しみにしていました。よろしくお願いします。移転後の京都オフィスにも来てみたかったので嬉しいです！
id:aereal こと、中澤亮太さん Classiさんは教育プラットフォームの開発・運営をされていますが、aerealさんがいま担当されていることや部署について、教えていただけますか？
プロダクト開発を担う事業部の中に「学習PMF部」という部署があり、そこでエンジニアとして籍を置いています。
入社して最初の2-3年は今と同じ事業本部内の「プラットフォーム部」という、技術的な関心を横断的に扱うチームにいましたが、僕の希望もあって、いまの部署へ異動して2年くらいです。
エンジニアロールとしては「アーキテクト」となってますが、主な業務としては、いろんなチームと関わって、チームやサービスの技術的な課題や、これから作っていきたい機能などについて相談を受け、設計を支援するといったことをしています。
昔、
id:taraoさん（はてな卒業生）が「難しいこと担当」と名乗っていた時代がありましたけど、そんな感じですかね。
当時のtaraoさんと同じ、というのは大変恐れ多いのですが、イメージとしては近いかもしれません。
主な業務としては今お話ししたような内容ですが、それ以外にも「開発者ブログの編集部長」と「GitHub運用委員」というふたつの役割も持っています。
今は金沢にお住まいですよね。全部リモートでやっているんですか？
そうですね、基本的に会社としては開発メンバーはほぼフルリモートです。もちろん、オフィスの方が仕事しやすいという人や、チームビルディングの機会などで集まることはありますが、日常的な業務は基本的にリモートで行っており、普段はオフィスにいるかいないかをほとんど意識せずに仕事できています。
プラットフォームからプロダクトへ
プラットフォーム側からプロダクト側の部門に異動してしているというのを知らなかったです。ずっとプラットフォーム側をやっているものだと思ってました。プラットフォーム部の時代はどんなことをされていたんですか？
代表的なものだと、YAPC::Kyotoで発表させていただいた、AWSサービスを組み合わせて作った「qron」を活用したプッシュ通知基盤の刷新プロジェクトがあります。
YAPC::Kyoto 2023に参加して『qron: Cloud Native Cron Alternativeの今』というトークをした #yapcjapan - Sexually Knowing
プラットフォーム部で、いわゆる「プラットフォームらしい」仕事と呼べるのは、主にこういったプロジェクトでしたね。
aerealさんの希望で今の部署に異動されたという話でしたが、なにかきっかけなどあったんでしょうか。
プロダクト側で個別のプロジェクトに最初から関わっていくほうが手っ取り早いなと感じたんです。
もともと、プラットフォーム部にいながら、特定のチームのヘルプに入ったり、技術的な相談に乗ったりする機会は非常に多かったんです。社内ではesaやConfluenceといったツールで情報共有しているのですが、それらを横目に見ていると、「この開発、なんだか順調じゃなさそうだな」と感じたり、議事録を見ていて「これ、大丈夫なのかな？」と気になって。周りの詳しい人に聞いてみたりしつつ、自分から「こうしたらどうですか？」と提案したりしているうちに、「では、この部分を手伝ってもらえませんか？」という話になる、といったケースが増えていって。プラットフォーム部では「横断チーム」と呼ばれるチームに所属していましたが、その頃から、個別の機能開発やプロジェクトに関わる比重が増えていきました。
そのなかで、横断チームの目標設定や成果は、どうしても後追いになりがちだ、ということを感じたんです。「〇〇チームのヘルプに貢献できた」「このプロジェクトの成功に寄与できた」といった目標は、問題が発生したり、課題が顕在化したりしてから動き出す、いわば「火の手が上がってから火消しに行く」ような側面がありますよね。一方で、問題解決の観点でいえば、「そもそも自分が初期段階から関わることができていれば、後から入るよりはもっと早く貢献できたのにな」と感じる場面が何度かあったんです。
なるほど、そういう理由だったんですね。
僕の性格的に、当時のプラットフォームチームのような横断的な役割にいつづける限り、長期的なプロジェクトに腰を据えて取り組むというよりは、どうしても次々と上がってくる「火の手」が常に意識の中心に来てしまうだろうな、と。そういった状況で、ヘルプする、火消しをするという立場に終始するのは自分には合わない。それよりも、プロダクト開発の初期段階から、文字通り「何でもかまう」という働き方の方が、より主体的に動けて自分に合っているだろう、と。そこでプロダクトチームへの異動を希望させてもらいました。
id:onk導入する技術に血を通わせる
OpenTelemetryやGoの導入とかをしてるのを見て、そういう「会社の技術を前に進める」役目を持ってるのかなと思ってました。なので技術基盤的なチームに居るんだと勝手に思っていたんですが、技術推進の辺りはいかがですか。
そうですね、推進はしますが、そういう役割を明確に持っているわけではないです。
進め方についても、考えてることがあって。当時のチームの状況や自分の性格的なところもあると思うんですが、特定のプロダクトに自分が良いと思う技術をおすすめするときって、その時にそのチームの人たちが一番困ってることの解決のほうがチームとしては優先されるじゃないですか。目の前のことが解決してないのに、僕から「これいいですよ」ってガイドしたところで、響かないし。それで何度かギクシャクしたことがあったんです。これは自分のマインドや仕事のやり方を改めないとなと思ったときに、自分が横断的に仕事をするよりも特定のチームの困りごとを解決しながら、それの解決につながる技術の導入を推進するみたいなほうが自分には合っているし、手っ取り早いなと気づいたんです。それがOpenTelemetryやGoの導入につながっているという感じです。
他の会社だと、例えば、バージョンアップやリアーキテクチャは基盤チームが担当して、機能実装だけをプロダクト開発チームがやっている、みたいなケースも割とよくあると思うんですけど、Classiさんはそうじゃないんですね。
データを扱うログ基盤のチームとかは、そういう仕事の仕方をしています。例えば、アプリケーションログをBigQueryに入れて、マーケターのメンバーが使い勝手よくデータを扱える、といったようなものですね。そういったPlatform SREのような仕事をするチームがあるくらいで、アプリケーションレイヤーは完全に各チームの中にいる状態です。だから、Embedded SREのような仕事も、アプリケーションレイヤーメンバーが担ってます。それはそれで、いまのClassiには合ってるように感じています。
なるほど、aerealさんははてなにいるときから、プロダクト開発チームの中で技術的に面白いものを作っては、導入する、みたいな。松竹梅があったら、なるべく松よりにできるように頑張る、みたいな動きをすることが多かったので、それに近いことを今も続けているんだなというふうな印象を持ちました。
これははてな時代に思ったことなんですが、新しい技術を導入した人がいずれいなくなってしまったときに、その技術にはどんな嬉しいことがあるのかを引きついだメンバーがずっと理解できていないと、いわゆる技術的負債みたいになるという側面があるなと思ったんです。その技術に血を通わせる、みたいなのは、自分が新しい技術を人に勧める時にも、自分が導入するっていう時にも、意識することの一つではありますね。
現場を見ないアーキテクトは絶対失敗する、みたいな話はありますよね。
まさにClassiに入った当初の自分の仕事の仕方が、現場を見ないアーキテクトみたいな感じになってたなっていうのは反省があったので。いまはそれを踏まえて意識するようにしています。
仕事の変化とOpenTelemetryの取り組み
OpenTelemetryの導入を推進したり、Fujiwara Tech Conferenceの登壇ではデプロイツールを作った話をされていたり、インフラ寄りの仕事をすることが多くなったのかなと思ってるんですが。
Fujiwara Tech Conference 2025で「盆栽転じて家具となる」という話をした - Sexually Knowing
Classiはアプリケーションの特徴として、マルチテナントデータベースを抱えてるというのがあって、どうしてもデータベースとか、コンポーネント間の通信みたいなところが難しい課題として残っているケースがあるんです。大きな機能追加をしようとする時にも、やっぱりマルチテナントデータベースを前提として、うまくやれるか？みたいなのを結構考えないといけなくて。そうすると必然的にレイヤーが下の方の課題に遭遇することが多くて、自分で望んでそっちに潜っていったというか、出てくる課題を順番に片付けようと思ったら、どんどんそういう方向に固まっていた、という感覚です。フロントエンドの方には、Angularに詳しい第一人者のメンバーがいるので、そっちのメンバーに背中を預けられるなって思っているのもあります。
意識してインフラに流れていったのかなってわけではない。
そうではなかったですね。
あのままはてなにいても、aerealさんがOpenTelemetryを推進するイメージは持ってなかったので、ちょっと意外ではあったんですよね。データを取る仕組みよりも、もっとプロダクトの実装側に興味を持っていたイメージがあります。
確かにそうですね。ClassiがDatadogを使ってAPMをやっているというのも大きいかもしれません。実際、APMがあることでこんなに自分の受け持ってるサービスの手触りって違ってくるんだな、と感じられたのは新鮮な体験で。トレースが開始してから終了するまでの時間をグラフにしたり、それをメトリックにして監視したり。複雑な、Mackerelで言う式グラフみたいなものが、APMと密接に連携できているのは便利ですね。もともとは、DatadogのagentでAPMのトレースを送るっていう時に課題があって、ちょうどOpenTelemetryが盛り上がってるらしいっていう時期に触り始める機会がありましたけど、APMがなかったら、僕もOpenTelemetryにここまで興味を持つことはなかったと思いますね。
MackerelもAPM機能がリリースされて、まさにそういう体験を提供するようになったので、今の話みたいにアプリケーションを触っている人に、APMを入口にMackerelを触ってもらえるようになってほしいんですよね。理想的なカスタマージャーニーだ。
僕が使っていたときのMackerelは、あらかじめ決めたメトリックを取得して送って監視する感じだったんですけど、今はとにかくAPMにトレースを送っていれば、個別にメトリックを送らなくても監視することができる、みたいなのが、自分の中で革新的な体験でした。お金はかかるんですけど、Datadog便利だなって。なかなか離れがたいところですね。
まさにオブザーバビリティですね。送っておいたら、後からでも何が起きたのか把握できるし、分析、可視化もできる。
技術ブログ復興の舞台裏
技術ブログの編集部長の話も聞かせてください。ブログ復興のエントリーも読みました。
ありがとうございます。今からちょうど5年前に、Classiでは、まさにコロナ禍で社会的に混乱している状況に加え、中学・高校の超繁忙期である4月に、ユーザーの皆様がClassiにアクセスしても画面が表示されない、使えないという非常に大きなインシデントを起こしてしまいました。
それ以降、僕がちょうど入社したタイミングでも、そのインシデントに関連したお客様とのコミュニケーションを継続していて、技術に関しての情報発信はもちろん、会社としての発信が非常にセンシティブな時期が続いていました。そのため、技術ブログも実質的に半凍結状態だったんです。
ただ、いずれこの状況は乗り越えなければならないし、乗り越えていくだろうと考えた時に、会社として事業の要でもあるお客様との直接の対話はアップデートされていく一方で、技術ブログは放置していたら廃れていくだけになってしまうなと危機感を持っていました。自分の中では会社の技術ブログや発表の場があるのは前提となっていたので、このままは困るな、と。
ただ、技術ブログを復活させるには、2020年4月に何が起き、我々がプロダクトやチームをどのようにアップデートし、二度とこのようなことが起きないようにしていくのか、という話をしない限り、ブログの再開はあり得ないと考えていました。ただ、そういったセンシティブな内容について自ら進んで書きたいという人は社内にはおそらくいないだろう、と。でも僕はここで、そういう事柄にも向き合う覚悟が必要だと思ったので、「じゃあ、自分がやろう」と手を挙げました。
内容を考慮すると、メンバーからではなく、当時のVPoTとVPoEという、技術組織のトップに立つ2人が発信してもらうほうがよいだろうと考え、広報の方とも連携し、お二人にお願いしました。内心「大筋の内容は広報と自分で作るので、お名前だけでも貸していただけませんか？」みたいなかたちでお願いしないと難しいかもなと覚悟をしてたのですが、お二人それぞれにご自身の言葉で書いていただけるということだったので、お願いしました。僕と広報でレビューし、記事を公開し、それ以降は「こういう形で編集部を立ち上げて、技術ブログを盛り上げていきましょう」という形で立て付けを行い、今に至ります。
編集部を作って、アドベントカレンダーの運営などもされていますよね。aerealさんが在籍していた当時からやっている、はてなの技術ブログ運営と同じフォーマットでやられていて、輸出してもらって光栄だなと思って見ていました。
はてなのやり方が自分が慣れ親しんでいたというのもありますし、それ以上に効果的に機能するだろうと考えました。まず、自分一人で記事をレビューし続けるのは単純に仕事量的に辛いですし、「あの人（aereal）がやっている」という感じよりは、チームとしてブログを盛り上げている、という風に見られた方が、活動全体に勢いがあるように感じられるだろう、と。また、「この内容をレビューしてほしい」と思った時に、僕個人に依頼するのは少し躊躇する、という人でも、編集部というチームにお願いする形ならより気軽に頼んでもらえるかな、とも思いました。そういった理由もあり、はてなのフォーマットを踏襲させていただき、編集部チームでレビューを回すという形にしています。同僚にインタビューしていくシリーズも真似させていただきました。
おー、あのシリーズも最初の方は「写真: id:aereal」と署名が入っていますよね。
写真懐かしい。はてなにいた時に、同僚のインタビューシリーズを自分自身もたのしく読んでいましたし、良い取り組みだと感じていました。特にコロナ禍を経て、Classiでも新しく入ったメンバーや、あるいはエンジニア以外の職種のメンバーから見て、「エンジニアが普段どのようなことを考えて仕事をしているのだろう？」「どういう価値観を持っているのだろう？」「そもそも、どういうバックグラウンドでClassiに入ったのだろう？」といったことが、ややふわっとしたまま仕事が進むことが多い、と感じていました。具体的に何かが困るというわけではないのですが、なんとなく、もう少しお互いを深く理解できれば、より仕事がしやすくなるのではないかと感じていました。どうしようかと考えた時に、はてなのインタビューシリーズが参考になったので、Classiでも始めてみました。
いいですね。僕らはインタビューシリーズの他に、広報が始めた社内報があって。入社した人は全員、とりあえず一番最初にインタビューを受けてもらうようになってますね。IDの呼び方とか、入社前にどんなコンテンツを見てくれましたか？みたいな話から、好きなものとか、そういうのが全員分、入社したあと少ししたら流れてくる、みたいな、そんな感じになってますね。
Classiでも特にコロナ禍以降は、広報チームが主導して社内報のようなものをやっていて、新入社員のインタビューもその一環として行われています。入社日に事前にいくつかの質問に回答する形です。「最もエキサイトできることは何か？」といった質問が4つぐらいあって、広報チームがそれをスライド1枚にまとめてくれます。事前に提出した顔写真と一緒に「今日入社したaerealさんです。こういう人で、こういうことを考えている方です。所属はこちらです」という形で、入社日に社内全体に共有されるので、多分似たような感じですね。
そういう情報があるとお互いコミュニケーションしやすかったりしますからね。はてなでは社内Cosenseに「facebook」というプロジェクトができていて、そこにみんなが自己紹介を書く、というカルチャーもあります。
YAPC::Hiroshima 2024に登壇して
aerealさんご自身でもいろんなアウトプットをされてますが、最近だとYAPC::Hiroshima 2024でのトーク、すごく良かったなと思ってます。
YAPC::Hiroshima 2024に参加し「好きな技術《コト》で、 生きていく技術」という話をした。 - Sexually Knowing
そうですね、ブログにも書いたんですけど、YAPC::Kyoto 2023で聞いた
id:ar_tamaさんのトークやその評判を見て、こういう発表のスタイルもありなんだなという風に感じることがあって。あとは、はてなを辞めてClassiに入ってから、これまで自分の中で培ってきたこととか、考えてきたことが、いろいろ相対化できてきたところもあるので、自分のためにも、ちょっとひとまとめするかと思ったのが2024での発表ですね。
aerealさんのアウトプットの集大成だなって思って聞いていました。2017年のエン・ジャパンさんのオウンドメディアの記事とか、「作りたがりな自分を飼い慣らすための趣味プログラミング」とか。あのエントリー、好きなんですよ。
ありがとうございます。
自分ではブログにも書いたように、下心が出過ぎたなっていう反省があって。下心を出した結果、下心に報われなかったっていう、二重の恥ずかしさみたいなのもあったなと思ってます。テックカンファレンスという場で、技術に関する何かを調べたり取り組んだりした結果を発表するのとは違うスタイルの発表ができたということは良かったです。ただ、やってみたうえで、僕はしばらくは、ああいうスタイルの発表をしないかな、っていう感じですね。
えー、もったいない。プログラマとしてこういう性質を持っていると幸せだよ、と世の中にずっと発信し続けているのは絶対いい話だし、aerealさんはそれを体現するように、ライブラリもどんどん作り続けている。毎年、何かしら5、6個ずつぐらい作り続けてますよね。
しばらくしない、と言ったのは登壇での独白スタイルというかたちでの発信ですね。
ブログでは「自分の独白」を記事にまとめてきました。ブログでの「独白」と比較すると、テックカンファレンスでの独白は自分としては少し感覚が違うなと思った。やっぱり登壇のほうがオーディエンスを意識するものになるので、そういうところで独白というか自分語りをするのは、合わないというか。少なくともYAPCに関しては、僕の中では滑ったなっていう感じですね。内容がどうこうっていうよりかは、自分語りをした結果、特に響かなかった、自分が欲しい反応が来なかった、っていう意味です。それはもう気まずすぎるので、少なくとも、同じような話をするっていうにしても、ブログでしかやらないだろうな、っていう感じですね。
ブログと登壇の違いの話は面白いですね。でも、本当にあれはいいトークだったなと思ってます。aerealさんって昔からずっと「恋に仕事に大忙し」って言っているじゃないですか。ソフトウェアエンジニアリングをフルタイムでやるなら、仕事っていう賃金を稼ぐ手段だけじゃなくて、面白さとかワクワクできるものを、と。
はてな時代のゲームチームでの学び
さて、はてな時代の話に戻っていきましょう。在籍時に担当したサービスだと、はてなブログ、はてなブックマークの自社サービスのチームから、任天堂さんの案件を担当するゲームチーム、そして再びはてなブログチーム、という感じだと思いますけど。
そうですね...。良く振り返るのはゲームチームの仕事ですかね。当時、ゲームチームでの仕事で自分の中でモヤモヤすることも多かったのですが、その時のマネージャーに「将来的に絶対、得るものが多かったプロジェクトだったと思えるから」というようなことを言われたことがあったんです。「分かるけど、そうは言ってもな…」という気持ちを当時は抱いていたのですが、Classiに入ってから、自分の仕事の仕方や、これからエンジニアとしてどうやっていきたいかを改めて考えた時に、ゲームチームのことをよく思い出したんです。
正直、ゲームチームでの当時の自分の仕事ぶりは、キャリアの中で一番「イケてなかったな」と反省しています。僕自身も、本当に惜しいことをしたな、と。特に、Miiverseをリニューアルする最後のほうの時期に、後からチームに入ってきた
id:astjさん（はてなチーフエンジニア）が、当時すごく難しいコンポーネントをいくつも担当している中で、それらをキャッチアップして、それまで暗黙知的に扱っていた領域の知見をドキュメントとしてまとめ始めたんです。自分は正直、積極的にキャッチアップしようという気持ちがそこまでなかったのですが、astjさんが熱心に取り組む様子を見て、「自分もやるしかないな」と思って気持ちを切り替えたんです。その後、リニューアルで様々なコンポーネントに触れるようになったのですが、そうなるまでの自分はエンジニアとして少し恥ずべき態度だったな、と今でも思っています。
なので、Classiに入ってからは、「難しいから」「やりたくないから」といった、やらない理由を色々作ることはいつでもできる、という風に考えるようになりました。自分がやりたくないかどうかではなく、やるべき理由や、解決すべき問題があるのならば、何でもやろう、というように考え方が変わりました。だから、まずは「とりあえずやってみる」というスタンスになりました。
先ほどお話ししたClassiでの横断的なチームでの仕事も、結果的にはプロダクトチームの方に戻ったわけですが、「食わず嫌いしなくてよかったな」と思いますし、その「食わず嫌いをしない」というスタンスは、やはりあのゲームチームでの反省が強く影響しているのかな、と感じています。
なるほど。はてなに残されていた退職エントリーの中でも、ゲームチームでの仕事に反省がある、というのを拝見して、すごい根深く刺さっているのだな、と感じていました。
僕自身も、本当に惜しいことをしたな、と。今見ても、当時のMiiverseぐらいの規模感、それこそAWSのEU, US, JPの3リージョンを活用し、トラフィックもデータの量も非常に多いサービスでした。それを「しゃぶり尽くせなかった」というのは、非常に惜しかったという気持ちがあるんですよね。
また、Miiverseというサービス自体も素晴らしかったと思っています。ユーザーの皆さんが、我々の想定していない使い方を日々どんどん生み出していて。もちろんサービスを提供する側として果たさねばならない責任も多く、大変な側面もあったのですが、完全にその中で、世界のユーザーのクリエイティビティが爆発していく様を見られたのは、今思うと本当に良かったな、と。
そういったプロダクトの側面から見ても、食わず嫌いというか、一つの側面からしか見れていなかったところがあったな、と当時の自分を省みて思います。今やっている仕事も、いずれ過去のものとなるのですが、その時に「これ、やっておけばよかったな」とか「このチームでこういうことしておけばよかったな」と、できるだけ後悔しないように仕事ができたら良いな、というのは、今強く思っていることです。
社会人人生30〜40年ぐらいしかない中で、その中で2年使ったら20分の1を使うわけなんですよね。この20回しか繰り返せない貴重な1回、誇れる仕事をしてほしい、みたいな気持ちが、当然マネージャー側にはあります。目の前の仕事の一番美味しいところが何なのかを見極めて、そこを本当にしゃぶり尽くしてほしいと思っている。
はてなにもMackerelも、ブログも少年ジャンプ＋も、それぞれ絶対に他のプロダクトでは得られない経験があるんですよね。そこをしっかり触ってほしいし、自分の軸足として成長や発信の起点にしていってほしいな、ということは、最近改めて考えています。
はてなって、事業を伸ばすとか、あるいはエンジニア個人がプロフェッショナルとして成長するといったことはみんな考えていましたし、会社からもそういったメッセージがあったと思うのですが、それと同じくらい「いい仕事をしよう」みたいな価値観は、色々なシーンでみんなが持っていた価値観だったなと思います。どうせ同じくらい大変な思いをするのであれば、より楽しい方向で、より面白そうなことをやろう、みたいなのがあったなと思って。それはやはり良い価値観だったな、という風に思っています。
いまのはてなはどう見える？
いいこと言ってもらったので、「はてなに物申す」ではないですが、外から見たはてなに対して思うことなどがあれば、伺いたいです。
そうですね。僕の中では、はてなにほぼ新卒みたいな感じで入ったんで、なんだろう... 正直、今ようやく客観視できるようになった、辞めて5年くらい経ってやっと相対化できたな、っていう感じがあるんです。良いところも悪いところも。結局、自分の中でかなり多くのことが「必然」になってしまっていて、正直今でも「こうしたらいいんじゃないですか？」とか「これは違うと思うよ」みたいな考えは、あまり出てこない、というのが正直なところです。
うーん、でも、あれかな。さっきお話したように、APMは僕がいた当時のはてなではあまり触れられなかった技術だし、今でもサービスでの活用度合いで言ったら、Classiでの経験のおかげで僕のほうがはてなのエンジニアよりも勘どころみたいなのはあるなって思ったりしてます。APMの良さっていうのは、結構、業界の中ではかなり気づかれてる技術だと思うんですけど、そこら辺は、特にオブザーバビリティみたいなところでは、再びはてながフロンティアにあってほしいなっていう気持ちは結構ありますね。
ありがとうございます。そうですね。我々はMackerelを持っていて、昔はNagiosとかも使っていたんですけど、Mackerelに全統一していった。その結果、統一以降に入社したエンジニアは今のMackerelでできることしか知らないんですよね。Mackerelをさらに活用するとか、Mackerelでできないことをやりたい欲求みたいなのが、持ち込まれづらくなっている、という流れがどうしてもあります。そこで最近は「Beyond Mackerel」と打ち出して、Mackerelに固執せず、オブザーバビリティを高めていくために集中的に取り組んでいます。OpenTelemetryを使いこなし、それをプロダクトに還元するっていう流れですね。
そういったオープン標準とかっていうところの貢献においても、はてなとかMackerel発祥っていうのがあると、すごいワクワクするなと思うので、楽しみにしています。APMでいえば、Mackerelは後発になると思いますが、逆に後発だからこそ、見習えるところがあると思うので、そこら辺、再びイニシアチブを取るところが見たいなっていう個人的な願望をお伝えします。
かつてMackerel がやっていた100週連続リリースみたいなアクションを取らないとそこにはたどり着けないと思ってますが、頑張りたいですね。期待してもらえて嬉しいです、ありがとうございます。
id:hitode909の「aerealさんの思い出 」というエントリーでも紹介されている 
id:shiba_yu36さんのＸ投稿写真（2012年） あと、1個話したいことがあって。REWORKって、37signalsの方たちがやってるポッドキャストで、「Hire Great Writers」っていう回があったんですけど、ご存知ですか？
ポッドキャストやってるんだ、というのを今知りました。
この回で話していることがすごく良くて。「良い開発チームを作るためには、まず良い文筆家を雇いなさい」ということを言っていて。良い文章や言葉を編み出せる人っていうのは、問題の事象の深掘りや、多面的に見る力、そしてそれを読者に対して過不足ない形で伝えたり、聴衆を考えて言葉を選ぶことができます。それって、結局、プログラミングやコーディングにも広く通じる話なので、いい文章使いを雇うっていうのがいいと思うという話をしていたんです。
僕ははてなの人たちはみんな文筆家だなと思って。文章を書くことだけじゃなくて、相手に伝わる話し方みたいなのも上手な方ばかりでしたよね。
グレード昇格した時に、CTOの id:motemenさんが僕の日々の仕事とか、過去の仕事とかっていうのを捉え直して、ご自身の言葉で「こういうところが印象的で、こういうところが評価に値すると思ったから、昇格することにしました。今後はこういう仕事を期待してます。」みたいなのを言葉で語ってくれて。それを聞くと、「あーすごくよく見てくれてるんだな」っていう嬉しい気持ちになりました。motemenさんに限らず、いろんな人が、各々の言葉を持ってるなと思っていて。だから、僕は当時、はてなの同僚に褒められると嬉しくて。それは、褒める言葉が上っ面じゃないと思えるからだったんですよね。
エンジニアに限らず、はてなの社内外の発表やブログの記事を読むのも楽しかったな、その源流は「いい文筆家」が揃っていたからなんだろうなということを、ポッドキャストを聞いて改めて感じました。はてなの強いチームの結構要素の一つなのかなと思うので、これからも大切にしてほしいなっていうの。改めて、素晴らしい文化というか特徴だったなと思うので、今日伝えたかったのでした。
いい話だ。ありがとうございます。僕もこれからもaerealさんの個人やClassiさんでの発信を楽しみにしています。今日はありがとうございました。
id:aerealさん、ありがとうございました！id:aerealさんこと中澤さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2025年8月頃更新予定、担当はid:onishiです。
id:onk
2018年4月 中途入社(3社目)。アプリケーションエンジニアとしてマンガビューワ「GigaViewer」や、Web小説サイト「カクヨム」「魔法のiらんど」の開発を担当。2019年4月よりチーフエンジニアとして技術組織全体のマネジメントにも携わる。
Twitter: @onk
GitHub: onk
blog: id:onk のはてなブログ
