CLOSE

パネルディスカッション〜各社の取り組みのここが気になる!(全2記事)

デザインシステム開発と事業開発のバランスをどう取るか? hey×note×アンドパッド、それぞれの課題と工夫

「Frontend Talk」は、ヘイ株式会社とnote株式会社と株式会社アンドパッドが合同で開催する Frontend Engineer と Designer 向けオンラインイベントです。今回のトークテーマは「デザインシステム構築のリアルな裏側」パネルディスカッションでは、各社の取り組みで気になる点について話しました。全2回。後半は、他のプロダクト開発とデザインシステム開発を同時に進めていくことでのバッティングやコンフリクトについて。前回はこちら。

複数プロダクトを持つhey社の工夫

鳩洋子氏(以下、鳩):パネルディスカッションなので、各社向けの質問をお互いにしたいなと思っています。それでは、noteの沢登さん。他の企業の方に質問はありますか。

沢登達也氏(以下、沢登):そうですね。noteは1プロダクトしかないのですが、複数プロダクトを抱えているheyさんの工夫を教えていただきたいです。

藤井大祐氏(以下、藤井):そうですね。まずエンジニアの話からいくと。変更差分をどこまで対応したかというのが、先ほどお話しした、バージョン管理を親Issueと各プロダクトでIssueを切って、それを週1で同期を取っていくかたちです。

構築段階では、リテールのプロダクトが先にデザインシステムを入れたので、「このコンポーネントはリテールでしか使わないのでは」みたいなものとか。そこの毛色が最初の頃だと入っていたというのが課題感としてありましたね。

議論していく中で、「このコンポーネントを他のプロダクトで使うのか」とか、「どこまで責務を持たせるのか」みたいな話は、他のプロダクトを横断的に合意を取りながら進めないとけっこう難しいと思っています。これは、井出さんにも聞いてみたいですね。

井出優太氏(以下、井出):そうですね。難しいのは、やはり同じようなユーザーに使われはするんですが、結局使われる環境が違ったり、使うチームの規模や場所だったりもぜんぜん違うので、どこまでローカルな仕組みを、その環境や顧客に合わせて持つかというところは、各プロダクトを触りながらじゃないとやっぱりわかりません。

デザインシステムだけを触っていてもわからないところを、プロダクトに入り込んで一緒にプロジェクトを回しながらアップデートしていくというのは、けっこう気をつけてやっていますね。

結局抽象化されて、こういうテーブルや、リストというふうに作ってはいくのですが、かなりロジカルに作らないと、「なんでこうなっているの?」みたいなことをすごく言われてしまう。それは当たり前というか、そこの事業から見たらそうじゃないほうが適切、みたいなことがすごくある。

自分自身でも、「これを使うと、ちょっとここを妥協しなきゃいけない」みたいなのはあるので。そういうのを伝えていくためにも、本当に細かいところまで言語化できるように、他社の調査をすごくやって、コンポーネント1つに対しても設計思想を持って作るということを意識してやっていますね。

沢登:ありがとうございます。

:ありがとうございます。アンドパッドも複数プロダクトあるのでわかりみが深すぎる話だなと思いました。

技術のアップデートとデザインシステムプロジェクトの同時進行の難しさ

:次は、アンドパッドの小泉さん。質問はありますか。

小泉佑太郎氏(以下、小泉):はい。noteさんは、数年前に大規模なNuxt化への刷新を行っていたり、技術的な面でもけっこう進んでいる印象がフロントエンド的に強いんです。そういった技術面のアップデートと、デザインシステムを同時に進めていくことでのバッティングやコンフリクトみたいなものの難しさはありましたか。

uto-usui(以下、usui):スライドの中でも少し話したのですが、「Nuxtに移行が完了しました」みたいなのを2021年にnoteでリリースしました。

実は裏では、次はNuxt3だという話が出ていたのですが、「Nuxt3にいくのがどうやら難しいぞ」という話になりました。それだったらReactでサービスを区切れるところで分割していくという手段を取ろうということになり、そこにコミットする意味でもデザインシステムが動き出したというのがありますね。Reactで切り出していくために、Reactのコンポーネントを量産して、滑らかに移行プロジェクトを進めるという意味ですね。

先ほども言ったのですが、ページ自体には混在していないのですが、ReactとVueが1つのドメインを跨いで混在するので、共通パーツはSvelteで提供しているところもあります。

あとは「SSRを最低限にしよう」という話もあります。そうなると、「Web Componentsを採用できるよね」とか、そっちの話も広がったりするのですが、現状はそんな感じですね。

:ありがとうございます。アンドパッドでもnoteさんのSvelteの記事を参考にして、Svelteを採用しているプロジェクトがありますね。

アンドパッド社に訊く、デザインシステム開発と事業開発のバランス

:では、heyの藤井さん。質問はありますか。

藤井:アンドパッドさんに聞いてみたいです。やはりデザインシステムは事業開発と並走して動いていくイメージがあります。デザインシステムをどう押し進めたのか、チーム体制と事業開発とのバランスを聞いてみたいです。

かわかみしずか氏(以下、かわかみ):私の資料にも載せたのですが、基本的には全員何かしらのプロダクトのデザインや開発をアサインされているのが前提としてあるので、そこからある程度限られたメンバーが二足の草鞋を履く感じで、現状はデザインシステムに取り組んでいます。

入社した時に「二足の草鞋か、大変そうだな」とちょっと思ったし、実際、事業開発のほうが忙しくなってくると、デザインシステムの進捗が鈍くなるというか、「なんかちょっと時間が取れないぞ」というジレンマを抱えつつも、だからこそ、こういう時にこういうデザインシステムがきちんとあれば、事業開発スピードを上げて他のことをできる時間が取れるから、「もっとこういうの欲しいな!」みたいなことを感じました。

自分事として生まれてくる情報を、デザインシステム側に持ち帰ることができるということに気づいた時に「二足の草鞋もわりと悪くはないな」と思いました。

ですが、片方が忙しくなると、片方がままならなくなるというジレンマを抱えている中で解決策を探っている、というのが回答になってしまいます。デザイナーとエンジニアは、所属組織も上司も違いますが小泉さんはこのへんをどう感じていますか?

小泉:そうですね。エンジニアは、所属は違うんですけど、チームとしては基本的に事業開発をメインとして担当しつつ、そこで実際に困っていることや、そこの取り組みとうまくデザインシステムを進めるというところをうまくマージしながらやっていく。実際に事業開発を担当していないと進めにくい部分だったりもするので、そこの理解度だったりをうまくフィードバックしながら、場合によっては他のメンバーとも協力しながら進める体制を、今のところは取っていますね。

hey社におけるプロダクト開発とデザインシステム開発リソースのバランス

:ありがとうございました。実はイベントのTwitterやチャット欄でも質問がきていて、「プロダクト開発とデザインシステムに関する開発リソースの分配がどれぐらいなのか気になる」ということだったので、ぜひheyさんにも聞きたいのですが、バランスはどうなんですかね?

藤井:デザインシステムを構築していくフェーズにおいては、プロダクト開発でたたき上げていったという感じです。ただ、今は基盤開発とプロダクト開発とで分かれていて、プロダクト開発の空きがある部分で細かな改善Issueをこなしつつ、移行自体は専属の1人に進めてもらっていました。

:専属の方がいたんですね。

藤井:そうです。デザイナーもSTAND専門みたいな感じの人がいます。

井出:2人、1人、1.5人ぐらいがデザインシステムに張り付いて作っています。リテール側はそういうふうに分担されているのですが、プロダクト開発とデザインシステムのUIを作るのはわりと同じ人がやっていて、プロジェクトを進めながら足りないUIは作っていくかたちで進んでいます。

なので、本当に適切なUIが作られずに、現在あるコンポーネントで組まれてしまう問題が起きてくるのは、そういうのが要因としてはあります。本当はきちんと各ライブラリに合わせて、UIコンポーネントもメンテしていくチームを持ちたいなというのが、今ある課題ですね。

:専属で入っている人はいるけど、チームにはなっていない感じという。

藤井:プロダクトによってチームの状況が変わっているので、本当はエンジニアで横断的な組織を1つ組めるといいかなというのが今の課題です。

メンバーみんながデザインシステム開発にコミットするnote社

:それでいうと、noteさんはもう横断的なチームになっている感じですか。

沢登:一応デザインシステムのチームは、僕とusuiさんともう1人イラストレーターの3名でやっています。僕のリソースの話でいうと、だいたい10〜20パーセントぐらいを割いていて、メインはプロダクト開発をしている感じです。usuiさんは?

usui:僕はわりとフルコミットです。アクセシビリティとか、プロダクトとは別の、もうちょっと抽象的なユーザー・インターフェイスに関するプロジェクトを中心に活動しているので、デザインシステムが100と言ってもいいかなあという感じではありますね。

沢登:先ほどみんなで作るという話をしていたと思うんですけど。トーン・オブ・ボイスとかは、デザインシステムチーム以外のデザイナーがオーナーシップを持っていたりするので、デザインシステムチームだけで作っている感覚はあまりないですね。

:じゃあ、比較的みなさんでデザインシステムにコミットするという感じですね。

沢登:そうですね。

:なるほど、三者三様ですね。パネルディスカッションでは聞きたいことがもっといろいろあったのですが、時間になってしまいました。noteさんもこのあと、noteをリリースするという話もあったので、各社さんからテックブログでの発信や、Twitter上での返答などがあるのを期待して、締めに入りたいと思います。

それではお時間になりましたので、イベントを終了いたします。ぜんぜん話しきれなかったと思うので、またデザインシステムについてのイベントをやっていけたらなと思っています。視聴者のみなさんも、本日はありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!