株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。
2018年6月6日には「堅牢で使いやすいUIを効率良く設計するためにAtomic Designを知る」を開催。「UI設計」という言葉はよく耳にする、目にもする。しかし、何から学べばいいのか、という人も多いはず。「UIを化学の原子に見立てて設計する」という「Atomic Design」を、実装レベルで国内において初めて導入した五藤佑典さんを講師にお迎えし、近年増えているアジャイル開発にも適した堅牢で使いやすいUI設計について、今、開発者が知っておくべきことをレクチャーしていただきました。
■今回のイベントのポイント
・アジャイルな開発現場とデザイン
・UI 開発の現場における問題
・UI構造のデザイン
・UIのコンポーネント化
・Atomic Design 方法論、実践論
・現場におけるポイント
株式会社サイバーエージェント所属のエンジニア。米国カリフォルニア州立大学サンバナディーノ校でグラフィックデザインを学んだ後、大手IT会社にてマーケティングとデザイン業務に従事。現職でエンジニアに転向。「AbemaTV」にてUI設計に携わり、実装レベルで国内において初めてAtomic Designを導入した。技術領域を動画へと広げて、「AbemaTV」の動画技術戦略に携わり、国内外で動画事業における技術研究を行っている。著書に『Atomic Design～堅牢で使いやすいUIを効率良く設計する』（技術評論社）がある。
▼今回の投影スライドは、こちらから確認できます
https://www.slideshare.net/ygoto3q/atomic-design-for-agile-ui-development-100961721
アジャイルな開発環境
参加者の中で、アジャイル型の開発に参画しているという方は少なめでしたが、五藤さんが勤務しているサイバーエージェントでは、社内の携わったすべてのプロジェクトがアジャイル型で開発されているそうです。
「アジャイル型の開発は、おおまかな計画と仕様で、イテレーションごとに機能リリースを繰り返していくため、開発途中に仕様変更や設計変更があることが前提となります」（五藤さん）
そうしたアジャイルな開発におけるデザインをどうしていくかは、開発チームにとって大きな課題だったと言います。なぜなら、UI変更を繰り返し適用することで、せっかくのデザインが壊れてしまうことがあるからです。そこで、アジャイル開発に適した、強い構造のUIデザインが必要になります。それが今回のテーマでもある「Atomic Design」です。
「Atomic Design」では、UIのパーツを、次の5階層に分けます。
・Pages（ページ）
・Templates（テンプレート）
・Organisms（有機体）
・Molecules（分子）
・Atoms（原子）
「これにより、たとえばOrganismsに属するパーツに変更が入っても、そのパーツを利用しているTemplatesやPagesといった上位層のパーツにしか変更が発生しません。したがって、変更の影響が及ぶ範囲を制限できます。このように、階層構造にすることで変更に強いデザインが生まれます」（五藤さん）
構造のデザイン
UI開発のワークフローは、一般的に、ディレクターがワイヤーフレームを作り、デザイナーに伝え、デザイナーはデザインカンプを作ってエンジニアに伝えます。
こうしたデザインカンプ・ファーストのワークフローでは、たとえば「端末によっては描画が異なる」とか「ここはなぜ赤なの？」とか「この微妙なラインの太さの重要性は？」など、デザインカンプだけでは伝えきれないデザインの要素や意図があります。
「これらのデザインの要素や意図は、デザイナーの頭の中にしか無く、エンジニアはこれを想像で補うことも多く、また、後に引き継いだデザイナーも想像で、補います。これを繰り返すうちに、少しずつズレが生じ、どんどん負債として溜まっていきます」（五藤さん）
これを抑止するツールとして、スタイルガイド、コンポーネントリスト、パターンライブラリ、デザインフレームワーク、デザインシステムなどが知られています。Atomic Designもデザインフレームワークの一つと考えることができるそうです。
デザインカンプ・ファーストでUIを構造化する場合は、行動プロセスを基準に考えることをお勧めします。
Atomic Designのような階層化アーキテクチャを使ってUIを構造化する場合は、行動プロセスを「デザインにおける関心の層」で階層化すると良いでしょう。
関心の層で階層化することで、問題を同じ層の中で解決するという基本原則が成り立ちます。同一層の関心事なら、別のコンポーネントに差し替えることで解決が図れるというのが階層化アーキテクチャの考え方です。
Atomic Designでは、UIのコンポーネント化を図り、各階層内で差し替え可能になるようにデザインしていきます。
Atomic Designの方法論
では、Atomic Designのコンポーネントとは、具体的にどのようなものでしょうか。五藤さんは、最小要素から順に、紹介してくれました。
Atomic Design実践論
さらに、あるインターネットTVのWebサイトを例にデザインされた実際のページで具体的な実装についても紹介してくれました。
通知の中の要素を順に切り出していきます。画像はAtomsで、番組系の表示もAtomsですが、バルーンチップやゴミ箱のように、さらに細かく分解できる削除ボタンはMoleculesとして切り出します。
切り出した削除ボタンを例にとると、まず構成要素であるAtoms: Balloonを実装します。例えばReactを使って簡単なサンプルコードを書くと次のようになります。
同様に<TrashCanIcon/>と記述することでゴミ箱アイコンを表示するコンポーネントもAtoms: TrashCanIconとして実装します。そして、これらのAtomsを組み合わせてMolecules: DeleteButtonを実装します。
そして、DeleteButtonや、画像、番組系など他のAtomsを組み合わせて、通知領域をOrganisms: Notificationとして実装します。
こうして階層別にコンポーネントを作っていき、最終的にPagesを作り上げていくのだそうです。
現場におけるポイント
最後に、現場でAtomic Designを導入する際のポイントや、メリットについても紹介してくれました。
「コンポーネント・ベースでUIを開発すれば、レビューコストを下げることができます」（五藤さん）
Atomic Designでは、UIコンポーネントごとにレビューできるため、スコープも限定されます。また、文言レビューやデザインレビューにおいて、ディレクターやデザイナーがコードを直接修正する場合も、GitやGitHubのようなソースコード管理ツールの決まった使い方を少し覚えるだけで可能になり「全体の構造を知らないから怖くてできない」という課題を解決できます。しかもこのとき、修正者がデザイナーならば、デザインレビュー・コストはゼロで済むといいます。
五藤さんは「既存のワークフローを活かすのであれば、デザインカンプを情報デザインと認識すると良い」とアドバイス。そして、カンプからこぼれた要素を、デザイナーとエンジニアが一緒に時間を取り、拾っていけば良いそうです。
また、Atomic Designにより、テストコストを下げる働きもあるとのこと。たとえば、退会手続きのUIを変更した場合に、テスト用のユーザーを作り、退会の手続きをとるテストを行いますが、Atomic Designならば、アプリケーションと切り離されているので、パターン再現が容易であり、コンポーネント単位でテストできます。
今回のイベントで、UIデザインの方法論も、開発スタイルに合わせて進化していることがわかりました。まだまだ、Atomic Designが導入されている現場は限られていると思いますが、その考え方はとても合理的で、普段のデザインにも応用できそうです。
