本記事では、「OSS応援企画」として記事の最後に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
こんにちは。今泉麻里（@ima1zumi）と申します。私はふだん、Ruby on Railsを使ったWebアプリケーション開発を仕事にしているエンジニアです。Webエンジニアとしてのキャリアの中心はあくまでRailsアプリケーションで、低レイヤー寄りのエンジニアとしてスタートしたわけではありません。文系学部出身で、コンピュータサイエンスの知識もありませんでした。
この記事では、Issueを出すのも怖かった自分が、どうやってエコシステムの中に居場所を見つけていったのかを振り返りながら、これからOSSに挑戦したい人へのメッセージをお届けしたいと思います。
最初の一歩は家族の絵文字から
Rubyに惹かれたきっかけは、Rubyコミュニティの雰囲気でした。私がRubyを学び始めた頃はコロナ禍でした。オンラインの勉強会がメインだったこともあり、Ruby関連のイベントやコミュニティに少しずつ顔を出すようになりました。ちょうどその頃、プログラミングスクールのフィヨルドブートキャンプに在籍していて、学びながらコミュニティに出ていくことが日常になっていました。
そんな中、ある日ふと見つけた不具合をきっかけに、私はRelineへのコントリビューションデビューをすることになったのです。
その不具合とは、IRBに家族の絵文字を入力して文字を削除すると、IRBがクラッシュしてしまうという問題でした。さすがに「これはバグだろう」と思う一方で、心のどこかではためらいもありました。
「家族の絵文字なんて、そんなにIRBに入力されないはず」
「こんなニッチなケースをIssueにしていいのかな……？」
クラッシュする以上は不具合なのは間違いないのですが、「誰も困っていないのでは」と考えて、Issueを出すだけでも少し怖かったのを覚えています。
そんな背中を押してくれたのが、当時一緒に学んでいたフィヨルドブートキャンプの仲間たちでした。仲間たちのおかげで、「じゃあ出してみよう」と思い切ることができました。
そもそもIRBとRelineとはなにか
ここで少し寄り道をして、この記事の主役でもあるIRBとRelineについて、簡単にご説明します。
IRB は Interactive Ruby の略で、Rubyの対話型シェルです。 Pythonにおける対話モードや、言語ごとのREPL（Read-Eval-Print Loop）に相当するもので、ターミナル上でその場でコードを入力して、すぐに結果を確かめることができます。
$ irb
irb(main):001> 1 + 2
3
開発中にちょっとした挙動を確認したり、ライブラリの使い方を試したりするときに、多くのRubyプログラマが日常的に使っているツールです。
一方でRelineは、IRBなどの対話的なコマンドラインツールの行編集を担当するライブラリです。キーボードの矢印キーでカーソルを動かしたり、入力履歴をたどったり、途中まで書いたコードを補完したりと、こうしたターミナル上での入力体験の多くは、裏側でRelineが支えています。
この記事では、そのIRBとReline、そして文字コードの知識を深めるようになった経緯を中心にお話ししていきます。
作者からの「やってみない？」の一言で、すべてが動き出した
Issueを出したあと、予想していなかった展開が待っていました。
当時参加していたオンラインのRubyコミュニティの集まりに、Relineの作者である糸柳さんが来てくださったんです。そこで直接、こんなふうに声をかけられました。
「あのIssue見たよ。原因はだいたいこういうところだと思う」
「Relineはこういう仕組みになっているから、こう直せば解決できそうなんだけど、やってみない？」
まさか自分が出したIssueについて、作者本人から「やってみない？」と誘ってもらえるとは思っていませんでした。でも、そう言われたからには、そして何より自分でも興味が出てきたからこそ、「じゃあやってみます」と答えるしかないな、という気持ちでした。
ここが、私とRelineとの付き合いが本格的に始まったポイントでした。
「原因はわかった。でも直し方がわからない」に悩む日々
とはいえ、そこからすぐに華麗に直せたわけではありません。
家族の絵文字の問題は、Unicodeの書記素クラスタの扱いに一貫性がないことから起きていました。ここでは詳細は割愛します※が、文字の挿入時と削除時で文字の数え方が異なっていたことが原因でした。しかし当時の私は、書記素クラスタどころか、文字コードの仕組みもあまり理解していない状態でした。
最初にやったのは、いきなりコードを書くことではなく、『プログラマのための文字コード技術入門』を読むことでした。「文字コードとは何か」「Unicodeとは何か」「1文字とは何か」「結合文字とは何か」といった足元の部分から、少しずつ学びました。
その頃はフィヨルドブートキャンプにいて、比較的じっくり学ぶ時間もあったので数ヶ月かけて勉強したり、また別のことをしていたりを繰り返しながら、のんびり取り組んでいました。
結果として、どこでおかしな扱いをしているのかは理解できました。でも、それをどう直すのが正解なのかはわからないという中途半端な状態に、しばらくとどまっていました。
※ 問題の詳細はRubyKaigi 2025のima1zumiの発表 “Ruby Taught Me About Encoding Under the Hood” をご覧ください
「ここまではわかりました」と正直に伝えたら、前に進んだ
そのまま時間が経ち、次のRubyのリリースが近づいてきた頃、作者の方から「例の件、進捗どう？」と声をかけてもらいました。
正直に言うと、このとき進捗がなく、
「原因までは分かったんですが、直し方は正直まだ自信がなくて……」
と伝えたところ、返ってきたのはダメ出しではなく、
「じゃあ、こう直してみるのはどうかな？」
という具体的な提案でした。
そのアイデアをもとに手を動かしてみると、たしかにうまく動きました。さらに「じゃあテストも追加しよう」「こういうケースも落とし込もう」と、教えてもらいながら、最終的に修正を仕上げていきました。
この経験から学んだのは、
- 「完璧な解決策が分からなくても、『ここまでは分かりました』と共有していい」
- 「途中までの理解も、メンテナーにとっては十分価値がある」
ということでした。
自力で全部をやり切れなくても、一緒に直す相手としてプロジェクトに関わることができる。この感覚は、OSSに対するハードルをぐっと下げてくれました。
自然と「勝手にお手伝い」するようになっていった
最初の不具合対応が終わったあと、Relineは私にとってちょっと特別なライブラリになりました。自分が関わったコードが入っているプロジェクトということもあり、どうしても目が向くようになりました。
そこからは、誰かに頼まれたわけでもないけれど、自然とこんなことをするようになりました。
- Issueで再現条件や使用バージョンの記載がないものには、確認のコメントをする
- 明らかにIRBやRelineではなく別のところが原因と思われるものには、その旨を丁寧に伝える
こういった「勝手にお手伝い」が歓迎されるかどうかは、メンテナーの方針次第です。でもRelineでは、それがむしろ助けになっていたようで、作者の方からもポジティブに受け取ってもらえました。
こうして少しずつ、「Issueを出すだけのユーザー」から「プロジェクトの近くにいるコントリビュータ」に、役割が変わっていったように思います。
作者が不在になったタイミングで届いた、メンテナーへのお誘い
やがて糸柳さんが、いろいろな事情もあって以前ほどアクティブに活動できない時期が訪れました。IssueやPull Requestが溜まりがちになり、対応がどうしても止まってしまうタイミングも増えてきました。
そんなとき、あるRubyコミッターの方から声をかけてもらいました。
「よかったら、IRBとRelineのメンテナーをやりませんか？」
それが、正式にメンテナーとして関わるきっかけでした。私一人ではなく、何人かのメンバー※とチームとしてメンテナンスを引き継ぐ形で、IRBとRelineに関わるようになりました。
※ tompng、st0012、hasumikin、ima1zumiの4名
ここで改めて感じたのは、
- 最初の一歩は小さくてもいい
- 「勝手にちょっと手伝う」を続けていると、やがてプロジェクト側から「中に入ってほしい」と声をかけてもらえることがある
ということです。少しずつの積み重ねでコミュニティの一員になれるのだと実感しました。
メンテナーになって初めて気づいた、意外な難しさ
メンテナーになってみて、一番大変だと感じたのはPRのレビューの難しさでした。
私たちは、自分で一からつくったOSSをメンテナンスしているわけではなく、誰かがつくったものを引き継いでいる立場です。
そのため、
- コードの全体像を最初から把握しているわけではない
- 元の設計意図が完全には分からない部分もある
という前提があります。
さらに、私は仕事としてはRailsアプリケーション開発がメインで、端末やCLIプログラミングの経験は決して豊富ではありませんでした。文字コードについては専門的に掘っている一方で、ターミナルやシェルやREPLの世界は素人だったんです。
そのため、PRをレビューするときには、
- 端末やOSごとの挙動の違い
- 既存ユーザーの使い方への影響
- これから入りうるバグのパターン
など、自分の知らない前提を一つひとつ埋める必要があります。正直に言うと、今でも全部をしっかり理解できているとは言えませんし、日々勉強が必要だと感じています。
それでもプロジェクトが回っていくのは、メンテナー同士で相談しながら、「一人で全部わかっている必要はない」「それぞれの得意分野を持ち寄ればいい」というスタンスでやれているからだと思います。
Rubyコミッターになって広がった、文字コードの深い世界
今年からはRuby本体のコミッターとして、文字コードまわりを中心に活動するようになりました。IRBとRelineで書記素クラスタの問題に向き合ったところから始まり、今ではUnicodeの仕様を理解してRubyの実装に落とし込むところなど、より深いところまで関わるようになっています。
文字コードは、普段のアプリケーション開発では「うまく動いていてほしいけれど、できれば触りたくない」と思われがちな領域かもしれません。私自身も最初はそうでした。
でも、一度足を踏み入れてみると、
- 「1文字」とは何か
- 世界中の言語をどうやって同じ土俵で扱うのか
- 端末やフォント、OSとの境界でどんなことが起きているのか
といったテーマは、想像以上に奥深くて、知れば知るほど面白い世界です。
そして、その基盤がしっかりしているからこそ、アプリケーション側では「普通に文字列を扱う」だけで、国や言語を超えたプロダクトをつくることができます。
続けることで得られた3つのこと
OSSへの関わりを続ける中で、私が特に大きいと感じている学びは、次のようなものです。
1. 「仕様書を読む力」と「分からないままにしない」
Unicodeの仕様や、端末の挙動、Ruby内部の挙動など、ドキュメントやコードを追いながら「なぜこうなっているのか」を自分の頭で整理する機会が増えました。
業務だけをやっていたら、きっとここまで文字コードを追いかけることはなかったと思います。どんどん掘り下げることで自分の理解が深まり、より深く広い世界を見られるようになりました。一つの分野を深く学ぶことで得られる楽しさを実感できたのは、OSSをやっていたからだと思います。
2. コミュニティとのつながり
最初のIssueから始まり、作者との対話、Rubyコミュニティでの出会い、メンテナーチームへのお誘い。どれも自分一人では決して辿り着けなかったものです。
オンラインの勉強会にふらっと参加していなかったら、フィヨルドブートキャンプで仲間に背中を押してもらっていなかったら、たぶん今も「IRBがクラッシュする問題、誰か直してくれないかな」と思いながら眺めていただけだったかもしれません。
3. 「自分は全部わかっていなくてもいい」という感覚
メンテナーになっても、Rubyコミッターになっても、全部を理解している状態にはなりません。むしろ、見えている範囲が広がるほど、知らないことの存在がどんどん見えてきます。
それでも、
- 自分がわかるところから手を動かす
- わからないところは素直に相談する
- 「ここまでは調べました」と共有する
というスタンスで少しずつ関わっていくことで、プロジェクトに貢献することは十分可能だと実感しています。でも、わからないままだとやっぱり悔しいので、どうやって動くか知りたい、理解したいという気持ちを絶やさないようにしたいと思っています。
これからOSSに挑戦してみたいあなたへ
この記事を読んでくださっている方の中には、
- 個人開発や学習はしているけれど、OSSにはまだ手を出せていない
- 興味はあるけれど、「最初の一歩」が怖い
- 業務ではOSSを使っているけれど、開発には関わったことがない
という方が多いと思います。
そういう方に、私からお伝えしたいのは、
「小さな違和感やバグ報告から始めてもいいし、自分で全部直せなくても大丈夫」
ということです。
- 「あれ、これ変だな？」と思ったら、とりあえずIssueを書く
- 再現手順や環境情報を書くだけでも、メンテナーにとっては大きな助けになる
- もし余力があれば、「ここまでは調べました」と途中経過を共有する
それだけでも立派なOSS貢献ですし、そこから作者やメンテナーとの対話が生まれることもあります。
最初から「かっこいいPRを出さなきゃ」と思わなくて大丈夫です。私自身、最初のIssueは自力で最後まで直せませんでしたが、それでも一緒に直す相手として迎え入れてもらえました。
基盤技術に取り組む面白さとこれからの私
IRBやReline、文字コードといった基盤的な領域は、華やかな新技術に比べると、どうしても地味に見えるかもしれません。
でも、基盤が安定しているからこそ、
- 日々の開発体験が快適になる
- 世界中のユーザーが、文字の扱いを気にせずアプリケーションを使える
- 長く使われる言語やライブラリとしての信頼が保たれる
といった、大きな価値を支えることができます。
そして基盤技術のもう一つの面白さは、変化していく世界をどう支えるかという問いが常にあることです。Unicodeも、端末も、開発環境も、止まってはいません。
だからこそ、そこに携わることは、未来のRubyや開発体験を少しずつ形づくっていくことでもあります。
こうした基盤の世界に向き合う中で、私が今後取り組んでいきたいことも、少しずつ見えてきました。
これからも私は、Ruby標準ライブラリ、とくにIRBやReline、そして文字や文字コードまわりを中心に、開発者の当たり前の快適さを支えるような改善を続けていきたいと考えています。
完璧じゃなくても、OSSは始められる
私のOSSへの最初の一歩は、「家族の絵文字を入力するとIRBが落ちる」という、ささやかな違和感から始まりました。Issueを出すのも怖かったし、自力で最後まで直せたわけでもありません。
それでも、仲間に背中を押してもらい、作者に「やってみない？」と声をかけてもらい、
少しずつ関わり続けた結果として、今はメンテナーやコミッターとして活動するようになりました。
もし今、「OSSに興味はあるけれど、自分なんかが関わっていいのかな」と感じているなら、このことを思い出してもらえたら嬉しいです。
完璧な修正が用意できなくても、小さな気づきや違和感を共有するところから、OSSへの参加は始められます。
そして、その一歩が、あなたの技術の世界を大きく広げてくれるかもしれません。