アンドパッドに新たに Ruby コミッタの nagachika さんこと、 近永 智之 が入社しました !
数年前の RubyWorld Conference の廊下で hsbt が声をかけたのが入社のきっかけだったということで、早速、 hsbt が福岡でインタビューしました !!

意外にも Ruby を使った開発ではなく、データ部へ配属になった背景も取材していますので、ぜひご覧ください ! 

インタビュアー：柴田（アンドパッド 開発本部 フェロー）
　　　　　　　　鳴海（アンドパッド 開発本部 製品（EE）エンジニア）
インタビュイー：近永（アンドパッド 開発本部 データ部 エンジニア）

Rubyコミッタとしての活動

柴田: 今日はアンドパッドに入社した近永さんの入社インタビューです。このインタビューのために、福岡オフィスに初めて出社しました。また近永さん同様に福岡からリモートで働いている鳴海さんにも参加してもらいました。

鳴海: 柴田さんとは前職の GMO ペパボで同僚でしたね。今日はよろしくお願いします。

柴田: それでは、近永さん自己紹介からお願いします。

近永: はい。私はアンドパッドに10月に入社し、開発本部のデータ部に所属しています。まずRubyコミュニティでの活動についてお話しします。私は現在、Ruby 3.3 系列の安定版ブランチメンテナを担当しています。

近永: 安定版ブランチメンテナの役割は、マスターブランチに入った修正の中から安定版に取り入れるべきものを見つけ、それをバックポートすることです。もう1つは、修正が溜まった時や脆弱性があった時にその修正のためにリリースを行うことです。具体的には、Ruby ユーザーが利用する 3.4.x や 3.3.x といったパッケージを作成するリリース作業を行います。主にこの2つが主なブランチメンテナの業務です。

柴田: 私も Ruby 3.2 のブランチメンテナですが、セキュリティ修正のみのフェーズのため、半年に1回リリースできるといいかな、くらいの気持ちで割とのんびりやってます。近永さんはバックポートやリリース作業は、どれくらいの頻度で実施しているのですか ?

近永: 過去には変遷がありましたが。最近では、週末などに重要な修正を見つけてバックポートする作業を、月に1～2回程度行っています。

近永: リリース頻度についても変化がありました。数年前までは、セキュリティ修正のリリースが頻繁にあったため、それに合わせてリリースすることが多かったです。しかし、標準ライブラリが default gems という形で Ruby 本体とは独立して個別にリリースできるようになったため、本体のリリースがセキュリティ修正に必ずしも引きずられなくなりました。最近はだいたい3ヶ月に1回、つまり四半期に1回程度のペースでリリースしています。

柴田: なるほど。半年や1年に1回ではなく、3ヶ月に1回くらいではリリースしているんですね。

近永: default gems の導入以前は大変でした。セキュリティ修正を出す際、すべてのバージョンで一斉に修正する必要があり、3.3だけリリースするわけにはいかず、3.3を出す時には3.2も、そしてマスターブランチにも取り込む必要がありました。それぞれにブランチメンテナがいるのでステークホルダーが多くなり、日程調整が非常に大変だったのがネックでした。

柴田: Ruby 3.4だけで修正してリリースし、3.3や3.2で修正しないままだと攻撃される可能性がありますよね。そのため、一斉に修正するためにブランチメンテナ全員の予定を調整する必要があったのは、本当に大変でしたね。

近永: 柴田さんのようにリリース作業時のインフラ担当者や、リリースノート作成、ドキュメントの公開作業などを担当する方々もいます。多くの関係者が同じ時間に作業できるように調整する必要があり、これが非常に大変でした。

柴田: それを考えると、実は僕がやったのですが、現在は default gems として単独でリリースできるようになったのは非常に良い点ですね。また、リリース作業自体もGitHub Actionsなどでかなり自動化しました。

近永: 昔はNaCl (株式会社ネットワーク応用通信研究所) さんのサーバーにSSHでログインし、特定のコマンドを打ってパッケージを作成し、FTPでアップロードする、といった作業をしていました。

柴田: 5-6年ほど前は、デプロイサーバーにログインしてコマンドを叩くような作業だった記憶があります。

近永: そのため、サーバー固有の環境依存の問題などでパッケージングミスがよく発生しました。そういった作業は最近、非常に簡単になるだけではなく、リリースパッケージの安定性が向上したという結果にもなりました。

ruby-trunk-changesについて

柴田: あとは、近永さんが昔からずっと続けられている ruby-trunk-changes、Ruby のコミットログ読みと解説の活動について聞きたいです。これは何がきっかけで始めたのですか ?

近永: 始めたのは2010年で、15年続くプロジェクトです。きっかけは、usa さんというコミッターの方が、丁稚な日々というブログを書かれていて、そこで週に1回くらいの頻度でRubyのtrunk（当時の開発バージョンブランチの名称、現在は master）に入ったコミットのコメントをまとめる記事を公開されていたことです。

柴田: usa さんがそのような記事を書いていたのは知らなかったです。

近永: その記事を見た時、「というわけで、誰かやってみませんか?」という内容が書かれていました。当時の職場では、UNIXのクラスタシステムを構築する仕事をしていました。その仕事で現在のオーケストレーションツールのようなものを作成しており、そのコマンド言語の実装をRubyで書いていました。

近永: その仕事でRubyを使っていると、時々 SEGVで異常終了することがあり、その修正のために Ruby 本体へパッチを投げることもしていました。社内で Ruby の開発バージョンには適用されていないパッチを当てたRubyを使用することもあり、このパッチのメンテナンスのためにアップストリームの変更に追随する必要がありました。そのため変更ログをある程度読んでいた経験から、記事にもなるぐらいだから「喜ぶ人がいるだろう」と思い、2010年8月に開始しました。

近永: 始めて1週間ほどで、当時利用していた、はてなブログの前身のサービスである、はてなダイアリーに「はてなスター」が非常に多くつき始め、注目される状態になり、承認欲求が満たされたというのがあります。

柴田: なるほど。それがきっかけだったのですね。知りませんでした。あと、この執筆のために専用のアプリケーションを開発して使っているというのを聞いたことがあるのですが、教えていただけますか?

近永: はい、専用のアプリケーションがあります。最初の1週間か1ヶ月は、ブログ投稿フォームを開いて一つずつ記事を書いていました。あまりに大変で、これは無理だと感じ、専用のツールを作成しました。当時の環境はHeroku上でした。Subversionリポジトリをクローンし、前回記事にした場所からの差分を抽出してエントリーを作成していました。コメントをフォームに書いて保存しておけば、後で記事としてまとめるという流れです。当時Railsは使っておらず、Rackの上に直接コードを書いていました。

柴田: そのアプリケーションは毎日コミットログを取得し、それがMarkdownなどに整形された状態で出力されるということですか?

近永: そうですね、ブログに貼り付けるための雛形が出力されるので、それを貼り付けます。

柴田: 実際の内容であるコミットログを読むという作業はどうやってますか? git log から読むか、テンプレートにあるリンクをクリックして Web でみる、などどういう感じでしょうか。

近永: 実際には、手元でGitでクローンしたリポジトリを、Tigを使ってコミットログを辿りながら読んでいます。また、コミットログの内容の解説を記事としてポストした内容は、もう一つ別の場所に git の note として入れています。正となるデータソースは Git としており、`git note`に付けたコメントはTigで表示したときに太字になる機能を利用しています。

柴田: なるほど。Tig と `git note`を見て、昨日どこまで読んだかを確認するのですね。

近永: はい。「今日はここから」という地点を確認し、一つずつ読み進める流れです。

柴田: `git note` には手元から直接書き込んでいるのですか ?

近永: 正確には、専用のWebアプリケーションのDBに一旦データを貯め、そこから `git note` に同期するツールを作成しています。

柴田: 私もOSSやアンドパッドなどで色々なプロジェクトを git で手元に置いてますが、`git note` は、Rubyでしか見たことがありません。普段の業務ではなかなか使わない機能ですよね

近永: git note はアノテーション機能ですね。Ruby本体では、リリース時にコミットログからチェンジログを作成しています。このような使い方をしているときに、コミットログのコメントの誤りをコミットの修正という形で変更してしまうと、コミットハッシュが変わるため後から直せません。そこで、「このコミットログのここは誤りでこれが正しい内容」というノートを付ける、という形で利用されています。

柴田: 近永さんが作成されている `git note` の内容を取り込むことで、日本人向けに、そのコミットに対する日本語の解説が追加されるわけですね。私も毎日のコミットを追うのに使ってます。

Ruby 以外のこれまでの仕事

柴田: あまり知られていないruby-trunk-changesの裏側のワークフローについて掘り下げて聞きました。では、前々職で使っていたというカスタムバージョンのRubyなど、これまでの仕事の話の続きをお願いします。

近永: 開発版の Ruby にパッチを当てて使っていた仕事の他にシミュレーターや物理学関連の開発もしていました。その後、13年ほど前、福岡に引っ越すのと同時に転職し、グルーブノーツという会社に入りました。

近永: グルーヴノーツでは、多岐にわたる業務を行いました。特に印象的だったのは、ブロックを繋げて作成するワークフローツールやローコードツールの開発です。また、2016年頃に機械学習が流行り始めた際、Google CloudのAutoMLのようなサービスを構築し、サービス化・運用を担当しました。

近永: その他、テックパークという学童保育サービス向けに提供する機械学習を利用したツールの開発も行いました。この学習プラットフォームはGCP（Google Cloud Platform）上に構築していました。

柴田: 幅広い業務領域をやられていたということですが、技術的な部分でもう少し深掘りしたいです。

近永: サーバーサイドの部分はRailsで構築されていたため、RailsとRubyを使用することが多かったです。一方、機械学習関連では、モデルのトレーニングやモデルと通信するためのAPIサーバーなどはPythonで書くことが多かったです。

アンドパッド入社のきっかけ

柴田: そのような中でアンドパッドに入社されたきっかけは何だったのでしょうか ?

近永: 正直なきっかけとしては、柴田さんから話を聞く機会があったことが大きいです。前職も長く続け、様々な分野や技術トレンドに沿った開発を行ってきました。一方で、一つの業種や業態を深く掘り下げれば、より大きな社会的なインパクトを与えることができるのではないかという思いがずっとありました。次々に新しい技術に取り組むのはエンジニアとしては魅力的ですが、振り返ったときに、後に残るものが少ないと感じていました。

近永: アンドパッドの建築・建設業界という領域に深く入り込み、それを継続することで、社会的に大きなインパクトのある仕事ができるのではないかと考えました。Vertical SaaSという概念に非常に魅力を感じました。SI は、多くのプロジェクトを通じて新しい業界や業種について学ぶ機会はありますが、一方でプロジェクト自体が終了したり、せっかく勉強したことが次に活かせなくなる、という側面も大きかったです。

柴田: そのような観点からアンドパッドが良さそうだと判断し、入社してくれたんですね。ありがとうございます。アンドパッドの選考体験はいかがでしたか ?

近永: ごく普通の採用プロセスだと思います。マネージャー、所属部門のトップ、社長と結果的に3回ほど面接を受けました。また、内定後のオファー面談もありました。

柴田: 都度選考ではないものの、僕もお邪魔してアンドパッドの魅力について色々と紹介させてもらいました。

鳴海: 最終的な所属が開発本部のデータ部だと聞いて、最初は驚きました。

柴田: 他の方々からも「施工管理ではないのか」という反応がありました。施工管理プロダクトが、最も大規模なモノリスRailsのコードベースを持っているため、Rubyに詳しい人は通常、その部門が選択肢に挙がるんですよね。

近永: データ部の部長である福田さんと、ポジションについて「Rubyを使う開発」、「Google Cloudのインフラ活用推進」、「機械学習プロダクト」の3つの選択肢について話し合いました。福田さんに私のメンタリングをしてもらったような感覚です。

柴田: それはいい話ですね。近永さん自身も、複数の選択肢がある中で迷いがあったのですね。

近永: 迷いはありました。Vertical SaaSへの憧れはありましたが、転職に際して覚悟を問われている、という感覚がありました。Rubyに関しては、今後も安定版のリリースは続けますし、「RubyがSegmentation Faultを起こした」と言われれば調査します。そうした貢献は可能ですが、自身の専門性という点では、機械学習を使ったプロダクト開発の方が高いと考え、データ部を選択しました。

近永: 実際に入社してみると、AIを使ったプロダクト開発が既に進められています。データ部にはMLプロダクトチームが存在し、メンバーの専門性が非常に高いです。特に現在のチームメンバーは、画像処理などを専門とし、長く経験を積んでいる方々です。正直、その技術分野で私が貢献できることは少ないかもと感じ始めています。そのため、自分が何を求められているのか、どこで力を発揮すべきかを考え直しているところです。

柴田: なるほど。今、改めて模索中なのですね。

近永: 自分のバリューを発揮できる領域を探し、挑戦中です。現在は、手を動かす作業としてはRailsを使ったAPIサーバー開発を行っています。AIなどの専門技術をどう適用すればインパクトが出せるか、同期入社したPdMと一緒に考え、技術的な全体像を把握する役割を担いたいと考えています。

柴田: プロダクトを作る前に「何が可能で、何が不可能で、何が非常に難しいのか」という判断は常にあるとは思いますが、AIプロダクトについてはどうでしょうか。特に社内でも期待感は高いと思います。

近永: 期待値の調整が難しいところです。例えば「これはこういうことができる」「すぐにできますよね」といった期待に対し、それを具体的に実現可能なレベルに落とし込む解像度にはグラデーションがあります。その間を埋める役割が、私にできることの一つと考えています。

柴田: 少し話は変わりますが、中長期的に、社内事情を抜きにして、個人的にやりたいことはありますか ?

近永: 現在のポジションとは別で、先ほど話したようにRubyがSEGVを起こす職場は良い職場だと思うので、そういう形にしたいですね。

鳴海: なぜそれが「良い職場」だと言えるのか、よくわからなかったのですが、どういうことですか?

近永: 基本的に、誰もやらないような特殊な使い方をしているからこそ、SEGVが発生するんですよね。そうした事象が起きたら、私は喜んで根本原因を調査したい。最近はRuby本体にパッチをコミットする機会があまりありませんが、改めてパッチを書きたいという希望があります。

柴田: アンドパッド社内でも、誰かしらはSEGVするようなバグを踏んでいる可能性があります。ただ、それがRuby本体のバグなのか、Cの拡張ライブラリなのか、サードパーティの gem のバグなのか、という領域までは深掘りせず、とりあえずバージョンアップ、とか、別の gem に置き換える、というようなワークアラウンドで対応されているのかもしれません。

近永: サービス運用においては、根本原因の特定よりも、まずワークアラウンドで問題を解決することが優先されるのは間違いありません。そこを理解した上で、根本原因の調査にも喜んで取り組みたいですね。

アンドパッドと AIプロダクト開発について

柴田: 少し話を戻して、アンドパッドが建築・建設業界のSaaSでトップを維持し続けるためには、AIプロダクトは不可欠だと思いますが、その辺についてはどうですか?

近永: 現在携わっているプロダクトでは、フロントエンド、API、そしてその奥の機械学習のモデルと通信する構成になっています。例えばバッチ処理で実行する場合、フロントエンドからではなく別の箇所から処理を呼び出すなど、アーキテクチャのパターンはいくつか存在します。

鳴海: 実は、「黒板AI作成」「豆図AIキャプチャー」機能は、入社時に携わったプロジェクトでした。これらはアンドパッドで当時、初めてAIを組み合わせて実現した機能の一つだったと思います。当時、私にはAIモデル側がどうなっているか分からない状態でリリースしましたが、「このようなインターフェースでデータが返ってくるので、それを元にユーザーが操作できるようにする」というのが、私たちの役割として進められました。

柴田: なるほど。ゲストとして呼んだ鳴海さんが関わっていたのは知りませんでした。過去にもデータ部の森さんにインタビューしましたが、そのプロダクトのフロントエンドを鳴海さんが担当されていたのですね。

鳴海: この機能は反響が良く、ユーザーの仕事の仕方を変えるほどの機能になりました。

柴田: いいですね。ところで、近永さんは福岡からリモートで働かれているのですよね。その辺について教えてください。

近永: はい、基本的には自宅でのリモート勤務になります。

柴田: 現在のチームメンバー構成はどのような感じですか ?

近永: チームメンバーは全員リモートかもしれません。

柴田: リモートでの入社とのことですが、オンボーディングなどで困った点などはありますか ?

近永: 2点ほどありました。入社して最初の1週間は東京でオフラインの研修を受けました。その後はチームに配属され、開発が始まりますが、開始直後は「これをどう進めたらいいだろう」「誰に聞けばいいだろう」と戸惑うことはありました。しかし、現在は毎朝、メンターと30分話すという形で継続的にサポートを受けています。

近永: もう1つは、現在担当している モノリスRailsに関する、プルリクエストをマージする条件、のようなルールを探すのが大変ということがあります。よくよく探してみると、ドキュメントは存在し、ルールは書いてありましたが、疑問に思ったこと全てについて、それを探して把握するということを日々模索中です。

柴田: 確かに。それは私が入社した3年前からもあったと思いますが、急成長中の企業では人の数だけドキュメントが記述されて、人の出入りによって見つけにくくなりがちなので、よくある問題かもしれません。

近永: 情報はあるが、アクセスしやすくないだけかもしれないので、MCP サーバーのようなツールの進化で楽になると良いとは思います。

おわりに

柴田: それでは、そろそろ終わりにしましょうか。近永さんから、最後に一言お願いします。

近永: 急成長しているアンドパッドの中で、自分の専門性を活かしつつ、新しい技術やプロダクト開発に挑戦していきたいと考えています。今後ともよろしくお願いいたします。

柴田: 今日はありがとうございました。

近永のように Ruby に詳しい方でも AI プロダクトに挑戦する、というエンジニアもアンドパッドでは大絶賛募集中です。今すぐに転職を考えている、という方に限らず、AI を活用したプロダクトの開発手法はもちろんのこと、プロダクトが持つ社会的インパクトなどについてももっと発信していきたいと思うので興味を持たれた方は是非お問い合わせください。