こんにちは、
id:da1chi24 です。
Classi では、チーム横断でOSS活動に取り組む「OSSやっていきの集い」を行っています。早いもので活動開始から1年が経過しました。 発足の経緯や過去の活動は、前回の記事をご覧ください。
ここでは、OSSやっていきの集いを通して、私自身が実際にOSSへコントリビュートした経験と、活動を通じて実感したメリットについてお話しします。
HTML Parser の修正（Herb へのコントリビューション）
社内では Rails サービスの開発をする際に、ERBの静的解析ツールとして Herb を利用しているリポジトリがあります。
ある日、HerbでHTMLをパースしているコードにおいて <div></DIV> のように大文字・小文字が混ざっていると、Parser エラーになることが分かりました。この挙動は普段ブラウザでは見かけないため、違和感がありました。
実際に発生していたエラー
Errors (2 total)
1. MissingClosingTagError at sample.erb.html:1:0
Opening tag `<div>` at (1:1) doesn't have a matching closing tag `</div>` in the same scope.
2. MissingOpeningTagError at sample.erb.html:1:5
Found closing tag `</DIV>` at (1:7) without a matching opening tag in the same scope.
そこで、改めて HTML Living Standard を確認すると「タグ名は case-insensitive である（大文字小文字を区別しない）」と明記されていました。
In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element’s tag name; tag names are case-insensitive. refs. https://html.spec.whatwg.org/multipage/syntax.html#elements-2
つまり、Herb Parser と HTMLの標準仕様は振る舞いに乖離がありました。特に深い意図がない限りは、基本的に Herb は HTMLの標準仕様に準拠するべきだと考え、Issue で報告しました。
さらに一歩踏み込んで原因を探るため、Herb Parser の内部実装も読んでみることにしました。Herb Parser は HTML + ERB を Abstract Syntax Tree (AST) という木構造に変換して解析しています。この AST を解析する処理を追っていくと、開きタグと閉じタグの比較が大文字・小文字を区別して行われている実装箇所がわかりました。その調査内容も Issue に追記しました。
報告後、オーナーの方から「確かにその通り、原因分かってるならぜひ直して欲しい！」というコメントをいただいたので、修正のPull Requestを作成、無事にマージされました。
1年間活動して感じた変化、当初の目的を達成できたのか
前回の記事では、活動を通じたアウトカムとして「OSSに関わる心理的ハードルを下げる」「実践を通じた学び」「チームを越えた交流」などが挙げられていました。実際に私が1年間参加してみて、これらは得られたのかを振り返ります。 https://tech.classi.jp/entry/2025/06/23/120000
OSSへの「心理的ハードル」が下がり、日々の仕事の質が上がった
以前の私は、問題の再現性をとってIssueを立てたり、普段開発をしないリポジトリに対して Pull Requestを作成したりすることに、ハードルを感じていました。しかしOSSやっていきの集いの中で、気軽に相談し、事象の再現方法を一緒に考えてくれる場があったことで、OSS活動へどのように関われば良いかという視点が得られました。その結果、私自身のOSSに対する心理的ハードルはかなり下がりました。
また、この「OSSに関わる観点やプロセス」は、普段の仕事にも直結していると感じています。Classi には社内ライブラリやデザインシステムがあります。こういった普段の自分が関わらないプロダクトに対しても、バグを見つけた際に「ここが原因だと思うので直していいですか？」と直接 Pull Request を出しています。こういった課題を拾い、原因調査をして、改善の提案をするまでの動きが早くなったという実感が得られました。
単なる指摘にとどまらず、解決策を提案するコミュニケーションを取るかどうかで、問題解決までの速度が上がるという話は、以下のブログで挙げられている「提案のレベル」の話に繋がっています。OSS活動での経験が、結果的に日々の仕事の「提案のレベル」を引き上げてくれたのだと思います。
チーム横断で問題を解決する地力を育てる場になってきた
OSSやっていきの集いでは、新卒1年目のジュニアエンジニアからアーキテクトまで、チーム横断で様々なエンジニアが参加しています。同じチームでなくても、フラットにコミュニケーションを取る場になっています。 実際にOSSにコミットするために、仕様書を読み込んだり、内部実装をデバッグし状況が再現するようなエビデンスを集める必要があります。今ある課題を特定し、問題が再現する最小のコードを探していくプロセスは、普段の業務でのバグ修正や障害対応に直結しています。こういった実践的な学びを得られる場として、OSSやっていきの集いは機能していると思います。
社内のレベルを底上げするOSSやっていきの集い
この1年間で、OSS活動はコントリビュートするという結果だけでなく、「課題を発見し、他人に伝わる形で再現し、実際に手を動かして解決するというプロセスそのものに重要な学びがある」と感じました。こういったプロセスを複数のメンバーと取り組むことで、個人の学びを組織の学びに昇華できる重要な機会になっています。今後も続けていきたい活動です。
今回の記事を読んで、1つでも得られるものを持ち帰っていただければ幸いです。
