2024年10月にカナリーにジョインしました。デザイナーの寺本裕成です。前職では、株式会社サイバーエージェントにてソーシャルゲームのUIデザイナーを務め、その後ABEMAに異動し「ABEMA FIFA ワールドカップ カタール 2022」や「ABEMA de DAZN」などのメインUIデザイナーとして務めていました。
その経験を活かし、現在はカナリークラウドのUIデザインを担当しています。
不動産市場のDXを行うカナリーでは、不動産ポータルだけでなく、不動産事業者向けにカナリークラウドというSaaSも運営しています。
そんなカナリークラウドで、自分が入社後はじめに取り組んだのが、カナリークラウドのデザインシステムにつながる、Figmaのマスターデータ設計でした。
リリースされてから約2年ほどで、すでに多くのお客さまにご利用いただいている急成長プロダクト「カナリークラウド」において、今後の運用を見据えたデザイン負債の解消ができるように、デザインデータの整備に取り組みました。
今回はグロースフェーズのサービスにおける、デザイン負債解消の取り組みをまとめてみます。
カナリークラウドはリリースから約2年間で、すでに累計利用者 (エンドユーザー) は100万人を突破しており、プロダクトとして急成長をしています。
カナリークラウドは長らく、専任のプロダクトデザイナーが不在の状況で、スピードを優先しアジャイルでの開発を進めてきました。
その結果、ユーザーの課題に沿ったプロダクト開発を実現できた反面、多くのデザイン負債が溜まっていました。
カナリークラウドは市場的には後発で生まれた不動産向けサービスで、お客さまからシンプルさや使いやすさで選ばれている側面があります。このままデザイン負債を貯めていくと、この強みが失われてしまうことになるため、解決していく必要がありました。
とはいえ、カナリークラウドは現状急成長しているサービスであり、改善や新機能開発も日々行われている状況でした。
その中で、デザイン負債解消のプロジェクトを精度高く実現するためには、開発施策とのマルチタスクで進めることは非現実的だと考えました。
そのために、10月に新規のデザイナーとして入社した段階で、他の開発施策にアサインされる前にデザイン負債解消にリソースを集中して実現しようと考えました。
ここでデザイン負債を解消するためによくある思考だと、「UIをリニューアルしたい」と思うかもしれませんが、すでに多数のお客さまが利用している大きなサービスではリスクが大きく実現性が低くなってしまいます。
そこで、問題をブレークダウンし、まずは現状のマスターデータを用意することからはじめました。
このマスターデータによってデザイン負債を誰でも把握出来るようになり、エンジニアとの共通認識を持つことで、その後適切なタイミングでスムーズな意思決定を可能にします。
このように、形骸化させないデザインシステムをつくるための「タネ」のような位置付けとして、マスターデータ化を進めました。ポイントとしては、以下の4つを意識しています。
デザイン負債が新たに発生しないマスターデータと運用プロセスの構築
「無駄」と「漏れ」のないマスターページ管理
「ローコンテクストコミュニケーション」を目指すドキュメンテーション
職能で閉じずチームで丁寧に共有
カナリークラウドでのマスターデータ化のポイントとして、負債が解消された理想のUIコンポーネントをつくるのではなく、あえて現状の負債を残した状態でまとめていくことを意識しています。
前述の通り、理想的なUIコンポーネントをつくったとしても、すぐに実装に落とせるわけではなく、デザイナーの自己満足のようなアウトプットに留まってしまいます。
負債はあるとしても、現状のマスターデータができれば、デザイン作業や開発作業の効率化が行われます。
その上で、改善すべき負債部分を把握できるようにしておき、機を見計らってUI改善に繋げる、という二段構えの目的を意識して設計しています。
より具体的には、ポイントが3つあります。
現状が把握できる上で、理想状態が分かるデータ設計
運用しやすいルールづくり
負債を産まないデータ管理
コンポーネントの設計において、あえて現行データの分岐はそのまま残しつつ、理想設計は可視化するようにしています。
長くマスターデータのない状態で開発を進めていたので、同じコンポーネントの役割でも見た目の異なるコンポーネントがあったりします。すぐには変更できないので、差分のあるものも意図的に残しつつ、適切でないことを明示しておきます。
命名規則などは運用しやすいように「分かりやすく、複雑にならない」ルール設計を意識しています。
具体的には、「汎用コンポーネント」と「汎用コンポーネントを構成するパーツ用コンポーネント」で命名を分けるようにしました。
汎用コンポーネントは、第一階層で分かりやすい単語で簡単に呼び出せるようにしています。(例えば「Button」「Tab」...)
逆に、単体で使わないパーツ用コンポーネントは「Parts」という階層を挟むようにしています。(例えば「Tab/Parts/CountTabTabItem」「Tab/Parts/NotificationTabItem」「Tab/Parts/IconTabItem」「Parts/NavigationItem」...)
そうすることで、パーツ用コンポーネントを適切な名称にするために冗長的になった場合でも、階層わけされているので許容できる命名にすることを可能としています。
汎用的なコンポーネントはすぐに呼び出せるようにしつつ、パーツ用コンポーネントを一つ下の階層にすることで「これは汎用的ではないものだ」とデザイン作業時・実装作業時に気づきやすくしています。
ここまでの設計で、汎用的に今後も活用してもらいたいコンポーネントと、そうではないコンポーネントが明確になっています。
データ構造を壊さない形で運用すれば、プラグインを使えばコンポーネントが現状どこで使われているのかをすぐに把握することができます。
そのためにも、あえて差分のあるコンポーネントを残す設計にしています。
ここで合わせて大事なのが「Detachしなくても成立するコンポーネント設計にすること」です。Detachされてしまうと、改善できるタイミングでコンポーネントがどこで使われているか分からず、対応漏れにも繋がってしまいます。
そこで取り入れたのがAtlassianさんのデザインシステムに利用されていた「SlotとSwap instance」で表現する方法でした。
例えば「FormModal」のデータならば、フォーム全体のスタイルは統一したものを用意した上で、その中のデータについてはレイアウトが崩れないように、以下の赤いエリアのような「Slot」という空のコンポーネントを入れ込む設計で構築します。
コンポーネントを階層化して、Slotの中身を自由に差し替えて変更できる運用にしています。
このように定義したコンポーネントを使って、各画面のデザインデータもつくっていきます。
あくまで現行の状態を表したマスターデータなので、UIのレイアウトは変更しません。コンポーネントを活用して、現行のUIで画面デザインデータをまとめます。
ここでのポイントは2つあります。
階層をわかりやすくまとめる
ページの変容もすべて可視化
マスターとなる画面データのつくり方として、画面遷移図をつくらないようにしています。
無数に画面や分岐があるので、遷移図のようにまとめるとむしろ全体観を把握しづらく、今後の変更を加えづらくなるためです。
カナリークラウドの場合は、ページ階層が明確になるようにまとめています。
こうすることで、シンプルに階層のつながりを俯瞰して理解しやすくなり、機能ごとの改善点を考えやすくなります。
マスターデータは、デザイナーだけが扱うものになっては意味がありません。
実装時に特に気になるであろう、イレギュラーな画面状態の変化についても、場合分けして該当画面の近くにコンポーネントの差分や、さまざまな状態をまとめておくようにしました。
今後のステップである「UI改善」「デザインシステム化」へとつなげていくためにも、今回のプロジェクトを一度きりで終わらせないことが重要です。
今後の運用に繋げていくために、以下の2つに取り組みました。
設計時に考えたすべての事をドキュメントとして整理
今までのコンテキストも可視化
今後デザインシステム化を進める時に、自分だけに知見が溜まっている状態にしないためにも、マスターデータ化に取り組んだ時に決めたことや、気づいたことをすべてドキュメントにまとめるようにしています。(SmartHRさんのデザインシステムを非常に参考にしました。)
また、デザイン負債がある箇所に関連する機能改善が生まれた時に、今後少しずつUIも改善できるように、現行verの何が問題で、こう変えると良いというメモも画面データ上に残しておくようにしました。
コンポーネントの命名規則など「なぜそのように考えたのか」「NGパターンは何か」といった何度も使うが忘れてしまう大事なことをまとめておくようにしています。
マスターデータ構築から作業効率化につなげるためには、開発チームのメンバーがデータを適切に読み取れるかが重要だと考えています。
その活用方法を浸透させるために重要なのが、エンドユーザーはもちろん開発メンバーにも便益がある状態を作ることでした。
このステップでは下記の2つを行いました。
なぜ行っているかを設計レイヤーから共有する
チームメンバーが活用できるように勉強会を実施
マスターデータ化を進めていく裏側で、現場のUIに対する課題認識をSlackでも頻繁にシェアしていました。
具体的な開発ラインに乗せるまでにはさまざまな検討が必要となりますが、それ以前に「今のUIのどこが課題なのか」については開発メンバー全体が理解できている状態にしておくことを意識しています。
デザインデータの完成度が高まってきたタイミングで、コンポーネントのつくり方やデザインデータの構成について実装関係者に浸透しようと試みました。
ここで「デザインデータできました！」とだけ伝えても、どのように活用するのかイメージしづらく運用されないことは目に見えていたので、マスターデータの活用方法が分かり、効率化ができそうだと思える状態にして浸透させることを意識しました。
そこで実施したのは、開発メンバーがデザインデータを理解+活用できるようになる事を目的とした「Figma勉強会」でした。
ただ「デザインデータが理解できるようになる/活用できるようになる」という目的だと、参加率や意欲が下がりそうだと思ったので、「デザインがつくれるようになる勉強会」というコンセプトで、みんなが気になりそうな勉強会に仕上げました。
最終的には、今回用意したマスターデータのコンポーネントを触るような時間を取り、結果的にマスターデータの活用方法が理解できるような勉強会の設計にしています。
このようなプロセスで、約1ヶ月の期間を経てマスターデータの整備を終えました。
まだ道半ばではありますが、具体的な効果も生まれています。
まずデザイン作業の効率が大きく改善されています。コンポーネントの構成が変わったことで物理的な速さはもちろん、機能ごとのデザインデータを俯瞰して眺められるようになったことで、全体のシステム設計をイメージしやすくなりました。
さらに、課題認識を垂れ流していったことにより、開発メンバーのUI改善意識が高まっています。現実的な改修は期間がかかるはずですが、これからさらに使いやすいサービスへと生まれ変わる土壌が確実にできています。
この事例をまとめている中で、つい先日、デザインシステム化に向けたプロジェクトも発足しました。マスターデータ化の次のステップ「UI改善」「デザインシステム化」へとすでに進み始めています。
今回のプロジェクトは、自分が入社して1ヶ月で行ったものでした。
いきなり何かの機能改善に取り組もうとしても、不動産ドメインという業界理解が難しいサービスではうまくいくかは読みづらいだろうと思いますが、デザインデータの整備から始めることで、サービスを俯瞰して捉えることができるようになりました。自分のオンボーディングとしても機能していたように思います。
また、カナリークラウドのような規模が大きく、すでに活用しているお客さまも多くいるサービスでは、デザイン負債を認識していても一気に改修することは現実的ではないと考えています。
今回のように、順を追って改修の土壌を整えておくことをファーストステップとすることで、グロースフェーズのサービスでも確実にデザイン負債解消を進められるのではないかと考えています。
カナリークラウドは、ありがたいことにお客さまから使いやすさを評価してもらっています。デザイナーとしては、その基準に達していくこと、超えていくことに真剣に取り組まなければいけません。
今回は、そのような価値の提供基盤になるようなマスターデータができたと考えています。
これからこの基盤とともに、カナリークラウドの提供価値をより高めていきます。
