エンジニアとデザイナーの共業≒協業を目指すための、Atomic Designの使い方 Part2

DMMの動画サービスに見る具体例

河西紀明氏：今回はせっかくなので、弊社のデジタルコマース事業のサービス開発環境をカイゼンするためにおこなった、アトミックデザインの概念を活用したUIインベントリの実施についてご紹介いたします。

デジタルコマース事業（動画や電子書籍 etc..）など歴史の長いサービスで、当然このようなサービスは闇の1つや2つは抱えるものです。うちの場合はサービスを管理するレポジトリが職務領域ごとの工程によって異なる3つ以上の複数管理で、さらに重厚なルールとともに運用されていました。

Photoshopで全てのページ（遷移）ごとにデザインデータを作っていて500枚くらいpsdのファイルがあって、HTMLやスタイルシートも乗算式に増えてました。リプレイスなど大きな改修ごとにグローバルで上書きされたCSSやJSが複雑な依存関係を持ち始めています。急激に成長するサービスは運用の最適な保守方法を考える暇なく最大の成果を取りに行くことも多いので、この状態になったことを罵ることはできません。どこでも起こり得ることです。

自らもその要因の一分になったり、最初から全てを見据えてものづくりができれば苦労しませんね……。

ボタン1個にしても出力されたDOMが異なったり、似て非なる色や、角丸の比率も微妙に全部違っていました、コピペと場当たり作業による負債です、ルールや指針がなければこんなものです（笑）。

僕が関わったときも、そんなカオスな状態から始まって、まずはSketchなど再利用性の高いデザインデータを作るツールを導入する推進を行っていたのですが、たまたまFigma登場して複数人の同時作業として使いやすかったことやメンバーのツールの学習も兼ねて、サービス内で利用されているUを棚卸して整理する『UIインベントリ』のワークを実施しました。別に紙でもよかったんですけどね。

ページごとにデザインする経験しかないメンバーも多かったためこのワークでのUIパターンの分類や粒度分けの練習としてアトミックデザインの学習概念を採用しました。

ワーク自体は初期段階でデザイナーのみで気軽にスタートし、ジュニアデザイナーの苦手とする情報アーキテクトやアプリケーション設計構造の部分を教育しながら、サービス内の画面遷移ごとの大量のスクショを用意してパーツの棚卸しやデータの整理をワイワイ楽しくやってました。

途中から「謎に包まれた」部分が多くでてきたので、ここらへんで昔からいるサービスの全体像に詳しいディレクターを召喚しました。「現状自分たちのサービスがどうなっているか？」という現状分析から徐々に派生していき、洗い出しが完了した段階でフロントエンド側の構造に照らしあわせるフェーズに移行していきました。

デザイナーの中でフロントエンド開発でのテンプレートエンジンなどを利用したUIのモジュール化の考え方、コンポーネント設計などの知識を持たないメンバーもいたので、「徐々に」の学習を取り入れながらワークを実施したことは、アプリケーションデザインを未経験のメンバーにとってのエンジニアリングに対する学習の苦手意識をさげることができたのではないかと思います。例えば、フロントエンド側の構造に照らしあわせるフェーズでは、すでにPhotoshopなどページ単位でのUI（ページ）デザインの考え方から、コンポーネント（部品）の持つ機能や状態ごとのに設計する考え方に改まっています。

それぞれの実施成果について

アトミックデザインで細分し整理されたUIパターンをスプレットシートに棚卸し、開発の実装コードと照合した議論は非常に合理的です。

赤色も同じ色のはずなのに何十種類もありました。やばいですよね（笑）。こんな状態で赤色とオレンジ色どっちのほうが儲かるか？　なんてABテストをしても全く意味がないですよね（笑）。ABテストなどで大きな成果を出すのは一過性のUIディティールの差分で「良案」を選ぶのではなく、サービス全体のタッチポイントやユーザー体験のプロセスを加味した分析と実査が求められます。

UIの整理だけの話だけでいうと、よく質問をされますが、BEM、Atomic Design CSSといったいろんなCSSの保守運用の手段がが存在しますが、正直どうでもいいです（笑）。無駄に規則は作らなくていいとも考えています。大事なのはそこじゃないんで……。

この事例でUIインベントリを実施した意義は、デザイナーだけで閉じた議論をしたり、キレイなデザインスタイルガイドを作ることがゴールではなかったということです。期待する成果としてはフロントエンドやUI検討・実査の流れを円滑にして開発に落とし込むまでのコミュニケーションコストを減らしたりすることが一つの目標となっていました。

見える化って大事なんですよ。開発チーム全員に大いに喜んでもらいましたし、デザイナーも手応えを感じて自分の仕事に新しい自信を持ってくれた気がします。

そんなこんなで「デザイナーとエンジニアが一緒にサービス開発全体に役立つ成果物を作りました」というある種の成功事例となって社内外に波及していきました。

VueやReactとStoryBookを組み合わせた機能的なパターンライブラリをつくったりと新たな活動へとも繋がりましたが、この時点でアトミックデザインという言葉は次第に使われなくなりました。不思議ですね。多分こういうことなんです。

今後の「共業≒協業」による開発シーンで、デザイナーの強みであるUI/UXのデザインの知識でプロジェクトをリードしていくには、目新しい手法やツールの使い方を覚えてや闇雲に試すよりも、プロダクトを支える基本的な技術や設計の知識を少しずつ見に付けていくことが求められるのでしょう。

サーバーサイドで完結できることやAPIによるつなぎ込み、データベース設計が必要な部分と必要ない部分の把握。もちろん全てを網羅的に理解する必要はありませんが、接点をつなぐ知識を身につけることで、経験が自分の専門性に還元され、高い視座を得ることができます。

UIパターンの戦術的な扱い方

ここまでは運用の最適化の話が多かったので、少し戦術的な、UIパターンやコンポーネントの活用の仕方をご紹介します。

こちらの図はUXの基本概念である「体験の時間軸」を元にした「シナリオボーディング」と「マイクロフレーム」の思考を組み合わせたフォーマットです。スケッチは必ずしも描かなくても良くテキストでもよいので、プロダクトにおけるユーザーの行動や体験を書き起こします。簡易的なペルソナを作成したり、想定ユーザーに近い被験者を見つけてヒアリングしたデータを元に何度も作り直す想定で描きます。カスタマジャーニーマップなどと併用することでさらにチームでの設計の効率があがります。

新しい施策や提案などに活用できますが、この実戦の良いところは、非デザイナーをデザインワークに引き込むことができるという点です。

体験軸のフェーズに合わせて対応するフレームを記入していきます。このフレームはグラフィクツールを使わず印刷したスクリーンショットを切り貼りするスクラップや、ペーパーでも大丈夫です。ここでチームで共通言語化されたUIパターンをフレームとして活用します。

こういったフォーマットでシナリオの設計したあとに、InvisionやXDで作成するような体験的なプロトタイプにつなげていくわけですが、具体的な画面設計の部分をより詳細に関係者同士で議論する上で、アトミックデザインのワークなどですり合わせたパターン活用術が活きてきます。エンジニアと「粒度はこれだよ」「コンポーネントはこういう意味だよ」というところを共有したうえでの議論は非常にスピーディーです。

事前にUIインベントリのワークでUIパターンを定義しておけば、ただの画面遷移やスクショの羅列じゃなくて、細かい粒度を起点に生産的な議論することができます。

個別の「ページ」ごとのデザインのカイゼンでなく、サービス全体のユーザー体験のプロセスにおけるコンポーネント設計やUIパターンごとのカイゼンに眼を向けることができるんじゃないかと思います。

職務領域を越えた共通言語（パターン）が存在し、対話のレベルを引き上げることができれば、あとは”判断”やチーム合意による優先順位付けだけですむことが大半なので、爆速でデザイン〜開発ができます。

僕が最終的に今日特に言いたかったのは、この共通言語（パターン）づくり部分です。アトミックデザインやUIインベントリなど活用したワークの最終ゴールが、単純にデザイナーとエンジニアが議論して業務を最適化することではなくて、共通言語（パターン）を元に議論したが活発化し、チームで考えた施策がサービスの売上やユーザーの体験価値の向上に直接つながるようになってほしいと考えています。

戦術的なデザインワークの協業化

サービスやプロダクトが提供したいことというのはビジネス側としてもわりとシンプルなのにもかかわらず、「なんで自分たちの開発現場ってこんなゴネゴネやってるんだろう」「角丸がどうこうって言ってるんだろう」となるんですが、もっと大事なユーザー求める体験価値がおざなりになっていることが多いんです。

InVisionなどでつくった解像度の高い体験的プロトタイピングも非常に良いものですが、このようにしっかりとしたシナリオの軸を定義し、チームの共通認識として持っておくことでデザイナーがきづけないようなアイディアが発見できたり、隠れたリスクを未然に防ぐこともできます。チームのメンバーが自らが目指すシナリオを考え自走しはじめるということです。

そのうえで画面のフローやタッチポイントがより粒度の細かいところのカイゼンを回して、チームで設計したコンポーネントを用いて議論するとすごく早いですし、新しい提案するときの工数もドキュメントも少なくて済みます。そういう部分でUIインベントリによる学習アプローチが活かせるところがけっこうあるんじゃないかなと思ました。

デザイナーの学習と、その先のキャリアプラン

改めてアトミックデザインというプラクティスを学習アプローチとして提起するのは開発チームメンバーの学習のボトムアップにつながることがわかりました。開発上の大きな課題を部分的に少しずつ切り崩し、漸進的な解決へと向かわせる糸口を見つけることができます。

これまでの業務効率を大幅にカイゼンし、新規追加などでかかる設計工数を多く削減できることになるので定量的な成果にも結びつけることができるでしょう。

ただ、これまでの話、実はサービスとして収益につながるような部分は少なく、主に開発環境やプロセスの最適化に寄っていると思いませんか？。これは視点を変えると「20人でやってたところを5人で回せるようになりました」というふうにも見えてしまったり、それだけサービスに対して開発するリソースを浮かすことができるという考え方もできます。

ということは経営側としては非常にドラスティックな判断もできちゃうんですよ。例えば「サービス1つに対してこんなに人数必要ないんじゃないか」とか（笑）。

でも本当に言いたいことはそういうことじゃなくて、長く続くサービスやプロダクトのデザインをシステム化し運用にのせることに成功したり、エンジニアだけでもコンポーネントライブラリを利用してUIデザインができるようになれば、ようやくデザイナーはさらに上位の設計を担う準備が整ったという見方ができます。

そのサービスデザインを担当デザイナー専任とせず、体系化できるというのは一つのサービス運用のゴールともいえます。デザインの協業化が実現に近づくにつれて手離れが生じます。単純作業なお仕事がなくなっちゃいます。 なので取り組んだ施策の定点的な目標を達成した”先”のことも考えて置くことを強くオススメします。

場合によってはジョブローテや、担当するサービス自体を変えてしまって新しいキャリアパスを築くのも全然ありだと思います。同じサービスに関わり続けることを悪いことだとは思いませんが職務領域だけでなく分野を変えてみないと気がつけないことや経験できないことは当然でてきます。

いずれにしても、やるかやらないかという行動力は求められるので。難しいところですが。デザイナーとしてサービス設計や情報設計に対して理解が進んだ先に、我々は本来何をデザインしていきたいのでしょう？という問いが残ります。

共業≒協業の第一歩

今後の職務領域を越えた巻き込み方、運用フェーズへの乗せ方。もっと細かい課題がたくさんあると思います。

僕の中の結論としてプロジェクトのソースとしてアトミックデザインは最終的に必要ないと思っています。なぜならアトミックデザインは成果物ではなく、共通認識や共通言語を作り出すための「学習プロセス」にすぎないと思うからです。そしてデザイン側の働きかけとしても「アトミックデザインを導入しましょう」「ツールを導入しましょう」というよりも、大切なのは「本質的な対話の質を向上させていきましょう」を実現するために思考することと議論を止めないということです。

リモートなどいろいろと推奨されている中で、本当に「となりにいるエンジニア」とちゃんと会話できているのか。認識はあっているか？伝えたつもりで伝わっていないのではないか？

先ほどのようにビジネスサイドにアプローチできるような観点をしっかり持ちながら、まずは開発現場で議論できたらいいかなと思います。

ちゃんと仕事としての信頼関係築けているのかがふりかえってみましょう。単なる仲良しではなく、共通の課題について力強く語りあえるという意味です。「デザインをデザイナーだけの仕事にしない」まずはそこから頑張ってみましょう。

最後に、『UIデザイン みんなで考え、カイゼンする。』こんな本を執筆しました。今回のお話させていただいた内容とあわせてぜひフィードバックください。

UIデザイン みんなで考え、カイゼンする。

すこし長くなりましたが、ありがとうございました。

（会場拍手）