2つのコンポーネントの乖離CSS設計において、コンポーネント設計に関することは、エンジニアを悩ませることのひとつです。このシリーズでは、現在の案件の中でエンジニアやデザイナーがコンポーネントをどのように考えているかを整理し、よりよい設計方法を考えていきます。次回このシリーズの記事一覧をみる目次はじめに呼び名はいろいろあれど多様なコンポーネントの「単位」どんなワークフローが理想?2つのコンポーネント感の食い違いはじめに「コンポーネント設計って、どうすれば最適解にたどり着く?」という話は、CodeGridでこれまで繰り返し取り上げてきたテーマです。ダイレクトにそのものは取り上げなくても、CSS設計に関わる記事は、その背景にサイトを構成する要素を、ある基準に沿った「まとまり」で考えることが背景にあります。近年、Vue.js、React、Angularなど主にWebアプリケーション開発のためのフレームワークにも、何らかの「まとまり」は常に意識されています。この座談会は、一意に「コンポーネント(まとまり)とは何か?」を定義するのが目的ではなく、実際の案件の中で我々はコンポーネントをどのように考えているか、どのように扱っているかを、自分たち自身で検証することを目的にしました。さん(以下、敬称略)にもご参加いただきました。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を叩かないといけなくなります。小さなコンポーネントを複数含むコンポーネントを設計すれば、大きなコンポーネントで取得したデータを、小さなコンポーネントに流してあればいい。すると、小さなコンポーネントはもらったデータの処理だけをすればよくなる。見た目とは別のデータの流れに注目したコンポーネントを想定しないといけないです。ことを最近考えてます。僕の今やっている案件だとAngularJS(1.x系)なんですけど、Reactとか、Vue.jsだとまた粒度が変わるのかな。そこが気になってます。devtools)っていうのがあって、それを使うとVueのコンポーネントにどんなデータが流し込まれているかが確認できるんですよ。コンポーネントが適切に分けられていれば、どんなデータが流し込まれているかわかるんです。devtools高津戸:あ、DevTool上でわかるんだ。コンポーネントが大きすぎると、そこに流された、まとまったデータしか見えなくて、末端にどういうデータが行き渡っているのかわからないので、デバッグしにくいんです。データが流される単位を考えるっていうのは、ひとつの重要なポイントですね。高津戸:複雑さを回避のためには、小さめの粒度でコンポーネントをつくって、それをコンテナするようなコンポーネントをつくったほうが便利だっていうことか。なんとでもできるじゃないですか(笑)。