はじめに

「コンポーネント設計って、どうすれば最適解にたどり着く？」という話は、CodeGridでこれまで繰り返し取り上げてきたテーマです。ダイレクトにそのものは取り上げなくても、CSS設計に関わる記事は、その背景にサイトを構成する要素を、ある基準に沿った「まとまり」で考えることが背景にあります。

また、近年、Vue.js、React、Angularなど主にWebアプリケーション開発のためのフレームワークにも、何らかの「まとまり」は常に意識されています。

この座談会は、一意に「コンポーネント（まとまり）とは何か？」を定義するのが目的ではなく、実際の案件の中で我々はコンポーネントをどのように考えているか、どのように扱っているかを、自分たち自身で検証することを目的にしました。

今回の座談会には、株式会社Gaji-Laboの代表取締役、原田直貴さん（以下、敬称略）にもご参加いただきました。Gaji-Laboは、主にCSSの設計や実装を得意とし、コンポーネントを意識した開発経験が豊富です。またクライアントとの開発プロセスを重視し、有機的なチームつくりも行っています。ピクセルグリッドの高津戸が、コンポーネント座談会ならぜひ原田さんをお呼びしたいと提案があり、実現しました。

そのほか、ピクセルグリッドの参加者は、次のとおりです。

• 高津戸 壮：フロントエンド・エンジニア
• 小山田 晃浩：フロントエンド・エンジニア
• 坂巻 翔大郎：フロントエンド・エンジニア
• 小原 司：UIデザイナー

さて、座談会はゆるゆると「コンポーネントとの馴れ初め」話から始まります。

（進行と構成：編集、外村奈津子） ※収録は2017年4月末に行われました

呼び名はいろいろあれど

——みなさんがコンポーネントを意識して制作し始めたのは、いつ頃ですか？

高津戸：前職ではコーポレートサイトをたくさんつくってたんですね。そのサイトでよく登場するUIのパターンを、その職場では「エレメント」って呼んでいたんです。そのエレメントをCMSで積んでいってページをつくるというやり方をしてました。そんなこんなで、そういうコンポーネント？的な設計というのはずっと昔からやっていますね。

小山田：BA（株式会社ビジネス・アーキテクツ）がモジュール的な概念で設計したのが、業界内では有名だったように記憶しています。

原田：そのBAのモジュールという概念が「すごい」と話題になったのは覚えています。確か、2003年頃だと思います。それから各社が「俺たちの考えるモジュール、エレメント、コンポーネント」という解釈が始まっていたのではないかという気がしてます。

小山田：僕も前職でそういうのをやりたかったんだけれど、会社の方向性がデザインに特化している会社だったので、なかなか会社に「コンポーネント」っていう概念が伝わりづらくて。

原田：たぶん歴史が何百回繰り返されても、CMSを使うか、たくさんの会社が連携してページを量産するっていう流れになれば、コンポーネントっていう考え方は、絶対に外せないもの。そういう意味では、特定の誰かによって考え出された概念っていうよりは、みんなによって自然に編み出されたやり方かなあとは思いますね。

小山田：Dreamweaver（アドビシステムズが販売しているWebオーサリングツール）にも、昔から「ライブラリ」っていう機能があるんですよ。それもコンポーネントに近い概念だったと思うんです。ライブラリに何かを登録すると、全ページでそれが共有される。

多様なコンポーネントの「単位」

——その頃の成果物っていうのは、SPAみたいなものではなかったんですよね？

原田：そうですね。HTMLとCSSでつくる静的なサイトです。でも、おそらくその頃からCSSを書いていた人に共通する思いであったと思うんですけど。最近「コンポーネント思考」っていう話が出てますけど、根っこの部分にあるのは、10年前の話と何も変わってないなと。

それをどういう技術に合わせるかで、微調整しなければいけないと思うんですけど、影響する要素が増えてきたのでコンポーネント設計の難易度が上がってきているというのが、現在じゃないでしょうか。

だから、変わっているといえば、変わっているし、超難しくなったといえば、超難しくなったともいえる。

——昔よりも、今のサイトのほうが勘案しなければならない要素が増えてきているってことですか。

小山田：うーん、どっちもどっちかなあ。CSSも機能が増えて、設計がやりやすくなったといえばなりましたけど、求められていることもそれだけ複雑になってきました。静的サイトであれば、要素の中に入るものって、だいたい決まっていたんですよ。でも、今のコンポーネントってJavaScriptと組み合わせるのが前提なことがけっこう多い。

高津戸：基本的な考え方が昔から変わらないっていうのはそのとおり。違いのひとつはCSSの設計方法論っていうのがいろいろ出てきて、BEMなどの考え方*が一般的に広まってきたというのはあります。

*注：BEMの設計方法

BEMの設計方法については、「BEMによるフロントエンドの設計」のシリーズで詳しく解説しています。

もうひとつ、SPAのUIはJavaScriptのフレームワークに組み込まれることが前提になることが多い。そうなると、CSSで考えているコンポーネントの単位というのと、アプリケーションの設計として捉えるべきコンポーネントの単位っていうのが発生しているのかなと思います。

原田：アプリーケーションっていうより、インターフェースとしての単位かな。アプリケーションという言い方をしてしまうと、全体でざっくりいけばいいじゃんという考え方になってしまう。重要なのは、GUIがどれだけ整って設計されているかっていうところで、そこに全体が引っ張られていく。だからCSS設計というよりは、GUI設計なのかなと思います。

——デザイナーさんはコンポーネントを意識していますか？

小原：いわゆる「コンポーネント」っていうのは、よほど技術と距離が近い人でないと、そんなに意識してないとは思います。ただ、デザインの基礎には「情報を相手に伝わりやすいように整頓していく」という段階があって、余白や密度を調節することで見えない線を引いて要素のグループをつくっていきます。

だから、コンポーネントを意識してなくても、普通にデザインをやっていると自動的にコンポーネントのようなものをつくっているという側面はあります。

どんなワークフローが理想？

——コンポーネントの単位についてはいくつか意見が出ましたが、それではそれはだれが切っていくものなのでしょうか。

原田：大規模なサイトでいうと、そのワークフローであるべき姿というのは、IA（インフォメーション・アーキテクト）がきちんといて、グラフィックやCI（コーポレート・アイデンティティ）を起こす前に、情報として分解していって、それがワイヤーフレームなり、コンテンツのインベントリとしてどう扱うか共通化の設計はされているという状態かな。

そこにインターフェースとしての使いやすさとグラフィックとしての見やすさが当てられるなら、情報設計がきちんとされているので、コーディングはそれに合わせてコンポーネントを切っていけばいいだけです。たぶん、上から突き詰めて流れる滝のようにやっていく仕事であったら、コンポーネントの設計はIAか、もしくはインターフェースデザイナーの仕事だと思っています。

——なるほど。理想は、ということですね。

原田：昔のサイトは、コンポーネントを1回決めてしまっても、流用可能だったら前につくったインターフェースを、見た目を変えて次の案件に使い回せたんです。なので、気が付いたらマークアップを手がける人たちがコンポーネントを切っていた状態になっていたというのが、現在のフローについての僕の理解なんですね。だからやるべき人がやっている状況とちょっと違うなと思っています。

——現在のSPAではどうでしょう。

原田：IAにそれをやらせるのは無理かなと思っているんです。なぜならインターフェースをつくる上で、さっきよもつさん（小山田）がいっていた「データをどう食わせるか」みたいな話になってくる。

——コンポーネントとJavaScriptと組み合わせ方ですね。

原田：カリカリのチューニングをするなら、どのデータをどのタイミングで引っ張ってこれるか、またどのデータをどこでキャッシュするのか、どのようにやれば、サーバーサイドレンダリングとフロントエンドの構築でうまく連携するかみたいなこと考え始めます。そうすると、けっこうGUIに対して制約が入り始めるんです。本来、それを乗り越えてチューニングするのがエンジニアリングの仕事だとは思うんですけど。期間の制約があると諦めざるをえないって話になると、理想像を描けたとしても、それを破壊せざるをえないところが出てきたりする。

そうすると、エンジニアで調整してインターフェースを決めていくって形になるので、相互の戻しの回数がすごく増えたっていうのがありますね。しかもそのコミュニケーションルールが存在してないから、最終的に誰も納得しない形で落ち着いちゃうのかな。

小原：SPAのデザインをやっていると、それはすごく感じますね。UIの状態がどんどん変わっていくものなので、どのタイミングでAPIを叩いてデータを持ってきているか、あるいはそれがキャッシュされて使い回せる状態になっているか想像していないと、うまく画面の状態を切り替えていくというデザインができない。

小山田：見た目のコンポーネントの単位のほかに、もうひとつデータの流れを考えないといけない。たとえば、大きなオブジェクトをひとつのコンポーネントにしちゃうと、そのコンポーネントは全部のAPIを叩かないといけなくなります。けれど、小さなコンポーネントを複数含むコンポーネントを設計すれば、大きなコンポーネントで取得したデータを、小さなコンポーネントに流してあればいい。そうすると、小さなコンポーネントはもらったデータの処理だけをすればよくなる。つまり、見た目とは別のデータの流れに注目したコンポーネントを想定しないといけないです。

2つのコンポーネント感の食い違い

高津戸：そのあたりのコンポーネントの粒度感って、けっこうフレームワークによって違うのだろうか？ ってことを最近考えてます。僕の今やっている案件だとAngularJS（1.x系）なんですけど、Reactとか、Vue.jsだとまた粒度が変わるのかな。そこが気になってます。

小山田：自分の場合はVue.jsを案件でやることが多いんですけど、VueのDevTool（Vue.js devtools）っていうのがあって、それを使うとVueのコンポーネントにどんなデータが流し込まれているかが確認できるんですよ。だから、コンポーネントが適切に分けられていれば、どんなデータが流し込まれているかわかるんです。

高津戸：あ、DevTool上でわかるんだ。

小山田：そうそう。でも、コンポーネントが大きすぎると、そこに流された、まとまったデータしか見えなくて、末端にどういうデータが行き渡っているのかわからないので、デバッグしにくいんです。なので、データが流される単位を考えるっていうのは、ひとつの重要なポイントですね。

高津戸：複雑さを回避のためには、小さめの粒度でコンポーネントをつくって、それをコンテナするようなコンポーネントをつくったほうが便利だっていうことか。

小山田：そうですね。

高津戸：そういう場合、CSSってどう書いているの？ なんとでもできるじゃないですか（笑）。

小山田：そうそう。できるできる。そこが悩みどころなんです。見た目のコンポーネントとデータの流れのコンポーネントが違うから。

高津戸：僕がやっている案件だと、それが食い違ってしまうところに苦しみを覚えていて。昔のバージョンのAngularJSだとコンポーネントって言わないんですけど、いわゆるこのコントローラーやディレクティブといわれるものの中で書かれているHTMLがあるんですよ。

HTML単位っていうのはボタンだとか、いろんな塊をコンポーネントっていっているんですけど、それがめっちゃ集まったものがAngularJS上でコンポーネントの単位になっていると、もうわけがわからんっていうか（笑）。複雑すぎて。Webアプリ上のUIとしてのコンポーネントと、HTMLテンプレートで定義した塊をコンポーネントとして考えると、それが食い違ってしまうところが苦しい。

小山田：うん、2軸はありますね。

高津戸：そう。そんな状態だと、もうCSS怖くて触れない（笑）。ECSSとかだと*、機能単位で切って、ほかに干渉しないようにしたほうがやりやすいぜ、ってことになっていて、それはなるほどねと思います。よもつ案件ではそういうやり方じゃなかったってことですね。

*注：ECSSの設計思想

高津戸が発言しているECSSの設計思想については、「Enduring CSSの設計思想」のシリーズで詳しく解説しています。

小山田：それが僕の失敗。

全員：（笑）

小山田：大きなコンポーネントにしちゃってたから、あの時もっと細かくしておけばよかったなと思ってます。見た目のコンポーネントに依存してつくったら、大きすぎてデバッグがしにくかった。でっかいテーブル（表）をひとつのコンポーネントにしたんですけど、そのテーブルに流されていたデータが膨大で、1列ずつデバッグできるように設計すべきだった。

高津戸：あー、見た目としては表はひとつのものだから、BEMでいうとBlockにしたんだけど、だめだったってことか。

小原：要件ありきですね。つくろうとするテーブルがシンプルなデータ表示だけに使われるのであれば、テーブル全体がひとつのコンポーネントでもいい。そのあたりがコンポーネントを切る人の裁量だね。

——それは途中で変更はできないものですか？

小山田：変えようと思えば変えられるけど。

高津戸：大手術ですね。

小山田：動いているものにわざわざ手をつけるっていうことだから。

原田：テストがどれだけ書けているかって話にも。

高津戸：新規につくるものだったらいいんですけど、いったん公開されたものだったりすると、バグが発生する可能性がすごく高くなります。だから、コンポーネント感が食い違ったまま運用していかなくてはならない。

——なかなか難問ですね。

（続く）