コンパウンドスタートアップのプロダクト開発を支えるDesignOps

弊社の代表が公開した「【実践編】コンパウンドスタートアップの作り方」に続き、これまでビジネス部門の責任者・ソフトウェアエンジニア・データエンジニア、様々なメンバーがコンパウンドスタートアップにまつわるestieの取り組みを記事にしてきました。

この記事は、デザイナーの荒井（@rakenarai）とデザインエンジニアのkyoncy（@kyoncy_site）が「コンパウンドスタートアップのプロダクト開発を支えるDesignOps」というテーマでお送りします。

はじめに

2021年までのestieは賃料策定に特化した「estie マーケット調査」を開発していましたが、2022年のシリーズA以後はマルチプロダクト戦略を掲げ、複数のプロダクト開発を並行して進めてきました。そして今年は物件の取得や売却に特化した「estie 物件売買」と、契約管理に特化した「estie 案件管理」を開発・リリースし、売買領域もカバーしました。
他にも商業用不動産のデータ構築と日々の業務を支える様々なプロダクト開発に取り組んでおり、未公表を含め提供中のプロダクトは6つに増えました。

もちろん、6つのプロダクトだけで商業用不動産のデータ・業務インフラの全てを満たすことはできません。この先もプロダクトを作っては統合し、各プロダクトの磨き込みと複数プロダクトの連携による価値を創出しながら「産業の真価を、さらに拓く。」というPurpose実現を目指していきます。

estieのような戦略でプロダクトを展開する会社は昨今「コンパウンドスタートアップ」と呼ばれるようになりました。コンパウンドスタートアップの代表格であるRipplingのCEO Parker Conrad氏による定義は「相互に連携した製品ポートフォリオを構築するために、幅広いポイントソリューションを同時に立ち上げる企業」です。まさにestieですね！！

estieは以下の図のように土地や建物、空室の情報といったデータの上に検索や認証といったミドルウェアを作り、その上にデータプロダクト・業務支援プロダクトを展開していきます。破竹の勢いでプロダクトを立ち上げ、様々な不動産アセットのそれぞれの業務に適した形へと進化させている最中です。

estieは商業用不動産に特化したVerticalなコンパウンドスタートアップであるため、ある企業XはプロダクトAとBを使い、ある企業YはプロダクトBとCとDを使うということが多く発生します。アカウントマネージャーが顧客の課題を紐解き、必要なプロダクトを提案しクロスセルを達成しまくっている（これもコンパウンドスタートアップの価値）ので当然ですね！

採用面談などで社外の方にこのようなご説明をすると、特にデザイナーやデザインエンジニア・フロントエンドエンジニアの方々から「どうやって複数プロダクトの整合性を担保しながら、スピーディな開発を実現していますか？」というご質問をよくいただきます。

この記事では、きっと最頻出であろうこの質問に対する回答として荒井からは「デザインレビューの仕組み」を、kyoncyからは「デザインシステムの取り組み」をご紹介します。
DesignOpsは、People・Tools & Infrastructure・Governance・Workflowの4つから成る定義をよく目にしますが、この記事でご紹介する取り組みはWorkflowに分類されるものです。
それでは「コンパウンドスタートアップのプロダクト開発を支えるDesignOps」のその1、「デザインレビューの仕組み」から参ります！

デザインレビューの仕組み

estieにはデザイナー・デザインエンジニアが7名（業務委託の方を含めると10名）在籍しており、私1人しかいなかった時代とは違って相互にデザインレビューができます。
これだけのプロフェッショナルが揃えばきっとデザインレビューをするたびに1人では得られない気づきを得られるのですが、デザインレビューはコンパウンドスタートアップと相性が悪い側面もあります。

estieの日常は、まさに束原が「コンパウンドスタートアップに潜む矛盾と困難、その先に広がる世界」で示している図の右で、本当に各所で祭りが起こっています。

この状況下でProduct AのデザインをProduct CやEのデザイナーがレビューすることはどれだけ効果的でしょうか？コンパウンドスタートアップにおけるデザインレビューの難しさはここにあります。
「デザインレビューして文殊の知恵でデザインクオリティ上げようぜ！」という正論ぽいことは、各自が各自の領域でフォーカスし、それによって生まれるクオリティとスピードで勝負をするestieではうまくハマりません。レビュイーにとってはコンテキストの共有コストが重く、レビュワーにとってはキャッチアップコストが重いのです。
ということで、estieではデザインレビューを以下のように整理しています。

デザインレビューは必須と任意に分ける
必須か任意かは、そのデザインがOne-Way DoorかTwo-Way Doorかによって決まる
One-Way Doorのデザインとは、一方通行、つまり一度出してしまったら修正できないものでレビューは必須。例えば展示会のブースやポスター・プレスリリースに使用するクリエイティブ
Two-Way Doorのデザインとは、行ったり来たり出来る、つまり後からの修正も可能なものでレビューは任意。例えばプロダクトのUI

ちなみにこの整理はジェフ・ベゾスが2010年に株主へ宛てたレターの中で言及したAmazonの意思決定スタイルを真似しています。

one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

出展：EX-99.1

私はこの整理を度々口にしており、特にestieにジョインしたばかりの方には念入りに伝えています。

コンパウンドスタートアップには「相互に連携した製品ポートフォリオ」が必要じゃないの？と思われるかもしれませんが、まずは個として強力なプロダクト、これが不可欠です。
個のプロダクトとして強力だからこそ相互に連携した時の爆発力が凄まじいのです。このコンセプトを先に伝えておかないと、「プロダクト横断で一貫性のあるデザイン」のような横軸の観点を気にして各デザイナーの担当プロダクトへの出力が最大でなくなってしまいます。

また、「事件は現場で起きているんだ！」ではないですが、各プロダクトで必要とされるデザインは担当デザイナーが最もよく分かっていると心底思っています。仮にデザインを外してしまったとしても、Two- Way Doorのデザインだからこそ、社内メンバーや顧客と会話しながらまた改善すれば良いのです。最も避けるべきは改善の歩みを遅らせることです。

一方、「とはいえ顧客基盤が大きい成熟したプロダクトではデザインレビュー必要じゃないの？」という考えもあると思います。実際、弊社のプロダクトにおいてもフェーズは様々で、求められる質や飲み込めるリスクは各プロダクトで異なります。それらを十把一絡げに同じルールを適用するのは適切でないという点は同意ですが、社内を見てみると、例えば最多のユーザー数を持つestie マーケット調査のデザインにおいてはそのプロダクトを担当するデザイナー・デザインエンジニアによってデザインレビューが生まれており、各所で然るべき進化が見られます。このようなことから、当面は今の方針で進もうと思っています。
ちなみに、このコンセプトを支えているのは強力なデザイナー・デザインエンジニアの存在です。彼・彼女らの圧倒的な力がestie流の分散とフォーカスを成立させています。

他方で、One-Way Doorのデザインではデザインレビューは必須で、少なくともデザインの責任者である私は必ず見させてもらうと伝えています。

estieは通算4回も展示会に出展しており、その度にブースやチラシを内製しています。また、イベントやプレスリリースに必要なクリエイティブもデザイナーが担っています。少なくない頻度でOne-Way Doorのデザインが求められますが、その際はデザインレビューを実施しています。ちなみに来月行われる不動産テック EXPOにも過去最大コマ数で出展いたします。ぜひお越しください！

こういったデザインは一度世に出したらそれで終わりで、そのクリエイティブによってestieの印象が決まる、まさに一方通行のデザインです。世に出してから「やっぱこっちにしよ」がほぼ不可能なデザインは予めデザイナー・デザインエンジニア総動員で知恵を絞りたいと思っていますし、最後は私が関門的に機能します。

以上がコンパウンドスタートアップを支えるデザインレビューの仕組みです。私のご紹介はコンパウンドスタートアップの「相互に連携した製品ポートフォリオ」を作るために必要な「強固な単一プロダクト」をスピーディに実現するための取り組みでした。ある種の割り切りをすることで、各所で祭りを起こすestieならではの分散とフォーカスを成り立たせています。

次にkyoncyから、本丸の「相互に連携した製品ポートフォリオ」を作るためのデザインシステムの取り組みをご紹介します！

デザインシステムの取り組み

後半部分担当のkyoncyです🐧

前半部分では、分散＆フォーカスによって複数プロダクトの立ち上げを同時並行で進める現在、プロダクト横断の一貫性は意図的に劣後させ、プロダクト単体の検証スピード・価値向上を優先していると記しました。
ただ、今後はコンパウンドスタートアップの価値である「相互に連携した製品ポートフォリオの構築」への挑戦が待っています。その際、プロダクト横断で一貫性のあるデザインを作る仕組みが必要不可欠なため私たちはデザインシステムの構築に着手しました。

estieには1年ほど前からデザインシステムチームが存在しているのですが、2023年に入ってからプロダクトを横断したチームとして本格的に動き出しています。どのような意図でデザインシステム構築の取り組みを行なっているかはestieにおけるデザインシステムの必要性と取り組みを読んでいただけたらと思います。

UIの統一を目的にすでに複数のプロダクトでデザイントークンやUIライブラリをパッケージとして配信しており、引き続きコンポーネントの拡充やガイドラインの整備を並行して行なっています。

UIライブラリの提供が全然追いつかない…

専任でデザインシステムを見る人がいない中で構築と導入を進めており、初めのうちは粒度をなるべく小さくして配信していたためユースケースを全てカバーしたコンポーネントを作れていませんでした。
しかし、プロダクトの立ち上げや成長の速度が爆速でUIコンポーネントの開発が間に合わず、プロダクト毎のリポジトリに似たUIのコンポーネントが作られている状況の改善が進んでいませんでした。

そのため現在は（デザイントークンをよりセマンティックにすることと）UIライブラリの提供・導入速度向上が最優先事項となっています。

ここから盛り返していくよ！

ではUIライブラリの提供速度を10xするためにどうするかなのですが、全てを内製で作る限界に来たためestieでは全て内製することを辞め、ライブラリに頼る選択をしました。ライブラリの選定にあたってはヘッドレスUIが流行っているためRadix UIを導入しました。
ヘッドレスUIは簡単にいうと「スタイルを持たないUIコンポーネント」のことです。

Material UIやChakra UIなどと比較すると分かりやすいのですが、これらのライブラリは初めからスタイルが当たっている状態で提供されています。そのためUIデザインにかかるコストがとても小さくなるメリットはありますが、組み立てた画面からはこれらのライブラリっぽさが強く出てしまい会社やサービスとしてのブランディングと合わないことがありました。
また、これらのライブラリを使用していてスタイルを変えたい場合には上書きする必要もあります。上書きする箇所が増えてしまうと、元のスタイルが何だったのかが把握しにくくなりメンテナンスが大変になります。デザインシステムチームの立ち上げ当初はMUIやChakra UIをベースにすることも案としてありましたが、これらを理由にestieでは採用しませんでした。

そこでこれらの課題を解決するヘッドレスUIライブラリが登場しました。
コンポーネントの挙動を提供してくれており、アクセシビリティやセマンティックHTMLを意識した作りになっています。そのためスタイルを当てるだけでコンポーネントを提供できるようになりました。

最初はRadix UIを検討していたのですが、Hikaru（@hikrrr）が担当しているプロダクトで導入している Mantineをオススメしてくれました。
MUIやRadix UIとも比較してコンポーネントやhooksの種類が豊富でDatePickerやCarouselなどのコンポーネントにも対応している（個人的にDatePickerのUIが良くて心を奪われた）ため、1から作る必要がなく爆速でUIライブラリを提供できます。

その他、

Next.jsやViteで使用する際のテンプレートやpropsなどドキュメントが整っている
Vanilla extractを推している（現状はemotionを使ってるので乗り換え予定）
バージョンアップが活発に行われている

という特徴があることも採用に決め手になりました。現在はこれまで提供していたコンポーネントを置き換えているのですが、考慮しきれていなかったアクセシビリティの問題が解決されたので1から自作してた大変さはどこへとなってます…
estieではUIライブラリの構築だけでなく各プロダクトでもMantineを利用する方針にしたため、各プロダクトで作成したMantineベースのコンポーネントをUIライブラリに輸入しやすくなると考えています。
ただでさえMantineを活用してUIライブラリを構築していくので爆速ですし、各プロダクトで作られるMantineベースのcomponentを取り込めばさらに爆速になります。こうしてコンパウンドスタートアップとして「相互に連携した製品ポートフォリオ」を目指してもプロダクト横断でUIの破綻がない状態を爆速に達成していきます。

以上がコンパウンドスタートアップを支えていくデザインシステムの取り組みです。
「相互に連携した製品ポートフォリオ」を作る上で考えなければならないデザインの一貫性について、デザインシステムチームが現在に至るまでの道を紹介しました。デザイナー・デザインエンジニアが個々の強力なプロダクトを作りつつUIライブラリを提供することでより高速にプロダクトを作っていきます！