いまどきのコンポーネント設計をめぐる座談会 第1回 2つのコンポーネントの乖離

CSS設計において、コンポーネント設計に関することは、エンジニアを悩ませることのひとつです。このシリーズでは、現在の案件の中でエンジニアやデザイナーがコンポーネントをどのように考えているかを整理し、よりよい設計方法を考えていきます。

発行

  • 高津戸 壮
  • 小山田 晃浩
  • 外村 奈津子
  • 小原 司
  • 坂巻 翔大郎
いまどきのコンポーネント設計をめぐる座談会 シリーズの記事一覧

はじめに

「コンポーネント設計って、どうすれば最適解にたどり着く?」という話は、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にしたんだけど、だめだったってことか。

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

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

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

高津戸:大手術ですね。

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

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

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

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

(続く)

高津戸 壮
PixelGrid Inc.
テクニカルディレクター

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

小山田 晃浩
PixelGrid Inc.
フロントエンド・エンジニア

2006年よりWeb制作会社にてUI実装や運用業務を経験した後、2010年よりフロントエンド・エンジニアとして株式会社ピクセルグリッドに入社。これまでの経験の大半は大規模Webサイトの壊れにくいHTML/CSS設計、及び実装。また、SVG, Canvas, WebGLの扱いも得意としている。 外部に向けたアウトプットも積極的に行っており、カンファレンスでの講演などを多数こなしている。Tokyo WebGL Meetupの主催者。2011年から2021年まで10連続でMicrosoft MVP(Developer Technologies)を受賞。 著書に『Webデザイナー/コーダーのための HTML5コーディング入門』(共著:エクスナレッジ、2011年3月12日)や『CSS3デザイン プロフェッショナルガイド』(共著:毎日コミュニケーションズ、2011年5月28日)』などがある。

外村 奈津子
PixelGrid Inc.
編集

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。

小原 司
PixelGrid Inc.
UIデザイナー

紙媒体をメインに制作しているデザイン事務所で広告デザインの基礎を学ぶ。2000年に独立。化粧品関連媒体の販促物を中心に、店頭グラフィック、パッケージ、POP、グッズ立案など多岐にわたるデザインを担当。2007年頃からWeb媒体へのデザインにも積極的に取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。2013年にピクセルグリッドに入社。現在では利用者にストレスを与えず迷わないユーザーインターフェースの設計とデザインに励んでいる。 著書に『ノンデザイナーズ・デザインブック[第4版]』(日本語版補足解説:マイナビ出版、2016年6月30日)などがある。また、マンセル色相環とムーン&スペンサー配色理論を採用した配色アプリ『HUE360』を1人でデザインから開発まで行い公開している。

坂巻 翔大郎
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、Web制作会社などで、マークアップエンジニア、プログラマ、サービス企画、ディレクターを経験。2013年、株式会社ピクセルグリッドに入社。HTML、CSS、JavaScriptなどをオールラウンドに担当。とりわけ、プログラマブルなCSSの設計、実装を得意とする。 趣味で作成したゲーム「CSS PANIC」は、JavaScriptを一切使わず、HTMLとCSSのみで実装。海外サイトで紹介されるなど話題となった。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます