こんにちは、CTOの 
id:motemen です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの id:motemen、エンジニアリングマネージャーの 
id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:motemenが担当する第11回のゲストは、サイボウズ株式会社でソフトウェアエンジニアとして活躍している
id:itchynyさんこと、濱田健さんです。
itchynyさんは、京都大学大学院工学研究科電子工学専攻修了後、はてなに入社。Mackerelチームやはてなブックマークチームでアプリケーションエンジニアとして活躍していただいていました。2021年にサイボウズ株式会社に転職し、Webアプリケーションエンジニアとして、kintoneの基盤チームで開発に従事しています。
現在はkintoneチームでインフラ基盤の移行を進めているというitchynyさんに、現在のサイボウズさんでのご活躍や、OSS活動、はてなを離れてみての印象など、お話を伺いました。
濱田健さん（
2015年4月 - 2021年10月 はてな在籍
X:https://x.com/itchyny
Blog: https://itchyny.hatenablog.com/
- サイボウズのkintoneチームで、インフラ基盤移行を担当
- kintoneのQA、テクニカルライターの仕事とは？
- kintoneのNeco基盤（Kubernetes）の開発・移行
- サイボウズとはてなの社内文化・カルチャーの違い
- サイボウズの開発文化、モブプログラミングとは？
- itchynyさんのOSS活動の作品とモチベーション
- はてな時代は技術的な記事を社内・社外に発信
- いまのはてなはどう見てる？
サイボウズのkintoneチームで、インフラ基盤移行を担当
id:motemen（以下「」） 今回のゲストは、サイボウズ株式会社のitchynyさんです。
インターネットではときおりお見かけしていましたが、改めて顔を合わせるのは大分久しぶりなので、懐かしい感じで嬉しいですね。
今回お声がけさせてもらったのは、itchynyさんがはてなを卒業して3年弱というのもあるし、自分が作ったOSSのメンテナンスもしていただいているので、今のご活躍と個人的な活動に関してお話を聞けると楽しいかなと思っています。
id:itchyny（以下「」）よろしくお願いします。
id:itchyny こと、濱田健さん まずは、いまitchynyさんがどんな仕事をされているのかについて、聞かせていただきたいです。
現在は、サイボウズ株式会社で、kintoneという製品の開発に携わっています。サイボウズにはグループウェア製品が4つあって、kintoneとサイボウズOffice、Garoon、Mailwise（メールワイズ）という製品があるのですが、その中のkintoneですね。
kintone開発の基盤チームに所属していて、新機能を開発するチームのサポートやCIなどを担当しています。いま取り組んでる大きいテーマとしては、Neco基盤（Kubernetes）への移行などがあります。
kintoneという製品単位で基盤チームがあるんですね。会社全体で見てもエンジニアが300人くらいでしたっけ。はてなの倍くらいだったような。kintoneチームだけでも40人くらいでしたよね。
それくらいですね。
itchynyさんがいたときのはてなは、たぶんエンジニア80人ぐらいだったと思うので、その半分が一つのチームにいるという感じなんですよね。やはり規模が大きいなと思うんですけど、kintoneチームに入ってみてどうでしたか？
最初はもう、びっくりしました。開発レーンが4つあって、それぞれレーンというか、サブチームがあって、それぞれでバックログを実装して、リリースしていくみたいなことをやっていました。あと新しい機能を作りながら、同時にフロントエンドのReact化も進めているとか。とにかく開発規模がでかいなという感じですね。
そのレーンやサブチームをまとめる大きなチームの会などはあるのですか？
ありますね。スクラムイベントなどは合同でやったりしています。スクラムの計画とかはある程度同期してやったり、各チームが集まってスプリントレビューみたいな形で作ったものを共有したりしています。
規模は大きくても、うまく情報を同期できていていいですね。itchynyさんの古巣のMackerelチームもわりと大きくなっていて、1チームの中に開発レーンがいくつか走っているんですよ。規模は違いますが、それでもわりと似たような体制になっているような気がします。
kintoneのQA、テクニカルライターの仕事とは？
kintoneの開発チームにはQAやテクニカルライターの担当もいらっしゃるんですよね。
はい。QAは、はてなにはいない職種で最初はちょっと戸惑ったんですけど、品質や機能をちゃんと試験してから世に出すということを、徹底してやっているって感じですね。
昔はQAが手動で機能試験していたのですが、今はかなり自動化されています。その自動テストの内容をQAが設計しています。また、最近はE2E テストをQAが実装する挑戦を始めていたり、より規模の小さなテストに分割してテストピラミッドの構造を改善する活動などもやったりしていて、結構面白いですね。
QAチームの中には、エンジニアもいるんですか？
QA自体がエンジニアのロールの一つではあるんですが、やはりコードを書くことには得意不得意はあって。E2EテストをQAが実装するようになったのは最近の取り組みなんですよね。開発メンバーがサポートしながら、できることが増えていっているという感じです。
いいですね！テクニカルライターは、どのようなことをされているんですか。これもはてなにない職種なので気になります。
基本的にはkintoneの画面に出る文言を全て書いていますね。あとはヘルプやリリースの告知といったところも担当しています。
なるほど。はてなに近いところでいうと、CREがそういうことをやっていたりするかな。CREがQAやテクニカルライターに近い感じなのですね。
kintoneのNeco基盤（Kubernetes）の開発・移行
基盤チームについても、詳しく聞かせてください。基盤チームでitchynyさんは今どんなことをされているのですか。
大きなタスクとしては、やはりNeco基盤（Kubernetes）への移行ですね。これまでオンプレミスの基盤を使っていたんですけど、スケールに問題があったり、独自の技術や知識が要求されるインフラ周りは運用のメンバーしか触れないみたいな状況でした。こういった問題を解決するために、Kubernetesへの移行をやっています。
新しい基盤では、kintoneチームとかGaroonチームが、PodやDeploymentなどのリソースを管理して、例えばPod数を調整したり、再起動したりするのも各チームの責任範囲になっています。負荷状況のダッシュボードを作ってモニタリングを仕掛けたり、新しいサブシステムとしてウェブサーバーを立てたりするみたいなことも、開発チームが自立してできるようになったという感じです。
各開発チームがデプロイから監視まで、オーナーシップを持っていけるようにするための移行なんですね。動いているものを別のものに載せ換えるってなかなか大変そうですね。アプリケーションだけならできそうなイメージはあるんですけど、状態を持っているものも移行しないといけないってなると、そこが一番難しいのかな。
たしかに難しいですね。MySQLやElasticsearchなどそれぞれ管理しているチームがあるんですが、開発チームと協力して、データベースだったらレプリケーションしたり、ダブルライトしたりといったことをやりながら移行しています。
なるほど、それぞれに専門のチームがあるんですね。
もう一つ、機能フラグというトピックもあります。kintoneは顧客の業務影響を考慮して丁寧にケアしているのですが、新しい機能を出すときも、必ず機能フラグによってオン・オフできるようにして出していくんです。
kintoneの上にプラグインやカスタマイズのエコシステムが広がっていて、その上に顧客の業務が成り立っているので、プラグインなどが壊れないように、丁寧なケアをしながらやっています。
たしかにkintoneは、ユーザーが自由にカスタマイズして使えるところがコアの製品だから、それを壊してはいけない。デプロイするときに気を使わなきゃいけないことが無数にあるわけですね。
そうなんですよ。
デプロイをいかにうまくやっていくかということは、基盤チームの大事なトピックになっていそうですね。
デプロイをうまくやるというか、機能を出すリリースをデプロイから分けたいんですよね。今は、アプリケーションサーバーをデプロイするタイミングと、機能自体をリリースするタイミングを分離できるような仕組みを構築しているところです。そこをちゃんと分離して、デプロイ時に障害になりにくいようにしたり、機能の公開を簡単にロールバックできたりする仕組みを目指しています。
なるほど、それは面白そう。デプロイの頻度はどうなんでしょう。
そこまで高くないですね。デプロイの作業を減らすような自動化も進んでいて、今後はよりデプロイ頻度を高めていきたいところです。あと、機能リリースは、それとは別のタイミングでコントロールしたいと思っています。
機能リリースは機能フラグを使って、デプロイとはまた別のタイミングでコントロールしていく、ロールアウトしていくと。なるほど、面白そう。お客様がたくさんいる環境だからこそ、デプロイ以外のタイミングでちゃんとコントロールしたくなってくるわけですね。
そうですね。
サイボウズとはてなの社内文化・カルチャーの違い
はてなとサイボウズさん、この二つの会社を経験して、似ているところと違うところがあると思うのですが、itchynyさんはどんなふうに感じていますか。
はてなも社内の見通しや風通しが良いというか、オープンだなって思っていたのですが、サイボウズも同様にオープンな雰囲気があるように思います。例えば「分報」という文化がある点とかも共通していますね。はてなで言えばSlackのtimesみたいな感じなんですけど。個人が思ったことを自由に書くのも活発で、そういう人が多いですね。
正式に依頼するほどでもないけど、何か疑問に思っていることなどを分報に書くと、それを見て誰かが拾ってくれたりするみたいな。そういう感じも、似ているのかなって思っています。
サイボウズさんははてなより規模が大きいけど、風通しがいいって思えるのはすごいですね。
はてなには、分報やtimesのようなものとは別に、社内のグループウェアを使って、ちょっとまとまったエントリーを書くみたいな場所や文化もあるじゃないですか。そういう場所はあるんですか。
むしろそういうのがないですね。まとまった文章、まとまった感想みたいなのを書く場所はあまりないんです。各チームの手順書などは、Confluenceで管理しているんですけど。社内の技術共有がはてなほど活発ではないので、そういう場所があるといいなと思ったりします。
分報文化も誰かが旗振りして定着していったものなんでしょうか。
そうかもしれないです。入社したときに分報のスレッドを作るように言われた記憶があります。
まるで社内SNS！「分報」でメンバーの状況をハイブリッドワークでも感じられるようにしよう｜THE HYBRID WORK サイボウズのハイブリッドワーク専門メディア
サイボウズさん、そういうカルチャー醸成とかってすごくしっかりやられている印象があります。チーム単位でのカルチャー維持に関してされていることや、チームのマネージャーが気をつけていそうなことって何ですか？
そうですね。チームのというよりも、会社のカルチャーをかなり大切にしている印象です。社内イベントとして、定期的に企業のカルチャーを共有する場があって、企業の理想や文化などを改めて再認識する機会になっています。
そうした機会を作っていくのは重要ですよね。具体的にはどういうテーマがどんなふうに紹介されるんですか？
サイボウズのカルチャーには、理想への共感や公明正大みたいな、いくつか切り口があるんです。今月はこのテーマみたいな感じでトピックを絞ってトップダウンで共有する場がありますね。あと、カルチャーの文言を更新するときは、みんなで投票するみたいなのもあったりして、チームとしてみんなで働く上で、文化の言語化とかそういう理想への共感とかを大事にしている印象です。
サイボウズさんは、社内外向けにそうした発信を丁寧にやってらっしゃる印象があります。文化醸成にも役立っていそうですね。
サイボウズの開発文化、モブプログラミングとは？
サイボウズさんの開発文化ってどんな感じですか？
多くのチームがモブプログラミングをやっていて、基本的に2人以上で画面を見ながらコードを一緒に書き、問題解決、設計、デバッグ、テストなどの作業を協力し合いながら実装しています。
常にモブプログラミングで実装しているんですか？
基本的に毎日ですね。業務時間の半分以上は、大体モブでやっています。知見のキャッチアップも速いし、レビューよりもイテレーションが速く開発が進む気がします。
実装の意図や細かいtipsなんかを的確に伝えられるし、レビュー待ちの時間もなくなって、サイクルが速くなるんですよね。とはいえ開発スタイルには合う合わないなど良い面もあればそうでない面もあるとは思うのですが、みんなもいいと思って、実践しているのですか？
モブプロの文化が続いているってことは、たぶんいいと思っているんじゃないでしょうか。逆に、サイボウズに新卒で入った人などは、レビューする経験があまりないみたいです。何をどう見ればいいのかわからないみたいな声も聞きますし、ずっと一緒にやっているから、一人でまとめてコードを見る機会がなかったりするらしいです。
面白い。モブプロがメインだと、コードレビュー自体が新鮮になるわけですね。これはまさに開発文化という感じですね。とはいえコードレビューも時おり発生する、と。
そうですね。モブプログラミング以外の時間は、それぞれリファクタリングだったり、各々の開発をしたり、それをチーム内でレビューし合う機会もあるので、全くそういう機会がないわけではないです。
サイボウズさんもリモートワークが多いと思うんですが、モブプログラミングがコミュニケーションに一役買っていそうですね。
そうですね。
他にitchynyさんが面白いと思ったことはありますか？
海外ではAWSで運用しているkintoneがあるんですよね。だから、現時点では旧基盤と新しいNeco基盤とAWSの3つで運用しています。同じサービスをこんなにたくさんの基盤で運用するのかって、最初はショックを受けました。しかも、それぞれでデータベースの特性とかも違いますしね。
それだけ製品の提供範囲が大きいということですよね。
基盤が増えると、E2Eテストなどもそれぞれで動かさなきゃいけなかったり、デプロイの手間が増えたりするので、そういうところが難しさになっていますね。
複数基盤ということは、それぞれの基盤を運用する担当が別々にいるということなのでしょうか。
そうですね。それぞれの基盤の担当がいます。
コミュニケーションは大変だったりしないですか？
大変です(笑)。でも、そこは上手く対応しています。責任分解点というのかな。境界はわりとはっきりしているので、依頼なども投げやすいですね。どういうことをしたくて、何を実現してほしいかみたいなことは、依頼しやすい仕組みになっています。
インターフェースがはっきりしているのはいいですね。たしかに、これでコミュニケーションを整理できそう。だからNeco基盤に移行することで、インターフェースの位置を変えようとしているのですね。
まさにそうです。開発チームはアーカイブを作るまでで、あとは運用チームにお任せみたいな感じだと、エラーログの調査は誰がやるのかとか、デプロイに失敗した時にロールバックして良いか分からないみたいに色々と問題がありました。なので、Kubernetesクラスタを運用するNecoチームと、その上でサービスを動かす開発チームという形で、境界が変わりつつあります。
いいですね。そういうふうになっていくのが現代的な気がします。
はてなにもマンガメディア開発チームという、マンガビューワ（GigaViewer）を作っているチームがあったんですけど、チーム編成でマンガメディアチームに名前が変わったのは、チームが運用もやるようになってきた表れかな、という話をしてました。
マンガチームもどんどん大きくなってきて、開発体制はどうなっているんだろうってよく想像していました。
そうそう。以前のはてなは、いろいろなチームに均等に人がいるようなイメージだったんですけど、最近はマンガビューワを作っているチームや、Mackerelのチームに人が増えてきました。
どんどん大きくなって、成長していく感じですね。
やることは、まだまだたくさんあるなって感じです(笑)。
itchynyさんのOSS活動の作品とモチベーション
続いては、自分が聞いてみたかった本丸であるOSS活動について、聞かせてください。itchynyさんの活動には、他の人とは一味違ったことをやっているというイメージを持っています。自分がitchynyさんを初めて認識したのが「lightline.vim」だったかな。これはたぶん最初の作品ですよね。
はい、ほぼ最初の作品です。
めちゃくちゃスターついていましたよね。
そうですね。6000ぐらいだったかな。
いきなり6000スターというのもすごいですが、ほかにもいろいろなソフトウェアを書いたりメンテナンスされてますよね。「gojq」や、Homebrewのインストーラーをシェルスクリプトに書き直したり。
まず、itchynyさんはどういうものをターゲットにしているのかというのを聞いてみたいですね。たとえば、gojqを作ろうと思ったきっかけって何ですか。
jqのクエリって書くのが難しくて、ちゃんと知りたいというところがgojqのスタートでしたね。今の完成度になるまではかなり時間かかっていて、結構大変だったのですが、その後はカバレッジというか、jqの挙動をどれだけカバーできるかといったところがモチベーションになって、高めていったという感じです。
ということは、作っている途中と、作り始めてから今の状態に持っていくまでで、作ることに対するモチベーションはちょっと違っていたということですか。
最初は本当に知りたいこと、原理を知りたいとか、クエリーを実行するインタープリターはどう実装しているのだろうというところから始まって、30％ぐらい挙動ができてきたら、あとは「これを100にするまでやらなくては」と取り組んできました。
なるほど。原理を理解するために実装するという学び方は私もイメージがつくのですが、その対象にjqを選ぶのは、最初の壁がかなり高そうだし、さらにそれを100%に持ってこうというモチベーションを持てるということが、itchynyさんのすごいところなのかなと思いました。普通は何となくわかったらそこで手放しちゃって、100%まで持っていこうというのは難しいですよね。
自分もgojqくらいです。ここまできたら、ユーザーがいるから頑張ろうというモチベーションですね。
なるほど。他にも、メンテナンスを引き受けるといったこともしているじゃないですか。それこそjqのメンテナーになったり、私が作ったものも引き取ってもらったりなど、人が作ったものをメンテナンスし続けていくモチベーションは、どんなところにあるのですか。
やっぱり自分が使うものだからじゃないでしょうか。jqに関しては、gojqを作ったことで大分自信を持てたというか、それなりに詳しくなったので。というのと、jqは一時期メンテナンスが滞っていた時期があって、メンテナーを募集していたんですよね。そこで手を挙げて、jqのメンテナーを始めてさらに詳しくなったという感じです。
たしかにjqにこんなに詳しい人、なかなかいないだろうな。というか、itchynyさんくらいしかいないのでは。
たぶんそんなにはいないとは思います(笑)。でも、僕以外にもメンテナーは7人くらいいて、それぞれ詳しい部分が違うので面白いですよ。
詳しい部分というのは、パーサーや実行エンジンとか、そういう区切りになるんですか。
それもそうですし、Cのインターフェースでlibjqというのもあったりします。自分はそういうのは詳しくなくて。別のメンテナーの方が詳しいですね。
Homebrewのインストーラーをシェルスクリプトに書き換えるというのも、めちゃくちゃいい仕事だと思ったんですけど。
いや、よくやりましたね。元々Rubyで書かれていたんですけど、時代の流れで、RubyやPythonみたいなインタープリター言語は、macOSの工場出荷状態では入れないという方針になってきたという背景があって。今はもう入ってないのかな。で、RubyがなくてもHomebrewをインストールできるようにしなくてはいけないというのは、メンテナたちはわかっていたけど、誰もやっていないからやろうと思って。
これに関しても、まずやろうって考えるのと、やり続けてちゃんと完成まで持っていくという、大きく二つの壁があると思うのですが、それぞれどういうふうに越えていったのでしょう。
元々シェルスクリプトを書くのがそれなりに好きというか、そういう機会が多かった気はしますね。それがないとたぶんやってないので。シェルスクリプトがある程度書けたのと、Homebrewはユーザーがたくさんいて、これをやれば世のエンジニアが助かるんじゃないかというモチベーションがあったことだと思っています。
たしかにはてなにいたころも、上手に使われていた印象です。そういうitchynyさんのここまではできるという感覚と、これをやったら実際にみんなが助かるというゴールの価値みたいなものが、うまく一致していたんですね。
例えば、jqはCで書かれていますけど、gojqは最初からGoのライブラリとして使われたらいいなというのはイメージしていて、それでGoで書いたんですよね。自分のスキルでできることと、これができたらいいなみたいな理想とがマッチすると、いいものができるみたいな。Goで書いたからこそghにも組み込まれて使われているわけです。
例えば極端な例ですけど、Haskellも少し書けるけど、HaskellでHomebrewのインストーラーを書いても意味がないわけです。適材適所で自分が使えるスキルと理想型、主観的ではあるけど、世のエンジニアに広く価値を届けたり、うまくマッチングできたりしたのが、今回の例なのかなと思っています。
itchynyさんは、自分の実力にちゃんと信頼を置いているんですよね。gojqを作るにしろ、自分はこれをやってのけられるという感覚がないと、そもそも最初の一歩を踏み出せないわけので。
自身のエンジニアリング能力に関して、itchynyさんが正しい自信を持っていることの表れかなと思いました。それは自分も、はてな時代にも感じていたことですね。
はてな時代は技術的な記事を社内・社外に発信
はてな時代の話になりますが、itchynyさんははてな社内のグループウェアに技術的なことやまとまった考えをたくさん投稿してくれていたんですよね。それこそシェルスクリプトの賢い使い方やMakefileの書き方、jqの使い方とかについて、たくさん書いてくれていたなと覚えています。
サイボウズはそういう技術的な場があまりないので、なんか懐かしいというか。はてなみたいに、世に出すにはあまり自信ないけど、細かいTipsみたいなことを投稿できる場所があればいいなって思います。
最近、社内のグループウェアに書かれたそうした記事の価値を再発見して、もっと書いていこうと話しているところです。その中で、itchynyさんがいい記事書いてくれていたのを改めて見て、
いいねって思ったんです。itchynyさんは社内に限らず、社外にも時々アウトプットしていましたよね。
書くことに対するモチベーションがあるのかなと思っていますが、それはどんなところに面白みを感じていますか？loadavgが7時間に上がる記事とかね。
その記事、すごく懐かしいですね。アウトプットは結構好きですね。なにか不可解な現象があって、その根拠がわかったみたいな嬉しさと、これは外に出したら面白いって言ってくれるんじゃないかみたいに考えると書いちゃいますね。
他に何かはてなでの経験が、今の環境で活きていることとかあれば、ぜひ聞きたいです。
はてなはインフラとの距離が近くて、それがものすごく楽しかったですね。
今はどの開発チームも運用からインフラまで見ていくようにしています。その中でも、itchynyさんがいた頃のMackerelチームは、運用監視をやっていくサービスなので、開発者もわかっていなきゃいけないってことで、わりとインフラを積極的にやっていくチームでした。それが良かったかもしれないですね。
Mackerelは開発と運用という垣根が低く、一緒にダッシュボードを見ながら監視を仕掛けたり、SLOを決めた思い出があります。KintoneもNeco基盤という形になって、開発チームがそういう領域まで責任を持つようになって、はてな時代の経験がより多くの場面で活きているという感じです。
いまのはてなはどう見てる？
最後に、今のはてなに対して、何か思うことや印象などあれば教えていただきたいです。
やっぱりMackerelは、自分にとって思い出深い製品なので、その動向は引き続き見ていきたいと思っています。最近でいうと、OpenTelemetry対応は、自分がいた頃は全然その影なかったので、よくやったなって思っています。まずは日本の企業におけるOpenTelemetry対応の利用促進をやっていくと、リードしていけるのではないでしょうか。
Mackerelはオブザーバビリティプラットフォームとして進化していきます - Mackerel ブログ #mackerelio
ありがとうございます。OpenTelemetry対応はめちゃくちゃ面白そうなんですよね。Mackerelみたいなプロダクトを作れる会社ってそうないと思うので、その面白さをエンジニアとしても楽しんでいきたいですね。
そうですね。Mackerelの時系列データベースをAWS上で実装し直すプロジェクトに参加できたのは、今振り返って見てもとても良い経験でした。
あと、最近「toitta」という新サービスが出ていて、ちょっとびっくりしたんですけど。
「toitta」は社内の新規事業チームでつくったプロダクトで、これまでのはてなとは結構毛色の違うものが出せたなというのは感慨深いですね。プロダクトとしてはこれからなんですけど、新規事業をやっていくということが、はてなでもまたできるんだというのは楽しいです。
生成AIを活用したサービスということで技術的なところはどうなっているのかなど気になって注目しています。社内でも生成AIの知見も溜まっているんじゃないかなと想像していますが、生成AIとUGCサービスの融合みたいなところがあると、またより面白いものが生まれてくるのかなとか思って。期待しています。
ありがとうございます。「toitta」は正式版を出したあたりで、技術的な話もこちらから出していこうかなと思っているので、その辺もご期待ください。
id:itchynyさん（2018年）id:itchynyさんこと濱田さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2024年11月頃更新予定、担当はid:onkです。
id:motemen
大坪 弘尚（おおつぼ・ひろなお）
CTO（最高技術責任者）兼 サービスプラットフォーム部 部長
2008年、東京大学大学院情報理工学系研究科を中退後、アプリケーションエンジニアとして新卒入社。うごメモはてな、Mackerelなどのサービス開発に携わり、2012年より技術グループ チーフエンジニア、2016年に最高技術責任者に就任。
Twitter: @motemen
GitHub: motemen
blog: 詩と創作・思索のひろば
