シェア
はてブ
高町咲衣さんは、PHPコア開発者でありPHP8.4にて日本人として歴史上初めてのリリースマネージャーを務めた人物です。ほんの2年前まで、高町さんはOSSへのコントリビューション経験がゼロでした。「OSS開発は超人たちがするもので、自分とは遠い世界の出来事」だと、ハードルの高さを感じていたといいます。しかし、一歩を踏み出す勇気と日々の小さな積み重ねが、キャリアを大きく変えたのです。高町さんのこれまでの歩みには、エンジニアがOSSに挑戦する意義や成長のヒントが詰まっています。
BC Break修正から始まったOSSへの挑戦
――まず、PHPのコア開発者やリリースマネージャーとして、どのような活動をされているのかを教えていただけますか？
PHPコア開発者としては、主にPDO*1やBCMath*2を担当しています。PDOはコア開発者になる前からIssueを見ており、その延長でデータベース系の他の拡張機能にも関わるようになりました。BCMathは新機能を追加するためのRFC作成や高速化を目的としたリファクタリングを行ううちに、自然と専門領域になりました。
リリースマネージャーとしては、2024年11月にPHP 8.4のGA（General Availability）をリリースした後は、現在のところ大きな作業はありません。もう一人のルーキーのリリースマネージャーである、Calvin Buckley氏と毎月交代でリリースを担当しています。
――PHPへのコントリビューションを始めたきっかけは何だったのでしょうか？
きっかけは、PHP 8.1で発生したBC Break（後方互換性の破壊）でした。データベースで桁数を指定した浮動小数型のカラムを使用している場合、従来の挙動では「3.60」のように指定された桁数の値が返されていたのに、特定の条件下で「3.6」のように桁数の少ない値が返される問題が見つかりました。
文章だけでは、コントリビューターの方々にこの仕様の問題点が十分に伝わらない可能性がありました。また、PHP 8.3の機能凍結の時期だったためコアメンバーが忙しく、Issueが立てられていても十分な反応が得られない状況だったんです。それに、このBC Breakが修正されなければ、私が業務で扱っているアプリケーションにも影響が出てしまうという状況でした。こうした背景もあり、「自分でやってみよう」と取り組むことにしました。
「PDOは私が見よう」前向きな責任感が生んだ新たな挑戦
――最初にPull Requestを出したとき、どのように感じましたか？
OSSというと、どこか遠い世界で超人たちが難解な技術を扱っているようなイメージがありました。ですが、実際に取り組んでみると、意外に内容を理解できましたし、修正も理にかなった形で進めることができたんです。もちろん不安はありましたが、そのバグによって困っているユーザーが他にもいるだろうと思い、「勇気を出して、これでいこう」と一歩を踏み出しました。
Pull Requestに対して辛辣なレビューが来ると思っていましたが、レビュアーのみなさんは非常に優しくコメントをしてくれました。やってみると、意外と自分にも手が届く世界だと実感し、それが自信につながりましたね。
さらに、PDOを専門とするメンバーがいないことをそのときに知り、既存のメンバーが限られたリソースで調査を進めている状況を目の当たりにしました。もともと、私はデータベースにある程度詳しかったこともあり、「私がPDOを担当すれば、他のメンバーの負担を軽減できるかもしれない」と考えたんです。そこから、PDOのコードを勉強しつつ、関連するIssueをすべて拾うように努めました。
――企業でエンジニアとして働きながら、OSSの勉強をするのは大変なことだと思います。どのようにして勉強時間を捻出し、モチベーションを維持していましたか？
業務時間の前後1時間や、土日の数時間を勉強に充てていました。とはいえ、必ずしもパソコンを使って作業する必要はないので、スマホのGitHubアプリでコードを読むことも多かったです。
もともと、「わからないこと」を理解できるようになることに達成感を覚えるタイプなので、何か疑問が浮かぶたびに、それを解消していきました。「勉強するぞー」という意識だったというより、「疑問を解決する」ことをくり返した結果、自然と勉強になっていたという感覚に近いです。
疑問が浮かんでから解決するまでのスパンが短く、それを何回も重ねて達成感を得る機会が多かったことが、モチベーションの維持につながったんだと思います。
――PDO関連の作業で、特に印象に残っていることや学びになったことはありますか？
「[PDO] PDO::PARAM_XXX behavior is inconsistent」というIssueでのやりとりが印象深いです。PDO::PARAM_XXXを使用した際の動作が、データベースドライバーごとに異なるという問題があります。この動作の不一致が原因で、同じPHPのコードを異なるデータベースで動かした場合に、予期しない挙動を引き起こします。そこで、PDO::PARAM_XXXのパラメーター指定において、すべてのデータベースドライバーが一貫性のある動作をするように変更したいと提案しました。
しかし、どの案を採用しても必ずどこかでBC Breakが発生してしまい、統一する利点があまり大きくないと判断されました。結果として、私の提案は実行されなかったんです。この経験を通じて、ある変更がもたらすメリットと、BC Breakによる影響を天秤にかけ、変更の価値を判断することの重要性を学びました。既存の仕様のまま使い続けているユーザーがいるなかで、その方々に負担を強いてでも変更を行う意義があるのかを、常に考える必要があると実感しました。
活動の実績が認められ、コア開発者に
――高町さんがPHPのコア開発者になった経緯も教えてください。
PHPのコア開発者として活動するには、The PHP Foundationが提供する支援プログラムに応募するのが一般的です。「いつかは自分もコア開発者になりたい」と思っていたところ、募集がかかっていたので応募しました。
「できることはやったけれど、そう簡単にはうまくいかないんじゃないかなー。だけど、挑戦してみよう！」という気持ちでドキドキしていました。本当に合格をもらったときは、信じられない気持ちでしたし、ものすごく嬉しかったです。後から知ったのですが、応募者は合計で200人ほどいたようで、なおさら驚きました！
――そうして2024年1月からコア開発者として活動され、BCMathのパフォーマンス改善に注力されたと伺っています。なぜ、この領域に取り組まれたのでしょうか？
私がコア開発者になる前から、PHPコミュニティ内でround関数の仕様についての議論が行われていました。その過程で、round関数のエッジケースについてコア開発者同士で意見が分かれ、方針を決めるために私が「RFC: Change the edge case of round()」を作ったんです。結果的にはこのRFCは否決されて、従来通りのround関数の仕様が維持されることになりました。
この議論をきっかけとして「小数を正確に扱うために、BCMathにround関数のようなものがあると良いよね」という話が出たんです。そこで、並行して私が「RFC: Adding bcround, bcfloor and bcceil to BCMath」も作成して、こちらは可決されました。
こうしたBCMath関連の議論を進める過程で、PHPのメーリングリストでは「BCMathはあまりパフォーマンスが良くない（ので、あまり触れない方がよいですよ）」という意見をたびたび目にしました。それが悔しくて。「遅いなら、もっと速くしよう！」という思いで、パフォーマンス改善に力を入れることにしました。
その後、パフォーマンス改善に詳しいコントリビューターのNiels Dossche氏が、BCMathの修正に加わってくれました。私が計算ロジックを変更し、Niels氏が別のアプローチから改善を加えていったんです。その結果、桁数の大きな除算においては最大で50倍の速度向上を実現しました。さらに、データの持ち方を変えるなどすれば、今後もまだ改善の余地があります。
――相当な高速化ですね！
ありがとうございます。この結果を出せて素直にすごく嬉しいのと、これをきっかけにBCMathを使ってくれる方がより増えたらと思っています。
思っているよりもずっと、コントリビューションのハードルは低い
――高町さんはPHP8.4にて、日本人初のリリースマネージャーも務めました。このお話も聞きたいです。
毎年、リリースマネージャーの枠は決まっています。立候補制になっていて、枠を超えた場合には投票で決定する流れです。PHP8.4では立候補者が複数名いましたが、投票で2位になりリリースマネージャーを務めさせていただきました。
リリースマネージャーを経験してあらためて感じたのは、PHPのコントリビューターのみなさんが本当に優しいということですね。リリース作業が円滑に進むよう、気を配ってサポートしてくれました。
これに関連する話をすると、PHPのコミュニティは他者への思いやりがあって、特定の個人を非難しない文化があります。何かの意見に対するコメントは積極的に行われますが、それはあくまで議論であって攻撃ではありません。もし、誰かを傷つけるような投稿があれば、必ず注意されます。そんな環境・雰囲気も、開発のやりさすさや作業効率につながっていると感じます。
――心理的安全性の高いコミュニティですね。この記事を読んで、OSSへのコントリビューションを始めてみようと考える人もいるはずです。そうした方々に、何かアドバイスはありますか？
ある程度の規模のリポジトリには、大抵CONTRIBUTING.mdというファイルがあります。これはコントリビューションの手引きのようなもので、環境構築の方法やルール、ノウハウなどが記載されています。まずはこれを読んで、プログラミングとは直接関係のない準備作業などを、ストレスなくクリアしてほしいです。小規模なリポジトリの場合は、README.mdに記載されていることもあります。ほとんどの場合は英語で書かれているので、英語が苦手な方はWebブラウザの翻訳機能を積極的に活用してください。
勉強方法としては、コアメンバーが作成した「差分の小さなPull Request」を暇なときに眺めるのもおすすめです。差分の大きなPull Requestだと内容を追うのが難しいので、変更行数が20行未満くらいのものを読んでください。すでにマージ済みのもののほうが、こうした特徴を持つPull Requestを見つけやすいと思います。
Pull Requestの説明文があれば「何をしたいのか」がわかるので、それをコアメンバーがどのように実現したのかを確認できます。Issueが紐づいていれば、何の問題をどう解決したのかを把握できます。
どのようなコードを書くべきなのかは、リポジトリから学ぶのが最も確実です。たとえば、php-srcはZend Engineを前提とした構造のため、C言語の知識があってもすぐにコードを書けるわけではありません。まずは、Zend Engineの使い方を学ぶ必要があります。
私の知る限り、Zend Engineを扱った書籍はそもそもありません。それに、プロジェクトにおける「最近の書き方」のようなスタイルもあるので、やはりそのリポジトリのコードを読み解きながら学ぶのをおすすめします。
――最後に、これからOSSへのコントリビューションに挑戦する方々へのメッセージをお願いします。
OSS活動というのは一種のボランティアであり、参加者が増えるのはとてもありがたいことです。確かに、乗り越えるべきことは多少ありますが、そのハードルはみなさんが思っているよりもずっと低いものです。やってみると、「そんなに身構えなくてもよかったな」と感じるはずなので、気軽に参加してほしいです。
PHPのすべてを理解している人はいないので、できる範囲でやってみてください。途中まで実装し、残りは詳しい人に任せるのも立派なコントリビューションです。ぜひ、気負わず挑戦してみてください。
取材・執筆：中薗昴
写真提供：高町咲衣
