DMMグループの一番深くておもしろいトコロ。
テクノロジー

「Atomic Design」と「Design Systems」〜デザイナーとエンジニアが二人三脚で開発する手法〜

DMMグループの一番深くておもしろいトコロ。

こんにちは! デザイン本部でUIデザインをやってるタクミンです。

デザイナーやエンジニアのための勉強会がたくさん開催されているDMMですが、本日の記事では「Atomic Design勉強会」についてレポートします。

参照:http://bradfrost.com/blog/post/atomic-web-design/

「Atomic Design」と「Design Systems」を知ろう

そもそも、「Atomic Design」とはサイトやインターフェースに含まれる要素を5つの段階で定義したデザイン手法。

5段階の要素を組み合わせることでサイトやアプリをUI構成することができるフレームワークで、これらの概念を包括的に「Design Systems」と定義付けています。

「Atomic Design」と「Design Systems」がもたらす具体的なメリットは主に3つ。

  1. 「Atomic Design」でUI設計が飛躍的に効率化することができる。
  2. 「Design system」をサービス開発に取り入れ、信頼性とクオリティの高いUIが提供できる!
  3. 「Atomic Design」と「Design Systems」の導入により、デザイナーやエンジニアなどプロジェクトメンバー間のコミュニケーションが円滑になり、適切なフローで開発できる!

というわけで、この手法と概念をDMMのプロダクト開発にも浸透させるべく企画されたのが、今回の勉強会です。

勉強会プログラム

勉強会の構成は以下のとおり。

【 Atomic Designとは。Design Systemsとは何か。】
吉竹遼(STANDARD inc.

【フロントエンド実装から見たAtomic Design開発のポイント】
石橋啓太(DMM.com ラボ デザイン本部フロントエンド開発部)

【Atomic Design with Canary】
藤森正貴/丸山祐里恵/中川陽介(DMM.com ラボ デザイン本部事業開発部)

発起人・司会進行・・・岩井ゆう紀(DMM.comラボ デザイン本部)

「Sketch入門&実践ガイド」で有名な吉竹遼さんによるコンセプトの概要の説明のほか、DMMのサービス開発での実例を交えた登壇もあり、充実したプログラムになりました。

「ゴールはプロダクトを作ること」

トップバッターは、ゲストとしてお招きした吉竹遼さん。今回の勉強会のテーマそのものである「Atomic Design」、「Design Systems」について、それぞれの捉え方や視点を語っていただきました。

「Atomic Design & Design Systems」をお話させて頂きました | よりデザイン

吉竹さん的「Atomic Design」解説

  • Atoms
    これ以上分解できない一番小さい要素(テキストや色、挙動など)
     
  • Molecules
    Atomsが複数集まっていて、一つの動作を実行できる要素(テキストボックスにボタンを組み合わせた入力フォームなど)
     
  • Organisms
    コンポーネントと呼ばれる再利用率の高い要素
     
  • Templates
    ワイヤーフレームに近い、ページを構成するための要素(画像などのコンテンツはまだ入らない)
     
  • Pages
    「Templates」にコンテンツが入った、ページそのものを指す要素
質問者の写真 吉竹さん

「Atomic Design」を構成する5つの要素は、「ページをデザインするのではなくコンポーネントシステムを設計する」という「Atomic Design」の大前提の考え方を巧妙に表現していています。ただ、いきなり導入するのはなかなか難しいですし、サービスのステークホルダーやともにサービスを作り上げるメンバーへの説明と説得が必要です。一つのサイトやアプリの中で共通のコンポーネントを使いまわすゆえの開発の効率化、同じコンポーネントに触れることでユーザー自身がUIに慣れやすくなるユーザーメリット、組織内の共通認識の醸成。これらは、導入の有力な説得材料になると思います。

質問者の写真 吉竹さん

「Design Systems」を一言で表現するのは難しく、世の中的にも抽象的な意見と具体的な意見に分かれています。コンポーネントを組み合わせるそのパターンや仕組みだけでなく、開発におけるプロセスや開発する人々そのものが「Design Systems」なんだと思っています。その根底には、「デザインシステムはプロジェクトではなく、サービスを提供するためのプロダクトである」(Nathan Curtis氏)という考え方があって、スタイルガイド、コンポーネントライブラリ、デザインシステム、それらはすべて最終的にはプロダクトに落とし込まれるものなんですよね。「Design Systems」自体が目的ではなく、「Design Systems」を介したプロダクト作りがゴールであることは、デザイナー、エンジニアともに共通の認識ですよね。

フロントエンドエンジニアが語る!Atomic Design開発のポイント

続いては、DMMからの登壇が2件。

一つ目はデザイナーからフロントエンドエンジニアに転身した石橋さんが考える、「Atomic Design開発のポイント」。

質問者の写真 石橋さん

デザイナーがステークホルダーになって独立して開発するのではなく、エンジニアとコミュニケーションを取りながら適材適所で作業を分担して、互いにとって建設的なルールを構築することが大事
マイナスをゼロにするコミュニケーションではなく、プロダクトの品質を上げるためには、10や100にするコミュニケーションが重要。そのような視点でAtomic Designを取り入れる必要がある

メンバー間のコミュニケーションに加え、修正しながらの開発を繰り返す変更に強い実装手法(いわゆるアジャイル的なアプローチ)の重要性が説かれていたことも印象的でした。

チームで実現!Atomic Design導入事例

DMMの事例を交えたもう一つの登壇は、DMMオンラインサロンのオウンドメディア「Canary」の開発がテーマ。canary開発チーム3名のデザイナーによる、実践に基づく実務的な観点からのTIPの共有でした。

質問者の写真 藤森さん

再利用性を意識し過ぎるとカラーやフォントサイズなどデザインの表現力を奪う淡白なデザインになりがちなので注意が必要。

質問者の写真 丸山さん

毎日、認識のすり合わせを行い、進捗とデザインの調整を行った。

質問者の写真 中川さん

各コンポーネント粒度の感覚は人によって違うので、お互いの認識を合わせることは大事。

再利用性を想定し過ぎることでカラーやフォントサイズなどを無意識のうちに制限してしまうケースが多い「Atomic Dsign」の特徴に触れ、淡白なデザインにならないような工夫や、表現を奪わないようなデザイン構想の必要性をなどを説明してくれた藤森さんの話は、具体例を交えているからこその説得力がありました。
また、各コンポーネントの粒度に対する感覚は人によって差異があるため、お互いの認識を合わせることが重要になってきます。そのために、日々認識のすり合わせを行い、デザインの調整を行うなど、私・タクミン自身の開発に今すぐ活かせそうなヒントが盛りだくさんでした。

「Atomic Design」の型にハマりすぎず、メンバー全員が主体性を持って判断すること、認識を合わせることの必要性を感じる登壇内容でした。

締め括りは質問&ディスカッションタイム!

勉強会の最後は、会場に集まった参加者の皆さんからの質問受け付け&登壇者とのディスカッションタイム! 実現場に取り入れる際にステークホルダーをどう巻き込んでいくか、実装担当者との協業方法等、今回の内容を実践に移すべく、具体的な質問が多々飛び交いました! DMMの事業は多岐に渡り、そのサービスの数は40を超えています。 サービスの数だけ関わる人も多く、決済権を持つステークホルダも増えるため意思決定に苦労する側面もあります。 そんな多様なサービスを抱える「いい意味でなんでもアリ」なDMMだからこそ、 今回学んだ「Atomic Design」、そして「Design Systems」を柔軟に取り入れて、より価値の高いサービス、愛されるプロダクトを今後も生み出し続けたいと心に誓った1日でした!

シェア