特定のリポジトリに対して機能追加・変更やバグ修正などを行う場合、エンジニアはPull Requestを発行します。プログラミングを続ける過程で数えきれないほど発行されるPull Requestは「エンジニアが歩んできた道のりそのもの」と言っても過言ではありません。
ならば、オープンソースコミュニティで活躍する方々が「特に印象に残っているPull Request」には、その人のOSS活動への思いや日々の研鑽が結実しているのではないでしょうか。今回は7名の著名エンジニアの方々に回答していただきました。
※人名の50音順に掲載。回答者は敬称略。
- うひょが紹介『Editorial: correct 'import * circularity' to 'export * circularity'』
- uhooi（ウホーイ）が紹介『Fix code span in README』
- おおくらまさふみが紹介『Update Pull Request Template [ci-skip]』
- kazupon（川口和也）が紹介『Implement basic validation』
- Songmu（松木雅幸）が紹介『Fix bug in yaml_emitter_analyze_scalar() when the string starting with multi-byte character』
- 高町咲衣が紹介『[RFC] Support object types in BCMath』
- Yusuke Wadaが紹介『Introduce RegExpRouter』
うひょが紹介『Editorial: correct 'import * circularity' to 'export * circularity'』
OSSとは少し違うのですが、私が「ECMAScript仕様書」に対して送ったPull Requestを紹介します。内容としては、仕様書に記述されたモジュール解決に関わるアルゴリズムを1箇所修正し、「import」を「export」に直しただけです。
ECMAScript仕様書はJavaScriptという言語の仕様を規定する文書であり、JavaScriptエンジンの実装者にとってとても重要なものであることは言うまでもなく、レベルの高い学習者にとっても有用なものです。それに修正を加えたということで、小さいながらも思い出深いものになりました。
とはいっても、言語仕様に私が変更を加えたわけではありません。私が行ったのはEditorialという種類の修正で、実際の言語仕様には影響しない、記述上のミスを直しただけです。
このミスは、私がECMAScript仕様書を読む中で気づいたものです。些細なミスではありますが、せっかくなので修正に挑戦したいと思いPull Requestを発行しました。修正を用意するのは一瞬ですが、なぜその修正をすべきなのかを説明するほうが大変でした。仕様書をよく読み、関連するアルゴリズムの中身を追う必要がありました。
結果、レビュー時に「Beautiful job laying out the reasoning, made the review a lot more straightforward.（素晴らしい仕事ぶりで理由を整理してくださったおかげで、レビューがとても簡単になりました）」というコメントをいただきました。Web標準が好きな人間として、このようなコメントをいただけるのはとても嬉しいことでした。
仕様を策定する側に回るのは難しいことだとしても、このようにEditorialな修正を行うことは、意外と可能です。Web標準が好きで興味がある方は、自分にも直せることがないか探してみてください。
ちなみに、ECMAScript仕様書にもう1つPull Requestを出したことがあります。こちらもマージはされたのですが、変更の必要性は認めてもらいつつも具体的な文言は全てレビュアーの方が書き直したため、私は0行の修正をコントリビュートすることになりました。
【プロフィール】
株式会社カオナビでCTO室に所属。フロントエンドエキスパートとして、開発環境の改善や開発効率向上、設計の改善などに取り組む。Web標準に興味があるほか、TypeScriptやReactも得意。著書に『プロを目指す人のためのTypeScript入門』（技術評論社）。
uhooi（ウホーイ）が紹介『Fix code span in README』
これは、私が初めてAppleにマージしてもらったPull Requestであり、非常に思い出深いものです。
いや、修正内容はうろ覚えだったので「思い出深い」は言い過ぎたかもしれません。鮮明に覚えているのは「Appleへ初めてコントリビュートしたこと」です。
修正内容はREADMEのコードスパンを調整したのみです。
- For Quick Help use the ```swift package --help ``` command. + For Quick Help use the `swift package --help` command.
これだけの修正で「Appleにコントリビュートしたぞ！」とドヤ顔で言い続けていました。しかし、それも事実なので問題ないはずです。
寄稿にあたり、このコラムの第1弾と第2弾を拝読したのですが、みなさん本当にすごいです。ほとんどの方が商業誌の著者やコミュニティのリーダーで、難しい修正を手掛けています。
一方で、私は商業誌を書いたこともなければ、何かのリーダーでもなく、ただの一般的なサラリーマンです。そんな私にできることは、「千里の道も一歩から」「気軽にPull Requestを送ろう」と伝えることくらいです。
OSS活動をしたことがない人にとって、Pull Requestを作成するのは非常にハードルが高いものです。いきなり複雑な修正を送るのは難しいので、ドキュメントの修正から始めるのは悪くないアプローチだと思います。軽微なPull Requestを積み重ねることで、複雑なPull Requestを作成する心理的なハードルも徐々に下がっていきます。
と、私の大したことないPull Requestを正当化したところで、私の話はこれでおしまいです。みなさん、よいOSSコントリビュートライフをお送りください！
【プロフィール】
iOSアプリエンジニア。OSSにも稀によくコントリビュートしているが、typoの修正や依存ライブラリの更新がメイン。最近はポケカに没頭していて、プログラミングのアウトプットが減少している。
おおくらまさふみが紹介『Update Pull Request Template [ci-skip]』
このPull Requestは、Ruby on RailsにPull Requestを出す際のテンプレートを改善したものです。私がこれを作ったのは、Rails Core TeamのメンバーであるEileen Uchitelle氏がテンプレートの改善に興味を示していたのを見たことがきっかけだと記憶しています。
具体的な変更としては、このテンプレート自体を必ずしも使用する必要がないことを明記し、あわせてチェックリストを追加しました。これにより、特に「初めてPull Requestを出すコントリビューターの説明不足により、レビュアーが意図を正確に把握できず、マージが難しくなる」という事態を防げるようになっています。
その後、テンプレートはさらに更新されました。
これは、私の加えた変更に対する他のコントリビューターの動きを踏まえた更新です。自分の変更が他の人によって改善されていくのも、OSSの醍醐味だと思います。
コードの変更ではなく、修正箇所もファイル1つのみですが、約3年前にマージされて以降、多くのPull Requestに影響を与えているという点で意義があると思い、今回取り上げさせていただきました。
【プロフィール】
フリーランスのソフトウェア開発者。Ruby/Railsが得意。Vimmer。書籍『マスタリングVim』翻訳者。Kaigi on Railsチーフオーガナイザー。Alba gemの作者。調べてみると職業プログラマになった直後からOSSと関わっていた（当時はissueのみ）。
kazupon（川口和也）が紹介『Implement basic validation』
これは、私がVue.jsに初めて送ったPull Requestです。
Vue.jsが初リリースされたv0.8の頃、Vue.jsはフォームのバリデーション機能をプラグインとしてvue-validatorで提供する予定でした。ただ、当時はバリデーションの具体的な仕様がドキュメントとしてまとめられておらず、プラグイン名のみが記載されたREADME.mdしか存在しない状況でした。そんな中、私は勝手にバリデーション機能を実装し、Pull Requestとしてレポジトリに送ったのです。
このプラグインを実装したのは、当時テックリードとして関わっていたプロジェクトで、jQueryに代わるものとしてVue.jsを導入した際に、フォームのバリデーションが必要になったためです。Pull Requestの内容を見れば、巨大なコミット履歴と膨大な実装コード量だとわかります。このPull RequestをレビューしてくれたVue.jsの作者Evan You氏には、今となっては大変申し訳なかったと思っています。
当時、プラグイン実装のベストプラクティスはなく、Vue.jsがリリースされたばかりで開発者向けの指針も不十分でした。そのため、自分でVue.jsのソースコードを読み、本体の実装内容を理解したうえでプラグインを実装する必要がありました。ソースコードを読んでもわからない部分は、Evan氏に直接質問し、Vue.js本体とプラグインがどのように連携するのかを学びました。こうした試行錯誤の末、このPull Requestは約半年後にプラグイン実装として採用され、Vue.js公式プラグインとして提供されるようになりました。
このPull Requestを通じて、OSSにおけるDXフレンドリーなAPI設計など、オープンソースプロジェクトでしか得られないナレッジを学び、OSS開発者として活動していく自信を得ることができました。
【プロフィール】
Vue.js コアチームメンバー、Vue.js 日本ユーザーグループ代表、Vue Fes Japan オーガナイザー。 日本における Vue.js の普及に努めながら、自らも国際化プラグインである Vue I18n、Intlify プロジェクト、そして気になる OSS の開発に関わっている。プレイドでは Developer Experience チームで OSS 開発やナレッジを活かして IC 的な立ち位置でプロダクトの開発体験改善等に取り組んでいる。
GitHub：kazupon X：@kazu_pon
Songmu（松木雅幸）が紹介『Fix bug in yaml_emitter_analyze_scalar() when the string starting with multi-byte character』
これは、Goで最もメジャーなYAMLライブラリである gopkg.in/yaml のバグ修正です。
value[i] と書くべきところを value[0] と書いていた、ありがちなインデックス指定バグです。修正内容はコードの1文字の修正と、それに伴うテストコードの追加のみです。修正自体はわずか1文字ですが、それを突き止めるには、複雑なYAMLライブラリだけあって苦労しました。
このバグはマルチバイト文字を扱う上で重大なものでしたが、当時すでに広く使われていたライブラリにもこのようなケアレスバグが残っていたことに驚いた記憶があります。
Pull Requestを起票した当初は反応がありませんでしたが、催促したところ取り込んでもらえました。知らないエンジニアからのPull Requestはどうしても後回しにされることが多く、このように催促する重要性を改めて実感しました。
また、この変更を取り込んでもらうにあたって、Canonical社のCLA（Contributor License Agreement）にサインする必要がありました。これが初めての経験で、CLAという仕組みを知るきっかけとなったPull Requestでもありました。
gopkg.in/yaml は長年広く使われてきたライブラリですが、つい最近（2025年4月）にメンテナンス停止のアナウンスがされ、リポジトリもアーカイブされました。まだ利用可能ではあるものの、YAMLを扱うソフトウェアは多く、今後が懸念されます。OSSの難しさや、YAMLの複雑さ・難解さを改めて感じました。
【プロフィール】
株式会社ヘンリーでフェローを務めるほか、複数の企業でエンジニアリング支援を行っている。ISUCONで3度の優勝経験を持つなど、Webアプリケーション開発やクラウド・インフラに精通したソフトウェアエンジニアであり、信頼性と高速性を両立したコードを書くことを得意としている。CTOやプロダクトマネージャーの経験を活かし、アジャイルに価値を届けるフルサイクルな開発運営を得意とする。また、「OSS作家」としての側面も持ち、Goを中心に200以上のOSSを公開している。ブログなどでの発信力にも優れ、共著に『みんなのGo言語』（技術評論社）がある。
高町咲衣が紹介『[RFC] Support object types in BCMath』
私にとって最も印象深いのは、BcMath\Numberクラスを追加したPull Requestです。
たしか2024年の3月ごろからこの機能追加について内部メーリングリストで議論していて、マージに至ったのは9月の頭。半年くらいこの機能に費やしたようなものです。
メーリングリストでは議論がとても活発に行われていて、私が考えてもいなかったユースケースを取り上げて「これをどう解決するか」という話になったりもしました。
そのようなたくさんの議論を経て、単なる「私のアイデア」を超え「私のアイデアを核に、みんなで作り上げた仕様」とでも言うべきものに仕上がりました。
半年近くあんなにたくさんの議論を交わしてくれた人達に応えるためにも、PHP8.4に絶対間に合わせるぞ、速度面も考えて、納得いく実装にするぞ、という意気込みでした。
普段はバグ修正やちょっとした機能変更が多い中、徹底的に議論して、アイデアが私だけのものではなくなるくらい色んな人を巻き込んだ、「大きな動き」を伴ったPull Requestで、とても思い出に残っています。
【プロフィール】
サーバーサイドエンジニアとしてPHPを使用しています、高町咲衣（たかまち さき）です。PHP Foundationのコア開発者の1人で、PHP8.4のRelease Managerでもあります。PHPのメンテナーとしての専門領域は、PDO（PHP Data Objects）とBCMath（任意精度数学関数）です。最近は、より専門領域を広げようと思い、SIMD（Single Instruction, Multiple Dataの略。並列処理方式の一種）について学んだりしています。
Yusuke Wadaが紹介『Introduce RegExpRouter』
これは衝撃的なPull Requestです。Hono史上最強です。
Honoというフレームワークは2021年の12月から開発を始めたもので、当初は僕1人が1日1コミットずつ育てていました。クリスマスの頃、手伝ってくれる方が現れて、それで2人になります。面識のない海外の方です。
まぁ楽しく作っていたわけですが、翌年2022年の2月14日、バレンタインデーに3人目のコントリビューターで今回のPull Requestの作者であるusualomaさんが突然現れました。「Added type to c.req.param key.」というPull Requestです。これは、URLのパスパラメータ（よく /posts/:id と書く部分）で id をキャプチャし、その id を型として取り出すという、TypeScriptの「文字列を型として扱える」特性を活かしたクールな提案でした。「こんなことができるのか！」と驚きつつ、マージしました。
それからほどなくして、2月20日。RegExpRouterが爆誕します。
もともと僕が作ったルーターは、Trie木といういわゆるツリー構造を利用したHTTPルーターになっています。Expressに搭載されているpath-to-regexp のように、登録されたパスを頭からさらっていくルーターよりは速い。しかし、このusualomaさんによるこのルーターはとんでもなく速い。
Trie木でもpath-to-regexpでも、候補となるルートが現れたら毎回正規表現のマッチが走ります。例えば、path-to-regexpだと10個のパスが登録されたら 10 回正規表現のマッチが走る。ところが RegExpRouter は 10 個のパスが登録されたらひとつの大きな正規表現文字列に変換して、毎回一発でマッチさせてしまうというとんでもないアイデア。これが速い。ケースによってはそうじゃないのですが、それでもJavaScript界で1、2を争う速いルーターです。それをさらっとusualomaさんが対応して送ってきた、このPull Requestは衝撃です。
このPull Requestをマージすることになるのですが、RegExpRouterがあるからといって、もともとのTrie木のルーターを消さず、残しておいたのがよかったです。Honoクラスをインスタンス化する時に、アプリで使うルーターを指定できるようにしました。その後、3 つ、いなくなったものを含めると4つのルーターが登場し、アプリごとに使うルーターを変えたり、組み合わせたりするようになります。つまりサーバーレス環境だったらこの組み合わせ、常駐する場合はRegExpRouterを使うとか、ユーザーがパフォーマンスを求める時に変えられるんですね。こうしたHono独特の仕組みの発端になったという意味でもこのPull Requestの存在は大きい。
ちなみにこれ、背景が面白いです。ルートをすべて一つの正規表現にしておくというアイデアは僕は初見ではありませんでした。実は、PerlにあるRooter::Boomというルーターで使われていたアイデアです。また、Perlは古来から、複数の正規表現を一つの正規表現にする文化と実装がありました。だからこのアイデアに至るのはわりと自然かもしれません。僕もそうだし、usualomaさんもPerlを書く方なんですよね。そういうシンパシーみたいなのはだいぶ感じます。JavaScriptのフレームワークがPerlにインスパイアされてるってのはなんか面白いですよね。
【プロフィール】
Webアプリケーション開発者。Cloudflare Senior Developer Advocate. Honoの作者。
