⼀⼈で⼤規模OSSに⽴ち向かうには Sosuke Suzuki YAPC::Fukuoka 2025 

⾃⼰紹介 Sosuke Suzuki ( https://x.com/__sosukesuzuki ) Systems Engineer at Bun WebKit Reviewer Prettier maintainer 2 

Perl、YAPC ● YAPCへの参加はYAPC::Hiroshima(2023)以来の⼆度⽬ ● Perlはほとんど書いたことがない ○ WebKitのスクリプトはPerl、Ruby、Pythonで書かれているので読むことはあるが... ● しかし、中学⽣の頃の将来の夢「天才Perlハッカー」 ○ 2014年、2015年くらいにmiyagawaさんやnaoyaさんのアウトプットを⾒て勝⼿に憧れてい た 3 

今⽇話すこと 1. 私とOSSとの関わり 2. OSSに⽴ち向かう上で、最も重要なアプローチ 3. より具体的な、OSSへの取り組み⽅ 4 

⾃分とOSSとの関わり ● Boostnote ( https://github.com/BoostIO/Boostnote-legacy ) ○ 2016 ~ 2018 ○ 福岡発のOSSだったはず ○ ⾼校⼀年⽣の時の最初のバイト先 ● Prettier ( https://github.com/prettier/prettier ) ○ 2019 ~ 現在 ○ ⼤学⽣になった頃貢献を開始、⼈⼿不⾜でメンテナーに ● WebKit/JavaScriptCore ( https://github.com/webkit/webkit ) ○ 2024年 ~ 現在 ○ 今⽇は主にここから得た話をする 5 

WebKit ● Appleが中⼼となって開発しているOSSのブラウザエンジン ○ Safariのやつ ● Apple以外にも、IgaliaやSonyといった企業の開発者たちも開発に参加 ○ 今ではBunも 最近ロゴがちょっとだけ変わった 6 旧ロゴ 

JavaScriptCore ● WebKitに搭載されているJavaScriptエンジン ● クソ速いインタプリタ 前⾝であるSquuirelFishのロゴ、かわいいね 7 

WebKit開発者の三つのランク ● Contributor ○ 基本的にまずは皆んなここから始まる ○ 特に明⽰的な権限はない（と思う） ○ 登録しとくとCIのrebuildとかができるようになる ● Committer ○ 30件くらいのPRがマージされると、推薦を受けることができる ○ mainブランチへのマージができるようになる ● Reviewer ○ 90件くらいのPRがマージされると、推薦を受けることができる ○ 他者のPRに対してreject/approveできるようになる 8 

⾃分の場合 ● 2024年の2⽉に貢献開始 ● 2024年の6⽉にcommitterの推薦を受ける ○ 実はここに法的な⼿続きがある ○ これに⼆ヶ⽉かかって2024年8⽉にcommitterになった ● 2025年の2⽉にreviewerの推薦を受け、reviewerになる ○ おそらく、この時点ではほぼ唯⼀の無給のWebKit reviewerだった、多分 ● 現時点で約300個くらいのパッチがマージされている 9 

JavaScriptCoreの難しさ ● そもそもJavaScriptは難しい ○ ⼤きく歴史があり⼀貫性がなく進化する仕様 ● そして最適化された⾔語処理系の実装も難しい ○ 構⽂解析 ○ バイトコードインタプリタ ○ JITコンパイラ ○ 正規表現エンジン ○ WebAssembly ○ ガベージコレクタ ○ メモリアロケータ ○ など... ● どうにかこうにかやってみて、フルタイムの仕事を得るに⾄った 10 

今⽇のメインテーマ ● 「⼀⼈で⼤規模OSSに⽴ち向かうには」 ● 「継続的に貢献をして信頼を得るには」 11 

実は「⼤規模なOSSに⽴ち向かう」必要はない ● 「⽴ち向かう」=「⾃明なドキュメントの修正やタイポの修正、⼀度や⼆度 のバグ修正ではなく、数年単位で責任を持ってやっていく」 ● 個々⼈の⽴場に⽴てば、ほとんどの場合⽴ち向かう必要なんてない ● 確かに良いことはたくさんある ○ 給料をあげたい、成⻑したい、有名になりたい、⾯⽩い、などなど ● が、⼤体コスパ悪いと思ってる ● （説得⼒はないだろうが...） 12 

それでもなぜか⽴ち向かいたい⼈向けの話 ● どうしてもやめられないとか、仕事で必要とか、⾊々な理由がある ○ ⾃分はそうだった ● 今⽇はそういう⼈に向けた話 13 

最も重要なこと ● 「時間を可能な限り捻出して、可能な限り集中して使うこと」 ○ ⾝も蓋もないのだが ● 特に、慣れる前は絶対にやった⽅が良い ○ 練度が上がると、短い時間でも成果がだせるようになってくる ○ ⼀⽅で、やりはじめたばかりのことは、⼀週間やらないと全部忘れてしまう ○ （⾃分のように）不器⽤な⼈は特に... ● かつて、あなたがやったように ○ ⼤体、この話を聞いてくれる⼈はある程度プログラミングができると思う ○ どこかのタイミングでプログラミングに時間を使って集中していませんでしたか？ ○ それと同じことを、意図的にやる 14 

情熱をエミュレートする ● 何かに熱中している⼈は⼤量の時間を突っ込んでいる ● 実際に好きかどうかはどうでも良いので、熱中している⼈のフリをして、時 間を突っ込んでみる ○ 「好きこそものの上⼿なれ」の真似 ● 時間を作るのは難しい、だけど ○ 「今のライフスタイルをみて、もしめっちゃ情熱のある奴だったら、どういう⾵に動くだろ うか」 ● それでも全く時間を捻出できないなら、それはOSSに⽴ち向かっている場合 ではない、と⾔うことかもしれない 15 

⾃分の場合 ● ⾃堕落にも、全てのやることを可能な限り放棄して、WebKitに全ての時間を 突っ込んでしまっていた ○ 朝起きて⼤学に⾏き、JavaScriptCoreのバグを直して、卒論やらなきゃなーと考えなが らJavaScriptCoreのコードを読んで問題を⾒つけて修正し、仕事やらなきゃなーと考え ながらJavaScriptCoreのコードレビューをして、夜には家に帰る ○ 仕事も学業もなんの進捗もない...みたいな⽇々 ● 会社員として学⽣としてダメダメではあるが、WebKitはできた ○ 情熱がどんどん⾼まっていった ○ JSCのことを考えるあまり眠れなくなったり、JSCをやるために起きたり、⼼⾝ともに疲弊し たことも... ○ （やめた⽅が良い） ● 過去のOSSへの関わり⽅（Prettier、Babel、など）も同じだった ○ ⼤学の課題などを全て放棄したり、OSSへの貢献を仕事にこじつけて業務時間にやったり... 16 

要は ● 「時間を可能な限り捻出して、可能な限り集中して使うこと」 ● 「現在の⾃分の⽣活の中で、もしめちゃくちゃ情熱的だったら時間をどのよ うに使うだろうか」を考えて動いてみる ● ライフスタイルをぶっ壊すのは... ○ 個⼈の⼈⽣なので好きにしたら良いとは思う ○ オススメはしない ○ 責任も取らない 17 

とはいえ、時間があっても ● 時間があっても、それをどう使うか、と⾔うのも重要 ● やってみて有効だったことや、後悔からくるTIPSを幾つか紹介 18 

対象のソフトウェアのアーキテクチャを把握すること ● コードだけでなく、ブログやドキュメント、コメントなどを⼿がかりにし て、ソフトウェアの⼤まかなアーキテクチャとなんとなくのコードを把握す ると役にたつ。 ● ユーザーの⼊⼒はどのようなデータ構造としてコンポーネント間をわたって いき最終的な出⼒へと繋がるのか？それぞれのコンポーネントは⼤体ソース コードのどこにあるの？ ● ⾃分だけで理解できない時は、コードを⾃⼒で読むための⼿がかりをClaude CodeやCodexに聞けて便利。 19 

たくさん⼿を動かしてメンタルモデルを得ること ● とにかくたくさんコードを書いて、⼿元でビルドをして、デバッガやprintf でちゃんと動作を⾒る。⾃分でやる ● どのタイミングでどのデータ構造にどんな値が⼊っているの？把握したアー キテクチャは本当に正しいの？ ● データ構造、データの流れ、コーディングスタイル、実際の値、開発のやり ⽅、などのメンタルモデルと常識を獲得する。 ● このフェーズでは⽣成AIコーディングエージェントを無効にするのもオスス メ。 20 

失敗は無駄ではないと認識すること ● バグを直そうとして⼀週間かけて、⼀つもパッチを出せなかったとき、とて も無駄なことをしている気持ちになる。 ● が、無駄ではないと認識する。 ● デバッグなどの⼿を動かす⼿癖、該当箇所におけるデータ構造や値の常識、 メンタルモデルが残る。これは次の⾃分を必ず助ける ● だから苦しくてもやる 21 

試⾏錯誤せず理解に努める > 思いつきでいろいろなパターンを試して正解を探しているだけなので、とても 時間がかかる上、新しい知識を何も学んでいない。 引⽤：⽜尾剛 (2023)「世界⼀流エンジニアの思考法」⽂藝春秋 ● ただ⼿（やAI）を動かして正解を⾒つけるのではなく、本気で理解しにいく ● 仮説を⽴てる、仮説を検証するために⼿を動かす、後の⾃分に何かが残るよ うに 22 

教科書を読むこと ● ときには、コードを読んだり書いたりせずに、そのソフトウェアに関連する ⼀般的な教科書などを読む。 ● 難しいソフトウェアのコード中には、⼀般的なWeb開発者では知らないよう な⽤語が出てくることがある。 ○ たとえばJSCなら「NaN Boxing」「Write Barrier」「Graph Coloring Register Allocation」 「Strength Reduction」などなど。 ● ⼤体普通に勉強すればわかるので、コーディングを⽌めて教科書や論⽂を読 みましょう。 ○ たとえば、上記の⽤語は「Crafting Interpreter」「The Garbage collection handbook」「コ ンパイラの構成と最適化」などで知ることができます。 23 

プログラミング⾔語の勉強をすること ● コードが理解できないとき、すんなり読めないとき、書かれている⾔語への 理解がたりないことがあります。JavaScriptからプログラミングを始めた⼈ にとって、C++はわかりにくい ● でもめっちゃ勉強すれば読める！めっちゃ勉強する ● 教科書を読んで、コードを読んで書いて、教科書を読んで、を繰り返す 24 

他の貢献者の活動に⽬を光らせる ● 経験のある他の貢献者はどのようにバグを修正しているだろうか。彼らのコ ミットメッセージ、差分はどの様なものだろうか。彼らがやり残しているこ とはないだろうか。 ● 勝⼿にコードレビューしてみるのもオススメ。 ● ⼩さな差分から、⼤きなアーキテクチャを想像できることがよくある。 25 

対象を適切に舐めること ● 対象を必要以上に難しいものだと思わないこと。 ● 理解しようとして、死ぬほど時間をかけてみて、⼈に聞いてみて、めっちゃ ⼿を動かしてみて、それでも本当に理解ができなかった概念がいくつある？ 多分あんまりないんじゃないか？ ● 適切に対象を舐めて、できるだろうと思ってやってみる 26 

寝ること、⾃然を歩くこと ● 寝よう ● ⾃然を歩こう ○ 可能な限り⼈と話しながら⾃然を歩く ○ 下の写真は筑波⼤学キャンパス内のカモと⽵林 27 

まとめ ● 最も重要なのは「時間を確保して集中すること」 ● その上で、本気で理解しにいく ○ ⾊々話したが、要はマジで理解しにいくだけ ● 気が狂ってきたら歩きながら鴨とか⾒る ○ マジで理解しにいくことは本当に疲れること、疲れたら休んだ⽅が良い 28