最新情報をお届けします！
建築業界に特化したバーティカルSaaS「ANDPAD」は、どうサービス全体のデザイン統一を進めていった？ かわかみしずかさん（デザイナー）と小泉佑太郎さん（フロントエンジニア）が語った、デザインシステム構築のプロセスとはーー。
※2022年3月10日に開催された【Frontend Talk 〜デザインシステム構築のリアルな裏側〜】より、「アンドパッド」の小泉佑太郎さん（フロントエンジニア）と、かわかみしずかさん（デザイナー）のパートをお届け。書き起こし形式で編集したものをお届けします。
目次
【1】ANDPADの開発体制について
【2】バーティカルSaaSならではの課題
【3】デザインシステム構築に取り組む中でやったこと
└デザインシステムのゴールイメージや構成要素のビジュアライズ化
└デザイントークンの再定義
【4】エンジニアがデザインシステムの導入に取り組む際の落とし穴
【5】なぜデザイン共通化プロジェクトが必要になったか
【6】デザイン共通化の落とし穴
【7】課題に対して行った3つのアプローチ
└「コンポーネント共通化」から「css共通化」へ
└小さいチームで進められる範囲に絞った
└新規プロダクトの実装時にセットで進める
ANDPAD…建設・建築業に特化したクラウドサービス。施工管理、チャット、タスク管理など建設業界にまつわるあらゆる業務のIT化デジタル化によって、業界の課題解決に取り組む。
かわかみ：
ANDPAD、デザイナーのかわかみと申します。私からは「ANDPADのデザインシステムの今までとこれから」というお話をします。
まずアンドパッドのミッションですが、「幸せを築く人を、幸せに。」です。衣食住の住という幸せを我々に提供してくださる建築・建設業界の方々を幸せにしたい。そういった思いで、建設・建築業界に特化したSaaS製品を提供しています。
開発体制でいうと、エンジニアとデザイナー職は、それぞれ別部署に所属していて、そこからプロダクトごとのチームにアサインされる形で一緒にサービスを作ります。私自身「所属とチームが別」という経験が少なかったので、この体制は新鮮でした。
また、基本的に、デザイナーの専門領域は、プロダクトの課題定義からUIデザインまで。なかには、HTMLとかCSSまでデザイナーが担当する会社もあると思いますが、ANDPADだとそっちはフロントエンドエンジニアの専門領域です。
私がANDPADに入社したのは、2021年でした。入社する前と後でいい意味でのギャップがあって。というのも、入社前は「工事現場で使う図面を紙じゃなく、iPadなどで管理できるアプリを開発している会社だよな」くらいに考えていたのですが、入社してみて「広く業界全体の課題解決に取り組んでいる会社」だと知りました。
バーティカルSaaSは業界特化型なので、チャットや会計システム等の機能を、建築・建設業界に合うように特化して開発しています。機能の種類は多様で、どれか一つ作るのにしてもドメインの知識が必要でした。どの会社のどんなプロダクトでもドメインの知識は必要だと思うのですが、一つのサービス内で必要となるドメイン知識が想像以上に多いと感じました。その分、一つのサービスでいろいろな機能をデザインできる。ここはバーティカルSaaSのおもしろさでもあると思います。
そもそも、なぜ、デザインシステムが必要だと考えたのか。そういった話につながってくるのですが、「ANDPAD」という1つのサービスの中で機能別にチームが分かれているだけなので、自分の所属チームに専門特化しつつ、それぞれの繋がりを考慮する必要がありました。
さらに、まだまだ業界のDX化に必要なプロダクトを作り続けている段階。共通のデザインガイドライン、コンポーネントが無いと、今後バラバラの新規サービスが生まれ、機能と機能のつながりもバラバラになるんじゃないか。その結果、プロダクトの品質の担保が難しくなり、本当にやりたかった「業界の課題解決」に取り組む時間が圧迫されるのではないかといった懸念がありました。
「デザイン開発のコストを、より本質的な仕事に使いたい」こういった課題はどの会社にもあると思いますが、ANDPADの開発体制、バーティカルSaaSのビジネスモデルでは、より積み上がる「差異」のスピードが速そう。だからこそ、デザインシステムの必要性を感じました。
そういった流れのなかで、担当サービスのプロダクトデザインをしながら、プロダクト共通のデザインシステムにも取り組むことになりました。
まずは、
・デザインシステムのゴールイメージや構成要素のビジュアライズ化
・デザイントークンの再定義
ここから取り組むことにしました。
一つ目の「デザインシステムのゴールイメージや構成要素のビジュアライズ化」についてお話します。
私が入社した段階で、すでにFigmaで作られたコンポーネントはありましたが、デザイナーが作ろうとしているもののゴールイメージが分かるものはありませんでした。そのため、今後取り組むべき内容がパッと想像しづらい課題がありました。
自分の脳内整理と同時に、他のデザイナーの方がどんなことを考えているかを知っていく。そのために、他のデザイナーとMiroであれこれ書き出しながら、すり合わせをしました。
また、「デザインシステム」というワードを含め、言葉の認識ズレも防ぎたい。そこで、直近で必要そうなパターンライブラリーの構成要素のビジュアライズも行ないました。
やってみると、新たに見えたこともありました。
たとえば、以前から「デザインシステムに取り組む中、同じ話をしているはずなのに、なんだか周りと噛み合わない…」と違和感を持つデザイナーがいたことが分かりました。今回ビジュアライズしたことで違和感の正体が「同じ方向を向いていたつもりだったけど、具体的に見てる所が違ったことに気づけた」という声があり、分かったりもしました。
もともと、途中参加の自分が他のデザイナーたちに追いつくため、コミュニケーションツールの一つとしてやったことではありました。ただ、改めて、言語化やビジュアライズのパワーは素晴らしいと感じた出来事でした。
そして二つ目の「デザイントークンの再定義」についてです。当時のコンポーネントは、社歴が長くANDPADについてよく知るデザイナーが、経験を中心に一定のデザインルールに則って作っていました。
ただ、いわゆる認知パターンの部分が誰でもわかる状態にまではなっていない課題がありました。そのため、別の人が作ると統一感に欠けたり、違和感はあるものの何が違うのかわからないケースがあったり。そこで、改めて認知パターンの見直しを行なうことにしました。また、認識の齟齬なく認知パターンの取り回しができるよう、デザイントークンの定義を行ないました。
デザイントークンの設計、管理方法は会社によって様々あると思います。
ANDPADの場合は、全ての参照元となる定数をリファレンストークンとしておき、それを参照する形でシステムトークンとし、UI上で使いやすくしたトークンを定義しました。さらに必要であればコンポーネントトークンを定義する形にしています。
このあたりの設計は、いろいろなデザインシステムを参考にしましたが、ANDPADに一番合うと思ったのが、Googleのマテリアルデザインのデザイントークンでした。それをもとにANDPADのデザインチームが管理しやすいようカスタマイズしています。
リファレンストークン自体は、もう少し増える予定ですが、それをもとに、たとえば、「色」はこんな感じでシステムトークンとして定義しています。
まだ一部のデザイナー間での共有のみですが、「トークンができてからデザインしやすくなった」と言ってもらえています。改良点はまだありますが、この設計ができたことで、私自身もやりやすくなったと感じています。また、必要に応じ、ドキュメントの追加整備もしています。
ただ、まだ本当にやりたいことは一部しかできていません。UIコンポーネントの充実も、ライティングやデザインパターンもやっていきたい。導入や運用も考えなきゃいけない。
課題は山積みですが、プロダクトの新しいデザインもどんどん行っていきたいので、デザイナーも絶賛募集中です。
小泉：
こんにちは、ANDPADフロントエンジニアの小泉です。私からは「エンジニアがデザインシステムの導入に取り組む際の落とし穴」というテーマでお話しします。少し大げさなタイトルですが、フロントエンドエンジニアとしてデザインシステムに取り組む際の苦労した部分、そこの乗り越え方についてお話します。
まず、そもそもANDPADでデザイン共通化プロジェクトが必要になった経緯を説明します。ANDPADは、先ほど紹介したように複数のサービスが集まっていますが、サービスごとにデザインが少しずつ異なっていました。大まかな方向性、ブランドカラーは統一されていますが、細部に違いがあります。
同じサービスなのに、なぜ、デザインが共通化されてないのか。これには大きく2つ理由があります。
まず一つは、ANDPADが建築・建設業界に特化したバーティカルSaaSで、未提供なものも含めてかなり幅広い種類のサービスを展開していること。先ほど、かわかみさんからもありましたが、開発体制は、各プロダクト毎の意思決定や開発速度を落とさないために、一つひとつのプロダクト毎にチームやリポジトリ、技術スタッフなどを分け、少人数で行なう体制です。そのため、サービス全体にまたがる大きなデザイン統一や変更となると、特にここまでサービスが増えた後だと、どうしてもハードルが高くなってしまいます。
また、二つ目が歴史的な経緯として、開発初期はエンジニアが本当に数えるほどしかおらず、デザインにそこまで明るくないRubyのエンジニアが画面実装まで担当していました。その後、デザイナーが加わってからサービス拡大が進み、新規機能を担当することも多かったのです。新規サービスでは既存関連の問題点を徐々にブラッシュアップしながら新しいデザインを作ってリリースしていたため、既存画面まではなかなか手が回らなかった経緯があります。
結果的に、サービスごとの差異が積み重なり、かつ「これが最も正しい」というプロダクトが存在しないといった状況になりました。
このような問題を解消するため、2020年秋頃からデザインチームの主導で、ANDPADのデザインシステム確立・導入の動きが本格的にスタートしました。
このプロジェクトでは2つの明確な目標が設定されていました。
・プロダクト間の差異をなくし、サービスを迷わず使えるようにする
・デザイナーとエンジニアの工数をなるべく削減する
しかし、正直にお伝えすると、それから1年半経った現在も、デザインの共通化はあまり進んでおらず、実際のサービスにあまり反映されていない現状もあります。
ではなぜ、このプロジェクトがうまく立ち上がらなかったのか？私たちがはまった「デザイン共通化の落とし穴」について説明します。
まず、デザイン共通化の初期段階、デザインシステムやルールを定義する取組みについてお話します。デザインシステムがある程度まとまった段階でどう実装を進めるか、実際にデザイン実装する立場であるフロントエンドチームのメンバーに共有・相談するミーティングが設定されました。ここまでは特に問題がなかったと思っています。
ところが、この共有を受けたフロントエンドエンジニア側としては「次にどこから、どう動いていいか見えない」という状態でした。
たとえば、ANDPADだとマイクロサービス化も同時に進んでおり、新しく定義されたデザインの中には、「サービスをまたぐ統一的なメニュー」が設定されていました。これを作るためにはフロントエンドに加え、サーバーサイドでのサービスをまたぐAPI、権限制御などについても確認する必要がありました。
他にも、ANDPADではVue.jsとReactのプロダクトが混在しているため、「共通コンポーネントを2種類作る必要が出てくるのか」など、デザイン共通化までにやらなければいけないこと、確認すべきこと、決めることを挙げると、キリがない状態。ミーティングは結論が出ずに解散となりました。
私自身も、このミーティングで、さまざまな懸念を出した側だったのですが、「何でこんなにも不安があるんだろう？」と自分なりに考え直した時に、「そもそもこのプロジェクトは全ての問題を一気に解決しようとしすぎているんじゃないか」という考えに至りました。
「デザイン共通化」とひと括りにされている中にも
・ツールの共通化
・実装の共通化
・プロダクト使用の統一
・ツールの共通化
・顧客の説明
まで、さまざまな要素が含まれています。
当初、デザインチームで共通化のゴールとして設定されていた、「プロダクト間の差異をなくす」「デザイナーとエンジニアの工数を削減する」も、もちろん最終的にはどちらも解決すべきです。ただ、「ユーザー体験」と「開発者体験」という本来は別の課題。そういった要素を曖昧にスタートしようとしたため、実作業に入る段階でどこから手をつけていいのか分からなくなる、と仮説を立てました。
そして、個人的に「落とし穴」になり得ると思ったのは、デザインの共通化は、他の横断的なプロジェクト。たとえば、技術基盤の刷新やマイクロサービス化などのテーマと比べ、最終的なゴールやそれによって受けられるメリットが比較的わかりやすく、プロジェクト自体も明確な反対意見が出にくい傾向にあると思います。だからこそ、最後の仕様の言語化、中間地点となる目標設定を飛ばしたままでも走り出せてしまい、その結果、途中で躓くことが起きやすいと考えました。
こういった課題に対し、フロントエンドの立場で、どう解決に向け取り組んだかお話しします。ここはまだ現在進行中なので、あくまで一例として聞いてもらえたらと思います。
実際に取ったアプローチは、大きく分けるとこちらの3つです。
まず一つ目が、フロントエンドとしての目標を「コンポーネント共通化」から「CSS共通化」に変更する提案をしました。
もともとデザイン共通化、コンポーネント共通化の話をしたときに、全員が「なんとなくの暗黙の了解」として、いきなりBootstrap、Element UI、SmartHRのUIといったようなUIコンポーネントを作るイメージがありました。
しかし、いきなりこれを目指そうとすると、細かい挙動、仕様のバリエーションなど、事前に要件をかなり詰めておく必要があります。さらに実装を進める上で、Vue.jsとReactの両方に対応させようと思うと今後のメンテナンスコストが倍になってしまう懸念もありました。
考えるなかで「各プロダクトのデザインを共通化する」という目標だけであれば、UIライブラリーでなくてもCSSフレームワーク的なものがあれば充分ではないかと思いました。実際、私自身もプライベートでBulmaというJavaScriptを含んでいないCSSのみのフレームワークを使っていて、それで作ったサイトをNext.jsに移植したことがあったので、使い方をイメージしやすかったのもあります。
このようにターゲットを切り替えたことで、Vue.jsとReactといったフレームワーク問題は考えられていますし、ライブラリとしてやること・やらないことの線引きも明確に。プロダクト間の仕様の差異も、単なるCSSであれば、最悪、サービス側で自由に上書きできます。これはメリットにもデメリットにもなりますが、移行措置としては有用だと思います。
そして将来的にコンポーネント共通化を行なうとしても、このCSSをベースにできるので無駄にならない安心感もありました。また、先ほどのミーティングで出た多様な懸念点については、すべてを最初から調整しようと思うと、とても手に負えなくなる。
そこで二つ目として、一旦はフロントエンドとデザイナーで動ける範囲に絞って取り組むことに。たとえば、サーバー側のAPIやプロダクト仕様など、まだどうなるかわからない部分は、一旦各サービスごとにカスタマイズで使えるよう幅を持たせるようにしました。実際のサービスへの反映のタイミングも、最初からすべてを決めず進めることができました。
そして3つ目、「新規プロダクトの実装時にセットで進めることにした」ですが、そもそも、共通コンポーネントの作成の実装にリソースをいきなり割くのが難しい現状がありました。
特に共通デザインの実装となると、ある程度ANDPADの全体を知っている人が進めた方がいい。ただ、経験の長いメンバーほど製品開発をリードする立場にあるので、そちらの業務をメインに進めてもらいたいし、そこのチームを利用してもらうのが難しいと主張がありました。
そこで、デザインシステムとして実装するのではなく、新規ページの実装時にデザインシステムに沿った実装を進めつつ、実装時に使った共通化のコンポーネントは別リポジトリに作って読み込むようにしました。これであれば新規ページとは言え、通常のプロダクト開発の一部なので、スケジュールを遅らせずに済みます。また、今使っているユーザーもいないので影響も最小限です。加えて、ここはあくまでプロダクト開発の一部なので、チーム内の調整だけでスタートができます。チームごとにすばやく意思決定を行なうアンドパッドのよい部分をうまく生かせたと思います。
このように取り組んだ結果、デザインシステムを導入できる新規ページの開発に合わせて、2021年末からフロントの実装がスタートし、2月には共通CSSが導入された新規ページがリリースされました。また、これをベースに同じサービスの既存ページ、別のサービスの展開についても準備が進みました。まだまだやることは多いものの、ようやくスタートラインに立った状態だと感じています。
最後になりますが、フロントエンドとしては「デザイン共通化」というと最初からUIコンポーネントを目指したくなりますが、中間も目標としてとることができます。組織横断的なプロジェクトだと、いきなりゴールを目指すより多少遠回りであっても、細かいタスクに分割して地道に進めることも必要だと感じました。皆さんの参考になれば幸いです。ありがとうございました！
編集 ＝ CAREER HACK
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
