自己紹介と本日のアジェンダ
かわかみしずか氏：アンドパッドのデザイナーのかわかみです。私からは「アンドパッドのデザインシステムの今までとこれから」をお話しします。
まず、自己紹介です。アンドパッドには2021年の7月に入社して、半年と2ヶ月ほど経ちました。担当プロダクトは、小泉さん（小泉佑太郎氏）と同じで、ANDPAD引合粗利管理というサービスをやっています。
十数年間、事業会社でデザインしたり、たまにデザインイベントの設計をしたり、HTMLやCSSを書いたりしていました。デザインシステムにきちんとメインで携わるのは、アンドパッドが初めてです。
本日のアジェンダです。アンドパッドについて、入社前と入社後のギャップ、入社後の取り組み、そして最後に今後についてです。
建築・建設業界に特化したSaaSサービスを提供している
アンドパッドについてです。アンドパッドのミッションは「幸せを築く人を、幸せに。」です。ものづくりをして、衣食住の住という幸せを私たちに提供してくださっている建築・建設業界の方々を、私たちは幸せにしたい、という想いを持って日々取り組んでいます。
先ほど小泉さんもおっしゃっていましたが、アンドパッドは、建設・建築業界に特化したSaaSサービスを提供しています。SaaSはソフトウェア・アズ・ア・サービスの略で、その中でも特定の業界に特化したSaaSは、Vertical SaaSと呼ばれています。対して、業界を問わず利用できるサービスは、Horizontal SaaSと呼ばれています。
アンドパッドはVertical SaaSなので、さまざまな機能を、あくまでも建築・建設業界に特化した状態で提供しているというのが特徴になります。
開発体制ですが、フロントエンドエンジニアを含むエンジニア職とデザイナー職は、それぞれ別の部署に所属しています。プロダクトのチームにアサインされるかたちで一緒にサービスを作っています。
前職では、所属とチームが別という経験が少なかったので、けっこうこの体制は私にとって新鮮でした。
HTMLやCSSまでをデザイナーが書く会社もあると思いますが、アンドパッドにおいてはHTMLとCSSはフロントエンドエンジニアさんの専門領域で、基本的にデザイナーの専門領域は、プロダクトの課題整理からUIデザインまでになっています。
入社前と入社後のギャップ
次に入社前と入社後のギャップです。友人や元同僚に会社名を言ったところ、ほとんどの人がアンドパッドのことを知らなかったのですが、私は趣味が間取り図なので、アンドパッドのことは一応知っていました。
工事現場で使う図面とかを、紙じゃなくてiPadなどで管理できるアプリを開発している会社だよなあ、みたいな感じで思っていました。
それ自体のギャップは特にありませんでしたが、入社後に、もっと広く業界全体の課題解決に取り組んでいる会社だということを知りました。
冒頭でお見せしたように、Vertical SaaSは業界特化型なので、チャットや会計システムという機能を、どの業界でも使えるように汎用的に作り込むというよりは、いろいろな機能を建築・建設業界に合うように特化して開発しているので、機能の種類が多様です。
また、1つの機能を作るためにはドメイン知識が必要です。ドメイン知識自体はどんな会社のどんなプロダクトでも必要だと思いますが、1つのサービス内で必要なドメイン知識の量が想像以上に多いなと思いました。
ただ、多くて大変だなとはもちろん思いますが、1つのサービスをやっているだけでいろいろな機能のデザインができるVertical SaaSはおもしろいなということも、入社してから思いました。
とはいえ、まったく違うサービス名の別のブランドを作ってるわけではなくて、あくまでも「ANDPAD」という1つのサービスの中で機能別にチームが分かれているだけなので、自分の所属チームに専門特化を持って取り組みながらも、それぞれのつながりは考慮する必要があります。
デザインシステムの必要性を感じた理由
さらに、今はまだまだこの業界のDX化に必要なプロダクトを、アンドパッドは新しく作り続けている段階なので、共通のデザインガイドラインやコンポーネントがないと、バラバラの新規サービスがどんどん生まれ、機能と機能のつながりもどんどんバラバラになるんじゃないかなと思っています。
開発コストは膨らむ一方で、プロダクトの品質の担保がどんどん難しくなって、その結果として、本当にやりたかったはずの業界の課題解決に取り組む時間が圧迫されてなくなってしまうという感じになってしまうんじゃないかなと思いました。
デザイン開発のコストを、より本質的な仕事に使いたいという課題はどの会社にもあると思いますが、アンドパッドの開発体制と、Vertical SaaSというビジネスモデルでは、負債の積み上がるスピードがより速そうだなと感じました。だからこそ、すごくデザインシステムの必要性を感じました。
そんな流れで、入社後に所属したサービスのプロダクトデザインを行いながら、デザインシステムに取り組みました。
取り組み1 デザインシステムのゴールイメージや構成要素のビジュアライズ化
最初にまずこの2つを行いました。デザインシステムのゴールイメージや構成要素のビジュアライズ化と、デザイントークンの再定義です。
私が入社した段階で、すでにデザイナー側にはFigmaで作られたコンポーネントがあったのですが、デザインや作ろうとしているもののゴールイメージなどがわかるようなものがありませんでした。
なので、これから取り組むべき内容の想像がパッとできないなと思ったので、自分の脳内整理と、他のデザイナーがどんなことを考えているんだろう？ と知るために、このような感じでMiroであれこれ書き出しながら、脳内や情報のすり合わせを行いました。
また、デザインシステムというワードを含めて、言葉の認識ずれを防ぎたいと思ったので、とりあえず直近で必要そうだと思ったパターンライブラリの構成要素のビジュアライズなども行いました。
これらの図自体は、単なるコミュニケーションツールの1つとして勝手に作っただけですが、結果論なんですけど、デザインシステムに取り組んでる中で、同じ話をしているはずなのに、なんだか噛み合わないぞ？ という、原因がよくわからない違和感が発生した時に、この全体図を作ったことで、「あ、違和感の正体は、同じ方向を向いていたつもりだったけれど、具体的に見ているところが違ったからだ」と気づくことができました、と他のデザイナーが教えてくれました。
最初は途中参加の自分が他のデザイナーに追いつくためにやったことだったのですが、やはり言語化やビジュアライズ化のパワーはすばらしいなと思いました。
取り組み2 デザイントークンの再定義
2つ目のデザイントークンの再定義についてです。当時のコンポーネントは、社歴がある程度長くて「ANDPAD」をよく知っているデザイナーが、経験を中心に自分の中にあるデザインルールに則って作っていました。
なので、いわゆる認知パターンの部分が誰でもわかる状態にはなっていませんでした。属人化というか、別の人が作るとちょっと統一感がなかったり、なんかイレギュラーっぽくなって、違う気もするけれど何が違うのかがちょっとわからない、みたいな状態になる人もいなくはなかったのかなという感じでした。なので、手戻り感はあったのですが、あらためて認知パターンの見直しと、認識の齟齬なく認知パターンの取り回しができるようにするために、デザイントークンの定義を行いました。
デザイントークンの設計や管理方法は、会社によってさまざまだと思いますが、アンドパッドの場合は、このようにすべての参照元となる定数をリファレンストークンとして置いて、それを参照するかたちでUI上で使いやすくしたシステムトークンを定義して、さらに必要であればコンポーネントトークンを定義するかたちにしました。
このあたりの設計周りは、本当にいろいろなデザインシステムを参考にしたのですが、デザイントークンに関してアンドパッドに一番合いそうだなと思ったのが、Googleさんのデザイントークンだったので、それをアンドパッドのデザインチームが管理しやすいようにカスタマイズしました。
リファレンストークン自体はこのような感じで、もうちょっと増える予定です。このリファレンストークンを元に、例えば色はこんな感じでシステムトークンとして定義しているという感じです。
まだ一部のデザイナー間での共有しか行っていないのですが、トークンができてからデザインしやすくなりましたと言ってもらえたり、運用に向けての改良点はまだまだあるのですが、私自身このへんの設計ができてからやりやすくなったなと感じています。また、必要に応じてこんな感じでドキュメントの追加整備も行っています。
山積みの課題を一緒に解決するメンバーを募集中
最後に今後についてです。全体から見ると、まだやりたいことの一部しかできていません。UIコンポーネントの充実、ライティングとかデザインパターン、導入・運用など、課題は山積みの状態です。
そんな中で、もちろんプロダクトの新しいデザインもどんどん行っていきたいので、デザイナーも絶賛募集中です。
このようにアンドパッドのデザインシステムは本当にまだまだ初期段階ですが、少しでもご興味のある方はぜひお話できればと思いますし、アンドパッドのデザインシステムには興味はないけれど、建築・建設業界に興味あるという方も大歓迎なので、ぜひ「connpass」などからご連絡いただけるとうれしいです。ご清聴、ありがとうございました。
