エンジニアがデザインシステムの構築に向けて、UX改善と両立して取り組んだ話

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の9週目の記事です！
1年間連続達成まで残り44週となりました！

はじめに

こんにちは、株式会社ログラスでエンジニアの浅井（@mixplace）です。開発チームのいちメンバーとして、チームの開発生産性改善を行う傍ら、デザインシステムの構築に携わっています。

ログラスもプロダクトローンチをして 3 年が経ちました。日々新しい機能の追加や改修が入っていく中で、開発チームも増え、チーム内でアウトカムを出していくことが増えてまいりました。

機能が増え画面数も増えてくると、比例するように「UX負債」や「共通UIコンポーネントの技術的負債」も目に付くことが増えてくるようになります。

このような課題について、プロダクト全体の品質や一貫性担保する観点で「デザインシステム」を構築して運用していくことが多いのではないでしょうか。

本記事では「プロダクトが大きくなっていく中で、エンジニアがデザインシステムに向き合う」という視点で、直近 1 年間で取り組んできたことについて紹介していきます。

本記事がデザインシステムの構築を担っているエンジニアやプロジェクトオーナーの一助になれば幸いです。

なぜ取り組もうと思ったのか

一言で言いますと、機能と画面が増え、画面内のUIも複雑化していくにつれ、以下のような課題感が上がってきたためです。

• Figmaのデザインデータとフロントエンドの実装が一致しておらず、意図した表現ができないケースがある。例えば:
  • Figma上のVariableとUIコンポーネント側の改修が追いついていない
  • エンジニア視点では、Figma上の「Text Styles」とCSS上で定義されている「デザイントークン（変数）」が一致していないため、読み替えるコストが発生する
• ユーザー体験を向上させる改善活動が機能開発より劣後しがち
• 画面によってスタイルとインタラクションに一貫性がない
  • 具体的には、hoverやfocus時におけるスタイルが「ボタン」と「チェックボックス」で異なる

もともとログラスのフロントエンド環境は最適な粒度でコンポーネント分けされており、ある種「コンポーネントライブラリ」といえる状態で構築されてきました。

こうした取り組みは、まだプロダクトの規模が小さい状態から取り組む方が、長期的に見ると高い効果を発揮します。今後も機能拡充やチームの増加が見込まれるため、取り組むこととしました。

純粋にこの領域に取り組めるエンジニアがいなかったのと、デザイナーと連携して創り上げて行きたかったという思いで、まずは取り組みを始めました。

デザインシステムの構築を進めるにあたり取り組んだこと

EMと取り組む範囲とリソース量を合意する

前提として、スタートアップのSaaSプロダクトにおいて、足りていない機能、拡充したい機能が目白押しの中において、リソース確保は正当な理由が必要です。

まずはエンジニアリングマネージャー（EM）の皆さんと合意をし、まずは私とフロントエンドに強い業務委託のエンジニア。計2名で、開発可能な全リソースの3分の1を上限として取り組むこととしました。

リソースは有限なので、リソース量の配分について認識を合わせるのはとても重要です。大局的に見ると今後の開発戦略や事業戦略にも影響してくるからです。

リソース量も週ごとに緩急をつける

この33％も毎週33％の時間を均等に割り当てるのではなく、

• プロジェクトのキックオフ、課題の共有、洗い出し、バックログ化など、取り組むべき重要となる最初の2週間: 67％
• プロダクトの機能開発が佳境にあたる2週間: 0〜10%

といった形で緩急をつけて進めました。

ログラスには LTV First というバリューがあり、目先の利益を追うのではなく中長期視点で利益が最大化するアプローチを採る価値観があります。デザインシステムを構築し育てていくことも、中長期的価値に寄与するところにも資すると考えています。

ユーザーの体験を大きく向上させる改修を四半期に一度入れる

デザインシステムの投資対効果については測りにくいとも言われています。長期的に見ると品質や効率の面から「あって良かった」と言えるものになりますが、短期的には非常に効果がわかりにくいものです。

そこで採ったアプローチは、デザイナーとも連携した上で、「ただデザインシステムを構築するだけでなく、構築した成果物からUX改善に寄与していくこと」でした。

作り上げたコンポーネントを実画面にまで適用し、ユーザー体験を良くするところまで進めていくということです。

顧客の皆さまからのご要望でUX改善に寄与するものも、あるべきものについて精査したうえで取り込むことにしました。

以下のようなものが挙げられます。

課題感	解決策
一覧画面で一部の列において、文字列が長くて「 … 」で丸め込まれてしまうため、最適な列幅を見直してほしい	テーブルの列幅ドラッグ機構の提供し、必要となっていた各一覧画面にまで提供
サイドバーの構造がわかりづらく、目的の画面に辿りづらい	ナビゲーション サイドバーの刷新。ユーザーに慣れていただくため、新旧デザインを併存させ、徐々に移行していただく

他の開発チームに入り込む

ユーザー体験向上に寄与する共通のUIコンポーネントが出来たとしても、コンポーネントが出来ただけではユーザーに使われることはありません。

実画面適用に際しては、他フィーチャーチームが管轄する部分へ導入するところもまで推進を行うこととしました。

特に大きくユーザビリティに影響を及ぼす箇所については、この行動が重要となります。

• 他フィーチャーチームのスプリントレビューに入り込んでレビューを受ける
• カスタマーサクセスの皆さんと一緒にユーザーへのご案内方法について一緒に取り組む（リリースノートやドキュメントの更新など）

こうして他チーム、他職種の皆さんと一緒に取り組んでいくことが、デザインシステムへの認知向上・理解を深めるためにも重要と考えています。

他チームのエンジニアも「UXの向上や開発者体験が良くなる取り組みをしてくれている」と協力的に受け止めてくれています。

小さくできる粒度でチケット化する

先述したようにデザインシステムの実装を手がけているメンバーは、私を含めて開発チームの中に所属しているため、リソース量には限りがあります。

デザイナーの皆さんとやりたいこと、改善したいことを棚卸しした結果、特定UIコンポーネントのhover状態の反映や、一部スタイル実装漏れの修正などもたくさん挙がりました。

全体を俯瞰して見ることが重要ですが、部分的なスタイル修正であればテストを含めても30分程度。このボリューム感を目安に、価値が体験できる最小単位でチケットを作成・分割していく戦略を採りました。

チケットの作成時においてはやや負荷は高まるものの、プルリクエストも小さくなってレビューもしやすく、開発からデリバリーまでのリードタイムが早くなる効果もありました。

Good First Issue

また、バックログ上で Good First Issue というタグを付けて、他チームのフロントエンド開発が得意なメンバーも、日々の業務の傍らでできるチケットをストックしておくことにしました。

こうしておくことで、

• 気分転換でチケットに取り組める
• 入社直後のエンジニアもバリューを発揮することができる
• 業務委託のエンジニアでリソースが空いた時に依頼できる

限られたリソースでも、生産性とモチベーションを上げられることができました。

おわりに

デザインシステムは育てていくものであり、サービスや価値観を持っている限り続くものと考えています。
構築にはエネルギーも伴いますし、継続性を持って取り組んでいくことが重要になります。

プロダクトも改修や拡大を経て大きくなっていく中で、内部をどれだけヘルシーにかつ保ちながら、ユーザー体験も開発者体験も良くしていく———。

一般的には、フロントエンドないしはデザインシステムチームという独立したチームを組成して共通基盤を担うことが多いかと思います。プロダクトと組織が拡大していく中で、デザインシステムの運用の仕方も変化していくべきと考えています。

最適なチーム組成、体制についてまだまだ模索している道半ばではあります。また来年にも同じテーマで筆を執りたく思います。

ログラスでは採用も募集しています。ぜひご興味持ってもらえたらお話しできると嬉しいです。
https://job.loglass.jp/