最近よくクリエイターが移住するカナダで Atomic Design を学ぶ
こちらは Frontrend Advent Calendar 2014 19日目の記事です。
2014年 12月8日〜12月14日の間、カナダに滞在してきました。目的は12月9日〜12日に開催される Smashing Conference 2014 へ参加するためです。
海外のカンファレンスに参加するのはおろか、海外旅行もしたことがないので、今回１人でカナダに行くということで終始緊張の連続でした。（Frontrend の @hiloki さんが「僕も行こうかな」と言っていたので、心強く思っていたのですが、残念ながら叶わず。）
本記事は、カンファレンスが開催されたカナダという国にまつわるお話を Frontrend の話題を交えながら書きつつ、このカンファレンスで一番楽しみにしていたトピックである「Atomic Design」について書いていきます。
参加の理由
今まで海外カンファレンスなど参加したことがない自分が今回参加を決意した理由は、興味があるスピーカー陣が多くいたことがもちろん１番なのですが、２番目の理由として、今年に入ってからカナダという国そのものに興味を持つようになったからです。
興味を持ったキッカケは、カンファレンス募集期間の前後、立て続けに日本からカナダに移住する Web クリエイター・エンジニアたちに会ったことです。そのうちの一人が、Mr. Frontrend である @t32k さんでした。彼のブログ記事「Webエンジニアからみたフィリピン語学留学」で書いている通り、彼はフィリピンで語学留学した後、現在カナダでエンジニアとして働こうとしています。
アメリカに近いという点でのカナダの魅力
「偶然なのか、なんだか最近多くの人がカナダに行っている気がするな。」となんとなく思っていました。IT 業界でエンジニアとして働いている者であれば、一度はシリコンバレーで働きたいと願う人も少なくないでしょう。だから、アメリカ合衆国で働きたい、というのは分かります。しかし、なぜカナダなのでしょうか。
そんな疑問に答えるかのように、Frog というクリエイターのためのカナダ留学支援団体のサイトにはカナダのバンクーバーについてこんなことが書かれています。
- バンクーバーはシリコンバレーと時差が同じ
- Facebook やアマゾンなどの企業が進出
- カナダで就労して、アメリカの就労ビザを取得したらシリコンバレー就職
なんともアメリカンドリームに近づけそうなカナダの魅力がそこにはありました。もし普通の日本人がアメリカで働きたいと思ったとしても、アメリカの就労ビザ取得は難しく、働きたくても外国人にあたる日本人はなかなか働く許可を得ることが難しいでしょう。それと比較すると、カナダは就労ビザの制度に融通が利きやすいということのようです。
実際、現地で出会った人の中にもいずれはシリコンバレーで働くことを目標にしている人もいました。
カナダ自身の魅力
上記のような理由は、カナダ自身というよりはアメリカへのアクセスに対してのカナダの魅力しか示していませんが、実際カナダのバンクーバーに行ってみると、人は優しく、街は綺麗でとても魅力的な国でした。
私は学生時代に約６年アメリカに住んでいた記憶もあって、カナダに着いたとき、街中の標識や店頭の商品を見てアメリカととても似ているな、と感じたのですが、実際に人と触れ合うと（言い方は悪いですが）アメリカのようなドライさはあまり感じられません。むしろ優しさに溢れていました。
たとえばロックが開かなくなった荷物について私が空港の人に助けを求めると「私には開け方が分からない」と言いながらもあの手この手で開けようと頑張ってくれたり、カナダに来たばかりで電車の乗車券の買い方１つ分からない私に通りすがりの人がとても丁寧に買い方を説明してくれたり、気候とは裏腹になんだかとても暖かい国だなと感じました。
そして、移民も多いためか外国人に対して慣れている感じも見受けられます。物価が若干高いところと、気候が寒いところを除けば、日本人にとっても住みやすそうな街に感じました。もちろん１週間しか滞在していないので実際のところは分かりませんが、The Japanese Community in Canada が示すようにバンクーバーの人口の 1.3% が日系であることからも日本人にとっての住みやすさが想像できます。
英語の重要性
カナダで開催されるカンファレンスということもあり、やはりコミュニケーションは英語になります。長く英語を話す機会から離れているので、この点も今回の旅において心配する要因の１つでした。
少し前に、エンジニアミーティング vol.6-4 エンジニアの英語戦略 というポッドキャスト番組でも話があったように、特にここ１、２年はまわりにいるエンジニアが英語を話せるようになる必要性を強く感じてきています。
実際、職場の友人も、English Lunch という呼ばれる英語オンリーで会話するランチを定期的に開いたり、Frontrend の @1000ch が「2014年の振り返りと人気記事まとめ」で触れているように レアジョブ英会話 で毎日レッスンを受けたりしている人がたくさんいます。
私も同様に、生の声を聞ける機会に英語で恐れず話ができることは大事だと今回の旅で思いました。（恐れず、を強調したのは、別に流暢でなくてもコミュニケーションを取ることができれば良いと思っているからです。）私は漠然と開発における技術やワークフロー、考え方など欧米は日本より進んでいるように思っていましたが、実際にカンファレンス参加者と話すと日本で私たちが課題に持っているのと同じような課題を抱えていて、相手の話が身近に感じたり私の話に共感してくれたりするのがとても新鮮でした。
Smashing Conference Whistler
さて、今回参加した Smashing Conference ですが、ウィスラーというバンクーバーから車で２時間程離れたリゾート地で開催されました。（ウィスラーは２０１０年冬季オリンピック競技が行われたくらいのスキーリゾートなので、正直スキーやスノボというオマケにつられてカンファレンスに参加した、という人もいました。）
参加者は、やはりカナダ人、とりわけバンクーバーから来ている人が多かったのですが、アメリカ人も多くいました。逆に考えると、カナダからアメリカのカンファレンスなどのイベントに参加することもそのくらい気軽なのだろうと感じます。（日本からアメリカのイベントに参加しようと思うとウン十万円と費用がかかるので、この点においては羨ましい限りです。）
Mr. Brad Frost と Atomic Design
今回のカンファレンスで一番楽しみにしていたのは、Brad Frost 氏の Full-day ワークショップを受講することでした。Brad Frost 氏は Responsive Design のパターンやニュースなどを集めたサイト This Is Responsive を公開し、Adaptive Design に関する実用的で深い見識を持っています。
私がこのワークショップを楽しみにしていた理由は、彼がレスポンシブな Web をコンポーネントベースでデザインする方法論として、Atomic Design というものを提唱していて、このワークショップはその考えを学ぶことができる場だったからです。
ここ１年、私は２つのプロジェクトでフロントエンドの開発をしました。どちらのプロジェクトでもコンポーネントベースでの UI 開発を意識してきましたが、コンポーネントをどんな粒度で作るのが１番再利用性が高くなるのか、なかなか明確な基準をチームの中で共有することができないでいました。彼のワークショップを通して、コンポーネント開発に対する考え方を磨きたいと思いました。
ここからは、そのワークショップおよび、カンファレンスの１セッションでもあった Atomic Design について書きたいと思います。
Atomic Design とは
Atomic Design はデザインシステムを作るための１つの手段です。ざっくり言うと UI コンポーネントを粒度に応じたカテゴリーに明確に分ける手法です。Atomic Design では下記のようなカテゴライズのレベルが示されています。
- Atoms - 原子
- Molecules - 分子
- Organisms - 有機体
- Templates - テンプレート
- Pages - ページ
これらのカテゴリーは上から下に行くにつれて、粒度は大きくなり、抽象度は下がっていきます。下位カテゴリーのコンポーネント（例えば原子）を組み合わせて上位のコンポーネント（分子）を構成するようにデザインを考えていきます。
We’re not designing pages, we’re designing systems of components.
まさに Stephen Hay 氏の上記の言葉にあるように、ページをデザインするのではなく、コンポーネントで構成するデザインシステムです。
特徴的な名称
私が Atomic Design が手段としてとても優れていると思う点は、カテゴリーの名称がコミュニケーション・ツールとしても柔軟なところです。
５つのカテゴリーのうち、原子、分子、有機体に関しては、開発サイドにメリットがあるカテゴリー名です。この３つの名称は、およそ Web デザインには関係が無さそうな名前です。しかし、原子と原子が結合して分子になることから連想すると、コンポーネントを組み合わせて新しいコンポーネントを作り出すという特性をとても正確に表しています。
それに対してテンプレートとページという２つの名称はとても一般的です。前者３つのコンポーネントより具体性が増して、このレベルではクライアントやプロデューサーに見せるアウトプットになるので、彼らと会話するときに余計な違和感を与えることなくコミュニケーションできる名称になっています。
Pattern Lab
５つのカテゴリーを１つずつ説明する前に、Atomic Design を実践するために便利なツールである Pattern Lab を紹介します。Pattern Lab は Brad Frost 氏と Dave Olsen 氏の両名が作ったパターンライブラリかつ静的サイト・ジェネレータです。
パターンライブラリとしては、原子や分子、有機体といったコンポーネントパターンをコードベースで管理することができます。また静的サイト・ジェネレータとしては、ページやテンプレートと言ったサイトレベルのデザインを原子、分子、有機体から生成します。
Pattern Lab は Atomic Design のパターンを作るスターターキットとしてとても優れているので、ここからの５つのカテゴリの紹介は Pattern Lab で説明していきたいと思います。
Atoms - 原子
原子という名前の通り、これ以上分割することができない基本的な要素がこのカテゴリに含まれます。これ以上分割することができない要素なので、ラベルやインプット要素、ボタンなどの HTML タグは原子としてカテゴライズされます。カラーパレットやフォント、アニメーションなどもこれ以上分割することができない要素として原子に含まれます。
原子にカテゴライズされる要素は、基本的に単体では UI として意味を成さないものばかりになりますが、この後に紹介していくカテゴリのコンポーネントも、ここの要素にあてられたスタイルがベースとなっていきます。この要素たちを集めて一覧化すれば、Dan Mall 氏の ELEMENT COLLAGES のような感じで、サイト全体のトンマナを要素レベルで俯瞰できるはずです。
Molecules - 分子
分子もその名の通り、原子がくっついてできる最小の単位です。ラベルやインプット要素、ボタンなどのコンポーネントを合わせて、例えば検索フォームという形にすることができます。原子は単体ではあまり意味をなさないものでしたが、組み合わせることで目的を持ったコンポーネントになることができます。
ただ、このコンポーネントが持っている目的はまだ汎用的なもので、コンポーネントとしての再利用性が５つのカテゴリの中で最も高くなるようにデザインしていく必要があります。これが Atomic Design システムの根幹を担います。この分子をいろいろな UI パーツに上手に組み込むことが Atomic Design のコツとなるように思います。
Pattern Lab では、このように既存で作った原子を組み合わせて分子としてのコンポーネントを作れるように、別のコンポーネントをインクルードすることができるようになっています。
Pattern Lab はテンプレートエンジンとして Mustache を使っており、{{> そのコンポーネントの名前}} という記述でほかのコンポーネントをインクルードすることができます。上記のコードでは、原子のコンポーネントである atoms-square をインクルードしています。原子から分子というように小さいコンポーネントを使って大きいコンポーネントを作っていくことが簡単にできます。
Organisms - 有機体
有機体は原子や分子を組み合わせて、さらに複雑なコンポーネントを構成します。このレベルでは、インターフェースのパーツとして人が意味のある名前を付けるコンポーネントとなります。例えば、ヘッダーやフッター、記事一覧などのパーツが有機体に含まれます。
Templates - テンプレート
テンプレートはその名前の通りで、具体的なコンテンツを持っていないページのテンプレートです。ヘッダーや記事一覧などの有機体、ページネーションなどの分子をレイアウトして構成します。
Pages - ページ
最後がページです。テンプレートに画像やテキストなどの具体的なコンテンツが流し込まれて完成します。
Pattern Lab では、コンテンツは JSON によってテンプレートに適用され、ページとなります。ここではここまで作ってきたコンポーネント現実のコンテンツに耐え得るかを確認します。サンプルテキストやアテの画像ではないコンテンツを流し込んだときにレイアウトが崩れることなく、コンポーネントとして成り立つことができているかをテストするカテゴリーでもあります。
デザインシステムの運用におけるパターンライブラリの重要性
私も過去のプロジェクトで、デザインシステムらしきものを自分で考えて、そのシステムに従ってコンポーネントを管理していました。いわゆるオレオレデザインシステムです。そのデザインシステムで作ったコンポーネントの粒度が適切だったかどうかはさておき、ディベロッパー間で共通言語として使うところまでは上手くいったように思いましたが、コンポーネントを組み合わせて新しいコンポーネントを作成していくため、粒度の小さいコンポーネントに修正が入ったときの影響範囲が分かりづらくメンテナンス性にずっと課題を感じていました。
コンポーネントベースのデザインシステムを運用で実践していくにあたっては、コードのメンテナンス性を保つために最低限下記の機能を持ったパターンライブラリが必要だと思います。
- 粒度の小さいコンポーネントをインクルードしてより大きなコンポーネントを構成する機能
- インクルードされる側の粒度が小さいコンポーネントがどこで使用されているかを把握できる機能
「粒度の小さいコンポーネントをインクルードしてより大きなコンポーネントを構成する機能」に関しては、細かいコンポーネントたちを１ソースにまとめるために必要です。やはりコンポーネントに修正を入れるときは１ヶ所だけ修正すれば良い状態が理想です。
「インクルードされる側の粒度が小さいコンポーネントがどこで使用されているかを把握できる機能」に関しては、コンポーネントを削除する時に便利です。長く開発・運用を続けていると、定期的にコードの大掃除する必要に迫られると思いますが、そのコンポーネントを削除してもほかのコンポーネントに影響が出ないか確認できれば不必要なコンポーネントの掃除が容易になります。
Atomic Design 実践用のサポートツールである Pattern Lab は、「粒度の小さいコンポーネントをインクルードしてより大きなコンポーネントを構成する機能」を Mastache を採用することにより実現し、「インクルードされる側の粒度が小さいコンポーネントがどこで使用されているかを把握できる機能」を Lineage という機能で実現しています。
コンポーネントベースでのデザインを実践するときは、どうしてもそのデザインシステムに合ったコンポーネント管理機能を持つツールが必要になります。デザイナー・ディベロッパーは自分のプロジェクトに合ったデザインシステムを採用する必要がありますが、そのデザインシステムをサポートするツールがあるとは限りません。むしろ、ないケースの方が多いでしょう。Atomic Design の場合は、そのデザインシステムに特化した Pattern Lab というツールがすでに用意されていることが、これを採用する強い理由になるように思います。