yuheijotaki.com

コンポーネント設計との上手な付き合い方

コンポーネントの基本 — Vue.js より

これはなにか

Webアプリケーション開発において、コンポーネント指向で開発を行うことがあります。

「コンポーネント指向で開発」とは、例えばこのインターフェース上のパーツ要素（=コンポーネント）は汎用的に使用するため

  • どういう名称で
  • どういう粒度で
  • どういうバリエーションを用意して

他のページでも使いまわせるようにしましょう、といった具合で設計する工程を指します。

DocBaseのButtonコンポーネントの例。Figma + Atomic Design でUIコンポーネント集を作りました – KRAY Inc. より

これまで何度かコンポーネント設計の工程を挟むプロジェクトにマークアップエンジニアとして携わってきましたが、反省点も多く、未だに正解も見えない部分もあるのが実情です。

記事のタイトルでは偉そうに書いていますが、今回はデザイナーやエンジニアを含んだチームがコンポーネント設計をどのように行えば良さそうかを考えたいと思います。

※ ビジュアルデザイン、ディレクトリ構成、コードの実例等は本記事に含まれません。
※ 主にデザイン（情報設計、UI作成、マークアップ）から見た視点での内容です。
※ 基本的にはWebサイトではなくWebアプリケーション開発を想定しています。

コンポーネント設計のメリットと失敗例

メリット

まずはコンポーネント設計を適切に行えると、どのような利点があるのでしょうか。

  1. 画面のUIデザインが統一できる
  2. 責務毎に分割したコードを作れる

1.はデザイン職種、2.はエンジニア職種が感じることが多い利点になるかと思います。
後ほど触れますが、これは同時に職種によって気にする視点が異なるということも言えそうです。

これらの利点によって、ユーザーや開発組織にとってはどのようなメリットが生まれるのかを考えます。
より分かりやすくするため抽象的な表現になりますが、

  • 一貫性
  • 再利用性
  • 拡張性
  • 保守性

を高めることができるというのが私の現時点での所感です。

※ 話が広がるため深堀りしませんが、この議題で私の考えにしっくりくる記事は デザインシステムの目的を考える｜seya｜note になります。

ありがちな失敗例

逆にそんなコンポーネント設計の難しさを理解するために、ありがちな失敗例について見ていきます。

「コンポーネント設計 失敗」などでググると、下記の記事などが出てきました。

どの記事もAtomic Designというメジャーな設計思想（フレームワーク）を使用した際の失敗体験になっています。
これはAtomic Designを使用すること自体が難易度が高いという点もあると思いますが、共通して書かれている設計の難しさとしては下記にまとめることができそうでした。

  • 人によってルールや粒度がバラバラになりがち
    • だんだんとこんなに細かく分割する必要あるの？という疑問が生まれてくる
  • 運用が辛くなりがち
    • エンジニアの意見を取り入れられていない場合など
      • ひとつのコンポーネントや状態追加の作業がこんなに大変になってしまった、など
  • 最終的にコンポーネント設計を何のためにやっているのか分からなくなりがち
    • 誰が幸せになるためにやり始めたんだっけ、など

これらは私も過去に感じたことがあった内容ですね。
以降ではこの問題をより解決に導くために、どのように取り組むべきかを考えていきます。

私の考え

コンポーネント設計は、こうして取り組んだほうが良さそうという現時点での私の意見は次の3点です。

  • 関わる人全員で、粒度・分割の方法の認識を合わせておく
  • どのような設計思想にも独自ルールは発生するものと考える
  • デザイン観点よりも開発観点での正解を優先する

関わる人全員で、粒度・分割の方法の認識を合わせておく

コンポーネントの分割について最も難しさを感じるのは、人によって解釈の違いが多いことだと思います。

この齟齬を埋めるにはデザイナーとエンジニアの共同作業が必要で、どちらかが関わるだけだと難しい印象です。
ただ、アウトプットの最初の出処がワイヤーフレームやビジュアルの場合が多いため、コンポーネント設計の話題についてデザインが主導になることが多くなるのは必然だと思います。

また、なるべく初期の段階でエンジニアも含めたコンポーネント設計についてのディスカッションをできると良さそうです。後述しますが、最終的に開発側の観点を採用したほうがメリットが多いため、後戻りをできる限りしないで済むようにするためです。
情報設計やワイヤーフレームを引いた後の段階で、コンポーネントの粒度をどうするか、の話し合いが始まるケースがありますが、できる限りその前の工程の段階で、どのような分割方針で行うのかを皆でディスカッションできると、エンジニア側が設計思想の理解やディレクトリの想定等もしやすいのではないかと思います。

※ 【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog の「設計はデザイナーと協業で行う」項と同じ意見。

どのような設計思想にも独自ルールは発生するものと考える

いざコンポーネント指向で作っていきます、という段階で、

  • 完全にオリジナルのルールを作るのか
  • 何かしらの設計思想やフレームワークに沿って作るのか

大きく分けて2パターンになるかと思います。
この判断は、そのプロジェクトの内容や使用するフロントエンドのフレームワーク、メンバーの経験などによって決めることが多いでしょう。

「何かしらの設計思想やフレームワークに沿って作る」場合、Atomic Designは最も聞き馴染みのあるコンポーネントの設計思想と思いますが、先ほども紹介したとおり、上手く出来ずに断念した、ということもチラホラみかけます。

理由はそれぞれのプロジェクト内容に起因すると思いますが、Atomic Designという設計思想を使うという決定以外にも、本来は考慮したり決めたりする事が多いから、というのが多い印象です。

例えば、下記などが「本来は考慮したり決めたりする事」にあたるかと思います。

  • Atoms と Molecules の境界はどこか
  • 画面に出てくるすべてのパーツをコンポーネントとするか
  • コンポーネントの各状態の種類はどれだけ必要か
  • StoryBookなどでカタログ化をするのか
  • 開発側の観点で不都合がないか
    • ディレクトリ構成をどうするのか
    • データ・状態の持ち方
    • Propsの流れ
    • テストのしやすさ

要は、Atomic Designを使っているから上手く開発が進められる保証はありません。
デザイン観点では破綻せずになんとか使えても、特に開発観点を考慮するとプロジェクト内での独自でルール決めが必要なことが多い印象です。
この「プロジェクト内での独自でルール決め」がそもそも発生しない想定で時間を取っていなかったり、チームのコミュニケーションが取りづらい状況で発生してしまうと段々と混沌として来てしまうなということを経験した記憶があります。

デザイン観点よりも開発観点での正解を優先する

デザイン側は、見た目的にコンポーネントをどのくらいの粒度や分割で、という意見を持ちがちですが、開発側の苦労（工数）を気にせず言っていることも多く、基本的には開発の意見を優先するほうが良いと思います。

特に先ほど「本来は考慮したり決めたりする事」の中の

  • 開発側の観点で不都合がないか
    • ディレクトリ構成をどうするのか
    • データ・状態の持ち方
    • Propsの流れ
    • テストのしやすさ

など、なかなかデザイン観点だけでは考慮できないことが多いです。

※ デザイナーとエンジニアで考えるReactコンポーネント設計 - KitchHike Tech Blog の「"デザインとしての構造性" と "コードとしての再利用性"」項と同じ意見。

また、分割の粒度を小さくしすぎないことも重要と感じます。
コンポーネントを追加する際のコーディング時の作業として、下記などが挙げられますが、

  • コンポーネント生成
  • HTMLとCSS書く
  • 型を追加
  • 親にコンポーネントを追加（値の受け渡し）
  • 単体テストの追加
  • StoryBookの追加

粒度が小さいとどうしてもバケツリレー的な処理が増えてきてしまうため、見通しやすさとのバランス次第で気持ち大きめを最小粒度とすることもアリかと思います。

さいごに

この記事を書くにあたり、他のブログ等も読みながら過去の経験を思い返しましたが、プロジェクトごとにも正解は異なると思うので難しい話題だなと感じました。

なかなか端切れの悪い記事にはなってしまいましたが、現状での考えはまとめることができて良かったと思います。
これからは特にデザインとエンジニアの境界の人がどのように立ち振る舞うべきか等、継続して考察していき以降のプロジェクトでも活かせればと感じました。

参考・関連リンク