hey×note×アンドパッドのデザインシステム開発の裏側　スコープ設定と構築・運用・アップデートで気をつけるべきこと

デザインシステムプロジェクトのスコープ設定をどうやっているのか

鳩洋子氏（以下、鳩）：続いて、パネルディスカッションのコーナーに入ります。今回のパネルディスカッションでは「各社の取り組みのここが気になる！」と題して、それぞれが今回の登壇で気になったこと、また、前から気になっていたことについて話していきたいと思っています。みなさま、よろしくお願いいたします。

視聴者から事前アンケートでいただいた質問からピックアップしました。まず1つ目です。

「デザインシステムのプロジェクトマネジメントやスコープ設定をどのように行っているか知りたいです。特にボトムアップの活動だと、目標を決めづらいなどないでしょうか」ということだったのですが、まずはheyさん、どうでしょうか。

藤井大祐氏（以下、藤井）：プロジェクトの立ち上げ期から今までの流れはスライドで説明したとおりです。ID基盤とリテール部門が最初に始まって、そこからReact、Vueのそれぞれが進んでいきました。

なので、プロダクト開発を進めながら、デザインシステムがどうしてもレジのリリースに向けて必要だったので、無理くり作っていったところがあります。現状は、デザイン組織は横断的なのですが、エンジニア組織はバラバラになっています。リテール部門だけの話でいうと、プロダクト開発ラインと基盤開発ラインが分かれていて、その基盤開発ラインの中に主担当の方が置かれ、「STAND」にどっぷり浸かってやってもらっている状態です。

ただ、初期のコンポーネントを作っていくフェーズにおいては、プロダクト開発でどんどん進めていきました。今は、その移行作業を主担当として進めている方がいます。

鳩：そういう感じだと、ボトムアップというよりは、どちらかというとトップダウンというか。heyさんの場合は「全社的にやるぞ！」と言って始まった感じなんですかね。

藤井：そうですね。井出さんはどうですかね。

井出優太氏（以下、井出）：最初は僕とCTOで、もうこれをやりますって決めて、そこからスコープの設定とかは、もはや僕のさじ加減みたいな感じになっていて、デザインとしてどこまでどうやるという話は、ある程度トップダウンで決めるかたちになっていました。

運用が始まってきているので、デザインとフロントエンドできちんとチームを作ってどうやっていくかというのが、直近の課題になり始めている感じですね。最初はトップダウンでゴリッとやった感じです。

鳩：なるほど。では、noteさんの場合はどうでしょうか。

沢登達也氏（以下、沢登）：発表でもあったように、それまでデザイナーがやっていたスタイリングを分解する必要があるという課題が、出てきました。そこを解決すると同時に、仕組み化しようというのが走った感じで、いきなりデザインシステムを作ろうという話ではなかったんですね。なので、トップダウンかボトムアップかというと、トップダウンだったのかなという気もちょっとしています。

鳩：デザイナーさんのほうで、そういう必要性があるよねと課題が出てきた時に、デザインシステムのような、デザインや体験を統一していくことが走り始めた感じですか。

沢登：そうですね。そこを解決しないと、プロダクトの開発に影響が出るというものだったので、それこそusuiさんの時間をすごく使って解決しようと動いたのが始まりですね。

鳩：noteさんの場合だと、「note」というプロダクトがあって、それにさまざまなデザイナーの方が関わるというところで、heyさんのパターンとはちょっと違うかたちで課題が出てきちゃったということですよね。

沢登：そうですね。

鳩：ありがとうございます。それではアンドパッドはどうでしょうか。

小泉佑太郎氏（以下、小泉）：そうですね。私もやはり発表の内容と一部かぶるのですが、どちらかというと、おそらく「デザインシステムが必要だねと」いう共通認識がアンドパッドの中ではあったと思います。実際にそれを導入していこうというタイミングで、デザインチームがまず率先してそこを定義していこうという動きがありました。そこは、ボトムアップだったかなと思います。

実際にそれを全社に展開していこうとすると、ボトムアップではやはり限界があると思うので、今のところはチーム内で少しずつ進めていきつつ、全社への最終的な展開は、もっと上のレイヤーの人たちを巻き込んで、トップダウンに近いかたちでの活動にしていこう、と動いているところです。

鳩：アンドパッドの場合だと、先ほどかわかみさんの登壇でもあったように、ボトムアップで出てきた課題をトップダウンで全社的な活動にしていこうという流れになっているという話ですね。

この質問は非常におもしろかったですね。三者三様、課題感を持ってスタートしているという話だったと思います。

デザインシステムプロジェクトの各フェーズにおいて気をつけるべきポイント

鳩：では、次の視聴者からの質問に移ります。「デザインシステムの構築・運用・アップデート、それぞれのフェーズにおいて気をつけるべきポイントがあれば教えてください」ということでした。では、アンドパッドから聞いてみたいと思います。どうでしょうか。

かわかみしずか氏（以下、かわかみ）：アンドパッドは、まだ運用までいっているとは言えないので、構築のフェーズで気をつけるべきことや、気をつけたことの話になります。フロントエンドエンジニアの方が気をつけるポイントは、先ほどの小泉さんの資料にあったと思うので、私が気をつけたポイントをお話しします。

資料にも載せたのですが、粗くても、間違っていてもいいので、作るもののゴールイメージを人に説明できるような状態を最初に作ると、議論のポイントがずれなくなるのでいいのかなと思っています。

あとは、デザインシステムもオリジナルのものをゼロから作ろうとせずに、運用フェーズにあるようなデザインシステムがパブリックにたくさんあるので、代表的なものをいくつか見てみる。そして、自分たちが理解しやすかったり、サービスにフィットしそうなものを見つけて、それの真似から始めるとやりやすいのかなと思います。

そのうえで、デザインシステムは、サービスやプロダクトの特徴、組織体制や開発体制、所属しているデザイナーや開発メンバーのスキルセットによって最適なやり方も変わってくるんじゃないかなって、作っていて思いました。

他社のものを使い始めてみて、ちょっと自分たちには使いにくいなと思ったら、無理して全部真似するのではなくて、自分たちに合うように変えるのがけっこう大事だなということに気づいたので、そう思われた方は、そこを気にかけてみるといいのかなと思いました。

鳩：ありがとうございます。それではnoteさん、いかがでしょうか。

uto-usui（以下、usui）：スライドでも触れたのですが、段階的に適用できるようなものがいいかなと思いますね。さっき言っていたデザイントークンをTailwindに適用させて、ユーティリティをガンガン書いていくところから始めると、一番簡単に始められるのかなと思っています。

あと1つのデザインリソースからあらゆるサービスに配れるように自動化もがんばっておくと、すごくテンションが上がって、みんなが幸せになった雰囲気がメチャ出るのでいいかなと思います（笑）。

また、真似をするリソースがいっぱいあるという話が今ありましたが、まさに僕もそうだなと思っています。AdobeのSpectrumやShopifyのPolaris、SmartHRさんのデザインシステムは、ドキュメントとかメチャクチャ充実していてすごいなと思っています。アクセシビリティに強いというイメージもみなさんお持ちだと思うのですが、メチャメチャ参考になるので、ぜひ見てくださいと推しておきます。

鳩：参考になる情報をいろいろと教えていただき、ありがとうございます。それではheyさん、いかがでしょうか。

藤井：heyだと、構築がおおよそ終わってきて、今から運用、アップデート、act2みたいな感じのところなんですけど。

構築は、とりあえずTailwindでやってみようと、CTOと井出さんで実装したというのもあるのですが、やはり進めることが最優先にあったのかなと思っています。サグラダ・ファミリアにならないように（笑）、とりあえずは前に進むために、デザイナーとの最低限のシンクだけ取って進めていきました。中途半端にならないように、必要最低限の同期を各プロダクトで取りました。

あと、アップデートについては、先ほどバージョン管理の話がちょっと出ましたが、デザイン変更をどのプロダクトがどこまでやったとか、どのコンポーネントをどのプロダクトが対応したという話が出るので、今は週1回定例を組んでいます。

デザイナーから「こういう変更をします」という話が出たら、親Issueを切って、それに対して、各プロダクトのリポジトリにリンクしたIssueを作って、全部が完了したら親Issueをdoneにするというかたちを取っています。今後も、まだまだ運用の課題は出てくると思っています。

鳩：ありがとうございます。noteさんはけっこうツールを使って自動化したという話があって。heyさんはコミュニケーションを密にしたり、コミュニケーションパスとか、そういうフローを整備したということで、けっこう各社さんカラーが出ているなというお話でした。

3社に共通していたのは、完璧なものを目指さずに走りながら考えていく、考えながら改善していくというところかなと思いました。

（次回へつづく）