シェア
はてブ
Did you mean? xxx
おそらく、ほとんどのRubyユーザーが一度はこのメッセージを目にしたことがあるでしょう。スペルミスを検出し、候補を提示してくれるgemのdid_you_meanは、Ruby 2.3から標準で組み込まれ、世界中のプログラマを支えてきました。
このgemの作者が、西嶋悠貴さんです。彼はページネーション機能を提供するgemであるkaminariのメンテナでもあり、長年Rubyのエコシステムに携わってきました。今回は西嶋さんに、これまでのOSS活動を振り返っていただきました。
Rubyコミュニティは「技術の進歩が、自分の目の前で起きている」
――西嶋さんは、長きにわたりRubyやRuby on Rails（以下、Rails）に関わっています。これらの技術を使うだけでなく、gemの開発にも携わるようになったのはなぜでしょうか？
仕事でRubyを使っていくうちに、より知識を深めたくなり、勉強会にも顔を出すようになりました。そうした場で、ソフトウェアのエコシステムの成り立ちやライブラリを作っている人たちの活動を、知ることができたんです。
もともと私はCやJavaのプログラマでしたが、それらの言語では「ライブラリ開発者たちと会う」という体験はなかなかできません。しかしRubyの場合は、コントリビューターに日本人が多いこともあり、そうした方々と実際に話すことができます。だからこそ、決して遠い世界ではないと実感できて、「自分にもできるのでは？」と考えるきっかけになりました。
――西嶋さんはkaminariのメンテナとして活動されていますが、これはどのような経緯で？
kaminariの作者である松田明さんが主催していた勉強会に、何度か参加していました。それもあって、kaminariをユーザーとして使うだけでなく、開発のエピソードなどにも触れる機会があり、以前から興味を持っていました。
また、一昔前にNoSQLの技術が非常に流行していた時期がありましたよね。その頃、kaminariもRelational Databaseだけでなく、さまざまなデータストアに対応しようという流れがありました。当時の私は仕事でMongoDBを使っていましたが、kaminariが対応していなかったため、自分で手を入れ始めたのがコントリビューションのきっかけです。
最初は、自分が関わったMongoDB関連の機能だけを見ていたんですよ。活動を続けていると、あるとき松田さんから「なんなら、（MongoDB関連だけではなく）全部やりますか？」と声をかけられました。そこから、kaminariのメンテナとしてすべてを見るようになりましたね。
――gem全体のメンテナンスに携わるのは大変そうです。西嶋さんが「やってみよう」と思えたのは、どうしてでしょうか？
まずは、せっかくいただいた機会ですし、「これは自分のためにもなる」と思えたからです。あとは、MongoDB関連のIssueは私が対応していたものの、他のIssueはなかなか対応されない状況が続いていました。「kaminariを利用する方々のためにも、気合を入れて他の部分も見ていこう」と思ったのが理由です。
「タイポが原因で時間を無駄にした経験」がアイデアのきっかけに
――その後、なぜdid_you_meanを開発しようと思われたのですか？
kaminariのメンテナになったことが、did_you_meanの誕生に影響しています。ユーザーの方々から「kaminariが動きません」という問い合わせを受けることがあるんですね。何時間も調査しても原因がわからない。けれど、コードをよく見ると、実はタイポが原因だったということが何度かありました。
これは重要な問題だと感じました。質問者も私も、無駄な時間を費やしてしまいますからね。そこで、Google検索の「もしかして」機能のような体験を、Rubyでも実現できないかと思い、gemの開発を始めました。
Proof of Conceptができたのは2013年の末ごろ。2014年の上旬には、ある程度動作するものができました。当時、私はPivotalのニューヨークオフィスで働いており、Rubyをよく使う環境で、常にペアプログラミングで開発を進めていたんです。あるRubyプロジェクトで、こっそりdid_you_meanを追加してみたところ、ペアの相手がサジェストを見てとても良い反応をしてくれました。「これはいけるかも」と感じましたね。
その後、Yコンビネーターが運営する「Hacker News」に紹介ブログを投稿したところ、ランキングの1位になり、コメントも大量につきました。「これはすごいことになった」と震えましたね。
――普及していく中で、印象に残っている出来事はありますか？
本当にたくさんあります。時系列は前後しますが、特に印象的だったのは、did_you_meanがRuby本体に取り込まれたときです。その際、私が組み込みのための修正を行ったのですが、CIが落ちてすぐにリバートされました。Rubyコミッターとしての洗礼のような体験でしたね。
また、当時のdid_you_meanの一部の実装を、CやJavaで拡張ライブラリを書いていました。私もC言語でRubyの内部APIを直接操作していたのですが、ダイナミックリンクや関数ポインタの扱いを十分に理解しないまま、内部関数のポインタを無理に上書きするような実装をしていました。その結果、Ruby本体の挙動に予期しない副作用が生じ、複数のライブラリに不具合を引き起こしてしまったんです。
当時はGitHub上でそうしたバグ報告を見つけては、「すみません、これはdid_you_meanの影響です」とコメントして回っていました。Ruby本体に組み込まれていたため、影響範囲が非常に広く、本当に大変でした。ただ、その後まつもとゆきひろさんが「did_you_mean のために本体を変えて良いと言われたら、どこを変えるか？」と提案してくださったことで、拡張ライブラリで実装していた機能をRuby本体へ追加してもらえました。
あとは、SNSで多くの反応をもらえたことも印象的です。中には、「これはシンプルな仕組みだけれど、世界中にいるエンジニアの合計で、何万時間もの作業時間が削減される」という旨の投稿をしてくれた方もいて、本当にうれしかったですね。
――did_you_meanを作ったことは、ご自身にとってどのような意義がありましたか？
このgemを通じて、多くのことを学びました。まずは、継続することの大切さです。最初にアイデアを思いついたのは2013年でしたが、そこからbundled gemになるまでには2〜3年かかっています。世の中で広く使われるようになるには、それなりの時間と継続が必要だと実感しました。
また、「小さく始めて、少しずつ改善していく」ことの重要性も感じました。思いついた瞬間に安定したものができて、いきなり「Hacker News」に載るなんてことはありません。まずは、最小限自分が納得できる状態にする。その次に、ペアプロの相手に使ってもらい、さらにPivotalの仲間に試してもらって、ようやく少しずつインターネットに投稿しました。話題になってからも、Pivotalのメンバーが毎日フィードバックをくれたことで、良いgemに育てることができました。
――この記事の読者には「多くの人に使われるライブラリを作りたい」と考えている方もいるはずです。効果的な方法はありますか？
プログラマが「作りたい」という気持ちだけで始めたものは、なかなか成果につながらないことが多いです。大事なのは、まず“問題”が存在していること。そして、それが他の人も抱えている問題であるか、あるいはまだ誰も気づいていない潜在的な問題であること。その問題に対して、「こうすれば大きく改善できる」と示す道筋をつくることです。「イシューからはじめよ」という言葉がありますが、まさにその通りだと思います。
――潜在的な問題に気づくには、どうすれば良いですか？
時間やお金、体力といった“資源”に注目することです。それらの資源が過剰に使われているなら、どこかに問題があります。たとえば、新型コロナウイルス感染症が流行する前は、オンライン会議は一般的ではありませんでした。でも今では、誰もが普通に行っていますよね。つまり、かつてはみんなが「対面で会うのが当たり前」と思っていて、移動時間という資源を無駄にしていたということです。「当たり前」だと感じていることの中に、実は改善のヒントが隠れています。
Speedshopでパフォーマンス最適化に取り組む
――西嶋さんのGitHubでの活動履歴を拝見すると、最近はRuby on Railsのパフォーマンスコンサルティング企業であるSpeedshopのリポジトリにもコントリビューションされています。
現在、私はSpeedshopの仕事をしています。代表のネイト・ベルコペックとはもともと知り合いで、彼がニューヨークに住んでいた頃、Pivotalのオフィスで開催されていたイベントなどにたまに顔を出していたり、RubyKaigiで話す機会に恵まれたりして、その縁で交流が生まれました。
ネイトは当時から、システムのパフォーマンス改善に関するコンサルティングを手がけていました。一方で私は、ニューヨークから東京へ戻って来た後、しばらくVMware Tanzu Labs（Pivotal買収後の組織名）に在籍していたんです。
その後、さらにVMwareがBroadcomに買収されるという話が持ち上がり、「もし今回の買収で仕事に影響が出るようなら、新しい職を探さなければ」と考えるようになりました。ちょうどその頃、ネイトもコンサルティング事業の拡大にあたって人を採用したいという意向があり、お互いの状況が重なったことで、Speedshopで一緒に働くことになりました。
ネイトは尋常ではなくパフォーマンス改善に詳しいです。一緒に議論している際も「あまりに内容が専門的すぎて、ついて行けない」という場面がよくあります。彼の知見を学びつつ、仕事を進めていますね。
――西嶋さんのようにハイスキルな方が「専門的すぎる」と感じるとは凄まじいですね。具体的には、どのような業務に取り組まれていますか？
たとえば、WebサーバーであるPumaでは「ワーカースレッドの最大数」を設定する必要があり、プロセスを立ち上げる際にその値を指定します。ただし、この数値を適切に決めるのは容易ではありません。最適化のためには、CPUの使用率、I/Oの状況に加えて、Ruby 3.2で導入されたGVL Instrumentation APIを活用し、「グローバルVMロック（GVL）の待機時間がどれくらい発生しているか」を正確に計測する必要があります。
私たちは、こうした計測やシステム最適化を実現するためのソリューションを開発・提供しています。その中で、「クライアント企業のアプリの状況によって自動で最適化を行うアルゴリズム」と「誰でも共通して使える汎用的な技術」の両方が存在します。前者は有償で提供し、後者はOSSとして公開するという方針で運用しています。
OSSはテクノロジーの世界のインフラ
――OSSは、西嶋さんのキャリアにどのような影響を与えましたか？
OSSとの関わりは、間違いなく私の人生を変えました。最初は小さな種のような存在でしたが、徐々に育ち、さまざまな機会をもたらしてくれました。たとえば、OSSでの活動を知ってくださった方々から、採用や登壇のお誘いをいただくこともあります。
私にとって、OSSは空気のような存在です。電気や水道と同じように、なくてはならないもの。テクノロジーの世界におけるインフラだと思っています。今後も、その重要性は変わらないはずです。
――「自分もOSSに関わってみたい」と思っている読者に、アドバイスをお願いします。
最初は、「自分のIssueやPull Requestが受け入れてもらえるだろうか」と不安になる人も多いと思います。でも、あまり気負いすぎず、まずは一歩踏み出してみてください。もし身近にOSSに関わっている人がいれば、「メンターになってください」と声をかけてみるのも良いですし、私に連絡してもらっても構いません。
【西嶋さんのアカウント】
私自身も初期の頃は、経験のある方に時間を割いてもらい、さまざまなことを教えていただきました。コードが書けるかどうか以上に、「最初の一歩を踏み出す勇気」と「背中を押してくれる誰か」の存在が大切だと思います。
――最後に、エンジニアがより良い人生を送るために、大切だと思うことを教えてください。
日本では、ソフトウェア開発の労働環境に本当に大きな幅があります。多重下請けで残業ばかりの会社もあれば、余裕を持って働きながら、有名プロダクトに関わっている人もいます。「自分はスキルが低いから、良い会社には行けないかもしれない」と思い込んでしまう人もいるかもしれません。でも、決してそんなことはないと伝えたいです。
私自身、学生時代の成績は平均的で、周囲には自分より優秀な人がたくさんいました。決して、最初から何でもできたわけではありません。私がここまで来られたのは、運がよかったこと、そして努力を続けられたことが大きかったと思います。信じて努力をしていれば、必ずチャンスはやってきます。だから、ぜひ自分を信じて、前に進んでほしいです。
取材・執筆：中薗昴
撮影：本多香
