ReactとAtomicDesignから考える、コンポーネント開発の今

会社によって異なる開発のプロセス

司会者：それではこれからトークセッションに入らせていただきます。では、石橋さん、よろしくお願いします。

石橋啓太氏（以下、石橋）：ここからは、登壇していただいたお2人と自分で、ざっくりと雑談的な感じでやりたいと思います。

自分が気になっていることとか聞きたいこともあるので、まずは3人のそれぞれの会社で、今日お話にあったコンポーネント開発みたいなところをどれぐらいやっているのかを聞きたいんですが、どうですか？　じゃあ吉竹さんから。

吉竹遼氏（以下、吉竹）：じゃあ僕から。僕はデザイナー、しかもクライアントワークが中心なんですね。事業会社に所属しているわけではないので、そのタイミングタイミングで組む人が違うということがあります。

組む人が違うと、それこそコミュニケーションとかやりとりに使われるフローとかプロセスも全部違ったりするので、毎回AdobeInDesignをインストールしてどうこう、というようなことは、正直そんなになくてですね。

どっちかというと、デザインのデータを開発側と共有するとき、例えば「このアプリはこういうコンポーネントを使っています。そのコンポーネントはこういう要素で構成されています」みたいなものをちゃんとガイドラインとして定義してあげて、それをエンジニアさんと共有して。

そこで「これを参考にして実装してください」というコミュニケーションに、そのコンポーネントの部分を使っているという感じですね。ざっくり言うと。

コンポーネントで開発するのが普通になってきた

堀川豊氏（以下、堀川）：私の場合は、今は管理画面とかを作っているんですが、私1人で実装していて、デザイナーさんとかもついていないんですね。

既存のVue.jsのElementというコンポーネントのライブラリを使っているんですが、それを組み合わせてなんとなくそれっぽいUIを作っていて。いろんなページで共通部分として切り出せそうなところをコンポーネントとして切り出していく感じなので、がっつりとはやってないですね。

石橋：自分も、ちょうど今やっている案件はデザイナーが不在なんですよ。今の堀川さんのお話とほぼほぼ同じような感じでやってます。

DMM自体はいろんな事業部があってけっこうバラバラにやっているんですが、実装の話をすると、ほぼ会社全体でコンポーネント系のライブラリというかフレームワークを使って開発している、と言ってもいい感じじゃないかとは感じています。

おもしろい話があって。この間、社内の人員公募みたいなものが出てたんですが、いわゆる情シス、備品管理とか社内のそういったものを包括的に管理してくれてる部署で、ReactかVueの開発経験ある人の募集が出てたんですよ（笑）。

吉竹：すごいですね（笑）。

石橋：それぐらい今はもう、そういうものを使って、コンポーネントみたいな考え方でWebを作っていくのはもう普通という意識が、エンジニアには求められているのかなと感じたんです。

ひたすら書いて改革した

吉竹：社内がそういう意識に移行している感じなんですか？

石橋：弊社ですか？　そうですね、もともとそういうものを布教する人たちがけっこういて、少しずつ「今まではそうじゃなかったけど、どんどん変えていこうよ。そっちのほうがきっといいから」というかたちでやっていた影響は、かなり大きいと思うんですよね。

堀川：その布教活動は、どうやって広めていったんですか？

石橋：書いちゃう（笑）。

堀川：ああ、もう乗り込んで書いていくという。

石橋：そうですね。黒船襲来みたいな（笑）。

吉竹：何年ぐらいかかりました？　何ヶ月？

石橋：僕がReactを実際に書き始めたのがたぶん2年前ぐらいなんですよね。ほぼ同じぐらいのタイミングで「UIの構築部分をもうちょっとシステマチックにやっていったほうがいいんじゃないか？」みたいな意識が徐々に来たような気がしますね。

堀川さんのところは、最初からそういう感じで進んでいたりとかするんですか？　

堀川：うちの場合は、そんなに計画的にという感じじゃなくて、そもそも専任のWebフロントエンジニアってほぼいないんです。Webできる方は1人いらっしゃいますが、本当その方ぐらい。

あとは今Vue.jsを使っているんですけど、それもCTOがなんとなく使っていたからという理由だけでそのまま使い続けているので、そこに関しては本当になんの方針もなく、戦略的になにかやっているということはないです。

石橋：みんなでも、もう勢いでどんどんやっちゃってる雰囲気はあるんですか？　あと今日話したかったことが、抽象化みたいなテーマ、抽象的にUIを考えていきましょうみたいなものが今多いのかなと思っていて、そのへんのお二方の考えが気になっているんですよね。

UIを抽象化しようというムーブメントが起きている

堀川：抽象化？

石橋：実装を抽象的にやっていきましょうというのもあるし、UIデザイン面もそういった概念を入れていきましょうみたいなものが、同時多発的にある気がしていて。

堀川：そうですよね。実装の部分でいうと、デザイナーさんがいる場合は、デザイナーさんにもらったUIから、Reactだったらどの部分をどういうふうにコンポーネントに切っていくかというところで、UIを抽象的に組み立てていくのかなと思うんですが。

個人的には、Reactを1回触ってからは、UI組むときはもうそういうふうに考えるようになってますね。どこをどういうふうに抽象化して、どういう感じで再利用できるかたちにしていくか、というような。

そこまで考えない場合もあるんですが、そういうときも、抽象化するというか、コンポーネント化するときの方針はチームで決めた上で進めるようにはしています。

吉竹：基本的に、デザインって、わりと開発のほうのムーブメントの後追いかなと僕は思っていて。とくにデザインの話でいくと、ツールの影響は大きいと思っています。個人的にSketchの登場はでかかったと思っていて、シンボルというものが作れるんですよ。簡単に言うとインスタンスが作れるデザインコンポーネントみたいなものなんですけど。

インスタンスを利用して、例えばそれをさらに入れ子にしていろいろコンポーネントを作っていく。そういう、構造的にUIを作れるとか、再利用できるデータとしてUIのパーツを見ていく視点が、Sketchで常装されたかなと思っています。

なので、僕も実はコンポーネント指向みたいなものに目覚めたのはここ3〜4年なんですよね。Sketchのおかげでそういう意識に目覚められたということはあります。

マテリアルデザインはデザイン界を席巻するか？

石橋：実装だと、今堀川さんの話にあったElementというUIのライブラリがあって。それはコンポーネントとしてもうできあがっているので、そのまま読み込むともう描画ができちゃう。

フロントエンド実装の世界ではそういうものが今いくつも出てるんですが、デザインの中でも今Sketchがあって、そういう感じでデザインが作れるようになってきてるじゃないですか。デザインは、そういう公開されているものってなにかあるんですか？

吉竹：いわゆるSketchのテンプレートデータとかでそういうものを学ぶみたいな感じはあります。ただ、それ以上なにか特殊なものがあるかというと、なにかしら定義されたものがあるという雰囲気はまだないかな。

例えるとしたら、InVisionが今Design System Managerというプラグインのβ版を出していますが、ああいうものとかかな。

石橋：なるほど。デザインシステムみたいな話がガーって来たあとに。まぁその前にマテリアルデザインがあったと思うんです。僕はけっこう、マテリアルデザインがもう、こういう話をしているときの現時点での王者みたいな存在になっている気がしていて。

あれってもう実装ベースのものも提供されていますし、デザインとしてのガイドラインもわりとしっかりしているじゃないですか。Googleのプロダクトの中ではすでにけっこう利用されている。この間もGmailが変わりましたよね。

吉竹：変わりました。

石橋：実績もあるし、かなり完成度の高いものになっているんじゃないかと。なので、もし今みたいな感じで、例えばAlibabaみたいな大きいところとかが似たようなものをどんどん出してきたら、わりとそれを使う側になってしまうかなとは思っている。

アプリのデザインはOSに左右されてしまう

この間ちょっと堀川さんと話してたんですが、すでに提供されているそういうUIライブラリに、デザインがどうしても引っ張られちゃうじゃないですか。だから、仕組みはそういうライブラリからもらって、見た目は自分でもっと自由にカスタムできれば、もう今日からプロダクションでも使えるのかなという。

堀川：確かに。

吉竹：僕はデザイン、デザインシステムの言葉を使っちゃいますけど、公開されているデザインシステムを使うときの一番の難点って、Webとアプリの違いだと思うんです。

例えばアプリでマテリアルデザインを使うとき、Androidのアプリを構築するときはけっこう有効だと思うんです。Androidというプラットフォームの中で提供されている、推奨されているものなので。でも、それをiOSに適用するのはまたけっこう「うーん」ってなったりするんですよね。iOSはiOSでHIGがあったりするので。

そうなると、デザインシステムとか、自分たちのプロダクトのトンマナを優先するのか、そういうシステムに乗っかっていくのかというのもわりとそのマナー、アプリ側に寄っている気がする。

Web側は逆にある意味なんでもできるというか適用しやすい環境なので、マテリアルデザインが出てきたときに、全部そっちに行っちゃうと、実際それを使ったときに「これが自分たちがやりたかったことなんだっけ？」ってなるかなと。さっき言った「拝借して、でも変えるところは変えていく」がちゃんと仕組み化できると、かなりよくなっていく感じがしますね。

UIライブラリにデザイナーは対抗すべきか？

石橋：僕は、実装の部分と最終的にできあがる部分が今はどうしても結合しちゃっている。しいて言えば、実現したいデザインも結合されちゃっているのが今のUIライブラリなのかなという気はしているんです。本当はもっと分離したい。

堀川：振る舞いと見た目の部分を分離して、振る舞いの部分だけ進めるみたいな。

石橋：そうです。僕らが描きたくないところは、すでに優秀なすごいエンジニアが作っているものを使って、そこでなにをしたいかだけスクラッチで書けるみたいな。

それの最終形に行こうとしているのは、今いろいろがんばっているWeb Componentsとか、あのへんの仕様が関わってきたりするのかなと思っています。まぁ今アプリとWebの話をするとややこしいですけどね。

吉竹：（笑）。

石橋：あとはUIライブラリ。でも今実際に使っていらっしゃるんですよね？　どうですか？

堀川：やっぱり楽です。細かいことは考えなくていいのがいいですね。見た目もある程度揃えられるので、コンポーネントを組み合わせればそれっぽいUIができあがってしまう。とくにエンジニアにとってはすごく楽な手法かなと思いますね。

石橋：自分もけっこう使うんですが、そうなってくるとデザイン側はどう対抗していけばいいのかとは思います。僕は今けっこうコードを書いてるのでエンジニア的な側面で見てるんですが、デザイナーはどう感じているのかな、みたいな。

吉竹：そこは線引き次第かなという感じはします。ある程度、管理画面とかそういうところはすばやく構築しようとか、でも実際にユーザーに触れるところのプロダクトの部分はどうしていこうか、とかはやっぱり悩む。

結局ユーザーの目に触れるのはコンテンツ

吉竹：昔Windows 8という懐かしいものがあったときに、MetroUIというものがあったんですね。マテリアルデザインとかもそうですけど、MetroUIのコンセプトって実は「コンテンツをがんばる」だったんです。

つまり、UIとかは自分たちがプラットフォームでちゃんと使えるものを提供しているから、あなたたちは中身の質をちゃんとやりなさい、担保しなさいというコンセプトだった。まぁ見事にコケたんですけど。

あの思想って、賛否両論あると思いつつ個人的には肯定していて。やっぱり、実際ユーザーの目に触れるのはコンテンツだから。UIをめっちゃ作り込んで、でも実際のコンテンツの構造や設計をどう届けるかがおざなりになったら、あんまり意味がないと思っていて。そこは線引き次第かなという気がしています。

石橋：そういう意味では、アプリの開発ってそういう側面があるじゃないですか。もうわりと用意されていて、それを使ってどんどんアプリを構築してもらうという。僕はわりとそれ羨ましいなと思っていて。Webはそれがない、ある意味自由なのがつらいところじゃないですか？

堀川：逆にいっぱいありますからね。どれ選んだらいいんだろうって迷う。

石橋：そこで今、1つ飛び抜けているのがさっき言ったマテリアルデザインみたいな部分かなとは思っている。それが発展していくとPWAの話とかに行き着くのかなと思っていて。

吉竹：ちなみにVRの世界は、もうそういう流れとかものって登場してるんですか？

石橋：Mozillaがフレームワークを出していますね。A-Frameというフレームワークがある。MozillaはVRに力を入れているみたいで、「A-Frame」って検索して公式サイトに行くと、もうWebVRでブラウザでVRができる。

Reactを利用してコンテンツ開発できる環境が登場してきた

石橋：まぁでも、まだかなり研究段階だと思いますね。（React360を）実際触ってみてどうでしたか？

堀川：さっきの発表の中でも言ったんですが、もう本当にReactをやってたらすぐコンテンツ開発できる敷居の低さはすごくいい、すごく魅力的だとは思いましたね。ただ、やっぱり3Dを扱うものなので、3D周りの知識とかは必須かなと思いますが、そこは後追いで覚えられますし、とっかかりが低いというのはいいですね。

吉竹：すみません、個人的に気になったんですけど、僕はあんまりコードを書かない人間なんですが、360を先に勉強するといわゆるWebとかReactのほうもなんとなくわかったりするんですか？

堀川：わかると思います。基本的に、UIを構築していくための概念としてはほぼ一緒なんですよね。あれをやればWebのほうにも活きてくるとは思います。

吉竹：ちょっと練習したいと思います。

石橋：僕はけっこうVRが好きなんですけど、最初React VRが出たとき、いわゆる僕らの知ってる知識でVRが作れるのかってワクワクして。そうなると、3Dの世界ってモデリングされた物体があるじゃないですか。例えばテーブルだったりテレビだったり。それをHTMLでどう表現するんだろうって。おもしろいなと思って。

堀川：それでいうと360は、そういう3Dのモデルは外部のモデリングツールで作ったものを読み込む。

石橋：そのまま読む？　ああ、なるほど。昔、人間の身体をHTMLで定義するみたいなネタがあって、身体のどの部分にどのタグが一番適しているかみたいな（笑）。その文脈でVRの立体もマークアップできるのかなってワクワクしたんですけど、そんなことはないみたいですね。

堀川：それは普通に外部で作ったのを読み込む。

Atomic Designの評価は今後どうなるか？

石橋：でも、イベントとかをアタッチするわけですから、多少は似たような文脈も発生するんですかね？

堀川：そうですね。イベントのアタッチの仕方とかは一緒です。attributeにイベントのハンドラーを定義していくところは一緒。

石橋：そうなってくると「UIとはなんなのか？」みたいな感じになる（笑）。

吉竹：急に深い話題に入ってきましたね（笑）。UIとはなんなのか。

石橋：でも、VRの世界にAtomic Designがどう反映されるのかとか、そのへんはけっこうおもしろい話題なのかなって思いますね。

吉竹：新しい概念というか、また別のレベルが出てきそうだなという感じはしますよね。次元が1個変わったり、空間、時間とか。

石橋：確かに。実際Atomic Designって、最初に話が出たのはもう何年も昔じゃないですか。でもみんながそれを知って実務とかでいろいろ試した結果、今日お話もあったように「ちょっと違う尺度のもので考えたほうが……」という流れが出てきている。ここから3年とか5年が経ったときに、どういう認識になっているのかなというのは、自分はUIデザインとかやっていたのでかなり興味あるんですよね。

吉竹：Atomic Designって、言葉を作っちゃったのがずるいなと思ったんです。「Atomic Designです」って言って「Atomsがあって、Moleculesがあって……」という言葉をオラッって出して。それまでもモジュールとかそういう話はありましたけど、もうちょっと腑に落ちるものが出てきちゃった。

でも微妙に使いづらいという話が出てきたときに、あれをアップデートしづらいのは1個難点だと思ってます。「早くブラッドさんアップデートしてよ」と思っているんですけど、ブラッドさんはブラッドさんで「あの化学方式が俺には合ってるんだ」って言って、とくに新しくしようとしてないんですよね。もうちょっとがんばってほしい（笑）。

Atomic Designはコンポーネント指向を認知させるための名前だった

堀川：今でもあの方1人で設計されているということですか？

吉竹：そうですね。たぶんされていると思います。

石橋：フリーランスの方でしたっけ？

吉竹：そうです。なので、クライアントワークでやっているらしいです。

石橋：あれがなんかバーンと出ちゃったせいで、日本国内の現場もけっこう混乱しているというか。僕も調子乗ってAtomic Designを本のタイトルとかにも入れちゃったんですけど、でも「実際Atomic Designってどうなの？」みたいな話をすると、案外ふわっとしている。もうちょっとアカデミックな感じでなにか書こうと思っても、意外とカチッとしたものが書けなくて、現場でふにゃふにゃと変わっていく概念なのかなと。

吉竹：今振り返ると、コンポーネント指向的なものを流行らせる、認知させるための言葉だったのかなと思います。とくにエンジニアじゃない人なんかは、Atomic Designから「そういうふうにものを考えるんだ」となったりもするのかなと。

この間おもしろい記事を読んだんです。Atomic Designの思想でイラストレーションを作るという。人の身体、着てる服、アクセサリー、というふうにAtomsとかに分解して、それでイラストレーションを管理して再現性のあるイラストを作るという話で。そういうふうに使っている人もいるんだというのはおもしろかったですね。

デザインの設計でエンジニアとデザイナーが接続された

堀川：あと、コンポーネント開発という展開の上だと、コンポーネントを設計するにあたって、1個の指針になっている感じはします。今までは、どういう考え方でコンポーネントを組み立てていきましょうという、考え方のフレームワークみたいなもので、目立ったものはなかったので。

石橋：そうですね。出てきた中でPrinciplesってあったじゃないですか。あれってぜんぜん新しいものじゃなくて、昔からデザイン制作会社とか行ってる人ならわかると思うんですけど、別に普通にやることなんですよね。

でも、そういう指標はあるけど、じゃあエンジニアがそれを実装するときにどうピックアップすればいいのかというと、今までそこはプツッと分かれていたと思うんです。でも、こういうデザインの設計みたいなものをしていくと、すんなりプロダクトに反映できるかなというのは感じます。

というか、僕、Principlesって名前がけっこう好きなんです（笑）。

吉竹：いいですよね（笑）。ちょっと話が逸れちゃうんですけど、Principlesって、デザインシステムの話が関わってくるととくにそうなんですが、「自分たちはなにをやるのか？」とか「自分たちが目指すものはなにか？」「大切にしているものはなにか？」を具体的に話していくんですね。

それこそAtomsは「自分たちのプロダクトはどういう言葉遣いで、それはなぜか？」というような、サービスの性格付けまで厳密にやっていて。とくにAtlassianとかそうなんですよね。「なんで私はこういう言葉遣いなのか？」とかを厳密に定義している。

実はそういうことって長期的にプロダクトづくりを見ると大事なんです。チームがスケールとかしたときに「こことここの言葉遣いぜんぜん違うんだけど？」みたいな、そういうときはPrinciplesが役に立っていたりしますね。

石橋：現場だと言葉がかなり大事ですよね。

堀川：めちゃくちゃ大事です（笑）。

石橋：そろそろ時間ですかね。けっこうおもしろい話もあったと思うので、興味ある方はこのあとの交流会で、直接登壇者に声かけてください。

司会者：では、お話が盛り上がったところですが、時間になりましたのでここらへんでいったん終わりにさせていただければと思います。みなさま、どうもありがとうございました。

（会場拍手）