シェア
はてブ
特定のリポジトリに対して機能追加・変更やバグ修正などを行う場合、エンジニアはPull Requestを発行します。プログラミングを続ける過程で数えきれないほど発行されるPull Requestは「エンジニアが歩んできた道のりそのもの」と言っても過言ではありません。
ならば、オープンソースコミュニティで活躍する方々が「特に印象に残っているPull Request」には、その人のOSS活動への思いや日々の研鑽が結実しているのではないでしょうか。今回は8名の著名エンジニアの方々に回答していただきました。
※人名の50音順に掲載。回答者は敬称略。
k0kubunが紹介『Count trace_running for internal event』
これは私が新卒1年目に初めてRuby本体に送ったPull Requestです。
当時、私は社内の開発者の生産性を改善するチームに所属していました。開発環境のアプリケーション上でデバッグ用にREPL（binding.pry）を起動すると、終了後に処理速度が10分の1になる問題が発生していました。原因は、Rubyのデバッグ機能を支える機能（TracePoint）がREPL終了後も有効だったためです。しかし、その当時のRubyではこのデバッグ基盤の機能を無効化するとランダムにクラッシュするという別の問題もありました。
Ruby本体はC言語で実装されていますが、私は主にRubyを使うプログラマーだったためCのコードのデバッグ経験は当時なく、Ruby本体の実装に関する土地勘もありませんでした。そこで、デバッグ方法や実装の仕組みをその場で調べながら、数日かけてクラッシュの原因を特定し、このバグを直すパッチを送ることができました。
Ruby本体のかなりコアな実装を初めて読み解き、再現自体が稀でデバッグが困難な問題を解決できたのは、とても達成感があったのを覚えています。このPull Requestを書いたときに初めて業務としてRuby本体の開発を行い、Rubyの実行速度の10倍の高速化を実現したわけですが、9年後の今もRubyの高速化をフルタイムの業務として行っていることを考えると感慨深いです。
【プロフィール】
ShopifyでRubyコミッターとしてフルタイムでOSS開発を行っている。YJITチームに所属し、Rubyプログラムの実行の高速化やメモリ使用量の削減を目標に、Just-In-Timeコンパイラの開発をしている。
塩井美咲が紹介『Rename hash to jar in CookieJar.build』
これは私にとって、初めてOSSに取り込まれた記念すべきPull Requestです。
内容はRailsのActionDispatch::Cookies::CookieJar.buildメソッド内の変数名を実態に合わせてリネームする、という簡単なもの。しかし一般に、このような見た目上の変更の提案は望ましくありません。レビュアーに負担をかけ、コードの歴史的なコンテキストも隠してしまうためです（Railsガイド参照）。また、パッチを送る側はその提案の妥当性を示す必要があり、この場合は元の変数名が使われていた理由を調べて記載するべきですが、それも不足していました。
以上の理由からこの提案は却下される可能性が十分にありましたが、実際にはレビュアーからコメントで指摘を受けたうえで、このPull Requestはマージされました。なぜでしょうか？
このとき対応してくださったRailsコミッターのkamipoさんに理由を伺ったところ、「せっかくRailsに興味を持ってコードを書いてくれたFirst-time Contributorのやる気を挫きたくないから」と理由を教えてくださいました。未熟な提案を否定せず、次につながるような成長の機会をいただけたことを嬉しく思いました。
このPull Requestは、OSS初心者にコントリビューターとしての心構えを教えてくれるとともに、新しく門をくぐった者として迎えてくれるものでもあったのです。
【プロフィール】
2018年よりプログラマーとしてのキャリアを開始。現在は株式会社エス・エム・エスにてプロダクト開発に携わる。2021年からプログラミング言語Rubyの国際カンファレンスRubyKaigi登壇。2023年度Rubyアソシエーション開発助成プロジェクト「socketライブラリへのHappy Eyeballs Version 2 (RFC8305)の導入」の取り組みにより2024年11月Rubyコミッターに就任したばかり。地域RubyコミュニティAsakusa.rbメンバー。
Takayuki Maeda（TaKO8Ki）が紹介『New lint: bytes_nth』
このPull Requestは、私がRust標準のlinter「rust-clippy」に初めて送ったものです。2020年、大学生だった頃にOSSに興味を持ち、主にRustで書かれたOSSへのコントリビューションを始めました。最終的にはRust本体にパッチを送りたいと考えており、その前段階として「rust-clippy」を選びました。
実装内容は、bytes_nthというlintルールの追加です。これは、.bytes().nth()と書かれたコードに対して、.as_bytes().get()を使用するよう提案するシンプルなものです。
// Example: "Hello".bytes().nth(3); // Use instead: "Hello".as_bytes().get(3);
OSSに興味があっても、最初に何をすればいいのか分からないという方は多いのではないでしょうか。私もかつて同じ悩みを抱えていましたが、linterに新しいルールを実装することは、本格的にOSS活動を始める第一歩として非常に良い方法でした。既存のルールを参考にしながら実装でき、どのように進めればよいか比較的明確だったため、OSS初心者の私にとって取り組みやすかったのです。
また、自分の実装したルールが取り込まれ、そのlinterを自分のプロジェクトで使うことで、コントリビュートした実感を得られるのも魅力的でした。この体験がOSS活動へのモチベーションを高め、その後も継続的にOSSに関わり、最終的にはRust本体に貢献しコミッターとして活動するきっかけとなりました。
【プロフィール】
Rustコミッター（compiler contributorsチームのメンバー）。2022年に株式会社マネーフォワードに入社し、所属しているチームや個人のOSS活動で主にRustを使っている。
武田憲太郎が紹介『[10.x] Disconnecting the database connection after testing』
最終的にはリバートされたこのPull Requestが、私の一番の思い出です。
条件によってテスト時のデータベース接続がリークし、場合によっては後続の全テストが失敗する問題がありました。この問題の発生は確率や運にも左右されました。私はこれを「非常に厄介なバグ」と捉え、Pull Requestを送ったのです。しかし、修正が既存のテストを壊す可能性があったため、リバートされました。
一旦は諦めたものの、Laravelチームに所属するメンテナが別のアプローチで修正を試みるPull Requestを提案しました。GitHub上では、破壊的変更に慎重な姿勢を取る作者や中立的な立場で修正を試みるメンテナ、そして情報提供を行う私を含む数名の利用者たちが、それぞれの視点から議論を交わしました。
そのPull Requestも最終的には完全な修正には至らず、クローズという形で幕を引きました。しかし、この一連の出来事は私のプログラミングに対する価値観を大きく変えました。
私は今でもこれを「修正すべきバグ」と考えています。一方で、発生頻度が低いため「諦める」という判断が妥当であることも理解できます。この経験を通じて、プログラミングは単に「正しい or 正しくない」で割り切れるものではないことを学びました。
ロジカルな世界においても「正しい」の定義は立場や視点によって異なることや、課題を乗り越えるための議論の重要性、他者の意見に真摯に耳を傾けながら修正をくり返すメンテナの姿勢。修正に至れなかった悔しさ以上に、開発者のあるべきさまざまな姿を教えてくれたPull Requestです。
【プロフィール】
Webアプリケーションエンジニア、OSSコントリビューター。PHP: Laravel, TypeScript: Next.js, NestJSを中心に多くのWebサービスの開発やプロジェクト運営に従事する傍ら、PHPやLaravelを中心としたOSSやドキュメント、コミュニティへの貢献活動を行っている。
Teppei Fukudaが紹介『fix(maild): email messages are sent infinitely』
OSSのホスト型侵入検知システムOSSECで、無限にメールが送信される問題に遭遇しました。最初は再現条件すら特定できませんでしたが、デバッグを重ねた結果、短時間に複数のアラートを検知した際に問題が再現することが判明しました。さらなる調査で原因を突き止めることができ、最終的にたった1行のコードで問題を解決しました。
「数行の変更でOSSに貢献したと言えるのだろうか」という声を耳にしたことがありますが、私はむしろ逆だと考えています。セキュリティに携わっていると脆弱性修正のコードを目にする機会が多くありますが、複雑な問題を1行で修正できることは珍しくありません。最小限の変更で重大な問題を解決できることこそ、エンジニアリングの醍醐味の一つだと感じています。
この経験を通じて、長い試行錯誤の末に生まれる解決策が、時としてとてもシンプルなものになることを改めて実感しました。現在、私はOSS開発者としてプロジェクトの維持に関わっていますが、レビュアーの視点からも小さな変更は理解しやすいため、非常に助かります。OSSへの貢献で大切なのは、コードの量ではなく問題解決への貢献度です。そのため、このPull Requestはたった1行ですが、大きな貢献をしたと自分の中では勝手に思っています。
【プロフィール】
Aqua Security社でOSS開発に従事。ウォシュレットの良さを海外に広めたいと考えていたが、ハンドシャワーも良いことに最近気づいた。
ふわせぐが紹介『[9.x] Add validation rule options: alpha:ascii, alpha_num:ascii, alpha_dash:ascii』
Laravelのalpha_numバリデーションに関連するこのPull Requestは、私が初めてLaravelにコントリビュートした思い出深いものです。
きっかけは、日々のコードレビューで発見した「半角英数字」を確認するための正規表現でした。当時の私は、Laravelのalpha_numルールで代用できると思い込んでいましたが、実際には全角文字も許容される実装であることを知り、大きな驚きを受けました。
このPull Requestの前に2回の提案をしましたが、却下されました。その理由は、シングルバイト圏の開発者には「アルファベット」の定義の違いが伝わりにくかったためです。彼らにとって「アルファベット」は文字の見た目が同じであれば、シングルバイトでもマルチバイトでも同じものとみなされるべきだという考えがあったのです。
しかし、諦めずにGitHub Discussionsでコミュニティの意見を募り、特にアジア圏の開発者からの賛同を得ながら、WikipediaやRFCなどの資料を引用して問題の本質を丁寧に説明しました。その結果、新しいルールを追加するのではなく、既存のalpha_*ルールに:asciiオプションを追加するという形で実装が受け入れられ、Laravel 9.49からマージされました。
この経験を通じて、技術的な正しさだけでなく、既存ユーザーへの影響や下位互換性への配慮の重要性を学びました。また、諦めずに粘り強くアプローチを変え続けたことで、最終的には良い形で実装を取り込んでもらえたことは、私にとって大きな自信となりました。今では世界中のLaravelユーザーがこの機能を使っていると思うと、とても誇らしく感じます。
// Before: 全角文字も許容 'username' => ['required', 'alpha_num'] // After: ASCII文字のみに制限 'username' => ['required', 'alpha_num:ascii']
【プロフィール】
2021年に株式会社ゆめみに新卒入社し、フルサイクルエンジニアとしてコーポレートエンジニアリングに従事している。社内のPHPテックリードとして育てていただいた経験を活かし、現在は案件でテックリードとして技術的な支援や勉強会を実施して客先エンジニアの技術力向上に努めるとともに、社内ではコードレビューやペアプログラミングを通じて後進の育成に取り組んでいる。また、LaravelなどのOSSへのコントリビューションや、独自のComposerライブラリの開発・公開にも取り組んでいる。愛知県在住の2児の父でもある。
yprestoが紹介『feat(#45195) Improve perf of unions with many primitives』
このPull Requestは、TypeScriptの型計算のパフォーマンスを改善するものです。
当時、勤務先のプロジェクトで使用していたReactのコンポーネントライブラリ「MUI」 (旧：Material UI) では、 エディタの補完に数秒待たされるのが当たり前でした。Microsoftの社員からは「型をシンプルにできないか？」というIssueも挙げられていました。
純粋な興味から、私はTypeScriptの言語機能を司る巨大なファイルをデバッガやプロファイラで解析し、MUIにフィードバックしていました。 その過程で、TypeScript自体が「高速化」のつもりで、複雑な型の不必要な解決を行ってしまうケースを見つけ、それを修正したのがこのPull Requestです。
TypeScript（に限らず！）の生みの親であり、レジェンドとして名高いAnders Hejlsbergさんから直々にレビューコメントをいただき、エンジニアとしてとても感激しました。
私の改善範囲は小さく、元の課題自体は別の修正で大きく改善されたようです。 しかし、この頃にTypeScriptの型解決について得た知見は、3年越しにTSKaigiでの発表につながるなど、 子育てなどでしばらく表立った活動ができていなかった私の技術的な自信を、再び取り戻させてくれるものとなりました。
【プロフィール】
LayerX バクラク事業部のソフトウェアエンジニア。経理の方向けのプロダクトを開発する傍ら、「Webフロントエンドギルド」のリードとして、ナレッジシェアやカイゼン活動に取り組む。自分が使うツールは自分で直すことが習慣で、これまでにTypeScriptやRails、RuboCop、Node.jsなどと、幅広くcontributeを行っている。
松本宗太郎が紹介『Add conversion to accept BOOL parameters』
この、どうということのない小さなPull Requestが、私が初めてOSSに送ったものです。
それまで、仕事で社内向けにPull Requestを送ったことはありましたが、知らない人にパッチを送るのは初めてで、とても緊張したのを覚えています。修正自体は些細なものでしたが、深夜1時に送ったPull Requestがその日の朝10時にはマージされており、プロジェクトオーナーのPeteが迅速に対応してくれていたことがわかります。
その年の6月、WWDCに参加するためサンフランシスコを訪れました。そのタイミングに合わせてPeteが「iOSとRubyをやっている人」のミートアップを計画していることを知り、会場のバーに挨拶に行きました。OSS開発を通じて知り合った人とアメリカで直接顔を合わせるのも、また初めての体験でした。
しばらくしてリポジトリのWrite権限が付与され、どうやらコミッターと呼ばれる立場になったようでした。ただ、その後は特にアクティブに活動を続けることもなく、私はiOSの開発から離れましたし、プロジェクト自体も活動が減少して、いつの間にか別の人が引き継いだ（？）ようでした。Peteと会ったのも一度きりです。
技術的な面白さや教訓はありませんが、このPull Requestはその後10年以上にわたる私の人生を暗示するような、あるいは一つの転機となった思い出深いものです。
【プロフィール】
Rubyコミッター。大学院でRubyプログラムの型検査の研究に取り組み、修了後はスタートアップでiPadアプリ・Webアプリの設計・開発に従事。2017年から型検査ツールSteepの開発を始め、2019年からはRubyコミッターとしてRuby標準の型定義言語RBSの開発を主導する。2024年4月、タイミーにフルタイムRubyコミッターとして入社。博士（工学）。
