本記事では、「OSS応援企画」として記事の最後に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
こんにちは、高町咲衣（@takamachi1saki）です！ PHPコア開発者の1人で、最新版PHP8.4のRelease Managerを務めています。日本では、BASE株式会社などでバックエンドエンジニアとしてのお仕事もしています。
今回は、OSS活動を始めた経緯や、OSSに興味がある方への具体的な内容紹介、そして参加するメリットなどを記事にまとめました。
世界に10人。PHPコア開発者としての日常
昨年からPHPコア開発者の1人として、私は主にBCMath（任意精度数学拡張機能）とPDO（データベース接続のための拡張機能）のメンテナンスを担当しています。PHPのコア開発者は世界に10人いて、それぞれ得意分野の領域を中心に保守や開発をしています。ただし、改修できる箇所はたくさんあるので、みんなで参加して改善させています。
また、PHP8.4でRelease Managerを務めており、毎月のパッチバージョンリリースを当番制（2人で交互）で担当しています。私は毎週水曜にやっていて、毎週新しいソースコードの管理だけでなく、Webサイトやメーリングリストでのリリースアナウンスも併せて行なっています。
社内の“困った”をきっかけに、OSSの世界へ
私がOSSに関わるようになった本当に最初のきっかけは、バックエンド開発中に社内で「PHPUnitの新バージョンが、期待した挙動にならない」という書き込みを社内連絡ツールで見つけたことでした。 具体的には、「PhpStormでテスト実行した時にvar_dump()などを使用してデバッグ出力を試みても何も出力されない、困ったぞ」、というような内容です。
その書き込みを見た時点では「OSSコントリビュートチャンス！」という感覚は全くなく、「社内で困っている人がいるから、何か力になれないかな」というような気持ちでした。実際、その問題を解決しようと試行錯誤を始めてみて、最初の方はPHPUnitに手を入れることなくワークアラウンド的にうまく解決できないかを探っていました。
試行錯誤を繰り返すうちにPHPUnitの該当箇所の仕組みを理解できてきて「これはPHPUnit本体を修正する以外に方法が無さそうだ」という結論に至り、そうなって初めて「OSSコントリビュート」の選択肢を選ぶことになりました。
OSSコントリビュートについてGitHubリポジトリの「fork」という仕組みは知っていましたが、forkしてその後「何を」「どのように」「どこで」「誰に」行動するべきなのか全くわかっておらず「手間だなぁ」「PHPUnitの作者ってすごい人だし、なんか怖そうだなぁ」というような（完全な偏見を含む）印象でした。
当時の私にとっては、それはチャンスでもなんでもなく、できれば避けたかった最終手段だったのです。
初めてのコントリビュート - PHPUnit
何もわからない状態だったので、ひとまずPHPUnitのコード修正を行いました。修正はたったの4行の削除のみで済みましたが、テストの方法が全くわかりません。「phpt」という拡張子の、見たことのないテストファイルの仕組みを調べながらテストを書き、どうにかPull Requestを作成しました。
これはPhpStormに大きく関わる変更であったため、開発者のSebastianの一存では決め切れず、JetBrainsのPhpStormチームの意見を聞く流れになります。
PhpStormチームとのやり取りに時間がかかり、私のPull Requestはしばらく放置状態となりました（2ヶ月後くらいにSebastianによってPhpStormへ影響を与えない形で問題を解決する変更がなされ、私のPull RequestはマージされずにCloseとなりました）。
初めてのマージ - php-src
PHPUnitのPull Requestがマージされるかどうかでドキドキしている最中、社内でまた別の問題が発生します。
PHPのバージョンアップに伴い、DBから取得されるデータの形式が「3.60」のような文字列だったのが「3.6」のように、末尾の0が無くなってしまうということが起きていました。これは以下のページの「PHP Data Objects（PDO）」の「MySQL ドライバ 」に記載されている変更に起因しているとアタリをつけました。
php-src（PHP本体のソースコード）はC言語で書かれていて複雑そうだったので、ひとまずIssueでのバグ報告をするだけにしました。
コメントをくれたtekimenさんの案内に従い再現コードを載せたりするも、メンテナーからの反応はありません。
※ 実はこの時期、PHP8.3のコードフリーズでメンテナーは大変忙しい時期でした。
MySQLの知識がないと「動作の何がおかしいのか」がまずわかりにくいということもあり、また、（忙しい時期だと知らなかったので）なかなか反応も来ないし修正されないのではないか？という不安も出始めました。私は幸いにもCが書けるので、いっそのこと自分でphp-src（PHP本体のソースコードを管理しているGitHubリポジトリ名）へPull Requestを出すことに。
PHPUnitの時とは違い、Pull Requestを出そうと決めるまではとても早かったです。PHPUnitでPull Requestを出した経験が「OSSへPull Requestを出す」ことへの心理的ハードルを大きく下げていたのだと思います。
経験があるのはPull Requestを出すところまでだけなので、その後のやり取りはとても緊張しました。恐ろしいコードレビューが来たりしないだろうか？と身構えもしましたが、実際にはとても丁寧で親切なレビュー。数日後にはあっさりとマージされ、私はphp-srcのコントリビューターとなりました。
“while you here” のたった一言で、継続を決意
コードレビューをしてくれたGinaのコメントのひとつに、次のようなものがありました。
Which... while you here might want to fix the other cases which for some reason just do return false; ...
日本語訳だと次のような内容です。
これ… あなたがここにいる間に、“なぜか return false; だけを返している他のケース”も修正した方がいいかも
修正内容は置いておいて、私は「while you here（あなたがここにいる間に）」の部分が心に引っかかっていました。たぶん、単発のコントリビュートで継続には繋がらないかもと思われたんだと思います。これは仕方のないことで、継続的なコントリビュートに繋がることの方が少ないのです。
DBの知識があるメンテナーが不在で、大変そうである中のコメントにOSSを維持する苦労が垣間見えた気がして、可能な限りDB - 特にPDO - について力になろうと決意しました。
その後は、Issue報告に上がってきたPDO関連のものを全て対応するように。対応しながら、少しずつphp-srcの仕組み、つまりZendについて学んでいきました。
localのDocker環境だと再現しない（つまりCIのテストでも再現しない）のにリモートのDBを使った時だけ再現するバグに遭遇することも。
DBを専門的に見るなら検証環境がちゃんと必要だと考え、local環境の他にAWSに個人的な DBサーバーを立ててphp-srcにバンドルされている全種類のドライバをリモートでも使えるようにしたりしました。また、IBMのDB2特有の事象にも対応するため、IBM環境も用意しました。
そんな熱意を見てくれていたのか、2024年からはコア開発者として活動することになります。
OSS活動で磨かれた、技術とマインドセット
OSS活動を通じて得られたことはたくさんありますが、自分で大きな変化だと思うものを挙げるとまず、間違いなくバグの調査・修正速度が上がった実感があります。
普段の業務では開発が多く、インシデント対応でもなければバグの調査や修正に時間を使うことはあまりありません。しかしphp-srcでは新機能の追加よりもIssue対応の方が優先度が高いため、そのあたりの「勘」がかなり鍛えられたと思います。
もうひとつ、本当に大きく変わったのが「コミットの積み方」です。
それまでは適度にキリがいいかな？というところでコミットして、何か間違いがあればあとから修正コミットして....というような感じであまり粒度を意識していませんでした。
OSS活動を始めてからは、まず「レビューしてもらうということは誰かの時間を奪うことだ」という側面を強く感じるようになり、可能な限りレビューしやすいものを出さなければならないと考えるようになりました。その結果、コミットを「関心」ごとに分割し、何か間違いがあった時には（レビュー前なら）rebaseして該当コミットの修正を行なうようになりました。時にはテスト駆動のように「テストだけ先に仕様変更」してわざとCIが失敗するのを待ち、その後でコード変更をコミットしてCIが通るのを示す、ということもするようになりました。
ここまでは主に開発者視点でのお話です。
Release Managerとしての経験はまた違ったものを私に与えてくれました。その多くはセキュリティ関係のことなのであまり詳しく書くことはできませんが、セキュリティ関係ではないものからひとつ。
リリース資材のtarball生成時、ソースコードを圧縮し、tar.gz、tar.bz2、tar.xzの3種類のtarballを作成します。圧縮時にGPG Keyを使用することで改竄を防止していて、自分のGistには圧縮の際のmanifestを公開します。
また、リリースアナウンス時、新しいお知らせをWebサイトへ追加したり、Change Logに変更を加えたりという作業があります。
一見どれも面倒そうな作業に見えますが、実は全てコマンド化されていて、コマンドを叩くと全自動で処理が完了します。
Change Logの更新なんかは、GitHubのphp-srcリポジトリ内の「NEWS」ファイルへアクセスして、正規表現を使ったりして該当バージョンの更新だけ抜き出して持ってくるなど、結構力技なこともしています。
多少強引で力技になったとしても、自動化できるものは自動化するというのはかなり負担が下がる実感があり、PHP以外の業務でもとにかく自動化を意識するようになりました。
可読性か、処理速度か。コンパイラからの学び
印象的なエピソードをお話しする前に、まずC言語の基本的なところに触れたいと思います。
C言語で書いたコードは、コンパイラによって機械語へ翻訳（コンパイル）され、実行できる状態になります。 PHPもCで書かれていますから、実行するためにはまずCをコンパイルしなくてはいけません。
さて、あるコードを書いていた時、活発なメンバーの一人であるNielsから「可読性が悪い」との指摘を受けました。私としては「可読性を犠牲に処理を早めた」つもりだったのでそのようにコメントを返したのですが「コンパイル結果はおそらくこの場合変わらないはずだ」と言うのです。試しにアセンブリコード（機械語に完全に翻訳すると人間が読める形ではなくなります。アセンブリコードは、機械語にした時と同じ処理手順を人間が読める形にした記述法です）に変換してみると、たしかに結果が変わりません。
それ以来、処理効率を上げる時は、ベンチマークで差が微妙な場合必ずアセンブリコードを確認するようになりました。
アセンブリコードが変わるような変更の際、Nielsはあまり可読性について指摘をしません。頭の中にコンパイラが入っているのかな？と思うくらい、高精度で結果を予測できるようです。最初「頭の中どうなってるんだろ...」と思っていましたが、処理効率を上げる変更を試みていくうちに私も多少は予測可能になってきました。
Nielsはコミット数がものすごいので、膨大な経験値が予測の精度を上げているのかもしれません。
可読性よりも実行速度を優先されやすく、かつC言語であるという点で、php-srcなどの言語系リポジトリ以外ではあまり見ないようなケースで、印象的でした。
PHPコア開発の現場から考える、これから
闇雲に新しい機能やAPIを追加するのはただ複雑さを増やすことに繋がりかねません。 現場で機能がどう使われているのか、そして「もっとこれがこうだったらなぁ」という声がどんなふうに上がっているのかを見て、色々な提案をしていけたらと思っています。
一方で、英語圏に比べると日本では「php-srcに機能要望を出す」ということがあまりない印象があり、日本のPHPコミュニティとphp-srcとの距離感がもっと近くなるには何が必要か？を考えています。
1行の修正からでも、OSSの世界に踏み出せる
仮に出した変更が間違っていたりしても全然大丈夫ですし、決して1人の一存だけで決まるものではありませんので、「こんなのはどうでしょうか？」と気軽に提案するイメージでやってみて欲しいです！
簡単な修正だと、1行だけの変更PRというのもメンテナーはたくさん出しています。 変更量が多くなければいけないということはありませんので、簡単なところからチャレンジするのがオススメです。
世界中のエンジニアと関われたり、キャリアアップのための実績にもなりますし、綺麗なコードの書き方やコミットの積み方などが身についたりと、メリットは沢山あります。
あなたも一歩、踏み出してみてはいかがでしょうか？