こんにちは、テクノロジー本部 デジタルテクノロジー統括部のイマムラです。現在、社内の新規事業プロジェクトの中でフロントエンドエンジニアとして業務にあたっています。
今回、私たちが社内プロジェクトで利用している既存デザインシステムをfork *1 して、新規プロジェクトに導入した経緯と、その過程で得られた知見についてお話しできればと思います。
デザインシステムとは
デザインシステムの定義については、デジタル庁の資料がとてもわかりやすいので、そちらを参照ください。
定義だけ簡単に解説すると、デザインシステムとは、「あるべきデザインを一貫性を持ってユーザーに提供するための仕組み」です。 個別に構築しているウェブサイトやサービスだと、デザインがバラバラで、ユーザーは構造や機能をその都度理解し、必要な情報にたどり着くのに時間がかかります。また運営側も、開発や更新に手間のかかる状態となっています。 そこであらかじめ「アクセシビリティ」「ユーザビリティ」を担保したデザインパーツを再利用することで、一貫性のあるデザインを効率よく実現し、使いやすさの向上、開発効率の向上、改善サイクルの迅速化を図り、より大きな課題やサービスの改善に集中できるようになります。
プロジェクト内での定義
デジタル庁の定義を踏まえたうえで、私たちのプロジェクトではデザインシステムを以下の要素の集合体としました。
なぜこの定義にしたかはまた別の記事で紹介したいと思います。
- デザイン原則
- デザインガイドライン
- UIコンポーネント（デザイン・コード）
- デプロイ手段を含めた開発環境
メリット・デメリット
デザインシステム導入には一定のメリットがありつつ、デメリットも存在します。
メリットとして以下が挙げられます。
メリット
- 開発の効率化と品質の向上：共通のUIコンポーネントとガイドラインを使うことで、デザインの再利用が可能になり、開発時間の短縮と一貫性のあるユーザーエクスペリエンスを提供できます。
- デザイナーとエンジニアの共通認識が作れる：デザインシステムはデザイナーとエンジニア間のコミュニケーションを促進し、認識を揃えることができる効果があります。
一方、デメリットとして以下が挙げられます。
デメリット
- 初期のセットアップに時間がかかる：デザインシステムの構築は時間と労力が必要なため、プロジェクトの初動が遅れてしまい、プロダクトの価値を損失してしまう可能性があります。
- プロジェクトの特定のニーズに合わせたカスタマイズの難易度：一貫性を保つために柔軟性が制限され、プロジェクトごとに提供したい最適なUXの障壁になる可能性があります。
これらの点は、プロジェクトを進めていく上での障壁になる可能性があります。
なぜfork *2したか
デザインシステムが必要だったけれど…
私たちのプロジェクトでは、4つのサービスを1つのブランドとしてリリースする計画が行われていました。また、そのサービスは並列にかつ順次リリースされることも予定されていました。
この状況を踏まえると、本来であればデザインシステムが必要であり、運用を見据えて、デファクトスタンダードな技術を取り入れることが求められました。さらに、技術選定は現在のチームの技術スタックに適合させる必要もありました。
そのため、ReactとUIライブラリを用いたデザインシステムの構築が我々には必要不可欠だったのですが、当時はまだ小さいプロジェクトだったのでコストやスケジュールの点からデザインシステムの構築はとてもハードルの高い話でした。
forkという決断に至った理由
さて、前述した経緯やメリット・デメリットを踏まえて、私たちのプロジェクトではデザインシステムを導入するために既存デザインシステムをforkするという選択をしました。
主な理由は以下の通りです。
スケジュールとリソース、品質のバランスを考慮した結果
新規サービス開発プロジェクトにおいては、限られた時間とリソースの中で最大限の品質を追求する必要があります。デザインやアーキテクチャを初期段階で統一しておくことは、長期的に見て開発の効率化と品質の維持につながります。 しかし、新規プロジェクトの立ち上げフェーズでは、ゼロからデザインシステムを構築することは現実的ではありません。 そこで、既存のデザインシステムをforkすることで、効率的に品質の高いデザイン基盤を確立することが可能となりました。
社内事情をクリアしている必要があった
社内でのサービス開発には、コンプライアンスや情報セキュリティなど、特定の審査基準を満たす必要がありました。既存のデザインシステムはこれらの社内事情を既にクリアしていたため、forkすることでこれらの要件を速やかにクリアすることができました。
作業可能なリソースを増やすこと
プロジェクトにおけるメンバーの入れ替わりは避けられない問題ですが、既存デザインシステムに携わったことがあるエンジニアならば、新規プロジェクトへのオンボーディングがスムーズに行えると考えました。プロジェクトチームの属人性を軽減し、より柔軟にリソースを活用できるようにするためです。
これらの理由から、既存のデザインシステムをforkして新規プロジェクトに導入することは、スケジュール、リソース、品質のバランスを最適化し、社内事情を満たしながら効率的に開発を進める最良の選択であると判断しました。
既存デザインシステム構築者との接点
そもそもforkするという選択肢がうまれたのは、UXDIGというエンジニア＆デザイナーの架け橋となる社内のコミュニティに参加したことでした。 そのコミュニティの交流を通じて、既存デザインシステムを構築したエキスパートと接触することができたことで、既存システムの構造や利点を深く理解することにつながったり、既存デザインシステムをforkできることになりました。
UXDIGはTech × Creativeのコラボレーションを推進するエンジニア＆デザイナーの架け橋となるコミュニティです。定期的に勉強会などの活動を行っており、社内のケイパビリティ強化にも貢献しています。
UIライブラリのみではなぜダメだったのか
UIライブラリは主にUIコンポーネントを提供しますが、デザインシステムはデザイン原則、デザインガイドライン、開発環境を含め、一貫性のあるデザインを提供するための全体的なフレームワークを提供します。このため、社内の特定のニーズに合わせたカスタマイズや、社内事情を合わせた要件を満たすためには、UIライブラリだけでは不十分で、より包括的なデザインシステムの導入が必要でした。
forkしたデザインシステムを導入してみた結果
私たちのプロジェクトに導入してみた後、UXDIGにて「forkしたデザインシステムを利用してみての所感」というタイトルで振り返りを実施しました。
デザイナー再度の考え・葛藤
元々エンジニアからの提案だったため、デザイナーの方々はどう受け入れてくれたのかもこの会で聞くことができました。
デザイナーとして、既存のデザインシステムをforkすることに対して大きな葛藤はありませんでした。
主な理由は、β版開発でのタイトなスケジュールとリソースの制約の中で、デザインガイドラインを一から作り上げる余裕がなかったからです。
また、ルールがないとデザインの統一感が損なわれるため、既存のデザインシステムをベースにカスタマイズを行うことで、効率的に品質の高いデザインを実現できると考えました。
ポジティブに捉えていただいたことがわかり、とても嬉しかったのを覚えています。
導入した結果
導入してみた結果、以下のような良い点・悪い点が挙げられました。
良い点
- 圧倒的なコスパ（デザイナー）
既存のルールに沿ってデザインを行うことで、コンポーネントの考慮漏れなどを防ぐことができ、時間と労力を大幅に削減できました。 - コミュニケーションの容易さ（デザイナー）
共有のデザインシステムを使用することで、エンジニアとの認識のズレを減らすことができました。 - 開発の迅速化（エンジニア）
デザインシステムが初めから構築されていたため、フロントエンドの開発を速やかに開始できました。特に開発環境とStorybookが提供されていたのは大きかったと思います。 - デザインの一貫性と正確性の確保（エンジニア）
明確かつ網羅的なガイドラインにより、デザインの統一性と正確性を担保しながら効率的に開発を進めることができました。 - コミュニケーションコストの削減・質の向上（エンジニア）
デザインシステムを共通言語として取り入れたことで、チーム全体のコミュニケーションがスムーズになりました。具体的な例を基に話し合うことができるため、担当者間の意見が一致しやすくなり、コミュニケーションの質が向上しました。さらに、細かな違いに悩まされることが少なくなったと感じています。
悪い点
- デザインシステムの把握に時間がかかる（デザイナー・エンジニア）
デザインシステム自体が規模として大きいものなので、コンポーネントやガイドラインの把握に時間がかかりました。また、使い方のわからないコンポーネント（利用用途が限られているコンポーネント）もあり、その取捨選択に苦労しました。 - 変更点の共有に苦労した（デザイナー）
forkし私たちのプロジェクトに合うようにトンマナなどを変更すること自体が初めての試みだったため、エンジニアとの変更内容の共有の仕方を手探りで行っており、その点で苦労しました。 - バージョン移行（エンジニア）
ちょうど破壊的変更が行われたNext.js 13が出てきたタイミングだったため、その移行に苦労しました。また、Storybookのバージョンアップについてもその影響を受け、そちらのバージョンアップにも苦労しました。
まとめ
デザインシステムをforkし、新規プロジェクトに導入することは、多くのメリットをもたらしました。デザイナーとエンジニア双方が、開発の効率化、コミュニケーションの改善、品質の向上などの利点を享受することができました。
もちろん一部のデメリットもありましたが、これらを補って余りあるメリットがあったことは確かです。そして、これらの成果は既存のデザインシステムが優れていたからこそ達成できたと感じています。
今後の目標
今後は、デザインシステムの導入と活用において、さらなる改善と効率化を目指します。具体的には、以下のような目標を持っています。
- シンプルかつ疎結合なデザインシステムの構築：現在利用しているライブラリやフレームワークの変更に柔軟に対応できるよう、よりシンプルで疎結合なデザインシステムを目指します。これにより、将来的な技術の進化やプロジェクトの変更にも迅速に対応できるようになることを期待しています。
- デザインシステムの基盤構築：現在のデザインシステムはあくまで既存のものをベースにしていますが、より根本的で低いレイヤーのデザインシステムの構築を目指します。これにより、社内での共通認識をさらに深め、開発プロセスの標準化と効率化を図ることができると考えています。
- ベースになったデザインシステムへのフィードバック：また、今回forkしたデザインシステムに対してフィードバックを提供したいと考えています。導入経験から得た知識や改修内容のノウハウを共有し、苦労した部分などの改善ポイントをリストアップして、元のデザインシステムを構築したチームへ還元する予定です。
デザインシステムの導入は、開発プロセスの効率化と品質向上において重要な役割を果たします。しかし、それを実現するためには、デザインと開発の両面からの継続的な改善とアップデートが必要です。今回の経験を踏まえ、より良いデザインシステムの構築と活用を目指していきたいと思います。
forkしたデザインシステムの導入により、デザイナーとエンジニアの両方にとって有意義な成果が得られたことは明らかです。この経験は、将来のプロジェクトにおいても大いに役立つことでしょう。今後も、より良いプロダクト作りに向けて、デザインシステムの改善と活用を進めていく所存です。
この記事が、デザインシステムに興味がある方や、導入を検討している方にとって、少しでも参考になれば幸いです。
イマムラ ヨウイチ Yoichi Imamura
デジタルテクノロジー統括部 デジタルソリューション部 Webアプリエンジニアグループ シニアエンジニア
2011年からキャリアをスタートし、フロントエンドエンジニアとして様々なWebサイトの設計・実装を経験。インタラクティブエージェンシーではナショナルクライアントをはじめとした多数の案件に従事。関係者が100人を超える大規模サイトの設計や実装、システムやサーバーサイドとの連携など幅広い領域を担う。現在パーソルキャリアにて新規事業開発に携わり、フロントエンド開発、UXデザインなどを担当。
※2024年4月現在の情報です。
