こんにちは、エンジニアリングマネージャーの 
id:onk です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの 
id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:onk が担当する第18回のゲストは、「小売業の未来を拓く」をミッションに、小売チェーン向けECプラットフォーム「Stailer（ステイラー）」を提供する株式会社10Xでデータエンジニアとして活躍している
id:syou6162さんこと、吉田康久さんです。
syouさんは、NTT研究所で機械学習の研究者を経験後、Webアプリケーションエンジニアとして2016年にはてなに入社。「はてなブックマーク」などの個人ユーザー向けサービスに関わったのち、オブザーバビリティプラットフォーム「Mackerel」での機能開発や、データ基盤の開発などでご活躍いただきました。
2021年3月にはてな卒業後、株式会社MonotaROでデータエンジニアを経て、2022年9月に株式会社10Xに入社されました。現在はデータエンジニアリングやデータ活用に関するコミュニティ「datatech-jp」の運営メンバーとしても活動されています。
今回はid:syou6162さんに、はてな卒業後のデータエンジニアとしてのご活躍とともに、現在の10Xで取り組まれていること、アウトプットやコミュニティに関する活動などについてお話を伺いました。
吉田康久さん（
2016年4月～2021年3月 はてな在籍
X：https://x.com/syou6162
blog：https://www.yasuhisay.info/
- 10Xでの「データエンジニア」の役割
- はてな、モノタロウ、10X それぞれの経験
- 「いろんなものを見る」のが好き
- 生成AIの活用と情緒
- 砂場づくり
- 自分が欲しいコミュニティを作る
- Mackerelでの機能開発とデータ基盤
- いまのはてなはどう見える？
10Xでの「データエンジニア」の役割
id:onk（以下、） 今回はsyouさんにお越しいただきました。いまノリに乗っているという印象なので、ゆっくりお話しできるのを楽しみにしてました。
id:syou6162（以下、）ありがとうございます。ノリに乗ってるかわかりませんが、楽しくやってます（笑）
id:syou6162 こと、株式会社10X データエンジニア 吉田康久さん 10Xさんのご紹介と、syouさんの役割についてお聞かせいただけますか？
10Xは、ネットスーパーを中心とした小売業向けのプラットフォームを展開している会社です。ネットスーパーアプリから、店舗のスタッフさんや小売店の本部の皆さん向けのアプリケーションや管理画面のほか、小売業の課題を解決するDXサービスを「Stailer」というブランドで拡大していっています。
小売りはどうしても薄利な業界だったりするので、業務の効率化だったり、利益率の改善が重要です。オフラインでのお買い物情報をネットスーパーのIDと紐づけてお客様に合った商品をおすすめするような販促だったり属人性が高く標準化が難しいとされている発注やプライシングなどを、さまざまなデータを使って支援するためのサービスを提供したり、準備したりしている最中です。
僕はそこに入ってくるさまざまなデータの取り回しだったり、データの機能や分析を支える役割を持つデータエンジニアとして働いてます。
小売りでは扱っているデータがさまざまありそうですね。
商品の在庫や価格などの情報からID-POSなど、さまざまな形式のデータがさまざまなクライアントごとに存在してます。それぞれ用にデータのパイプラインを作っていくのは大変なので、いったんデータを受け止める口として、データストアというものを準備してます。そこでさまざまなデータを集めて、ある程度汎用的に使える形にしたうえで、出口であるアプリケーション向けに加工する、みたいなところをやってます。
syouさんが所属しているデータ基盤チームというところがプライシングや発注などのアルゴリズムも考えるんですか？
そうですね。データ基盤チームにはいま4名のエンジニアがいますが、EMがもともとデータサイエンス系の方なので、アルゴリズムはその方が主に担当してます。ほか2名がアナリティクスエンジニアリング中心で、このふたりがさまざまな分析や加工をやりやすくなるように、僕はデータエンジニアリングからアナリティクスエンジニアリングと呼ばれる領域を広くやっているという感じです。
id:onk データエンジニアって、世の中的にはだいぶ一般的な職種になってますよね。
はい、ここ最近でずいぶん景色が変わったなとは思います。一方で、アナリティクスエンジニアはまだまだこれからって感じがしてます。
せっかくなのでそのふたつの違いについて説明してもらってもいいですか？
データエンジニアはデータが入ってくるところの入口から出口までを広く、なんでも見る感じかなと思っていて、アナリティクスエンジニアはBigQueryやSnowflakeのようなデータストアに入ってきた後の、BIツールでの活用や、データのモデリング、加工、品質保証など、限定された範囲に特化しているイメージです。
データエンジニアはパイプライン全体を構築・運用する仕事みたいなイメージを持ってました。
データエンジニアの定義はデータエンジニアを採用している会社の数だけ異なる定義がある気もします。10Xの場合は、入口から出口まで、データの取り扱いだけでなく、要件定義から関わってますね。
アナリティクスエンジニアはデータ活用の後半だけなんですね。
はい、そこにより特化しているという感じです。
はてな、モノタロウ、10X それぞれの経験
syouさんははてなではデータ分析チームの立ち上げなどに関わられていましたが、その次のモノタロウさんでは既にデータ活用がかなり進んだ環境に変わったと思います。そして今の10Xさんではまた違う働き方になっていると思うので、それぞれの違いについて伺いたいなと思ってました。
そういう意味では、どの場所でも本当に良い経験をさせてもらったと思ってます。
はてなにいた当時は、データエンジニアという仕事もデータ基盤っていうものもなくて。複数のスプレッドシートが複雑に絡み合った状態から、全てを自分で作っていく「0→1」のフェーズに立ち会わせてもらいました。
Mackerelチームの事業計画やお客様のヘルススコアについて、それぞれプロデューサーやCREと会話して、どういう状態を捉えていきたいのかをヒアリングしながら「こういうのが見れたら便利だったり面白かったりするよね？」というのを考えてどんどん整理していきました。
次のモノタロウでは、また全然環境が違って、社員のうち400-500人がBigQueryを使って分析したりするだけじゃなく、倉庫のオペレーションにも使っているような状況で、一気に規模や景色が変わりました。全社のデータ基盤という大きな規模で、求められる品質も変わったり。見ないといけないところが一気に増えたという感覚でした。そういうときって、管理することが目的になりがちだと思うんですけど、はてなの経験があったので、自分が実際に使ってみたり、担当者にヒアリングして改善ポイントがないか聞いたりして、使う側にちゃんと寄り添うみたいなことは忘れずにしつつも、品質とバランスをコントロールするみたいなことを学べたのは貴重だったかなと思ってます。あとは自分と同じような仕事をする人が数名いて、みんなで話し合えるみたいなのもよかったかなと思ってます。
10Xははてなとモノタロウの間、くらいの感覚ですね。はてなは200名、10Xは60名くらいの会社ですが、自分がはてなで所属していたMackerelチームとの人数の比較だと、はてなとモノタロウの間。扱うデータのことを考えても中間くらいかなという感覚があります。10Xの小売りのお客様はエンタープライズ企業が多かったりしますので、行きつく先にはモノタロウに近くなっていくんだと思うんです。そういう想像がつくというのはモノタロウでの経験があるからなので、すごく役立ってますね。先を見据えて、いまやっておくべきことがわかったり、これからの道筋がイメージできたり、みたいなことはいいことですね。
それぞれ面白い経験ができたと思いますし、それを活かしていまにつながる仕事ができている感じはしています。
id:syou6162さん（2018年） 面白いですね。EC・小売りとかと比べると、Mackerelはデータ分析によってコスト削減や売上貢献がしづらかったと思うので、見える世界も全然違うんだろうな。
それで言うと、はてなから転職しようと考えたのも、その軸でしたね。データ活用によってプロダクトが良くなる、みたいなことではなくて、もうデータ活用や事業やサービスの肝みたいな会社という軸で検討しました。
データ分析とかって、マネージドSaaSとかOSSとかでもだいぶやりやすくなっていますし、ソフトウェアエンジニアが居る会社では、兼務でデータ分析するとかでも十分なケースもたくさんあると思うんですよ。
はてなでの僕もそういう感じだったと思いますし。
ただ、僕自身、自分はソフトウェアエンジニアとしてすごく中途半端だと思っていたので、データに特化して、そこで勝負していけるようにしたかったんです。兼務とかじゃなく、一日中データのことだけ考えているのは、ライフワークっぽくもあって、自分の価値観とも合うなと思って。
ソフトウェアエンジニアとして中途半端だったとは思ってませんでしたが、キャリアの選択としては納得感がありますね。
データ基盤をやっていても、ソフトウェアエンジニアの経験はすごく活きるなとは思っていて。エンジニアに何か依頼する際も、どういうやり方なら実現しやすいかなとか、これは難しいよなとかが想像できるので、それを前提としながらコミュニケーションできるのはいいですね。
Mackerelで入口から出口までやった経験も血肉になってるなと思って。メタ分析とかも好きなんですが、監査ログや議事録やSlackの会話とかを見ながら「ここにペインがありそうだな」「ということはこういうデータが必要なんじゃないかな」と思って提案したり「このあたりのディスクリプションは丁寧目に書いておくと親切だな」とか考えたりしてます。
いろんなものを見るの好きですね。
「いろんなものを見る」のが好き
ディスクリプションを書いておくという話題が出ましたが、syouさんは一貫してずっと「メタデータ」と言い続けているなと思ってます。
メタデータは仕事というよりは僕にとって趣味みたいなものですが（笑）
メタデータは、システムのスキーマがカバーできない、開発者側の意図を伝えるために必要なんです。
例えば、システムのマイグレーションなどで、新しいカラムが導入される状況とかでは、新システム移行後は値が入るのですが、旧システム側には値がないため、データベースのスキーマ上はNOT NULLにはできない。でも、データ利用者に「基本的には NULL ではなく値が入っていると思って欲しい」という暗黙の期待がある。システムのスキーマでは、そういうところが書けないんです。
僕はそういう足りない情報とかを、ディスクリプションなどにねじ込んで、アナリストの人が集計時に誤って引っかからないようにする。そういう「ここが足りていない」というのをSlackで見つけては、よっしゃ、と思って拾いにいくみたいな。
あとは、OSSとかでコントリビュートしてたりするのも、データウェアハウスやデータマートを作る人にデータソース側の注意書きが伝播しないという問題を解決したいからですね。知識が資産として回っていくようにする、ということを、仕事でもやっているし、OSSや趣味みたいなところでもやっていますね。
syouさんはSlackを眺めて困りを見つけるのが本当に好きですね。
onkさんこそSlackやXのジャンキーですよね（笑）それと似ている気はしています。
たしかに。情報は多ければ多い方が自分の判断の根拠になりやすいので、ここで困ってそう、みたいなデータを集めるっていうのは僕も趣味にしてますね。
同じくです。
僕はSlackのSave For Later機能を使って、事業サイドの「ここで困った」という具体的な声をひたすら集めているんです。
具体例だと、データコントラクトの話ですね。スキーマの定義みたいなやつを、使う側（データの消費者）と作る側（データの生産者）の間で、データコントラクトという形で結んでやりましょう、という考え方があります。
データコントラクトなしにデータを使っていると、それは単なるデータのスクレイピングのようなもので、勝手に使っているだけになってしまう。そうではなくて、「この形式でデータを渡します」「この期待値で使います」というコントラクトを結んだ状態にしたい。
10XではRDBではなくFirestoreのようなスキーマがカチッと決まらない、柔らかいものを使ってるんです。そうすると、いつの間にか仕様が変わってしまい、BIツールやデータマートの集計が合わなくなるみたいなことが起こってたんですよね。
なので僕が入社した時からデータコントラクトを入れたいねって話題があったんですが、データ基盤の足回りが重くなるとか、工数が重たいといった理由で、なかなか導入が進まなかったんです。
そこを、各所で困りごとや事故が発生している状態をSave for Laterにどんどん貯めていって、それをCTOに持って行って「実はこういうことがあってですね」と見せて。何度もそういうことをやっているうちに、ついにそこはしっかり着手していきましょうという流れができてきたかなと思います。
いいですね。
新規事業のところでも、小売店さんからいただく仕様書をデータコントラクトとして書き起こし、それに基づいてBigQueryにロードするためのスクリプトや、dbtのソーステストを自動生成したりしています。データストアからAI発注のようなアプリケーションに渡すところもコントラクトファーストでできるようになってきてますね。ネットスーパーで培った経験を新規事業に活かしながら、品質高く作れる仕組みを構築しているという感じです
- 10Xのデータストアに関する参考記事
- Data Contractの導入についての
なるほど。コントラクトファーストにすることで、データの入口の品質を高めていく、という話なんですね。
あくまで品質を構成する1項目でしかないんですけどね。
だからこそ、アセスメントで全体感を見る活動を継続していて。はてな時代も、Mackerelチームだけでなく、マンガチームやはてなブログのチームにもお邪魔しては、PdMの人やデータを使っている人に直接ヒアリングし、さまざまな項目で「どういうところに課題があるか」とか「ここはまだこのままでいいよね」みたいなことを会話するようにしていました。
アセスメントはモノタロウでも実施していましたし、10Xでも毎年やってます。今年でちょうど3年目ですね。
11の項目を設けているのですが、事業の成長に応じて、その評価項目が年々どう変わっていったかを見てます。僕らの仕事によってどこがどう成長したか、あるいは事業の変化によって必要なレベルが上がり、「もうちょっと高めないといけないね」といったところを、いろいろ見ながらやっているという感じです。
今年は生成AIを使うようになったので、ドキュメンテーションの優先度が上がってきた、というスライドが面白かったです。
生成AIの活用と情緒
生成AI、使いまくってますね。
そうですね。去年、GitHubのコントリビュート数が7,000くらいだったんですが、今年は先週くらいにもう7,000を超えていたんですよ。今年の初めは、レビューが増えたりして、むしろ去年のペースより遅いかなと感じていたんですけど、Claude CodeのMaxプランを5月末に契約してから、状況が一変しました。ハマりにハマって、7月だけで1,700コントリビュートくらい入ってて、これはやばいぞ、という感じです。面白いんですが、なんというか情緒不安定になってる感じもします（笑）。
特にこれはすごいなと思ったことがあって。問い合わせ調査で「このステータスだと集計が合わない」といった依頼が来たときに、状態遷移図があれば、「ここに来るパスはこれとこれだ」「ここがターミナルならもう調べなくていい」とすぐにわかるじゃないですか。ただ、そんな都合のいい図は普通用意されていない。かといって、ソフトウェアエンジニアに網羅的な状態遷移図を書いてってお願いしたら、お礼に焼肉ごちそうしなければいけない感じじゃないですか（笑）。そこで、Claude Codeにお願いして、僕はシャワーを浴びに行って、シャワーから戻ってきたら普通に書いてくれていたんですよ。
ソフトウェアエンジニアの人にも見てもらったら、ほとんど合ってそうで、間違った遷移もなさそうだ、と。ソースコードだけでなく、クライアント側のビューなど、さまざまな情報を見て「画面のどういうときにここを遷移するのか」といったパターンまで書いてくれたんです。これはすごいなと。
同時に「こんなレベルの高いことができるのに、なぜこれができないんだ！！」みたいにもなって。「こんなことまでできるんだ！」とハイになっている時の状態と、「なんでこれができないんだ！」の負の感情が交互にきて、情緒不安定になりますね。このメンタルのブレ幅はちょっと辛いので、AIに任せきりにせず、良いソフトウェアのプラクティスやガードレールでコントロールしなければいけないな、と感じています。
ちょうどそういう話をTokyo dbt Meetupでもしてきたところです。
状態遷移図は本当にいいな。一般のソフトウェアエンジニアよりも、データエンジニアであるsyouさんはうまい使い方をしていると思う。データの発生からの流れを意識して指示しているからかな。
どうですかね？データエンジニアはソフトウェアエンジニアのサブセットだと思っているので、基本的にソフトウェアエンジニアリングのスキルや知識は備えていないといけないと思っています。
k1LoW/deckを使ってスライドを作ったっていう話も面白かったな。
本の記述をスライドの文字に起こしながら、自分の理解が甘いところを聞いたら無限に答えてくれるし、Claude CodeやChatGPTやCodexとか、いろいろ使い分けてやってますね。あと、音声入力をすごく使うようになって。
音声入力。
キーボードを全然叩かなくなったりしました。人間向けにSlackで書くときはさすがにキーボードですが、AI向けにチャットでいろいろ聞くときには、音声でバーッと喋っても、いい感じに解釈してくれるんで。レビューのコメントとかも全部音声入力ですね。コンテキストをダンプする感じ。
彼らは整理するのが得意なので、「そうそう、これが言いたかった」とかグループ化して整理するとかを任せてます。一度テキストにしておくと「あの時言ったあれ」とピックアップしやすくなることもあって、今までは書いたブログとかをリファレンスとして持ってきていたのが、より思考が音声でダダ漏れするようになった。
こうして何でもテキストにして残していくというのも、生成AIをうまく使うコツなんでしょうね。ブログは本当にコンスタントに書き続けているし。
syouさんはジュニアからシニアに上がるときに考えることだったりとか、サイエンティストの人にソフトウェア・エンジニアリングを教えるだとか、育成的な記事をよく書いていますよね。社内でそういう役割を持っているんですか？
世代的にも教育的なことは期待されてはいると思いますけど、明示的に言われてるわけじゃなくて。
さっきステータスの遷移をAIに出してもらったって話をしましたが、そういう使い方ができると面白いよねってことをチームのメンバーにも知って欲しいなと思ったので、アナリティクスエンジニア向けのLLMを使ったコードリーディング会みたいなのを企画してやりました。これはアナリティクスエンジニア向けのつもりだったんですけど、意外とソフトエンジニアの人とか、デザイナーの人にも意外と好評で、PdMやBizDevといった他の職種の方向けにもレビューでの活用の話をしてみたり。
あとは、普通のディメンショナルモデリングの勉強会とかもやろう、と思ったのも、新しくチームメンバーが入ってきて、いろいろ共有するときに、自分も見直すのにちょうどいいかなと思ってまとめてみた感じです。
教育というか、自分が面白いと思ったりとか、自分が知りたいと思ったりで、じゃあ、やりますみたいな。
なるほど。読書会もそういうきっかけで始めてることが多い？
そういう感じでやると良くないですか？自分が欲しい感じにデザインできるので。自分がやりたいと思ったものなら、モチベーションの心配はしなくていい。最悪、人が抜けていっても、自分がいればどうにかなる。
自分が知るのがゴールだったら最後自分一人になってもメリットはありますね。
大人になっても、衝動ドリブンで生きてる感じですが（笑）
若干、教育っぽいところへの意識はなきにしもあらずではあります。ペアプロをしているときに、分析用のSQLを書けることと、継続的にデータ基盤のクエリをメンテナンスしたり、データプロダクトの品質に頼る作り方ができます、っていうところは、断絶があるなとは思ったんです。
その断絶は、結局、ソフトエンジニアリングの考え方の有無なのかなという風に考えて。ペアプロしながら考え方を何度か話していたんだけど、これは同じようなケースの時にもう一度話して伝えるよりは、まとめておくと便利だなと思って、音声入力でバーッとまとめて記事にしました。
ソフトエンジニアからすると当たり前じゃんって思うことも、違う職種を経験してきた方からすると意外と当たり前じゃないんですよね。色々な職種の方と関わることでそう考えるようになりました。
砂場づくり
「ジュニアエンジニアからシニアエンジニアになるまでに自分がやっていたこと」のエントリーの中でも紹介されていますが、まず砂場を作ろうっていう話をしていて。syouさんはちゃんと砂場を育て続けてるのも偉いなと思ってるんですよね。
僕がはてなにいた時の技術メンターが
id:shiba_yu36さん（クラスター株式会社 柴崎優季氏 @shibayu36）だったんですが、インフラをまったくわからなかったところからいろいろ教えてもらって。サーバーを立てるとか、障害が起きた時に何すればいいのとか、どういう設計をすればいいのとか、みたいなことを、誰かの指示通りにやることはできても自分で考えることはまだできなかったので。
自分でちゃんと勉強しようと思って、とりあえず、EC2の上で色々サーバーを相乗りさせて、みたいなところから組み立てていって。自分の砂場だったら、何しても怒られないし、好きなだけ失敗できまくるじゃないですか。そういう自分の経験も踏まえて砂場を作ろうって話をしている感じです。
実際syouさんがその砂場に対して何か変えてる様子は、ブログで延々書いてるじゃないですか。
20記事ぐらい書いてましたね。
あれはすごく良いなと思ってました。
天才的な人はすごいと思うんですが、やっぱり自分にとっては再現性がないなと思うことが多くて。過程がわかるみたいなことが好きだし、そういうのを残しておけると参考にしてもらえるかもしれないなとは思ってます。
砂場づくりのエントリーも、読み返すとどんどん成長していってる様子がわかりますね。ステップがいっぱいあるということがわからずに最終形だけ見てもわからないことってあると思うので、全体像やステップを理解するのは大事だなと思いました。
過程を見せることを意識して書いていたのは気づきませんでした。なるほどなー。
意識というか自分の趣味とか志向という感じですね。ブログは19年書いてますから。19年分の過程を見てもらえます（笑）
すごく長く続いてる。
その過程が面白いって感じですかね。書いてあることはわかるけど、身をもって体験するとか本当の意味で理解するって数年単位でかかったりすることあるじゃないですか。
そのときに、数年前の自分はそれについてどう書いてたかなとか、自分がどう処理したのかなとかが、自分の言葉として残っているというのがすごく大事だなと思っていて。過去の自分に支えられながら今も過ごしています。
インタビューなんでいいことも言っておくと、id:onishiさんだったと思うんですが、はてなのときに「自分たちはインターネットに育ててもらったから、インターネットに恩返ししなくちゃいけない」ってことを言っていて。そういう感覚は自分にもあるかなと思います。
ブログやブックマークやXを通じていろんなこと教えてもらったので、その分は返していきたいですね。
自分が欲しいコミュニティを作る
コミュニティ活動をいっぱいやってるのも、インターネットへの恩返しの一環だったりしますか？
あんまり高尚な目的ではやっていない、っていうのが、正直なところではあるんですけど（笑）
コミュニティを活性化させようというよりも、自分が欲しい場を自分で作るという感覚ですね。話すのにちょうどいい場所がなくて。自社でイベントやるのはなかなかカロリー高いし、気軽にちょっと発信できる場所を作っておくといいなと思って。それでCasual Talkっていうのを始めたんです。
今年の頭にやった回は300人ぐらい集めていて、でかくなってますね。
完全に僕のやる気ドリブンなんで、3ヶ月に1回やることもあれば、2年くらい空いたりしていますけど。「頑張らないことを頑張る」のを大事にしています。頑張りすぎると燃え尽き症候群で立ち消えになっちゃうってコミュニティにおいて結構あるあるな話なので。
例えばZoomで録画したものをYouTubeにそのまま出してます。編集とかしだすと続かなくなるので絶対やらないし、司会も頑張らない。「頑張りません」を宣言してからやってます。
それでいながらdatatech-jpは1800人のコミュニティに育ってて、すごいなって思ってました。あと、Xスペース、ずっとやってるよね。
あれはメルカリのna0さん (@na0fu3y） っていう、BigQueryのBQ FUNっていうコミュニティをやってる方と一緒にやってます。10Xや僕がやっていることとスタンスは違っていて、お互いどういう感じで最近の状況を捉えてるのか？とかを話してます。前はMeetで1on1で話していたんですが、特にこれは閉じる必要がないよなと思ったので、MeetからXスペースに場所を変えて、誰でも聞いてもらえるようにしただけです。
いろいろ精力的に活動していて、すごいなと思ってます。
東京をはじめとする都市圏に住んでないと新しい情報のキャッチアップがしづらい、みたいな話があるじゃないですか。僕は全然感じていなくて。インターネットでは長く言われていることですが、やっぱり情報は出す人のところに集まってくるものだと思うんです。僕自身は基本的には雑談とか苦手なんですけど、データの話とかは趣味でもあるのでいくらでもできる。自分がアウトプットしておいたことをきっかけに、誰かが関連した情報を教えてくれたり、それについて話すきっかけを作れたり。なので10年くらい京都にいるけど、東京と比べて不利に感じることはあんまないかな。
面白い。僕は京都に来て、さすがに東京よりも情報入ってくる量減ったなと思ってるんで、それを感じてないっていうのは、syouさんがめちゃめちゃ情報を出しているからなんだろうなというのを思います。
そうはいっても月に1回くらいは出張で東京に行くので、そのときにイベントに参加させてもらったりっていうのはしていますね。あとはXとかでつながりのある方々に声をかけて少人数で5時間くらい飲み会したら、だいたい最新のことはキャッチアップできるでしょ、みたいなノリではいます。
えっ、情報を集めるための飲み会を企画してるんですか！
やりましょうって言うだけで何もしてませんけどね（笑）お店は全然わからないので助けて貰ってますし。
ただ、事前に「こういう話が聞きたい」とか「これについて話したい」みたいなのは準備していっています。飲み会で話せなかったり、喋り足りないことがあれば、Xスペースやポッドキャストとかの場を用意することで、話すことができるんです。なので「これについて話しませんか？」みたいなことは自分から声を掛けていますね。そういうときも、普段のアウトプットを見てもらえてるので、前提が揃ってたり、更に話が広がったりするのが便利だなと思います。
うまく自分好みのコミュニティを作りましたね
すでにあるコミュニティに入っていくより、最初からデザインしちゃうと楽なんで。こういうのやりましょうっていうのを言い出しっぺで作って、あとはもうそこに乗るだけ、みたいな （笑）
SnowflakeとかTableauとかのコミュニティやユーザーグループって、すごくしっかりしているじゃないですか。それはそれでとてもいいことだと思うんですが、自分が言い出しっぺで作るコミュニティに関してはあんなに頑張れないなと思って。最初から頑張らない前提なので、集まってくれたdatatech-jpの運営メンバーとはそこが共有できている分、すごく助かってますね。
いやー、コミュニティだけじゃなく、情報を得る環境についても自分が欲しいものを作る方が早いというのがとても面白い。
結局、東京に限らずどこに行っても、最先端のことを話しているのって一部の人じゃないですか。あと情報を知ることも大事ですが、やっぱり自分がどれだけ手を動かしたが一番大事で。信じられるのってそこですよね。だからやっぱり3ヶ月とか半年くらいは、インプットして手を動かして、という期間が必要なので、それくらいの頻度のコミュニティ活動でも全然いいんじゃないかなとか思っています。
どっちかっていうと、事業で手を動かすチャンスがある方がむしろ大事かなっていう気もします。その点、10Xはすごい恵まれていますね。技術的なチャレンジをしたいというより、事業的な課題をどうにかせねば、みたいなところから機会が生まれてくるのが幸せなことだなと思います
なるほど。僕の場合は、自分が手を動かすまでに、2、3回同じ話を聞いたら「そろそろやるか」となるんですが、この「2、3回聞く」までの時間が、東京にいる時と地方にいる時と全然違うな、みたいなことを思っていて。
そこで言うと、多分ソフトウェアエンジニアリングのところとデータエンジニアリングのところの層の厚さみたいなのが如実に出るかもなと思います。データエンジニアリングは1/20くらいなので。
だったら話を聞いたら、飛びついた方がいい？
僕もある程度は大人になったので、飛びつくこともゼロではないものの、自分が関わっている事業の課題に繋がりそうだなというアンテナを張って、可能性がありそうなものは試したりという感じです。試すハードルも生成AIで下がったし。
syouさんは、はてなを辞めてからの方が、OSSのコントリビュートも増えてますよね。
タイミングがそうなっただけという感じではありますが。いま積極的なのは間違いなく、はてなでの経験があったからですね。
かつては、OSSにプルリクエストを出すのはスーパーエンジニアだけがやることだと思ってました。はてなでMackerelチームでリクエストをもらう側になって、仕事としてOSS活動に触れる機会をもらえたのは良かったですね。確実に今に活きてるなと思います。
出てからの方が、外向けに出てる量が増えたのが面白いなと思っています。出しやすくなったきっかけとかあるんですか？ 自分が困るようになったとか。
それはあると思います。Webサービスを作っていて何か困ってもOSSにプルリクエストを送るほど深入りしたかで言えば、自分のモチベーションとしてそこまでは湧ききれないみたいなところはあった。データ基盤の方だと、ここをどうにかしてやらないといけない！みたいな感じで、モチベーションと自分の趣味や興味が合ってた、のはありそうです。
なるほどね。自分の興味領域で、何とかできる能力も持っていて、データエンジニアリング業界にはコードで貢献する人が少ないのでコントリビュートする機会も多いと。
多分、ソフトウェアエンジニアの業界だと普通な活動ボリュームでも、データエンジニアの領域でやると頑張ってるねと言ってもらえちゃう気はしてます。dbtのCommunity spotlightに選んでもらったり、Google Developer Expertに選んでもらったりしましたけど、ソフトウェアエンジニアからすれば、全然普通のことやってるような感覚でしょうから、いいの？とは思ってます。
いやいやいや。素晴らしいですよ。
Mackerelでの機能開発とデータ基盤
ガラッと話を変えて、はてなでの仕事の思い出話もしておきましょうか。大きい仕事としては、Mackerelのロール内異常検知とデータ基盤の構築だったのかな。
そうですね、ロール内異常検知は思い出深いです。
社会人になって何回か転職してますけど、一番しんどかったのはNTTからはてなに入ったときだなと思っていて。研究者からソフトウェアエンジニアに職種をガラッと変えたし、ソフトウェアエンジニアとしては、はてなの優秀な新卒の方々のほうがはるかにできるような状態で。プルリクエストを出したら50個以上コメントもらったり、チームには
id:itchynyさん（サイボウズ株式会社 濱田健さん 参考：サイボウズで活躍中のid:itchynyを訪問 | はてな卒業生訪問企画 [#11] - Hatena Developer Blog）とか
id:astjさんみたいなめちゃくちゃできる人たちがいて、「すげぇ、これはどうやったら生き残れるんだ」と思って、入って1年半か2年くらいはすごい苦しんだなと。ただ、そのあとやっとロール内異常検知という自分の専門性が多少なりとも発揮できる機械学習を使った開発の機会が巡ってきたというのと、あとは苦しんでいた期間に多少なりともエンジニアとして成長できたり、Mackerelのドメイン知識もついたりというのがあったので、そのあたりが嚙み合ったタイミングだったなと思ってます。
コスト観点や、「異常」の解釈や判定基準などは、いま振り返ってもうまくできたかなと思ってるので、専門性やエンジニアとしての成長を感じられる良い機会でしたね。
当時、誤検知と検知漏れがどうしても出てくる中で完了の定義をどうするかって話をしていましたよね。今だと生成AIでやる可能性もあるのかしら。
データが同じなら同じ結果になる再現性みたいなところとか、ML Ops的なところもすごく重視して作っていたので全然違いますね。コストが事業的にペイするかとか、チームの中で機械学習専任がいるよりはソフトウェアエンジニアだけでやれる方がとか、色々考えるところはありますが、うーん、今振り返っても、あれでいいと思っています。
なるほどなぁ。今も元気に動いていますよ。
しばらく実際に鳴ったアラートを全部見ながら、ひたすらスプレッドシートでこれは正しそう、正しくなさそう、みたいなのをラベリングしてたのを思い出しました。ああいうのはすごく楽しかったですね。
その後が、データ基盤の作成ですよね。
データ基盤は1年くらいしたら大体何か形になってきたなって感じでしたね。事業計画やCREの活動にも使えるようになって。
KPIもそうですが、仮説検証サイクルを高速に回したいという、プロダクトの開発を早くするための役に立ったのが本当に助かりました。こういう人は何人居るんだろうがすぐ分かるようになると状況が変わりましたね。
良かったです。
僕の気になりとしては、はてなは僕が居た時代から変わらずデータエンジニアを専任としてたてたり採用したりするのではなく、ソフトウェアエンジニアが兼任みたいなかたちなんですかね？いまはどういう感じで回ってるのかな？ という興味があります。
ここは何度かやろうとしては失敗してるのが現実ですね。専任として立ち上げできそうだったけど、キーマンが転職してしまったり。でもプランナー、PdMがクエリを投げるのが普通の世界になったのは当時との差分かな？
そうですね、クエリに限らず、なんか色々異常にできてしまう、みたいな人がいると、変に作り込まずにいけるところはありますよね。会社としてそっちを選択することもあるのかなと思います。
今のプランナーの人たちも、AIに聞きながらChrome拡張を作って、業務を楽にしました、とか言っていて、頼もしいなと思っています。
その辺ははてならしいなーと思います。
いまのはてなはどう見える？
じゃあ、最後に、はてなに物申すコーナーいきますか ？
あんまり考えてなかったな。そうだなぁ。物申したいわけじゃなくて、応援したい、みたいなところはあります。
おぉー
「知る」「つながる」「表現する」っていうはてなのミッションの部分。特にC向けのブログに自分もずっとお世話になってきました。ただ、世の中的には色んなブログサービスが閉じちゃったり、生成AIによってトレンドや検索行動の変化したり、ブログに来てくれる人が減ったり、収益化が難しくなっている現状もあるのかなと想像しています。
20年くらいブログを書いていると、そこは第二の自分のうちというか、第二の自分みたいな感じになってくるんですよね。その表現する場としてのブログとかの場を、引き続き頑張って欲しいなと思っている、という感じです。
エンジニアだと、自分のブログサービスを立ち上げることもできるといえばできるんですけど、さすがに20年となるとはてなブログへの愛着があるので。
自分でブログを立てるのは勉強になるのですごく良いんですけど、作ったあとメンテできなくなってよく潰れるんですよね。サービスとしてずっと残るところに自分のデータを預けたい、みたいなニーズはありますよね。ここはプライドを持ってやっていくつもりでいます。
自分もそうですけど、さっき言った、過程を残して、他の人が追体験する。自分がやるだけじゃなくて、誰かの自己表現を見て、自分も楽しみたい・学びたいところはやっぱりあるので、そういうことが実現されるプラットフォームとして、今後も頑張ってほしいな、って思っています。
ありがとうございます。やっぱりtoCサービスを頑張ってと言ってもらえることが多いので、今後も頑張ります。
id:syou6162さん、ありがとうございました！id:syou6162こと吉田さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2026年1月頃更新予定、担当は初登場の 
id:daiksyです。
