コンポーネント指向開発とデザイナー×エンジニアの協業
喜多峻氏：今日は「コンポーネント指向開発とデザイナー×エンジニアの協業」ということでLTをさせていただきます。
まず自己紹介なんですが、名前はどうでもいいんですけれども、ドワンゴという会社から来ました。
Twitter（@Ln_north）のほか、弊社が運営しているマストドンのインスタンスであるfriends.nicoでも「@Ln_north」という名前でやっていますので、ぜひ遊んであげてください。
今日は高田さんにお誘いいただいたきっかけでもありますが、「ドワンゴ Advent Calendar 2017」で書いたこちらの記事（コンポーネント指向フロントエンド開発におけるデザイナーの参画について）をもとに、現在の内容も含めてアップデートをして、このスライドを作成しています。もし興味があればQiita記事を読んでみてください。
ここから本題の話に移ります。僕は2016年に新卒でドワンゴに入社して3年目になりました。ニコニコ生放送のHTML5化をやってました。その後「実験放送」というニコ生の実験的取り組みをやっています。
実はこの2つどっちも同じ技術スタックを使っていて、React.jsとAtomic Designや、SCSSとCSS Modules、そしてUI確認環境としてStorybookを使っています。
ドワンゴに入ってから2年半ぐらい、フロントエンド環境での開発でデザイナーとしてコミットしてきました。
今回話す3つのこと
スライドのテキストがちょっとエモい感じですけど、今日はこの3つについて話をしようかなと思います。
最初は「難所」の話です。Reactを使っているとよくある現象として、「コンポーネントにスタイルを含めると、コンポーネントの再利用性が下がる」という問題が1つ大きな課題としてありました。これはデザイナーが参画する上で調整が難しいところでした。
これについては、コンポーネントとスタイルをひとまとめにするのではなく、スタイルはコンポーネントに利用されるものと定義して分離できるようにしました。
次に、特徴的なのがスタイルの注入の仕方で、スタイルは決定される時点でrequireしています。
例えば、Atom時点だと、このコンポーネントではButtonという文脈しかないので、どういうスタイルかわからないと思いますが、Atomより具象的なMolecule層にいくと、どういうスタイルかわかるようになり、このわかった時点でrequireをします。
この先さらに親のコンポーネントでもスタイルの差し替えをできるようにしています。このような手法でスタイル都合で再利用できないという問題を基本的には回避しています。
エンジニアとデザイナーのどちらが責務を負うのか？
2つめは、「責務」の話です。すごく雑な図ですが、今の環境をシンプルに表したものです。
まず、よく出る話題として、このCSSを誰が書くか。エンジニアかデザイナーのどっちが書くかというのが1つの話題になると思います。
CSSはデザイナーのほうが見た目の振る舞いなので変更に対する関心が高いし、UIやビジュアルデザインに理解がないと意図どおりに書くのが難しいと思っていて、CSSはきちんと意図を書き下すと保守性が増すと考えています。それに、コーナーケースの判断はデザイナーがやりやすいというのもあるなどの理由で、弊チームでは今の所CSSはデザイナーが書いたほうが効率がよいだろうという結論になっています。
今回すごくお伝えしたいのが、このHTMLのところなんですけど、エンジニアからは、コンポーネントの設計の対象や、あとストアのデータの写像の対象としてHTMLに関心があって、デザイナーからは逆にCSSで利用するUI要素として関心があるという状態です。
ですので、HTMLがエンジニアとデザイナーの境界となって、非常にこの境界を意識することが開発を効率的に進める上で重要ってことがわかっています。もしよかったら先述したQiita記事を読んでみることをおすすめします。
心理的な障壁を減らす分担方法
ちょっと時間あるのでアニメーションの話をしますが、複雑なアニメーションを作ってデザイナーがエンジニアさんに丸投げすると実装コストが高く見えて敬遠されがち、ということが割とあると思います。
前述した責務分担であれば、こんな感じでエンジニアさんに状態だけHTMLの属性を通して渡してもらい、デザイナー側がにCSSでアニメーションを全部担当してしまい、アニメーションを全部こっちで持ちますよっていう話であれば、お互い心理的障壁が減って非常に取り組みやすくなったという例があります。
このスライドは時間がないので飛ばしますが、デザイナーとエンジニアで各必要な知識です。
あとからスライドは「ニコナレ」に公開していますので、ぜひ見てください。
Reactとスタイルのコンポーネントは一致しない
最後に「未来」の話です。現状作ってきてわかっているのが、たぶんReactのコンポーネントとスタイルのコンポーネントは合致しないということがわかってきてます。
詳しく説明します。まず、Atomic Designの各段階と抽象度の関係は、Atomのほうが汎用的、Templateにいけばいくほど具象的という状態です。
このスライドは先ほど出したものですが、われわれはスタイルをそのスタイルが決定される時点で注入しているので、このあたり（注：スライド内で線を引いた箇所）でコンテキストを持つので注入することになります。
ただ、このスタイルたちの上にはさらに抽象度の高い、例えばカラーパレットやフォントファミリー、フォントサイズ、マージン、グリッドなどがあると思うんですね。これらは共通化であったり別ファイルとしてくくりたくなると思うんですが、厳密にはコンポーネントのAtomic Designの粒度として取り込むのは難しいのではないかと考えています。
つまり、このコンポーネントのコンテキストが確定した状態で当たるスタイルも実際にはその手前にスタイルのコンテキストでの構造化があって、実際にはこのスライドのようなイメージじゃないかなと考えていて。ReactはReactのコンポーネントでAtomic Designの軸があって、スタイルはスタイルの軸でAtomic Designの軸があって。このスタイルにもライブラリ層があるんじゃないかということが弊チームではわかっています。
この設計を現在進行形で取り組んでいるのですが、非常に難しいです。ただ、ちゃんと実現できたらなより使いやすくなるだろうと思っています。コンポーネントやクラス名の設計はすでにReactのコンポーネント設計（Atomic Design）やCSS Modulesで解決されているため、BEMやECSSなどはあまり参考にしていないのですが、SMACSSやOOCSS、FLOCSSといったCSSのスタイル文脈の設計を参考にしつつ設計しています。あまり厳密にしすぎると身動きが取りづらくなったり、導入コストが高くなるので、明確に利便性が上がるところをエッセンシャルに取り入れようと努力していますが、そのバランスは難しいところです。
なくても良い境界は減らし、必要な境界はコミュニケーションを怠らない
後半はスタイル設計の話のようになってしまいましたが、一応まとめです。
デザイナーとエンジニアの協業について、この会社に入ってずっと協業して成果を出してきたわけですが、協業をする上で境界は必ずあると感じています。
その上で、なくてもいい境界を減らしていくこと、そして必要な境界においてのコミュニケーションを怠らないことが僕はとても重要だと考えています。境界を取り除く例としては、CSSをデザイナーで扱うことだったり、境界上の話だと、HTMLの話がありましたが、ちゃんと境界だとわかることによって、そしてそこでコミュニケーションを怠らないことによって、現在非常に開発がスムーズに進んでいると感じています。
最後に、まだコンポーネントの分割やAtomic Designの話はしなかったんですけど一応ノウハウはあるので、ぜひ懇親会でやりとりできればなと思います。あと、私事なのですが、僕結構友達が少なく割と懇親会が不安なので（笑）、ぜひお声がけいただければと思います。
以上で発表を終わります。ありがとうございました。
（会場拍手）
