はじめまして、株式会社アバップでデザイナー・デザインシステムおよび UI エンジニアをしている山田です。
OSS の活動としては、日本発の React UI ライブラリのYamada UIとYamada Colorsを開発しました。他には、Next.js、Storybook、Chakra UI、Mantine、Refine、Lucideにコントリビューターとして関わっています。
今回は、Yamada UI の開発の経験を通して、「OSS 開発で最も学びになったこと」について書かせていただければと思います。
実は、4 回作り直している
Yamada UI は、実は最初から UI ライブラリとして開発していなかったんです。「ある」ものを作っていて、「ある」きっかけで、UI ライブラリとして転換したんです。
UI ライブラリを作るなんて最初は全く考えていませんでしたし、ライブラリを作った経験もなかったので、開発を進めるにつれて次々と壁にぶつかり、4 回も作り直すことになってしまったんです。
最初の開発
当時の山田は、MUIやChakra UIなどの 既存の UI ライブラリを日頃使っていて、「UI ライブラリって、大体こんな作りだろうな」って軽い気持ちで、Yamada UI の開発を始めました。
でも、実際に開発を進めていくと、その表面的な理解じゃ全然足りなくて、次々と技術的な壁にぶつかっちゃうんですよね（笑）
主な課題や失敗
最初に直面した課題は、いわゆる「循環参照」です。
UI ライブラリって、大体 100 個以上のコンポーネントでできてるんですよね。で、これがまた複雑で、あるコンポーネントは他のコンポーネントを組み合わせて作ってたり、あるコンポーネントをラッピングして新しい機能を追加したりしてるんです。
例えば、A、B、Cという 3 つのコンポーネントがあるとします。BはAに依存して、CはBに依存していて、依存関係に従ってAから順番に開発を進めていくんですけど、Cを作ってる時に「あ、この機能Aでも使いたいな」って思っちゃうんですよ。この時点で循環参照が起きちゃってますね。
その循環参照を解決するためにCの機能をAに移行すると、Aに依存しているBにもその機能がついてきちゃうんです、Bはその機能を使わないのに…。で、その機能が大きいものだと、Bのサイズも不必要に大きくなっちゃうんですよね。
結局、この循環参照の問題が解決できなくて、1 回目の開発は失敗に終わってしまいました。
2 回目の開発で課題となったのは、「柔軟性の無さ」です。
最初は「UI ライブラリって、大体こんな作りだろうな」って軽い気持ちで作り始めたので、プロジェクト全体のテーマやコンポーネントのスタイリングも、その場その場の感覚で作っていったんです。
でも、コンポーネントが増えていくにつれて、スタイリングの要件もどんどん複雑になっていって…。新しい機能や状態を追加したいと思った時、最初に作ったスタイルの関数では対応できなくなっちゃったんです。
無理やり条件分岐を追加して対応しようとすると、今度は他のコンポーネントのスタイルに影響が出てきて…。あれも直さないと、これも直さないと、って感じで、もう最初から作り直さないと無理だなって思ったんですよね。
結局、その場しのぎで作ったロジックは柔軟性が担保できず、2 回目の開発も失敗に終わってしまいました。
3 回目の開発で課題となったのは、「スタイルの不一致」です。
さっきも言ったように、UI ライブラリって 100 個以上のコンポーネントでできてるんですよね。で、デザインの一貫性を保つために、セマンティックトークンを使って各コンポーネントのスタイルを管理してるんです。
でも、これがまた難しいんですよ。コンポーネントによって役割もサイズも違うから、色や高さ、余白、角丸なんかを個別に調整しないといけないんです。でも、調整しすぎると今度は共通のデザインシステムから外れちゃうし…。
実際に 100 個以上のコンポーネントを並べてみると、あれ？ここズレてる？あ、こっちも…って感じで、気づいたら全部ズレてるんですよ（笑）。で、ズレを直そうとすると、依存してる他のスタイルも影響受けて、またズレる…。もう無限ループですよね。
結局、スタイルの一貫性を保つのが難しすぎて、3 回目の開発も失敗に終わってしまいました。
4 回目でやっと順調に進めた理由
あまりにも上手くいかず、株式会社アバップの代表の松本創さんに相談しました。そしたら、「山田くん、日頃 Chakra UI 使ってるよね。リポジトリとかソースコードは参考にしたの？」って言われたんです。 当時の山田は、プログラミングを始めて 1 年半で「リポジトリ？ソースコード？」って思ってしまったんです。おかしいですよね、日頃 GitHub や GitLab を使っていて、リポジトリって概念を知っているはずなのに、ライブラリにリポジトリとかソースコードって概念があるの？って。
Google で「Chakra UI GitHub」って調べてみたら、本当にリポジトリが出てきたんです。「ほんとにあったんだ」って思いましたよ（笑）。
だって、パッケージマネージャーでnpm installとかやって、node_modulesに勝手に入ってきて、ドキュメント通りにコードを書いていけば動くんですから、今までの山田はそういう概念を全く考えていなかったんです。
言われてみれば、ソースコードがあるから動いて、それを管理するリポジトリがあるのは当然なのに、その当時の山田はその視点が完全に抜け落ちていたんですよね。
ソースコードを見てみると、本当に衝撃的でしたね。今まで知らなかった機能や書き方がたくさんあって。「これは、本当に山田が知っている JavaScript なのか…」って思いましたよ。
ProxyやuseSyncExternalStoreなんて、当時は全く知らなくて、「こんな機能あったんだ！」って画面に向かって叫んでました（笑）。それに、chakra("div")って関数だと思ってたのに、chakra.divみたいな書き方もあって、白目を剥きましたよ。
今思えば、関数もオブジェクトですから、chakra("div")もchakra.divも表現できるのは当然なんですけどね。当時は本当に衝撃的でした。
理解するのに、約 2 週間かかりました。ソースコードのあちこちにconsole.logやconsole.traceを入れて、コンソールを確認しながら、ずっと動きを追いかけて…。でも、やっと理解できた時は、本当に嬉しくて、思わず画面の前で拍手しちゃいました（笑）。
そこからは一気に加速しましたね。やっぱり、何かを参考にするって大事なことなんだと実感しました。たとえば、デジモンアドベンチャーのオープニングテーマ「Butter-Fly」に「無限大な夢のあとの 何もない世の中じゃ」って歌詞がありますよね。一見ネガティブに聞こえるんですけど、捉え方を変えれば、「無限大な夢=参考になるもの」があれば、それを武器にしていろんなことが乗り越えられるんじゃないかって思うようになったんです。
もちろん、何度も失敗はしました。でも、それを無駄と捉えるんじゃなくて、参考にしながら進んでいった結果、最終的にはゴールにたどり着くことができた。そのプロセスこそが、山田にとって大きな学びでしたね。
実装や機能をどこまでやるか問題
OSS って、多くの人に使ってもらうことを想定して作るものだと思うんです。Yamada UI の場合も、リリース前に試験的に多くのプロジェクトで使ってもらって、フィードバックをいただいたんです。
そのフィードバックをもとに、使いやすさを追求して機能を追加していくのですが、ここでまた壁にぶつかっちゃうんですよね。機能を追加していくと、「この機能って本当に多くの人に必要とされるものなのかな？」って疑問が湧いてくるんです。
特定のケースだけに使われる機能だと、ライブラリのサイズを不必要に大きくしてしまう原因になるかもしれないし、使いやすさを追求したはずが、機能が多すぎて逆にドキュメントが分かりづらくなってしまうんじゃないかって…。
これって、OSS 開発でよく直面するジレンマだと思うんです。ユーザーの声に応えたい気持ちと、ライブラリの品質を保ちたい気持ちの間で、どうバランスを取るべきかって。
「やりすぎ」と「やらなさすぎ」のバランス
この「やりすぎ」と「やらなさすぎ」のバランスを取るのは、本当に難しいんですよね。機能を追加しすぎると、先ほども言ったように見づらくなってしまうし、かといって機能が全くないと使いものにならない…。
このバランス感覚を身につけるために、僕は 2 つのアプローチを取ったんです。
1 つは、「コンポーネントやフックが使用されるあらゆるケースをシミュレーションする」ことと、もう 1 つは、「既存の UI ライブラリで類似しているコンポーネントの機能を参考にする」ことです。
特に、既存のライブラリに実装されている機能は、それだけ需要があるということの裏付けになると思うんです。多くの開発者が使っているライブラリなら、その機能はきっと多くの人に必要とされているはずだって。
OSS ならではの「他の人が使う・見る」ことを意識した設計
Yamada UI を OSS として公開することになった時、最初に意識がガラッと変わったのは「自分だけが使うわけじゃない」ということでした。
個人で開発したり、社内で開発したりする時って、ある意味で「動けば OK」「自分たちが分かればいい」みたいなところがあるじゃないですか。でも OSS は全然違う。他の人が使って、他の人が読むんです。そうなると、自然と「読みやすさ」や「再利用のしやすさ」「意図の伝わる命名」「ドキュメントの丁寧さ」が求められてきます。
そして、それ以上に大事だと思ったのが「余白を残す」という考え方です。
機能を詰め込みすぎず、ユーザーが拡張しやすいようにあえて抽象度を上げておくとか、オーバーライドできるように設計するとか。「使う人の未来の選択肢を残す」というのは、OSS においてすごく大事だと感じました。
自分が書いたコードが、他の誰かのプロジェクトで使われて、改良されて、また別の誰かに使われていく。そういう連鎖を生むためにも、「他人に優しい設計」が本質的な価値を持つんだなと思っています。
OSS 開発を通じて仕事に活きていること
OSS 活動って、趣味とか学びの一環って思われがちなんですけど、実は仕事にもめちゃくちゃ影響を与えてくれるんですよね。Yamada UI の開発を通して得た経験は、日々の業務にも確実に活きています。
OSS 開発の経験が仕事にどう役立ったか
OSS 開発って、やっぱり「他人に見られる」っていう前提があるからこそ、コードの書き方、ドキュメントの残し方、命名のセンス、すべてに対してものすごく気を使うようになるんですよね。
この経験が、そのまま仕事でも活きています。特にチーム開発では、「このコード、他のメンバーが見た時にすぐ理解できるかな？」「この設計、後から変更しやすいかな？」っていう視点でコードを書けるようになりました。結果的に、レビューの指摘も減りましたし、チーム内のコミュニケーションもスムーズになったと感じています。
また、OSS でのトラブルシューティングやイシュー対応の経験を通じて、問題解決のスピードや精度も上がりました。誰かが書いたコードを読み解いてバグの原因を突き止める、みたいな経験は、社内のシステム保守やレガシーコードの改修にもすごく役立っています。
失敗や試行錯誤を経て得た「自分なりの判断基準」
何度も作り直して、何度も失敗して、その中で「この設計は後々破綻するな」とか「この書き方だと柔軟性が足りないな」といった勘所が、少しずつ身についてきました。
その中で見つけた自分なりの判断基準が、「未来の自分や他人がどう感じるかを想像すること」です。今は完璧に思える設計でも、半年後には負債になっているかもしれない。逆に、「一見手間だけど、こう書いておいた方が後々助かる」というケースもある。
コードだけじゃなくて、UI の設計でも同じです。今だけを見るんじゃなくて、将来的な変更・拡張・保守を見据えて考える。その「ちょっと先を見る力」は、OSS で何度もぶつかってきた壁から得られた、大きな財産だと思っています。
まとめ
ここまで、Yamada UI を OSS として開発してきた中で得た経験を振り返ってきましたが、改めて感じるのは、OSS って本当に「学びの宝庫」だということです。
OSS 開発は「失敗してもやり直せる」「学びが多い」場であること
Yamada UI を 4 回作り直したという話をすると、「そんなに失敗したの!?」って驚かれることもあるんですが、僕にとってはどれも必要なプロセスでした。
OSS のいいところは、「最初から完璧を目指す必要がない」ことだと思っています。公開している以上、もちろん破壊的な変更には慎重さが求められますが、それでも改善やリファクタリングの余地は常にあって、「試行錯誤しながら少しずつ良くしていける」環境が整っているんですよね。だからこそ、「まずはやってみる」「ダメなら改善する」というサイクルが、自然と身につくようになりました。その過程で得られる学びは、本当に大きいです。コードの書き方だけじゃなくて、情報設計、命名、構造化、ドキュメントの書き方、ユーザーの声の受け止め方、全部です。
そして、山田はこう思います。OSS は、「ダンジョン」だなって。
ダンジョン（リポジトリ）に挑戦（ソースコードを見る）してみるんです。最初は、入ってすぐのモンスター(コード)にボコボコにされます。で、レベルが高いなって思ったら違うダンジョンに挑戦してレベルを上げて、もう一回さっきのダンジョンに挑むんです。すると、面白いことに進めちゃうんですよ。まるで、ゲームのダンジョンを攻略しているかのような。気づいたら山田は、なにかの移動中でも GitHub のアプリで色んなソースコードを読みまくるほど熱中していました（笑）。
これから OSS に挑戦したい人へ
「OSS ってハードル高そう」と感じる人もいるかもしれません。でも、最初はほんの小さなことからで全然いいんです。Good First Issueや、自分が日頃使っているライブラリのイシューを見てみてください。
自分のコードが誰かの役に立つって、想像以上に嬉しいことなんですよ。そして、実際に誰かの反応をもらえると、「もっと良くしたい」「もっと勉強したい」って思えるようになります。
もし「自分にはまだ早いかな」と感じている人がいたら、声を大にして言いたいです。今がちょうどいいタイミングだって。
「失敗しても大丈夫。OSS は、失敗しながら成長していく場所だから。」
では、OSS というどこかのダンジョンであなたと出会えることを楽しみにしています！それでは！