2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
鳩洋子氏(以下、鳩):パネルディスカッションなので、各社向けの質問をお互いにしたいなと思っています。それでは、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の藤井さん。質問はありますか。
藤井:アンドパッドさんに聞いてみたいです。やはりデザインシステムは事業開発と並走して動いていくイメージがあります。デザインシステムをどう押し進めたのか、チーム体制と事業開発とのバランスを聞いてみたいです。
かわかみしずか氏(以下、かわかみ):私の資料にも載せたのですが、基本的には全員何かしらのプロダクトのデザインや開発をアサインされているのが前提としてあるので、そこからある程度限られたメンバーが二足の草鞋を履く感じで、現状はデザインシステムに取り組んでいます。
入社した時に「二足の草鞋か、大変そうだな」とちょっと思ったし、実際、事業開発のほうが忙しくなってくると、デザインシステムの進捗が鈍くなるというか、「なんかちょっと時間が取れないぞ」というジレンマを抱えつつも、だからこそ、こういう時にこういうデザインシステムがきちんとあれば、事業開発スピードを上げて他のことをできる時間が取れるから、「もっとこういうの欲しいな!」みたいなことを感じました。
自分事として生まれてくる情報を、デザインシステム側に持ち帰ることができるということに気づいた時に「二足の草鞋もわりと悪くはないな」と思いました。
ですが、片方が忙しくなると、片方がままならなくなるというジレンマを抱えている中で解決策を探っている、というのが回答になってしまいます。デザイナーとエンジニアは、所属組織も上司も違いますが小泉さんはこのへんをどう感じていますか?
小泉:そうですね。エンジニアは、所属は違うんですけど、チームとしては基本的に事業開発をメインとして担当しつつ、そこで実際に困っていることや、そこの取り組みとうまくデザインシステムを進めるというところをうまくマージしながらやっていく。実際に事業開発を担当していないと進めにくい部分だったりもするので、そこの理解度だったりをうまくフィードバックしながら、場合によっては他のメンバーとも協力しながら進める体制を、今のところは取っていますね。
鳩:ありがとうございました。実はイベントのTwitterやチャット欄でも質問がきていて、「プロダクト開発とデザインシステムに関する開発リソースの分配がどれぐらいなのか気になる」ということだったので、ぜひheyさんにも聞きたいのですが、バランスはどうなんですかね?
藤井:デザインシステムを構築していくフェーズにおいては、プロダクト開発でたたき上げていったという感じです。ただ、今は基盤開発とプロダクト開発とで分かれていて、プロダクト開発の空きがある部分で細かな改善Issueをこなしつつ、移行自体は専属の1人に進めてもらっていました。
鳩:専属の方がいたんですね。
藤井:そうです。デザイナーもSTAND専門みたいな感じの人がいます。
井出:2人、1人、1.5人ぐらいがデザインシステムに張り付いて作っています。リテール側はそういうふうに分担されているのですが、プロダクト開発とデザインシステムのUIを作るのはわりと同じ人がやっていて、プロジェクトを進めながら足りないUIは作っていくかたちで進んでいます。
なので、本当に適切なUIが作られずに、現在あるコンポーネントで組まれてしまう問題が起きてくるのは、そういうのが要因としてはあります。本当はきちんと各ライブラリに合わせて、UIコンポーネントもメンテしていくチームを持ちたいなというのが、今ある課題ですね。
鳩:専属で入っている人はいるけど、チームにはなっていない感じという。
藤井:プロダクトによってチームの状況が変わっているので、本当はエンジニアで横断的な組織を1つ組めるといいかなというのが今の課題です。
鳩:それでいうと、noteさんはもう横断的なチームになっている感じですか。
沢登:一応デザインシステムのチームは、僕とusuiさんともう1人イラストレーターの3名でやっています。僕のリソースの話でいうと、だいたい10〜20パーセントぐらいを割いていて、メインはプロダクト開発をしている感じです。usuiさんは?
usui:僕はわりとフルコミットです。アクセシビリティとか、プロダクトとは別の、もうちょっと抽象的なユーザー・インターフェイスに関するプロジェクトを中心に活動しているので、デザインシステムが100と言ってもいいかなあという感じではありますね。
沢登:先ほどみんなで作るという話をしていたと思うんですけど。トーン・オブ・ボイスとかは、デザインシステムチーム以外のデザイナーがオーナーシップを持っていたりするので、デザインシステムチームだけで作っている感覚はあまりないですね。
鳩:じゃあ、比較的みなさんでデザインシステムにコミットするという感じですね。
沢登:そうですね。
鳩:なるほど、三者三様ですね。パネルディスカッションでは聞きたいことがもっといろいろあったのですが、時間になってしまいました。noteさんもこのあと、noteをリリースするという話もあったので、各社さんからテックブログでの発信や、Twitter上での返答などがあるのを期待して、締めに入りたいと思います。
それではお時間になりましたので、イベントを終了いたします。ぜんぜん話しきれなかったと思うので、またデザインシステムについてのイベントをやっていけたらなと思っています。視聴者のみなさんも、本日はありがとうございました。
関連タグ:
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05