スタートから1年半経ってもなかなか進まないデザイン共通化　アンドパッド社が陥ったプロジェクトの落とし穴

自己紹介とアジェンダの紹介

小泉佑太郎氏：アンドパッドフロントエンドエンジニアの小泉です。アンドパッドは他の2社と違って、デザイナーとエンジニアでセッションを区切ります。まず私から「エンジニアがデザインシステム導入に取り組む際の落とし穴」というテーマで話します。

少し大げさなタイトルですが、フロントエンドエンジニアとしてデザインシステムの導入に取り組む際に苦労したところや、その乗り越え方について、他の2社より少し手前の部分の話ができればと思います。

自己紹介をします。2019年6月入社、アンドパッドのフロントエンドエンジニアを担当してもうすぐ3年になります。社内ではVue.jsとNuxt.jsを専門に開発していて、プライベートだと2021年末からNuxt 3を触っています。ANDPADは建設・建築業に特化したクラウドサービスです。施工管理・チャット・タスク管理など、建設業界にまつわるあらゆる業務をIT化・デジタル化することで、業界の課題解決に取り組んでいます。

（スライドを示して）本日のアジェンダです。内容を詰め込んだので、やや駆け足になるかもしれませんが、ご了承ください。

デザイン共通化プロジェクトが必要になった経緯

まず、そもそもなぜアンドパッドでデザイン共通化プロジェクトが必要になったのかという経緯を説明します。現在のアンドパッドには、先ほど紹介したように複数のサービスが集まっていますが、サービスごとにデザインが少しずつ異なっています。大まかな方向性やブランドカラーは統一されていますが、細部には違いがあります。

同じサービスなのになぜデザインが共通化されていないのか、疑問を持たれるかもしれませんが、これには大きく2つの理由があります。1つは、「ANDPAD」が建設業界に特化したVertical SaaSで、かなり幅広い種類のサービスを展開しているからです。

ANDPADには、スライドのように未提供のものも含めてたくさんのサービスがあり、各プロダクトの意思決定や開発の速度を落とさないために、一つひとつプロダクトごとにチーム、リポジトリ、技術スタックなどを分けて少人数で開発する体制になっています。その一方で、ここまでサービスが増えたあとでは、サービス全体に跨るような大きなデザイン統一・変更があった場合、どうしてもハードルが高くなってしまいます。

また歴史的な経緯として、開発初期はエンジニアが数えるほどしかおらず、デザインやCSSにそれほど明るくないRubyエンジニアが画面実装まで担当していました。デザイナーが入ってきたあとにさらにサービスが拡大したため、新機能を担当することも多く、既存画面にまでなかなか手が回らない一方で、新規サービスでは既存画面の問題点を徐々にブラッシュアップしながら新しいデザインを作ってリリースを行ってきました。サービスごとの差異が積み重なった結果、正しいプロダクトが存在しないという現状につながっています。

このような問題を解消するためにデザインシステムを確立・導入しようという動きが、デザインチームの主導で2020年の秋頃から本格的にスタートしました。このプロジェクトには、プロダクト間の差異をなくしてサービスを迷わず使えるようにすることと、デザイナーとエンジニアの工数をなるべく削減することの、明確な目標が2つ設定されていました。

しかし、それから1年半経った現在もデザインの共通化はほとんど進んでおらず、実際のサービスにあまり反映されていない状態です。なぜこのプロジェクトがうまく立ち上がらなかったのか。アンドパッドがハマったデザイン共通化の落とし穴について説明します。

どこからどう動けばいいのか、見えなくなってしまった

まずはデザイン共通化の初期段階、デザインシステムのルールを定義していく取り組みについて。あとでデザイナーのかわかみさんの話でもいろいろ出てくると思いますが、このあたりは比較的順調に進捗していたと思います。デザインシステムがある程度まとまった段階で、この実装をどう進めていくか。実際にデザインを実装する立場であるフロントエンドチームのメンバーに共有・相談するミーティングが設けられました。ここまでの流れは特に問題ないと思っています。

ところが、この共有を受けたフロントエンドエンジニア側は、次にどこからどう動けばいいのかが見えない状態に陥ってしまいました。例えば、アンドパッドではマイクロサービス化が同時に進んでいるのですが、新しく定義されたデザインの中にはサービスを跨ぐような効率的なメニューが設定されており、これを作るためにはフロントエンドだけでなくサーバーサイドでもサービスを跨ぐAPIや権限制御について確認する必要がありました。

ほかにも、VueとReactのプロダクトが混在しているために、共有コンポーネントを2種類作る必要が生じるなど、デザインの共通化までにやらなければいけないことや確認すべきことを挙げるとキリがない状態になり、そのミーティングでは結論が出ずに解散となりました。

すべての問題を一気に解決しようとしていた

私自身もそのミーティングでさまざまな懸念点を出しましたが、なぜこんなに不安なんだろうと自分なりに考えたところ、そもそもこのプロジェクトはすべての問題を一気に解決しようとしすぎているんじゃないかという結論に至りました。

先ほどの懸念する点を並べてもわかるのですが、「デザイン共通化」という名称で一括りにされていても、ツールの共通化から実装の共通化、プロダクト仕様の統一、ツールの共通化や顧客の説明までとさまざまな要素が含まれています。デザインチームが共通化のゴールとして当初設定していた、プロダクト間の差異をなくすこととデザイナーとエンジニアの工数を削減することも、最終的には解決すべきことではあるものの、ユーザー体験と開発者体験は本来別の課題です。

それらの要素を曖昧にしたままスタートしようとしたため、実際の作業に入る段階でどこから手をつけたらいいのかわからなくなったという仮説を立てました。

さらに、個人的にデザイン共通化の落とし穴は、デザイン共通化が、技術基盤の刷新やマイクロサービス化などのテーマと比べて、最終的なゴールであるなど、それによって受けるメリットが比較的わかりやすいために、プロジェクトに明確な反対意見が出にくい点にあると思いました。だから、細部の仕様の言語化など中間地点となる目標の設定を飛ばしたままで走り出せたものの、途中でつまずいてしまったのではないかと思いました。

アプローチその1　CSS共通化で対応

次に、こういった課題を解決するためにフロントエンドという立場でどう取り組んだか。ここは現在進行形なので、あくまでも一例として聞いてください。実際のアプローチを大きく分けるとスライドの3つです。

まず、フロントエンドとしてのコンポーネントの共通化から、CSS共通化に変更するという提案をしました。もともとフロントエンドの中でデザイン共通化・コンポーネント共通化の話をした時に、全員がなんとなく暗黙の了解としてBootstrapやElement UI、他社の例だとSmartHRのSmartHR UIのようなUIコンポーネントをいきなり作るというイメージを持っていました。しかし、いきなりこれを目指そうとすると細かな挙動や、仕様のバリエーションといった要件を、事前にかなり詰めておく必要がありました。

実装を進めるにしても、VueとReactの両方に対応させようとすると、今後のメンテナンスコストが倍になってしまうという懸念がありました。いろいろ考えた結果、各プロダクトのデザインを共通化するという目標だけであれば、UIライブラリでなくてもCSSフレームワーク的なものがあれば十分なのではないかと思い付きました。

これを考えたのは、私自身がプライベートでBulmaというJavaScriptを含んでいないCSSのみのフレームワークを使っていたからです。しかも、それで作ったサイトをNuxtからNextに移植したことがあったので、使い方はイメージしやすかったです。このようにターゲットを切り替えたことで、VueやReactといったフレームワークの問題を考えずにいられるし、ライブラリとしてやること・やらないことの線引きも明確になりました。

プロダクト間の仕様の差異も、単なるCSSであれば、最悪、サービス側で自由に上書きできます。これはメリットにもデメリットにもなりますが、移行措置としては有用だと思います。そして将来的にコンポーネント共通化を行うとしても、このCSSをベースにできるので無駄にはならないという安心感がありました。

アプローチその2　進める範囲を再確認

また、ミーティングで出た懸念点は、最初からすべてを調整しようとすると手に負えないので、いったんフロントエンドとデザイナーが動ける範囲に絞って取り組むことにしました。例えば、サーバー側のAPIやプロダクト仕様など、まだどうなるかわからない部分については、サービスごとにカスタマイズして使えるように幅を持たせるなど、実際のサービスの反映のタイミングも最初からすべてを決めずに進めることにしました。

アプローチその3　新規プロダクトの実装とセットで進める

ということで、新規プロダクトの実装時にセットで進めることにしたわけですが、そもそも共通コンポーネントの作成部分の実装にリソースをいきなり割くのは難しい状況でした。特に、共通デザインの実装となると、ある程度ANDPADの全体を知っている人が進めたほうがいいのですが、経験豊富なメンバーほど製品開発をリードする立場にあるので、そちらの業務をメインに進めてもらいたいし、 そのチームを異動してもらうのは難しいという事情がありました。

そこで、デザインシステムとして実装を行うのではなく、新規ページの実装時にデザインシステムに沿った実装を進めつつ、その時に使った共通化のコンポーネントは別リポジトリに作って読み込むようにしました。これなら新規ページとはいえ、通常のプロダクト開発の一部なので、スケジュールを遅らせずに済み、今使っているユーザーもいないので影響も最小限で済みます。

また、あくまでもこれは開発の一部なので、チーム内の調整だけでスタートできました。チームごとに素早く意思決定を行っている、アンドパッドの良い部分をうまく活かせたと思います。

デザイン共通化に取り組んだ結果

このように取り組んだ結果、デザインシステムを導入できる新規ページの開発に合わせて2021年末からWebフロントの実装がスタートし、先日（※取材当時）共通CSSが導入された新規ページがリリースされました。これをベースに同じサービスの既存ページや、別のサービスの展開の準備が進んでおり、まだまだやることは多いですが、ようやくスタートラインに立ったと感じています。

まとめです。フロントエンドとしては、デザイン共通化と称して最初からUIコンポーネントを目指したくなりますが、目標はそこだけではなく、その間も取ることができること、さらに組織としても横断的なプロジェクトならいきなりゴールを目指すよりも、多少遠回りであっても細かいタスクに分割して地道に進めていく、とりあえず動いてみることが必要だと感じました。今回の発表がみなさんの参考になれば幸いです。ご清聴ありがとうございました。