こんにちは、CTO の 
id:motemen です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの id:motemen、エンジニアリングマネージャーの 
id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:motemen が担当する第14回のゲストは、ポーランドを拠点とするソフトウェア開発およびコンサルティング企業であるVirtusLabで、Scalaのコンパイラエンジニアとして活躍している
id:tanishiking24 さんこと、谷口力斗さんです。
id:tanishiking24 さんは、京都大学工学部の学生時代からはてなにアルバイトとして所属。その後、2017年に新卒で入社し、「はてなブックマーク」をScalaとDDDで完全リライトする大規模なフルリニューアルプロジェクトを担当するなど、2020年に卒業するまでの間、はてなのサービス開発に大きく貢献していただきました。
現在の所属であるVirtusLab社は、Scalaを開発したスイス連邦工科大学ローザンヌ校（EPFL） の LAMP（Laboratory for Programming Methods） 研究室と連携し、Scala 3の開発支援やScala関連ツールの開発・OSSプロジェクトへの貢献などに取り組んでいます。
今回はtanishikingさんに、VirtusLab社でのScalaのコンパイラエンジニアという仕事についてや、VirtusLabご入社の経緯、最近取り組まれているプロジェクトなどについて、お話を伺いました。
谷口力斗さん（
2017年4月～2020年8月 はてな在籍
X：https://x.com/tanishiking
Blog：たにしきんぐダム
- ポーランドの会社 VirtusLabでScalaのコンパイラエンジニアとして活躍
- はてなを退職後、VirtusLabと出会ったきっかけ
- オープンソースプロジェクトの醍醐味とは？
- VirtusLabのScalaチームがやっていること
- ScalaのWasmバックエンドを実装することになった経緯
- これからのキャリアについて
- はてなに入社した動機・大きな仕事・活かされた経験は？
- いまのはてなはどう見てる？
ポーランドの会社 VirtusLabでScalaのコンパイラエンジニアとして活躍
id:motemen（以下、） 今回は、tanishikingさんをお招きしました。よろしくお願いいたします。
現在、tanishikingさんは、ポーランドのVirtusLab社に所属して、Scalaのコンパイラエンジニアとして働いているということですが、気になることがいっぱいあります！お話を伺うのを楽しみにしていました。今日はよろしくお願いします。
id:tanishiking24（以下、） 僕もお話できるのを楽しみにして来ました。よろしくお願いします。
id:tanishiking24 こと、谷口力斗さん VirtusLabさんの拠点はポーランドですが、tanishikingさんは関西のご自宅からリモートで働いているんですよね？
そうです。
時差もあると思うんですが、どんな働き方をされているんでしょうか。
週に何度か日本時間の夕方から夜にミーティングがあるのですが、基本的に仕事をする時間は自由です。朝から仕事をすることもあれば、夜中に集中して仕事をすることもあります。ポーランドとの時差が7-8時間あるので仕事の時間が自由なのはありがたいですね。
ポーランドのオフィスに行くことはそんなに無くて今までも2回しかオフィスに行ったことはないのですが、世界各地で開催されるカンファレンスで同僚と会ったりすることはありますね。この間は日本で開催されたScalaMatsuriに同僚が何人か遊びに来てくれました。
VirtusLabがどんなことをしているか教えていただけますか？
VirtusLabは、ScalaやJavaやTypeScriptなど様々な言語を使ったクラウド開発から、IDEやBazelなどの開発者ツールに強みを持つソフトウェアエンジニアリング企業です。
社内にはScalaのエキスパートがいて、企業のコンサルティングを担当したり、EPFL（スイス連邦工科大学ローザンヌ校）やLAMPという研究室などと連携して、Scala言語の開発とエコシステムの強化に貢献しています。僕もコンパイラエンジニアとしてそこに関わっています。
はてな注：
Scalaは、2001年にスイス連邦工科大学ローザンヌ校（EPFL） の Martin Odersky教授のLAMP（Laboratory for Programming Methods） 研究室で開発が開始されたプログラミング言語です。Scalaの開発・研究には、EPFL・LAMPのほか、2016年にEPFL内に設立された非営利組織であるScala Centerが関わっており、Scalaの教育、コミュニティ支援、オープンソース開発を推進しています。
VirtusLabは、これらの組織と連携し、Scala 3 の開発支援、Scala CLI や Metals などのScala関連ツールの開発、Scala Toolkitの提供、OSSプロジェクトへの貢献などに取り組んでいます。
VirtusLabにいるScalaのエキスパートがScalaコミュニティに深くかかわることで、自社の技術広報にもなるし、Scalaを使ってプロジェクトやっていく中で、困ってる部分とかをScalaやアップストリームに還元するから、Scalaも嬉しいし、VirtusLabも嬉しいという感じなんですね。
はい、そうです。
はてなを退職後、VirtusLabと出会ったきっかけ
ご入社までの経緯が気になっています。どんな過程だったんですか？
もともとは趣味の時間に、Scalaのコードフォーマッターやリンター、language server実装のMetalsの開発に関わっていました。
その中で、ScalaのOSSプロジェクトにフルタイムで関わる人がVirtusLabにいることを知り、日本から雇ってもらうのは難しいと思いつつも、思い切ってその方にポストが空いていないかDMで尋ねてみました。
その結果、以前からOSSでやりとりしていて信頼関係を築けていたこともあり、しばらくしてポストが空いたタイミングで入社させていただけることになりました。
そこでポーランドにたどり着いたわけですね。そういう仕事があると知って、すぐに自分も働きたい、という感じになったのでしょうか。
このまま趣味で続けていくという選択肢もありました。ただ、趣味でやっていると、どうしても大きな仕事ってやりづらくて。フルタイムでできたら、もっといろんなことができるんだろうなと思って。まずはダメもとで聞いてみたら仕事をいただけたという感じです。
オープンソースプロジェクトの醍醐味とは？
オープンソースのメンテナンスは余暇の時間を自分で工面してやっている人が多いから、どうしても自分のプライベートを犠牲にしたり、OSSの仕事をまとめてやれなくて、少しずつやるという進め方になりがちですよね。
フルタイムで貢献できるっていうのは、違った楽しみがありそうに思います。オープンソースプロジェクト自体にもすごくいいことがありそうですが、実際やってみてどうですか？
趣味の時間だとやろうとすら思わなかったであろうことに手をつけられるようになったのは、すごくありがたいですね。今、僕がやっているWebAssembly（Wasm）バックエンドの開発などはかなり時間がかかるので、余暇時間でOSSをやっていたら手が出せなかったと思います。
確かに、やろうとも思えないくらい時間がかかりすぎるのもあるし、その間にScala.jsとかScala本体が進化しちゃって、追いつけないみたいな。
やってもやっても全然進まないから、途中で諦めちゃったりするかもしれないな、とは思います。
モチベーションを維持させる意味でも、ちゃんとまとまった時間を使えるっていうのは大事なことですよね。今はScalaに貢献するというのがミッションになるということでしょうか？
今のところはそうです。ただ、たまに社内外のクローズドなプロジェクトなど、OSSではないプロジェクトに配属されて、開発するということもあります。例えば最近だとScalaプロジェクトのビルド高速化のためにBazelというビルドシステムに移行する仕事に携わったりしました。
Scala本体に貢献をすることもあれば、Scalaを使う側になることもあるんですね。
VirtusLabのScalaチームがやっていること
VirtusLab社のなかで、Scalaのコンパイラエンジニアはどのくらいいらっしゃるんですか？チームみたいな形になってるのでしょうか。
Scalaのコンパイラエンジニアは今だと4〜5人ぐらいいますね。そのチームで定期的にミーティングをして、自分がやってることを話したりはするんですけど、基本的にやっていることはみんな別々です。
たまに「この部分のバグで困ってるんだよね」という話をすると、そのバグに詳しかったり、その部分に詳しかったりするので、協力してくれます。だから、チームとは言いつつ、個人で開発して情報共有をする立ち位置のチームになりますね。
社内のメンバー以外のScala貢献者ともScala開発者会議のような場で会話する機会はあったりするんですか？
EPFLの方と一緒にScalaのコンパイラの開発をどう進めていくかといったミーティングは定期的に開催されています。
tanishikingさんの上司になるようなマネージャーとかもいらっしゃるんですよね？
はい。ただ一般的に想像されるマネージャーとは違うかもしれません。マネジメントそのものみたいなことはやってなくて、基本的に外部とのやりとり上の窓口としてやりとりしています。
コーディネートする人という感じですかね。活動が基本的に個人なんですね。
そうです。個人個人に対して、こういうタスクがあって、これをいつまでにやってくださいと言われる感じだと、自分がやるべきことがはっきりしてて、楽ではあるんですけどね。仕事の専門性が高いので、自分でマネジメントできる前提で、基本的に個人で仕事を見つけてやっています。
ScalaのWasmバックエンドを実装することになった経緯
今、ScalaのWasmバックエンドを生成するプロジェクトをされているとのことですが、その仕事を担当するようになった経緯について教えてもらっていいですか？
もともと、ScalaNativeという、ScalaのLLVMバックエンドの開発をやっていたんです。それがひと段落したタイミングで、ScalaもWasm生成したいよねという話が持ち上がるようになりました。
2023年にマドリードで開催されたScalaの国際カンファレンスScalaDaysで、Scalaの生みの親のMartin Odersky先生とお話ししたときに、「次は何やる? Wasmはどう？」と声をかけていただいたのがきっかけで、Wasmバックエンドについて調査を始めました。
Odersky先生に言われたら、もうお墨付きをもらった感じですね。
はじめはScalaNativeをベースに調査していたのですが、調査していくうちに、最終的にScalaNativeじゃなくて、Scala.jsの方からやった方が良さそうだということが分かり、Scala.jsをベースに実装を進めることにしました。
面白い。そもそも、ScalaをWasm化するメリットについて教えてもらえますか？
Wasmの利用用途としては今のところざっくり分けて2つあります。1つはブラウザ上で実行するWasm。もう1つブラウザ外のサーバーなどで実行する、いわゆるサーバーサイドWasm。
ブラウザ上で実行するWasmについては、JSと比較して最適化の余地が大きいこと。そしてサーバーサイドWasmについては軽量なサンドボックス環境が魅力かなと思います。
Wasm化の何が嬉しいかというと、コンテナと比べてVMの起動がめちゃくちゃ早いんですよね。マイクロ秒レベルで起動できるのが1つの強みです。それでいてセキュリティの面でも、サンドボックス内で動作し、明示的に許可したホスト環境のリソースにしかアクセスできないなどの強い制約があります。
これらにより、信頼できない開発者によるコードを軽量かつ安全に実行することができるようになります。
また、いろんな言語からWasmにコンパイルできるという点も大きな魅力です。こうした特徴から、コンテナに並ぶ新たな選択肢として「サーバーサイドWasm」が注目されています。
最近、エッジでも使えるみたいな話が出てきたりしているし。確かにコンテナほど何でもできるわけではないけど、セキュアだし、軽量な選択肢としてWasmが割と現実的になってきているわけですね。
そう思います。そこにScalaも参画できたら面白いし、ScalaをWasmにコンパイルしたいというモチベーションですね。
もう一つのモチベーションは、Wasmコンポーネントモデルという、いろいろな言語とのインターオペレーションを簡単かつ安全に実現するためのWasmの一つ上のレイヤーを提供するプロポーザルを使った試みです。例えば、ScalaからRustのコードを呼び出したりRustからScalaのコードを呼び出したり、そういった他言語間関数呼び出しを容易にする提案です。
RustやGoなど、最近の言語もWasm生成をサポートしがちだし、Scalaがもう一つの選択肢として出てくるのはよさそうですね。Scalaを実行するのにJVMが必要といった前提を取っ払えるわけですよね。
そうですね。もちろん現状のScalaが生成するJVM/JS/Nativeコードを使って外部関数呼び出しをすることは可能ではあるのですが少し難易度が高い。
ScalaをWasmコンポーネントにすることによって、Scalaのライブラリを他の言語に提供する敷居を下げて、間口を広げることができるし、逆にScalaいろんな言語の関数を呼び出すこともできる。コンポーネントモデルという一つの窓口があれば、いろんな言語がお互い呼び出すことができるんです。
一回Wasmにしてしまえば、どんな言語とでもそれが対応していればやり取りができるというわけですね。
はい。Wasm Component Model が今後どうなっていくかはわかりませんが、もし実現できたら面白そうな世界が広がっていると思ってやってみています。
こういうプロジェクトをやるときって、100%できるって分かった状態で進めるのか、それともできるかどうかわからないけど、時間かけてやってみるかでいうと、どうなんですか？
まずは技術調査して、プロトタイプを作ってみて、それで筋が良さそうだと思えたら本格的に時間をかけてやってみるという感じになります。
ただ、研究開発に似たプロジェクトなので、100%うまくいくと分かった状態で話が進むことはなかなかないと思います。
ScalaNativeでは、ScalaのLLVMバックエンド、つまりScalaをネイティブのバイナリーにするためのコンパイラのバックエンドがありますよね。このLLVMを経由してWasmにするってことができるんじゃないかと思ったんですけど、それはどうなんですか？
可能ではあるけれどいくつか問題があるなと思っています 。僕の同僚がすでにemscriptenというC/C++からLLVMを使ってWasmに変換するコンパイラを使ってプロトタイプを作ったのですが、技術的な問題がいくつかありました。
その一つがガベージコレクションです。ScalaのようなGCによるメモリ管理を前提とした言語をWasmに変換するときは、基本的にGCコードをWasmモジュールに組み込んであげることになります。
GC Rootから到達可能なオブジェクトを探索することで、不要になったオブジェクトを見つけていくのですが、GC Rootを特定するためにはスタックをインスペクトする必要があります。でも、Wasmってスタックをインスペクトすることができないという制約があるんです。
ワークアラウンドとしてはAsyncifyというプログラム変換ツールを使ってプログラムの実行状態をメモリ上に保存してあげることで問題を回避することはできます。
しかしこのような変換を行うと、実行時オーバーヘッドを受け入れることになり、これは良くないかもしれないという結論に至りました。
確かに、ScalaをWasm化するためにはGCの存在が壁になるんですね。
一方で、WasmGCっていうWasmにGCをマネージドなstructを生成するための命令や型とかを追加する、Wasmの提案があるんです。WasmGCというプロポーザルで、ちょうど僕 がWasmをやろうと思い始めた2023年末か2024年ぐらいにいろんな実行エンジンで広くサポートされ始めました。
2024年だったら、WasmGCを使うことも一つの選択肢なんじゃないかということになりました。GCはもうWasmGCに任せるっていう形で実装すれば、GCの問題は解決します。
Wasmの実行エンジンがGCのスペックに対応しだしたから、Wasm上でGCを実現できる見込みが出てきた。そんな中で、Scala.js経由だとうまくいく、というのはどういうことなんですか？
Scala Native は LLVM を前提として設計されたバックエンドなんですけど、LLVM IR は低いレイヤーの命令セットを想定していて、WasmGC のような比較的高級なプログラミングモデルにそのまま適用するのが難しいようです。そもそも C/C++ から WasmGC にコンパイルすることも試みはあったようですが難しいみたいで。
LLVMの表現になった時点で、既に結構低いレイヤーになっているんですね。
はい。LLVMが使えないとなると、それに大きく依存しているScalaNativeを使うのは難しい。そのうえScalaNativeの中間言語もかなりLLVMに寄った設計になっているので、ここからWasmGCを使うのは骨が折れそうだなと思いました。
その点、Scala.jsで使っているIRは、もうちょっと高級だということですね。
そうですね、Scala.jsの中間言語は十分WasmGCに変換できそうで、簡単に言語コア部分のプロトタイプを作ることができました。
サーバーサイドWasmを実現するためには最終的にはJS依存をなくしたいという話はあったんですが、第一段階として、JavaScriptに依存したバックエンドを生成して、そのあとJavaScriptへの依存を無くしていくというやり方ならなんとか実現できそうという印象がありました。
JS依存の部分を残しておくことで、最初のステップが達成しやすいということですね。
そうですね、ただこのあたりの意思決定はすごく自信があるわけではなく、もしかするとLLVM経由の選択のほうが良かったんじゃないかと思うこともあります。最後まで実装して自分の選択が正解だったと示すことができたら嬉しいですね。
これからのキャリアについて
ここからは、キャリアについてお話を聞いていきたいと思います。今はScalaのコンパイラをやっていらっしゃいますが、これからは何をやっていきたいのか。このままScalaをやっていきたいのか、コンパイラをやっていきたいのか。そのあたりはどんなふうに考えていますか？
Scalaはすごく面白い言語だと個人的にも思っているので、しばらくなんらかの形でScalaには関わり続けていくと思います。他のメジャー言語と比べると採用面なんかで難しいところはあるんですけど、すごく面白い機能がたくさんあって、一つのやることに対して、いろんな書き方ができるというところなどですね。なんていうか、おもちゃとしてすごく面白いし、本当に全然飽きない言語だと思います 。
一方で、キャリアとしては、Scalaそのものにはあまりこだわりはないんです。どちらかというと、コンパイラだったり、もうちょっと低いレイヤーに興味があるかんじです。コンパイラのパーザや型チェッカーなどに興味があると思っていたんですけど、やっているうちにバックエンドのコードを生成する部分の方が楽しいかもと思うようになりました。
やっているうちに気づくというのは面白いですね。この先は、どこにたどり着いて何をやっていたいですか？
今はWasmのバイナリを生成するところをやっていますが、今後はWasmに限らないより低いレイヤのコンパイラバックエンドの開発にも興味があります。
より低みを目指していくかたちですね。ちなみに、そういうことをするときに、海外の企業がいいとか、日本でやりたいとか、ロケーションや国に関する希望ってあるんですか？
住んでみたいと思う国はあるものの、特に海外で働きたい！という思いは無いですね。どちらかというと日本に大切な家族や友人がいて住みやすいとも思っているので、できることなら日本を拠点に生活を続けていきたい。
ただコンパイラ開発は選択肢が限られた職種なので、一応日本に限らないポジションや企業もウォッチしています。
日本の会社でコンパイラをやるのは、選択肢が少なくて難しいですね。
コンパイラエンジニアは、そもそもキャリアの選択肢がかなり少ない職種なので、日本に住み続けたいと思いつつも視野を広く持っておきたいと思っています。
コンパイラは日本国内でえり好みしてると、選択肢が本当に狭くなっちゃうんですね。
はてなに入社した動機・大きな仕事・活かされた経験は？
tanishikingさんは、はてなに入社した時はWebアプリケーションエンジニアでしたが、そもそもはてなの入社の動機って、何だったんですか？
IT企業でソフトウェアエンジニアになろう、そもそもプログラミングが好きだなっていうことに気づいたのが、大学時代でした。とりあえずプログラミングをやれたらいいな、というふうに思っていたので、大学院で研究するより学部で卒業して就職した方がプログラミングする機会はたくさんあるかなって思ったんです。
その時にどういう会社に就職しようかなと考えたときに、自分が使っているサービスの一つとしてはてながあって、それではてなが選択肢になりました。あと知り合いが何人か、はてなで働いていたことや、イベントなどに参加して自分の性格に合っていて過ごしやすそうな会社だなと思ったことも理由の一つです。
そう言ってもらえると嬉しいです。tanishikingさんには、「はてなブックマーク」のリプレイスという大きなプロジェクトに関わってもらいました。そこでの経験で覚えていることや、いま活きているなと思うことがあれば伺いたいです。
今も活きていると思うことが大きく2つあります。1つは、レガシーアプリケーションとの付き合い方です。すごく巨大でいろいろな人の手垢のついたアプリケーションをリプレイスするときは、まず現状のシステムやロジックがどうなっているのかを精査しないといけません。
一方コンパイラのようなソフトウェアもすごく息の長いプロジェクトで、10-20年前に、すでにプロジェクトから退いた人によって書かれたソフトウェアを読むことがよくあります。はてなでは、そういった巨大で歴史的経緯が複雑なシステムに触れる機会があり、ひとつひとつ読み解いていけばなんとかなるという成功体験が今のコンパイラ開発でも役に立っていると思います。
はてなのサービスも結構長い方だと思いますけど、コンパイラ自体はもっと長いわけですよね。
コンパイラをブラックボックスだと思わず、ただのプログラムっていう文字列を受け取って、別のコードを生成するアプリケーションなんだと思えるようになりました。はてな時代にいろんな複雑なコードを読み進めたおかげで、そういうふうに見ることができたというところは、大きな経験だと思います。
読めば分かるって思えるのは大事ですよね。ちょっと巨大すぎたり、古すぎたりすることで、読めないってなっちゃったらどうしようもない。
もう一つが、これも巨大ソフトウェアとの付き合い方に関する話ではあるのですが、大きなソフトウェア開発プロジェクトのタスクの洗い出しです。
「はてなブックマーク」をリプレイスするにあたって、 何をやるべきことなのかなどをリストアップすることが ありました。その時にやったのが、「はてなブックマーク」の既存のすべてのエンドポイントを全部、コードを一個一個見ていく。
実際のソフトウェアを動かしながら洗い出していって、リストアップして、そこから優先順位をつけたり、このエンドポイントを移行するのは、このためには、この機能が必要だとかの依存関係の洗い出しをやっていました。
すごく大きなプロジェクトであっても、そういうやるべきことを1個、1個全部洗い出していって、その依存関係を作っていけば、自分がやるべきことって見えてくるんだなということが学べた体験でした。
タスクをどういう粒度で分解していくのか、依存関係の優先順位をつけて、一個ずつつけていくというプロジェクトマネジメントの基礎的なやり方が今でも通用するというのは面白いですね。Webサービスとコンパイラって全然離れてるけど、そこでも使えてるっていうのも興味深いです。
そういうWasm化みたいなプロジェクトも、自分でプロジェクトマネジメント、セルフマネジメントしなきゃいけないんですか？
そうですね。自分で直近のタスクを洗い出して管理しています。一つ一つのタスクによって難易度が変わるので、精密な議論まではできないんですけど、進捗を共有するのには便利です。それに、細かいゴールを作ることで、自分のモチベーションを維持するのにも役立っています。
タスクが大きすぎると進捗がわからなくなるから、すこしづつ区切ってやるというのは、すごく大事ですね。
活かされた経験、というと少し違うかもしれないのですが、もうひとつはてな時代に経験できたことがよかったことがあって。
卒業生企画の
id:itchynyさんの回でも言及されていたんですけど、はてなの社内ブログ文化だったり、テキスト文化ってすごく強いというか、面白いなっていうのを、他のところに行って、改めて気づきました。
はてなでは、ちょっとした技術Tipsとか社内ブログに書きやすいし、社内限定のアーキテクチャというか、外部にはちょっと発表できない感じの話なども書きやすかった。技術発信がすごくしやすい文化だったのは良かったですね。
最近はリモートになっているから、オフィスで直接顔付き合わせて話す機会ってほぼなくて。だから、こういうテキストでコミュニケーションをするっていうのが、より重要になってきているという感じですね。ただ、チームによってツールが違ったりするので、共有しやすさは意識的に作っていこうと思っています。
Slackだけだと簡素なコミュニケーションになりがちで。まとまった技術共有は、社内技術ブログとかって、すごく有効な手段でしたね。
あまり構え過ぎなくてもいいんだけど、ちょっと書くぞっていうつもりで臨まないと、書けないことってありますよね。
いまのはてなはどう見てる？
最後に、はてなに物申すというか、外から見てはてなに対して思うこととか。そういうことがあったら教えてほしいです。これは率直に教えてもらえると嬉しい。
最近、toC以外にもtoBで、「はてなCMS」だったり、「toitta」だったり、新しいサービスがどんどん出てきていますね。toBサービスではあるけど、はてなっぽいというか、テキストコンテンツをベースとしたサービスだったり、toB向けにユーザージェネレイティッドなコンテンツを作るところが個人的にはてなっぽいサービスだなと感じました。toBサービスがすごく盛り上がっているのが、すごく嬉しいと思っています。
そう言ってもらえると嬉しいですね。すごくいろいろアイデアを出した中で採用された事業で、ユーザーインタビューしまくりました。「Mackerel」とかみたいなSaaSも自分たちがサーバーの管理とか、監視するために作ったプロダクトを売り出していった。「toitta」も結構そういう形で出てきたっていうのは、すごく面白い。
toCじゃなくても、そういうはてならしさが出てきているのは面白いです。
そうだね、はてならしさってなんだろうなって考えたりもするけど。こういう、はてなだから面白そうと思ってもらえるとか、いいねって思ってもらえるものは作っていきたいですね。
はてなの自社プロダクトがたくさん新しく出てきて、盛り上がっているのは嬉しいです。法人向けって書いてあるけど、個人でも「はてなCMS」使いたいです（笑）。
自分たちがやっている事業やプロダクトも、新しい展開を作っていくことができているのはすごくいいなと、自分たちも思っているんですよね。はてなはサービスや事業をあまり変えずに長くやっていくパターンが多かったので。
ビジネス的に盛り上げていくために、新しいものを作ったり、ちょっとドラスティックなことをやってみるという事業形態ができつつあるのは、いい変化がだんだん起きてきてるなとは思っています。
エンジニアの意識も事業の目線を持つといういい方向に変わってきているので、はてなもいい方向に成長していっていると思います。今日はありがとうございました。
id:tanishiking24さんこと谷口さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2025年5月頃更新予定、担当はid:onkです。
