istyleにおけるAtomic Design利用の現状と課題

高田孝平氏（以下、高田）：「istyleにおけるAtomic Design利用の現状と課題」というタイトルでお話させていただきます。よろしくお願いします。私はアイスタイルでバックエンドエンジニアをしています、高田です。

竹内美帆氏（以下、竹内）：デザイン部でフロントエンドエンジニアをしております、竹内です。よろしくお願いいたします。

細江佳菜美氏（以下、細江）：同じくデザイン部でデザイナー兼ディレクションをやっています、細江と申します。

高田：はい、ありがとうございます。まずAtomic Designを導入するまでの経緯について話します。

その前に、アイスタイルがどんな感じで開発を行っているかと今回の事例について、前提知識として説明します。

今アイスタイルでのWeb開発は、PHPがメインで行われてます。またHTMLやCSS、JavaScript、PHPが、1つのリポジトリで管理されていて、お互いがけっこう密結合になってしまっています。いわゆるモノリシックなアプリケーションになってしまっています。

あとコンポーネント指向開発の点で言うと、PHPで作られているサービスのうちの一部、ナビゲーションの部分やボタンをコンポーネントとして切り出したもの、そういう実装もいくつかあります。

次に、今回の事例での開発の役割分担を説明します。APIの実装やインフラ、DBの話とかは趣旨から外れるので省略します。

まず1番右、デザイナーがいて、UI設計とかビジュアルデザインを行っています。次にフロントエンドがいて、今回で言うとVue.jsのUIに関するテンプレートやスタイルなどの簡単なJSの実装を行っています。

次にエンジニアがいて、開発環境を整えたりAPI開発を行ったり、APIとVue.jsで接続する部分を実装したり、あとは複雑なJSのロジックの実装、デプロイ先のサーバーの準備を行ったりしています。

フロントエンドも、普通に後ろに「エンジニア」って付くと思うんですけど、この会ではそのあとにいるエンジニアと区別するため、「エンジニア」を取って「フロントエンド」と呼びます。

この3者がいて、今回はそれぞれから代表して3人が話します。部署や人によっては若干前後する場合もあるんですけど、アイスタイルでの開発はだいたいこんな感じです。

アイスタイルでは、アプリケーションに対してそれぞれチームがあるという開発をあまり行っておらず、部署によるウォーターフォールで作業分担をして開発をしています。エンジニアだけは部署が違ったりするので、そこで壁を感じてたりもします。このあと話すんですけれども、部署が分かれてることによる問題も起きたりするので、そのへんもまたあとで話します。

Atomic Design導入までの経緯

高田：では、今回の事例について説明します。

今回、新規のWebの画面を作成するような案件がありました。そこはNuxt.js、つまりVue.jsで作ることに決めました。しかも優先度的に一旦止まってるような案件だったので、新しいことを実験できる時間がありました。

最初からデザインがほぼ完成していたので、それをどう実装に落とし込んでいくかっていうところからスタートしました。

では次に、アイスタイルでAtomic Designを導入するに至った経緯を説明します。

先ほども言ったんですけど、アイスタイルではこれまでもコンポーネント開発を、一部行ってはいました。ただ、その設計には基準となるものがありませんでした。

コンポーネント開発をやってて、直近で問題になった具体例があって。それは作業分担の点で問題になりました。

エンジニアがVueファイルを仮で組んで、画面遷移とか動きとかを実装したあとに、デザイナーとかフロントエンドに渡して、CSSとかUIに関わるJSを実装するっていうやり方をしました。

このやり方だと、コンポーネントの切り方とか設計に関してエンジニア側でやってしまったんで、フロントエンドとかデザイナーのやりやすいかたちで開発することができませんでした。

こういった問題の原因は、作業分担をすることによってコンポーネント設計の共通認識のコミュニケーションが十分でなかったことだと思います。設計の認識が最初にみんなで合わせられていれば、作業が流れてくる前に実装方法を考えておくことができるし、エンジニアからフロントエンドっていう流れだけじゃなく、逆にすることもできるのではないかと考えました。

つまり、エンジニア・フロントエンド・デザイナーの3者が設計の指針の認識を合わせることができて、組織の壁に風穴をぶち開けられる手法があれば良いと思いました。そこで挙がってきたのがAtomic Designです。

Atomic Designとは何か？

細江：今、「みんなが設計の指針の認識を合わせられる手法」としてAtomic Designという名前が挙がってきたんですけれども、そもそもAtomic Designとは何かについて軽くご説明します。

Atomic Designとは、簡単に言うと「メンテナンスしやすいUIの開発ができるデザインフレームワーク」です。

小さいUIコンポーネントを組み合わせてより大きなコンポーネントを作っていくための手法で、ページ単体でデザインしていくのではなくて、コンポーネントを組み合わせてページをデザインするというのが特徴です。

じゃあその「コンポーネント」って何だっていう話なんですけど、コンポーネントは簡単に例えると「部品」のようなものなのかなと思ってます。

家に置き換えるとわかりやすくて、ネジや木、小さな取っ手などのコンポーネントを集めてドアを作って、さらにそのコンポーネントを集めて家を作る、というものになります。

Atomic Designも同様の考え方で作られていて、小さなUIコンポーネント、ここで言うネジなどそういった小さいものから検品していって、なにか不具合が発生してもそのコンポーネント単体を調べれば不具合の原因がわかる、というような考え方になります。

Atomic Designでは、そのコンポーネントを5つの粒度で分けてます。

1番小さいものがAtomsで、1番大きなものがPagesです。このUIコンポーネントをAtomsからPagesに向かって作成していくのが、Atomic Designのデザインフレームワークになります。今回弊社では、この考え方をコンポーネントの切り方の参考にしました。

デザインから見たAtomic Design

細江：以上を踏まえて、弊社で取り組んだAtomic Designの、デザイナー視点のお話をさせていただきます。デザイナーの担当内容と、フロントエンドへ渡すまでの流れはこんな感じです。

前提でもお話したように、今回はデザインが完成した時点からの作業となったため、Atomic Designの「小さい粒度から作っていく」という前提をちょっと無視しまして、完成されたデザインを分解していくという作業を行いました。

その作業が完了したあと、分解したコンポーネントのたたきを見ながら、フロントエンドとエンジニアと一緒に認識の齟齬（そご）が無いか確認していく、というような流れです。

コンポーネントの切り方ですが、図のように要素を分解していきました。

コンポーネントを切る目安として、これで言うOrganismsの場合は、sectionごとで分けるようなイメージで。Moleculesはこの例で言うと、listで分けるようなイメージをしました。Atomsはとくに分けるのが難しくて、要素がこれ以上分けられないところまでというのを意識したんですけど、「これは何に当てはまるんだろうなぁ」ということが多くて苦労しました。

その苦労した点の一部が、こちらになります。

とくに悩んだのが「ボタン風リンク」の存在で、挙動としてはよくある「押したら別ページへ遷移する」というものなんですけれども、見た目はボタンの形をしてるのに中身がbuttonタグではなくaタグっていうようなかたちで。

こちらをボタン扱いにするか、それとも中身はテキストリンクと一緒だし……というところで悩んで、結果、ボタン風リンクとしてAtomsに入れることにしました。もしほかに良い解決方法をご存じの方がいらっしゃったら、ぜひ教えていただきたいです。

あとは周辺の要素の補助で使っていたテキスト、ちょっとわかりづらいのですけど、この「ラベル」ってとこですね。こちらをラベルにするか、テキストにするかで悩みました。こちらはテキストとCSSのスタイルが同じだったというところで、テキストに合わせました。

最後の「カウント」というのは、記事の総数のカウントやアクションボタンのカウントで使っている数字のことです。最初はラベルと一緒で、同じスタイルが使えるからテキストっていうふうにしてたんですけど、こちらは3桁目にコンマが入るという見た目の変化があることから、Atomsとして扱うことにしました。

そしてその分解したたたきを持ち寄って、エンジニアと認識を合わせていきました。このフェーズでは、デザイナーとフロントエンド側と、あとエンジニア側で、「コンポーネントを切りたい箇所が違う」というところが大きなポイントでした。

デザイナーとフロントエンドは見た目ベースで考えるため、同じ見た目をしているものでコンポーネントを切っていたんですけれども、エンジニアさんは裏側の機能で揃えたいっていうところがあったので、そのあたりの調整を意見を出し合いながら解決していきました。

そしてそれが終わって全員のコンポーネントの認識が揃ったら、最後にコンポーネントに名前を付けて、フロントエンドへお渡ししました。続いてはそのフロントエンド側のお話になります。

開発から見るAtomic Design

竹内：それでは、「開発から見るAtomic Design」ということで、フロントエンドとエンジニアがどう進めていったかを説明いたします。

まず開発の進め方を検討しました。Atomic Designが小さいコンポーネントから大きなコンポーネントを積み上げていく手法というところから、開発の流れもAtomsからテストして、大きいMoleculesなりTemplatesなり作っていくっていうかたちにしましょう、というふうに認識合わせをしました。

その次は、「Atomsはじゃあどうしようかな」って話していて。今検証している以外のほかのサービスにも使う可能性があるし、共通のコンポーネントが既に、ヘッダーとかフッターとかっていうのがあるので。そちらでも使えるように、別環境で作ってそれらから呼び出すようにしようかな、というのに話し合いが決まりました。

ちょっと図で、こんな感じになります。

今までは、サービス共通のコンポーネントが、ヘッダーやフッターがあって読み込まれてたんですけど。Atomic Designを導入したら、Atomsがあってそれをサービス共通のコンポーネントなり、各サービスの開発環境から読み込めるようにっていうところで、確定ではないんですけどこれで検証を進めていっております。

このかたちに関しては、ほかにもいろんな会社さんがやられてるものを検索して見てたりとかしてたんですけど「Atomsだけを外に出してる」みたいな例がなく、とりあえず試してみようということで（笑）。逆に、前例がなくて何がベストプラクティスなのかわかんないけどやってみようかな、っていうところで落ち着きました。

単一ファイルコンポーネントの開発について

次。Vue.jsでは横のソースコードのように、templateとscriptとstyleっていうタグが1つのファイルの中にあって、「.vue」という拡張子のファイルとして1つのコンポーネントを作る機能があります。これが単一ファイルコンポーネントと呼ばれているんですけど、その1つのファイルの中でフロントエンドとエンジニアが同じファイル触ることになるから、どっちがどこまでどういう流れでやろうか、というところも検討しました。

それを検討する前に「じゃあ今までどうやってやってたかな」っていうのをちょっと振り返ってみました。

実際の案件であった手法のまず1個目の例が、フロントエンドが静的テンプレートを作ってエンジニア側に引き渡して、HTMLをエンジニアがビューに埋め込む、っていうかたちです。

これに関してはフロントエンドとエンジニアが同時並行で作業をできるんですけど、最後のビューの部分をエンジニアが再度埋め込むことになり、同時並行でできるメリットはあるんですけど、ちょっと2度手間になりますね。。

2個目が、エンジニアがビューでロジックなり、全部仮のHTMLを埋め込んだ状態。このあとフロントエンド側でHTMLとCSSなどを当てていくっていうのが共通コンポーネントのVue.jsとかPHPベースの両方で、案件によってはありました。

これに関してはフロントエンドが、エンジニアがロジックなどを全部埋め込むのを待つ必要があって、同時に作業することができない。もしフロントエンドが、エンジニアが作業している間にリソースが空いてたらもったいないな、というところですね。

エンジニアとデザイナーの作業分担事例

次、それをもとにじゃあ今回どうしようかっていうのを話し合って、作業分担としてはこうなりました。

フロントエンドはモック、主にテンプレートとスタイル、スクリプト部分、UIに関するパターン。エンジニアがロジック、データの受け取り、APIつなぎこみなどのスクリプト、表示の出し分けに関するテンプレートの部分の条件などを行う。

エンジニアは先にAPIを作ることが多いとうかがったので、その間にテンプレートとスタイルの部分を作成して、テンプレートまでつなぎこみを行って。でも必要によってはやっぱりエンジニアが入ってから調整したほうがいいよね、っていうのは発生する可能性があるかなと思います。

エンジニア側としては、モックコンポーネントのロジックを受け取って実装する。時間がかかりそうなものに関しては、既にAtomic Designっていうみんなで認識を合わせた設計があるので。それをもとにビューのファイルを作っていく、っていうかたちになっていて。

設計はわかっているので、こっちとしてもロジックを先に組まれたとしても、「あ、そういうふうに来るんだな」みたいなのが、ちょっと心持ちが違うっていうところですね。お互いスムーズかなと思いました。最後にPagesにAPIつなぎこみを行います。

ということで、Atomic Designという設計の共通認識で解決しました。

まず1個目が、ビューファイル内でのテンプレートとスタイルを作るので、エンジニアがHTMLのすごく大変な出し分けとかの場合、やっぱり解読して表示パターンを埋め込むのが大変なんですけど、そういう必要がありませんね、っていうところと。

2個目の例が、ビューファイル自体は同じで並行作業はできないんですけど、うまくコミュニケーションをとって、フロントエンドも開発を前倒しすることができるようになったよね、っていうかたちになりました。

Atomsの開発で考えたこと

今回、AtomsからPagesまでちょっと終わっていなくて。Atomsまで開発が終わりました。

Atomsの開発に関しては、認識としては基本「要素を表示するだけに徹する」っていうかたちですね。どんなサービスにも使えるようなベースのものにする、ってかたちです。

今回検証予定のサービスで利用するAtomsだけを作りました。またほかのサービスで利用して、かつ共通で使えそうなものはどんどんAtomsとして設計して実装していきたいと思います。

ここでAtomsに関してちょっと、一応外部に見られても大丈夫なようなものなので（笑）。1回表示をしたいと思います。

今回Atomsの、「何があるかな」って中のやつを、一覧できるように「Storybook」というプラグインを導入しました。（画面を指して）これがアイコンの例ですね。svgファイルを設定してただ表示するというものです。

これがボタンですね。ちょっと見づらいんですけど（笑）。ボタン要素です。使い方はこんな感じで見れるようになっております。あとcountやheadingとかも。デフォルトh1なので、見た目でわかんないですけどこれがh2になっています。

噂の「見た目ボタンなんだけどリンク」っていうのはこれですね。ボタンとまったく変わんないです。でも中のbutton要素とa要素っていうような違いがあります。じゃあ、プレゼンに戻ります。

これはAtomsの最終的に作った個数ですね、10個近くあります。

今回全部説明してる時間がなくて、あとでたぶん資料が配布されると思うんで、そのときに見てみてください。

Atomsの実装の認識について

まとめです。Atomsの実装の認識というのが、こんな感じに落ち着きました。

Atomsは基本的にタグを表示するだけでロジックは持たない。ただしやっぱりheadingとかhx、1～6まであるので。それの出し分けや、「カウントのコンマ付ける」っていうスクリプトは仕方ないねって。表示に必要なものはOKとしました。

スタイルとしては、アイスタイル共通として決まってるスタイルをできるだけ持つ。あとは各サービスから共通コンポーネントで、Atomsを使ってMoleculesとか作っていくと思うんですけど。やっぱり上書きっていうのがスタイルの場合は前提になるので、classを設定したり、今回scopedなしで実装しています。

このscopedなしっていうのに関しては、名前をそのコンポーネントごとに全部一意で決めているっていうことで。scopedはあとから付けるほうが影響範囲が少ないので、とりあえずこれで検証しようってかたちになっております。

あとはそのコンポーネント自身の役割を超えたスタイルは付与しない。marginとかpositionに関するものですね。いろんなコンポーネントに入ると思うので、自分の役割を超えたものを入れてしまうと、いろんなコンポーネントで制御がしづらくなってしまうのもあるし、というかたちですね。

あとはスタイルに関しては、どんな画面、横幅とかですね。例えば、固定値を付けないとか、そういうかたちにしました。

悩んだ、苦労したところ

最後、悩んだところとか苦労した点なんですけど、Atomsを「ただ表示するだけ」っていうところは最初、頭にはあったんですけど、どうしてもロジックをすごい埋め込みたくなってしまって。どこまで実装したらいいのかっていうところに悩んだんですけど、今は自分の中で落とし込みができたので、大丈夫になりました。

「コンポーネント設計で途中で変更した」っていうのは、細江さんのほうから説明したんですけど、「ラベルはテキストとスタイルに違いないよね。あれ？」ってなって統一したりとか。見た目ボタンなんだけどaタグで遷移って、そういえばどうすればいいんだろう、とか。そういう感じです。

あとは、「デフォルトの色は何にすればいいんだろう、いろんなサービスから使われるよね」っていうところで。

現在デザインメンバーのほうでUIガイドラインを、確定はしてないんですけど作っていたので。「将来的にこんな感じかな」っていうのを一緒に話し合いながら検討して実装しました。

なので開発面だけじゃなくて、将来的にはやっぱりうまく連携して、UI/UXの部分、デザインの統一性とかユーザーの操作性とかにも貢献できたらな、と思いました。次回はできたら、MoleculesからPagesの開発に関して話せたらと思っております。

では、総括です。

やってみてよかったこと

高田：はい。まず、やってみて良かったこと。こんな感じなんですけど、一つひとつ見ていきたいと思います。

まずコンポーネントの切り方や中身の実装について、今までけっこう実装者に依存している部分が大きかったんですが、それに対して共通の基準が生まれました。今はだいたいの大枠が決まっているので、今後は誰でも設計できるはずです。

あと、フロントエンド的に、テンプレートの切り方が事前にわかっているので、スタイルの設計とか考えられるし。設計にもみんな関われたんで、コンポーネントの切り方とかで不満はなくなるのではないかと思ってます。

リソースが空いていたらモックを作るとか、そういったこともできたので開発効率にも貢献できたのではないかと思います。

また、うまくみんなで認識を合わせられて、デザインとか開発のフローに取り入れることができれば、デザインが統一されてUIのブレが防げると思いました。

例えばユーザーにとって同じ種類のアクションなのにUIの挙動とか色が違うと、ユーザーを迷わせてしまうことになります。特定の色が持つ役割の認識がデザイナーによって違うと、ユーザーにとっては同じものなのに違う挙動や色になってしまうのを防げるかなと思いました。

さっきも言ったガイドラインでここらへんが統一されつつもあるんですけど、まだちょっと時間がかかると思うんで、そこらへんと連携して開発できるといいなと思いました。

あとはさっきもちょっとお見せしたんですけど、Storybookによる描画の確認ができました。

Storybookはけっこうプラグインがあって便利です。今後コンポーネント開発とか、必ずStorybookで見るようにして、いろんな表示パターンをストーリーとしていつでも見られるようにする。そういう決まりにしておけば、表示の確認漏れなどの事故が防げるなと思いました。

アイスタイルの開発では、けっこう表示パターンが多いものがあって。そういったパターンが漏れることによる確認漏れみたいなものを発生していました。あとは仕様書を最初に作ってそのあと更新しない、みたいなこともあったりするので、新しい担当者がぜんぜん把握できなくてパターンが漏れる、みたいなこともありました。

そういうのをStorybookによる確認で流れをしっかりしておけば、表示事故を防げるのではないかと思いました。

あとはこの会のことなんですけど、インプットしてそれを業務で使って社会にアウトプットする、みたいな流れが作れたのが良かったなと思っています。

今まで弊社であんまりそんな、社内でやってることを社外にアウトプットすることが少ししかなかったので、良かったなと思ってます。

苦労したこと・課題に感じたこと

高田：次に、課題について話します。これまで社内でやってきたデザインのやり方に対して、Atomic Designのやり方をどうやって取り入れていくか、みたいなところをデザイナーとして悩んでいるところはあります。

あとはMoleculesが最初「呼ぶとき恥ずかしい」みたいな問題がけっこうありました。

（会場笑）

あとさっき言ったStorybookで確認とかはできたりするんですけど、そこにちゃんと説明とか書いとかないと、今までと同じように結局ほかの人が把握できてなかったりするんでそこの流れとか決まりはちゃんとしなきゃな、と思いました。

次にAtomic Design以外の課題です。

今回、VueとかStorybookとかNuxtとか、いろいろ初めてのものがあってけっこう大変でした。あとは今までgulpをメインで使ってたんで、Storybookのwebpackの設定への移行が大変だったりしました。これはNuxtと、あとStorybookで設定が別だったんで、共通に切り出して取り込めるようにしました。

最後にまとめです。Atomic Designを取り入れたことによって、それぞれの共通言語ができました。

まだAtomsまでではあるんですけど、効率的な開発ができるようになりました。あとは最初に言った今まで課題になってたものは、解決したなと思ってます。これからもっと開発を進めていく上で、もっとメリットが出てくるんじゃないかなと思ってます。

あとAtomic Designをそのままじゃなくて、「取り入れるプロジェクトや組織によってカスタマイズすべし」って言ってるのは、Atomic Designを提唱したブラッド・フロスト氏は「5つに分ける」という簡単な分類方法のみを記しています。アイスタイルではAtomsを、どんなサービスでも、共通コンポーネントからも利用できるくらいに小さくしたんですけど、小さいサービスだったらここまでやる必要ないかなと思います。

どういったふうに分けるかという分類も、状況に合わせて開発とか運用がしやすいものにしていっていいかな、と思ってます。あとは開発フローとか、誰がどこまで実装するかなども、ぜんぜん変えていっていいかなと思ってます。

こういうときはこうしたよ、っていう情報を共有できるとみんなが幸せになると思って、今回アイスタイルの状況を共有させていただきました。みなさんのコンポーネント開発の情報をみんなで共有していくと、みんなが幸せになれるので、ぜひ共有をお願いします。ありがとうございました。

（会場拍手）