はじめに

この記事はGoodpatch UI Design Advent Calendar 21日目の記事です。

僕が担当しているプロジェクトではWebアプリケーションを開発しているのですが、その開発の中で発生したコンポーネントにまつわる問題とそれを改善するための取り組みについてご紹介します。なお、この記事の中で言う"コンポーネント"はUIを構築するための"UIコンポーネント"を指すのだと思ってください。

デザインと実装の分業によるコンポーネント設計思想のズレ

開発初期はデザイナー1人とエンジニア2人の体制でデザイナーがデザインファイルを作成して、エンジニアが実装を担当していました。初期段階では、厳密にAtomic Designなどの設計手法は用いていませんでした。

その頃は人数も少なかったので、コミュニケーションも取りやすくスムーズに進められていたのですが、その後、デザイナーが3人、エンジニアも5人に増えて、サービスの規模も大きくなってくると、コミュニケーションコストが高くなり、次第にメンバー同士で思想を統一することが難しくなっていきました。

その思想のズレによってデザイナー側では１つのコンポーネントとして考えていたものが、エンジニア側では複数のコンポーネントに分けられたりして、結果的に似たようなコンポーネントが量産されてしまいました。これはメンテナンスコストを増大させ、UIの一貫性も失われるリスクがあります。

もっと効率的にコンポーネントを運用できないかと改善活動をはじめ、デザイナーとエンジニアでコンポーネントの運用方法について議論しました。議論する中でデザイナーとエンジニアでコンポーネントに対する観点が異なることが分かりました。

デザイナーとエンジニアのコンポーネントに対する観点の違い

デザイナーはそのコンポーネントをどのような目的で使うのか、どのような場所で使うのかに主な関心があることに対して、エンジニアは再利用性を高めるためにどのように階層化して、どのような情報を変更可能にしておくべきかということに関心がありました。

これはUIの利便性に責務を持つデザイナーとそれを実現することに責務を持つエンジニアの関心事の違いによるところが大きいのではないかと思います。

デザイナーとエンジニアのコンポーネントに対する観点の違いについて色々と考えているときに上野さんの以下のツイートが流れてきて、めちゃめちゃ納得してしまいました。

そもそもコンポーネントとは何だろう

そもそもコンポーネントとは何なのでしょうか。私個人としては、コンポーネントは視覚情報・属性・インタラクションを持つ再利用可能な部品のことだと解釈しています。

たとえば、パソコンのディスプレイやキーボード、マウス、電源アダプターなどはすべてコンポーネント = 再利用可能な部品です。コンポーネント化することによって、ユーザーは経験知を活かしてUIを効率的に学習することができますし、開発面においても既存コードを再利用することで開発工数を抑えることができます。

先ほどのデザイナーとエンジニアの関心事の違いとコンポーネントの要素を照らし合わせると、デザイナーは視覚情報に主な関心があり、エンジニアは属性に主な関心があるように思います。インタラクションの部分はデザイナーとエンジニアの間に落ちがちで、コードが書けるデザイナーや美的感覚を持つエンジニアなど領域超境型の人間が力を発揮する部分ではないかと思います。

長く愛されるコンポーネントのための取り組み

少し話が逸れてしまいましたが、僕たちはお互いの価値観を尊重しつつ、コンポーネントの運用方法について見直しを行いました。

デザインガイドラインの整備

まずはデザイナーの設計思想をデザインガイドラインという形で明文化しました。（というか、いつの間にかデザイナーが作ってました...！）

コンポーネントに関する内容は「5. UI Components」になります。

1. Design Principle
プロダクトのデザインを考える上で基本となる思想について
2. Structure
プロダクト内で扱う情報のモデリング、ナビゲーション、モードの扱いについて
3. Skelton
画面内におけるペイン構成と各ペインの役割等について
4. Visual Design
プロダクト内で扱う色やアイコン、タイポグラフィ、ラベリング等について
5. UI Components
プロダクトで扱うUI Componentについて

上記のデザインガイドラインについてもう少し詳しく知りたい方は以下の記事をご参照ください。

これも一種の言語化ですが、それぞれのコンポーネントに適切な名前を付けることは共通認識を持つ上でとても重要になります。

デザインガイドラインはデザイナーが交代したり、増えたりしたときに既存の設計思想を継承するためにも大切なツールになりますし、デザイナー以外の人（POやエンジニア）がデザインの意図を理解するために役立ちます。

コンポーネントカタログの整備

実装フェーズではエンジニアが主体となってデザインガイドラインを参考にしつつ、コンポーネントを実装します。その後、実際に動作する形でStorybookというコンポーネントカタログに反映します。

デザインガイドラインは主に思想的な内容でステークホルダーとのコミュニケーションツールとして使いますが、コンポーネントカタログはデザイナーとエンジニアが視覚情報・属性・インタラクションの認識を合わせるために利用します。

これらの施策によって、デザイナーの思想をエンジニアリングの設計に取り込み、今まで発生していた設計思想のズレを解消して一貫性のあるUIを効率的に提供することを目標としています。

とはいえ、ワークフローの中で必ず境界線が存在するので、その部分はコミュニケーションを取っていく必要があります。

終わりに

今回はコンポーネントの運用について僕たちが今取り組んでいることについてご紹介しました。

順調なサービスほど作り手より寿命が長くなります。これは作り手がプロジェクトを抜けた後も別の誰かが代わりに作っていくことを意味します。そのようなサービスにおいて、コンポーネントの存在はユーザーとシステムの橋渡しを行う重要な存在になります。つまり、コンポーネントを健全に保つことはサービスの未来を支えることに繋がります。

しかしながら、この取り組みは過渡期で運用を続けながら改善を回していくところなので、実績を積んだら別の機会にご紹介できればと思います。

最後になりますが、今年のアドベントカレンダーは割と頑張って以下のような記事も書いたので良ければご覧ください。