さくらのクラウドのSDK開発エンジニアとしてジョイン。中川真宏にインタビュー

いままでずっとベンチャー企業で働いてきました。最初に入ったのが株式会社Preferred Infrastructure（現：株式会社Preferred Networks）で、APIサーバーの開発や新規プロダクトのMVP開発などを担当しました。1年半ほど在籍したあと、当時のCTOの太田一樹さんがアメリカに渡ってTreasure Data, Inc.という会社を立ち上げ、そこに誘われて移りました。

Treasure Dataでは最初、Hadoopの運用をクラウドでおこなうデータ分析の会社として、運用まわりのツールやメッセージキューの開発・メンテナンスを担当していました。途中から、お客さん向けに提供していたログ収集ツール「Fluentd」というOSSが、思いのほか日本や海外の企業で採用されるようになり、私がそのコアメンテナーの1人となりました。

当初は1人体制でしたが、途中から海外の開発者もチームに加わり、Cloud Native Computing Foundation（CNCF）の支援も受けながらFluentdの開発を続けました。その後、Treasure DataがArm社に買収された2〜3年後に一通りやりきった感があったので会社を去りました。それからさくらインターネットに入社するまでの4年間は無職で自由に過ごしていましたね。

実際、Fluentdの初期のユーザーは本当にウェブ企業が多かったです。それまでのバッチでWebサーバーのログを定期的に処理する方法から、もっと早い段階で問題点を知りたい、ユーザーの傾向を把握したいというニーズが高まってきて、そこにFluentdがマッチしました。開発者が古橋君という日本人だったこともあり、日本では爆発的に普及しました。その後、CNCFに採用されてからは海外でも急速に広がっていきました。

そうですね。最初はほかの業務と並行していて、プラグインのメンテなども趣味でやっていた部分もありました。しかし、ユーザーが増えてきたので片手間でメンテナンスをするのも厳しくなり、会社の意向もあってFluentdのメンテナンスを本業としました。その後、コミュニティ運営やCNCFのヨーロッパやアメリカのイベントでの発表も仕事になり、ユーザーとのコミュニケーションが増えていきました。

一番大変だったのは、「あるお客さんの環境で1か月Fluentdを動かすと実行中のプロセスが停止する」という問題でした。調査の結果、お客さんのLinuxカーネルのバージョンが古く、inotifyのなんらかのスレッショルド（しきい値）を超えたときに止まるのではないかという推測ができました。しかし手元では再現せず、最終的にはお客さんに3週間ごとにFluentdプロセスを再起動して凌いでもらいながら、新しいLinuxカーネルに更新してもらって解決しました。手元で再現しない問題は本当に難しかったです。

スレッドの競合など、手元である程度の負荷を掛けて再現できる問題なら、コードをチェックしてロックの取り方などを修正すれば解決できます。しかし環境に依存する問題で、しかもほかに報告がないような事例は本当に難しいですね。とくにFluentdはユーザーが使っている環境が多様だったので悩ましかったです。

Fluentdの前にももっと性能がよいプロダクトはありましたが、Fluentdは最初から多様なデータソースに対応しようというプラグイン思想で作られていて、ElasticsearchやMongoDBなどとも接続できる柔軟性がありました。それに加えて、Rubyで書かれていてプラグイン開発も簡単。多少パフォーマンスに課題があっても、ユーザーが多かったという先行者利益があったんじゃないかと思います。

僕も最初はRubyを採用したことがネックになるかと思ったんですけど、逆に書きやすさが受け入れられた。いまでこそ海外ではPythonが主流ですが、当時はそれほど差もなかったですからね。
その後、Fluentdの発展とともに、軽量版の「Fluent Bit」も開発されました。当初は組み込み向けに開発されたものですが、ちょうどコンテナの波と重なり、いまではコンテナ環境ではFluent Bitのほうが主流になっています。Cで書かれているため、ほかのプロダクトと比べてもパフォーマンス的に引けを取らず、かつプラグイン機能も備えているので、ほぼデファクトスタンダードになっています。

Fluentd以外だと、D言語が好きで関わってきました。ほかのエンジニアと違って、私はプログラミングを始めたのが大学3年生と遅かったんです。C言語やJavaの講義を受けたあと、プログラミングにくわしい先輩がいたのですが、その人がやっているのと同じことをするのもおもしろくないと思い、調べていたらC++をもじったD言語というのを見つけました。

実際にC++より短くコードが書け、性能も近いということで気に入り、触っているうちに有用なライブラリを書きたくなってMessagePackのライブラリを書きました。それがD言語のメンテナーであるアンドレイ氏の目に留まり、標準ライブラリには入らなかったものの、標準ライブラリのメンテナーにならないかという話になりました。いまは趣味で書く程度ですが、当時は標準ライブラリのパフォーマンス改善やAPIの修正、バグ修正などを担当していました。これが大学時代に起きたことで、自分のプログラミング能力に自信を持つきっかけになりました。

D言語は当時、バージョンアップするたびに互換性が壊れるようなチャレンジングな言語でした。安定性よりもおもしろい機能を追求する人たちが集まっていて、機能提案しては消えていくようなおもしろい環境でした。みんなで持ち寄って機能開発や標準ライブラリのメンテナンスをしていた時期は本当に楽しかったです。

言語というより、いまAIの流れが来ているじゃないですか。そのAIがどう進化するのかに興味があります。いまはGitHub上にコードが多いPythonやTypeScript、Goなどが相性がいいと言われています。でも、AIがちゃんとコンテキストを理解できるようになれば、Rubyのような短いコードのほうがコンテキストを取りやすいはずなのに、現実ではそうなっていない。そのあたりが将来的にどうなるのか、どの言語が相性がよくて生き残るのかに興味があります。

本当にAIが賢くなれば言語を選ぶ必要自体がなくなるかもしれません。プロンプトを入力すれば、出てくる言語は何でもよくなる。最終的にはアセンブリを直接出力することもおかしくない。そもそも言語を覚えるという行為自体が将来どうなるのか気になります。私は言語を覚えるのが好きなのでRustなども触ってみたりしましたが、それが単なる趣味の範囲になってしまうのかなというのも少し気になっています。

飽きなかったです。「無職をするには才能がいる」みたいな話がX（旧：Twitter）でも流れますが、私は全然問題ありませんでした。ゲームも好きだし、知り合いとボイスチャットしながらプレイすることもあって、コミュニケーション自体はずっと取っていました。eスポーツの大会を見るのも好きですし、博物館や美術館に行くのも好きで、美味しいラーメンやつけ麺を探すのも好きでした。趣味でコードを書いたりもしていたので、知的欲求はある程度満たされていたと思います。

もともとおもしろそうなことがあれば就職してもいいと思っていて、さくらインターネット以外にもいくつか声をかけていただいていました。条件としてフルリモートワークは必須でした。さくらインターネットに決めた理由ですが、以前からガバメントクラウドをやっているのは知っていましたが、実際にどこまでできているのか疑問でした。
しかし最近、知っているエンジニアたちがどんどんさくらインターネットに入っていて、これだけのメンバーが集まっているということは、かなりやる気があり、実現性も高いのだろうと感じたんです。AWS（Amazon Web Services）やGoogle Cloudなどの大手クラウドが圧倒的なシェアを持つなかで、これだけの強いエンジニアを集めて本気でクラウドに取り組む姿勢が見えたので、私も挑戦してみようと思いました。

これまではスタートアップの早い段階から参加することが多かったので、ちゃんとしたオリエンテーションが2日間あることや、ドキュメントがきちんと整備されていることに新鮮味を感じています。社内のドキュメントもしっかりしていて、動線がちゃんとあるのは大きな会社ならではだなと思いました。

SDKの開発というのは日本ではあまりないポジションです。Webサービスのバックエンド開発などは多いですが、クラウドのSDKのようにユーザーが直接触るものを開発する仕事はめずらしい。とくに今回、私がこのポジションの1人目なので、どういう開発をしていくか、どういうフレームワークを作っていくかを含めて考えられるのはおもしろいと思いました。
現在、さくらのクラウドではGo言語のSDKしかなく、それもIaaS系とオブジェクトストレージ、最近追加されたAppRunくらいしかありません。Windowsユーザーも多いでしょうし、Javaを使っている企業もあるでしょう。将来を見据えるとRustなども必要になってくるかもしれません。リソースには限りがありますが、タスク管理やマネジメントもしっかりやっていく必要があります。

最近のサービスはOpenAPIを使っているとのことですが、古いサービスとのミスマッチもあるようですね。自動生成の整備が進めば理論的には簡単にできるようになるはずですが。

そうですね。たとえばWindows向けの.NET環境でのモダンなアプリ開発は私の専門外なので、そういう部分はほかの人の力が必要になるでしょう。

そうです。水曜日がお休みです。入社時に相談したのですが、さくらインターネットでの仕事にリソースは割きたいけれど、自分の時間も大切にしたいと思いました。博物館や美術館を巡りたいのですが、土日は混んでいるので平日に行きたいという思いもあって、週4日勤務¹をお願いしました。

田籠さんからそういう働き方ができるかもしれないと聞いて、それも入社の決め手になりました。フルリモートで柔軟な働き方ができる会社は最近減ってきているので貴重です。

やはり興味深いのは、これまでに在籍してきた会社もインターンの若手を採用していましたが、みんな優秀で、ベテラン勢に劣らないコーディング能力や設計能力を持っているという印象がありました。私たちはC++やD言語など古い言語から書いてきましたが、いまの若い人たちはAI前提のコーディングをしてくる方が多いと思うので、逆にそういうところからいろいろ学びたいですね。
どういうふうにして開発体験を向上させているのか、どこから情報収集して、どのように自分のコーディングスタイルに取り入れているのかなど、もしSDKチームに若手が来るのであれば、そういったことを知りたいと思います。

年々求められるコーディング能力が上がってきて、それが大学レベルに下りてきている印象があります。いまの若い人たちは最初からオープンソースにプルリクエストを送っている人も普通にいますし、GitHubが前提となっていて、最初から分散環境でのコーディング経験を持っている人も多い。知の高速道路のようなものを本当に感じますね。

SDKを作る仕事は本当に珍しく、チャレンジングだと思います。社内のプロダクトなら社内の人に聞いて機能を作ればよいのですが、SDKの場合はユーザーが、とくにさくらのクラウドは今後爆発的に増える可能性があり、そうした人たちの期待に応えられるライブラリや周辺ツールを作っていくことになります。
さまざまな言語に触れる可能性もあるし、自分が得意ではない言語を触ることもあるかもしれません。それが良いか悪いかは人によりますが、非常におもしろいポジションだと思っていますので、そういったことに興味のある方はぜひ一緒に働きましょう。