こんにちは、レバレジーズの HR テック事業部でフロントエンドエンジニアをしている縄巻です。
- 「日々の実装タスクをこなすだけじゃ、なんだか物足りない…」
- 「もっとプロダクトの根幹に関わるような、インパクトの大きな仕事がしたい！」
エンジニアとして少しずつ経験を積んできた今、そんな風に感じている方はいませんか？
この記事では、実務経験 2 年未満だった私が、チームをまたがる大きな課題であったデザインシステムの導入に、オーナーシップを持って挑戦した経験をお話しします。
この記事を読めば、若手であっても自ら課題を発見し、最新技術を駆使しながら事業を前に進めていける、レバレジーズの挑戦的な文化を感じていただけるはずです。
そもそもデザインシステムとは？
本題に入る前に、少しだけ「デザインシステム」という言葉について説明させてください。
デザインシステムとは、単なる UI コンポーネントのライブラリではありません。それは、一貫したユーザー体験を効率的に提供するための「仕組み」そのものを指します。具体的には、再利用可能な UI コンポーネント、デザインの原則やガイドライン、そしてそれらを運用するためのルールやツール群を体系的にまとめたものです。
デザイナーとエンジニアが共通の言語と思想を持つことで、プロダクト全体の品質と開発速度を飛躍的に向上させることを目的としています。
課題：オーナー不在のデザインシステム
私が所属する SaaS プロダクトには、もともと「共通コンポーネント」として管理されている npm パッケージが存在しました。
しかし、専任のメンテナーはおらず、各開発者が必要に応じてコンポーネントを“継ぎ足し”していく運用が続き、体系的な管理がなされていない状態でした。
その結果、開発現場では、次のような数々の問題が起きていました。
- Figma と実装の乖離：Figma にはないのに、React コンポーネントだけが存在する。
- 命名の不統一：Figma と React でコンポーネント名が異なり、探すだけで一苦労。
- 巨大モノリスパッケージ：たった一つのコンポーネントを更新したいだけなのに、パッケージ全体への影響調査が必要になる高い更新コスト。
- ドキュメントとテストの不足：誰も正確な仕様を把握できない、ドキュメントもテストもないコンポーネントたち。
- 過剰な依存関係：特定のライブラリに依存し、他の場所で再利用できないコンポーネント。
- アクセシビリティの欠如：キーボードで操作できない、スクリーンリーダーで読み上げられないなど、アクセシビリティへの配慮不足。
これらの課題は、多くのメンバーが「問題だよね」と認識しつつも、日々のサービス開発が優先され、誰も根本的な改善に着手できずにいました。
「誰かがやる」から「自分がやる」へ
こうした状況に、私は強い危機感を覚えていました。
最初は、個人として既存コンポーネントのメンテナンスや機能追加といったコントリビュートを始めました。しかし、プロダクトが急成長する中で、一個人の部分的な改善では到底追いつかないことはすぐに明らかになりました。
そこで私は、上長との 1on1 でこの問題の大変さと、抜本的な改善の必要性について話しました。そして、「誰かがやってくれるのを待つのではなく、自分が主体となってこの状況を解決したい」と伝え、この課題のオーナーになることを志願しました。
幸いにも、同時期にジョインしたデザイナーも既存の Figma 運用に強い課題意識を持っていました。こうして、エンジニアリングとデザインの両側面からアプローチする「デザインシステム刷新プロジェクト」が、ついに本格始動しました。
そして、このプロジェクトの担当エンジニアは、私一人。もちろん不安はありましたが、それ以上に「この状況を自分の手で変えられるんだ」というワクワク感の方が大きかったのを覚えています。
実行：若手の裁量で進めた課題解決
山積する課題を解決するため、技術選定はゼロベースで、その意思決定はすべて私に一任されていました。
若手の提案だからと色眼鏡で見られることは一切なく、ロジックと熱意さえあれば挑戦させてもらえる。そんな文化が、このプロジェクトを前に進める大きな力になりました。
ここでは、導入した主要な技術や、開発を加速させた AI ツールの活用法について解説します。
1. 開発体験の向上を目指した基盤整備とコンポーネント再開発
まず、デザイナーとエンジニア間の連携をスムーズにするため、Figma コンポーネントの再設計と命名規則の統一を行い、React コンポーネントもより使いやすい形に再定義しました。これにより、デザインと実装の間の認識齟齬をなくし、コミュニケーションコストを削減しました。
幸いなことに、レバレジーズにはレバテックの「VoLT」というデザインシステムをリードしたデザイナーが在籍しており、その知見を惜しみなく共有してもらえました。
裁量を持って挑戦できるだけでなく、こういった組織の横の繋がりからノウハウを吸収できるのも、大きく成長している会社ならではの魅力だと思います。
2. 独立したパッケージとして管理
巨大な単一パッケージが引き起こしていた更新コストの問題を解決するため、モノレポ構成への移行を決定しました。
Nx なども候補に上がりましたが、私たちのチーム規模や設定の学習コストを考慮した結果、ビルドキャッシュによる高速な CI/CD とシンプルな設定が魅力のTurborepoを選択しました。また、pnpmを組み合わせることで、ディスク容量を効率的に利用しつつ、厳密な依存関係管理を実現しています。
これにより、各コンポーネントを独立したパッケージとして管理し、サービスごとに必要なコンポーネントだけを選択的に更新できる、柔軟な運用体制を構築しました。
3. Radix UI でアクセシビリティを当たり前に
コンポーネントの品質、特にアクセシビリティを担保するために、ヘッドレス UI ライブラリであるRadix UIを採用しました。
MUI や Chakra UI のようなスタイル付きのコンポーネントライブラリも検討しましたが、プロダクト独自の厳密なデザイントークンを適用する必要があったため、スタイリングの自由度が低い点は懸念でした。
Radix UI は、スタイルを持たず、WAI-ARIA に準拠した高品質な振る舞いのみを提供してくれます。
これにより、デザインの制約を受けることなく、アクセシビリティを当たり前の品質として確保することができました。
4. Storybook によるドキュメント管理
ドキュメント不足を解消し、コンポーネントの利用を促進するためにStorybookを導入しました。
コンポーネントのカタログツールは他にも存在しますが、業界のデファクトスタンダードであり、アドオンによる拡張性が非常に高い点を評価し採用しました。
特にテストとの連携は強力です。Storybook のplay関数を使って定義したインタラクションテストを、vitestがテストファイルとして実行する仕組みを導入しました。これにより、Playwright 経由で実際のブラウザを起動してコンポーネントの操作をテストできるため、より信頼性の高い品質保証体制を構築できています。
また、各コンポーネントの Props、使用例、インタラクティブなデモを Storybook 上で一元管理することで、誰もがコンポーネントの仕様を容易に理解できる仕様書として機能させています。
5. AI は、本質的な仕事に集中するための“相棒”
担当エンジニアは私一人。これらの施策を、通常のサービス開発と並行して進める上で、AI コーディングツール（Cursor, Claude Code など）の活用は、もはや“選択肢”ではなく“必需品”でした。
これは、単に流行りの技術を使いたかったからではありません。たった一人のリソースで、最速で価値を届けるための、極めて合理的な戦略でした。
コンポーネントの雛形作成、Storybook のドキュメント生成、リファクタリング、単体テストの実装……。もしこれら全てを手作業でやっていたら、半年で今の状態に到達することは不可能だったでしょう。
定型的な作業を AI という“相棒”に任せることで、私はより本質的なコンポーネントの設計や、デザイナーとのコミュニケーションに集中できました。
成果：個人の挑戦がもたらしたチームへの好影響
デザインシステムの構築から約半年、その効果を測定するために、利用しているエンジニアを対象としたアンケートを実施しました。
開発体験の向上を裏付けるデータ
アンケートでは、デザインシステムの貢献度について 5 段階評価で回答してもらいました。
- UI 実装速度の向上：4.05 点
- UI の一貫性担保：4.27 点
- 総合的な貢献度：4.27 点
特に、UI の一貫性担保や総合的な貢献度で高い評価を得られたことは、このプロジェクトの目的を達成できた証だと感じています。
さらに、これらの改善活動により、フロントエンド全体の UI 実装速度が 30% 向上したこともデータで確認できました。
開発現場からのリアルな声
定性的なフィードバックとして、開発者からは以下のような嬉しいコメントが寄せられています。
「Figma のコンポーネント名と実装名が一致しているので、迷わず実装できるようになった」
「Storybook を見れば使い方が一目でわかるので、コミュニケーションコストが大幅に削減された」
「これまで各サービスで独自実装していた UI が共通化され、無駄な実装がなくなった」
エンジニア歴 2 年目の私の活動が、実際に事業やチームの開発体験にこれだけポジティブな影響を与えられたという事実は、私にとって大きな自信になりました。
今後の展望：AI で開発生産性をさらに高める
デザインシステムは作って終わりではありません。むしろ、ここからが本当のスタート。このデザインシステムを、事業の成長をさらに加速させる強力な武器へと育てていくために、短期・長期でこんな野望を抱いています。
短期的な目標：コンポーネントの拡充と適用範囲の拡大
まずは、デザインシステムがカバーする UI パターンを増やし、より多くの開発シーンでその価値を発揮できるようにすることに注力します。
- コンポーネントの拡充：現在の基盤に加え、より複雑で多くのサービスで必要とされるコンポーネントを拡充していきます。デザイナーと協力して汎用的な仕様を定義し、開発を進めることで、各サービスでの車輪の再発明をなくします。
- 適用範囲の拡大：構築したデザインシステムを、プロダクト内のさらに多くのサービスに展開していきます。そのために、既存 UI からの移行ガイドを整備したり、導入を検討しているチーム向けの勉強会を開催したりと、導入をスムーズにする活動に力を入れていきたいです。
これらの活動を通じて、デザインシステムをプロダクト開発に不可欠な存在へと成長させていきます。
長期的な夢：AI とデザインシステムを融合させ、仮説検証の速度を極限まで高める
そして長期的には、AI の力を最大限に活用し、「デザインと実装の境界線を溶かす」ことに挑戦したいと考えています。
皆さんも、Figma のデザインを実装に落とし込む際の、ちょっとしたズレや手戻りに悩まされた経験はありませんか？私たちは、その根本的な課題を解決したいのです。
目指すのは、例えばこんな世界です。
- デザイナーが Figma でワイヤーフレームを描き、「ここのボタンは、ユーザー登録を促すためのものです」といった意図を AI に伝える
- AI がその意図を解釈し、デザインシステムに定義されたコンポーネントの中から最適なものを提案。さらに、A/B テストのための複数のデザインパターンを自動で生成してくれる
- プロダクトマネージャーやデザイナーは、生成された実際に動くプロトタイプを使って、エンジニアが一行もコードを書く前にユーザーテストを実施する
この仕組みが実現すれば、アイデアの仮説検証サイクルは、数週間から数時間へと劇的に短縮されるでしょう。エンジニアは「Figma を再現する」作業から解放され、より複雑なロジックの実装やアーキテクチャ設計といった、本質的な課題解決に集中できます。
「自ら課題を見つけ、最新技術を駆使して事業を前に進めていける」—そんなレバレジーズの文化を体現するような、未来の開発生産性を創り出すのが、私の野望です。
まとめ：私がレバレジーズで働く理由
ここまで、エンジニア歴 2 年目の私がデザインシステムという大きな課題に挑戦できた話をしてきました。
なぜ、このような挑戦ができたのか。それは、レバレジーズに根付く「オーナーシップを尊重する文化」と「挑戦を推奨する風土」があったからだと思います。
大きな課題に対して、たとえ担当者が一人であっても、「やりたいです！」と手を挙げれば、年次に関係なく「まず、やってみなよ」と背中を押してくれる。たとえ実力不足な面があっても、周りの先輩たちがサポートしてくれます。そして、その挑戦を「いいね！」と称賛してくれる仲間がいます。
また、Cursor や Claude Code といった最新の AI ツールをいち早く全社に導入するなど、世の中の新しい流れを柔軟に取り入れ、開発体験や品質について妥協せず考え抜く文化も、私にとって大きな魅力です。「現状維持」ではなく、常により良いプロダクト、より良い組織を目指して本気で議論できる環境が、ここにはあると思います。
もし、この記事を読んでいるあなたが、
- 「言われたものを作るだけじゃ物足りない」
- 「もっと主体的に、事業にインパクトを与えるような開発がしたい」
- 「自分の仕事に責任と誇りを持ち、最高のプロダクトを追求したい」
そう感じているなら、レバレジーズは最高の環境かもしれません。
私たちと一緒に、未来の開発生産性を創りませんか？
最後までお読みいただき、ありがとうございました！
We are hiring!
この記事を読んで「レバレジーズ、面白そうだな」「自分もこんな環境で挑戦してみたい」と感じていただけたなら、ぜひ一度カジュアルにお話ししてみませんか？
私たちは、この記事で紹介したような課題に、オーナーシップを持って共に挑戦してくれる仲間を募集しています。
あなたからのご応募を、心からお待ちしています。
■会社説明資料
■採用情報はこちら（HRMOS）
■まずはカジュアル面談から
■開発部の雰囲気がもっとわかる動画はこちら！
コメント