カナリーのプロダクトチームでは、Figma Makeを使ってマスターのデザインに近い形でのプロトタイプ生成ができるようなワークフローを整備しています。
このフローを構築した目的は「無数の新機能の価値検証を早める」ことです。
これにより、初期の価値検証のためのプロトタイプを行う速度が大幅に上がっています。さらにPdMや営業メンバーへの浸透も終えていて、彼らがスピーディーにプロトタイプをつくりお客さまから反応を回収していく価値検証の活動に多くの時間を使えるようになっています。
このフローをつくった背景や、具体的な現在のフローの内容、プロダクトチーム全体への浸透方法についてまとめます。
カナリーは、ダウンロード数550万件を突破したマーケットプレイス「カナリー」と、不動産業界におけるVertical SaaS「カナリークラウド」を運営しています。
不動産業界は、深刻な人手不足と人件費の高騰が進む中で生産性向上が喫緊の課題となっています。一方でアナログな業務も根強く残存していてレガシーなシステムがまだまだいくつもあり、それらを置き換えていくことが必要な状況です。
なのでカナリーは現在、1社1社の不動産事業者と深く連携しながら新機能や新プロダクトを無数に立ち上げていく戦略を取っています。その実現のためにもいくつもの不確実な新機能の価値検証を高速で進めていく必要があります。
僕はデザイナーの視点から、カナリーのプロダクトチームが価値検証を早めるためのボトルネックは「精度の高いプロトタイプをつくるコスト」だと捉えていました。
カナリーではプロダクトチーム全体にデザインスキルがある程度浸透し始めていて、例えばPdMも自分でFigmaを触ってある程度精度の高いプロトタイプをつくれるようになっています。(この浸透のためにデザイナーが行った活動の事例はこちら)
一方で、さらに価値検証を早めようと思うとまだいくつかの課題が残っているのが実態でした。
課題の一つは、暫定的なプロトタイプが意思決定されるまでの期間が長くなっていることです。価値検証を早めるためには、できるだけ早くプロトタイプを用意してそれを社内やお客さまから何度もフィードバックをもらって磨いていくプロセスが必要です。
対して、どうしてもデザインに慣れていない時はプロトタイプを用意するまでに時間がかかりすぎてしまいます。さらに新機能は新たな要望をもらう中で日々仕様も変わっていくため、モノにするまでに時間がかかるといつまで経ってもプロトタイプがFIXしない状態になってしまいます。
さらに別の課題として、エンジニアメンバーとのコミュニケーションエラーがありました。
カナリーではデザインを途中段階でもオープンに共有しながらつくるスタイルを取っているのですが、あくまで価値検証の途中である前提で途中段階のデザインを共有したのにエンジニアからは「この仕様はどうなっていますか？」など具体的な部分に質問がくるようなことも多く起こっていました。
プロトタイプのクオリティが低い状態でエンジニアに共有すると、検証フェーズで本来議論したい体験の話ではなく具体的な仕様のあれこれが気になってしまいます。とはいえ検証フェーズのプロトタイプのクオリティを磨き込もうとすると時間もかかりすぎるため、どのようにバランスを取るべきか悩んでいました。
このような課題を解決してUI制作の時間よりも根本的な体験の議論やお客さまへの価値検証に時間を使っていけるように、Figma Makeでマスターに近いデザインプロトタイプを誰でもすぐにつくれるようなフローを整備しました。
冒頭にも書いたように、このフローによって大きくUI制作コストが下がっています。
例えばデザイナーである僕ならばカナリークラウドの画面の1機能のデザインであれば、1時間程度でコンセプトに沿った仕様・デザインデータをFIXすることができるようになっています。(以前は3時間から半日ほど調整に時間がかかるものも)
フローが運用されるようになるまでの具体的な流れを「セッティング段階」「実運用段階」「浸透段階」の3つに分けてまとめます。
まずは、実画面に近いデザインが生成されるようにFigma Makeマスターデータファイルをセッティングするところから始めます。
実業務で活用しようと思うと、出来るだけ実際のプロダクトのデザインとズレがないようなアウトプットが生成される必要があります。
私は解決策として、現在リリースされているプロダクトのFigmaマスターデータ (または実画面のスクショ) をFigma Makeにすべて取り込んで生成用のマスターファイルを用意しました。
何度も言いますが、これはプロトタイプを早く生成して価値検証を進めることが目的です。なのでデザインデータの調整は生成後に仕様FIXしてからデザイナーが行うことにしています
そのため、デザインシステムを読み取らせて完全なUIを1発で生成するようなことは目指していません。カナリーのUIはコンポーネントでいうとシンプルなものなので、実画面のスクショを入れ込むだけでもプロトタイプとしては十分精度の高いアウトプットが生成されます。(しかもこのセッティングの考え方なら、半日〜1日も時間を使えば終えられます。)
実際に業務でプロトタイプを生成する流れを、toC側のプロダクト「カナリー」の一機能のデザインがFIXするまでの実例でまとめます。
まず、午前11:00ごろにPdMから検証したい項目のイメージが伝えられました。(この時はまだデザイナーでフローを検証している段階だったので、PdMが生成をすることはしていませんでした。)
それを受けて、すでに用意していた機能別のマスターファイルの該当するものを開きFigma Makeに仕様を伝えます。
そうすると、すぐにある程度仕様を満たしたプロトタイプが生成されました。
まだこの時点では、以下のような点が満たされていないと感じたので細かくレビューしながらプロトタイピングを進めます。
コンポーネントの統一 (角丸など)
ボタンコンポーネントの表現・視認しやすさ
グラフィックのトーン
最終的に十分プロトタイプレベルでは仕様を満たしているものができました。これをPdMに共有して仕様の合意を取ります。朝11:00にPdMから仕様のイメージが共有され、合意が取れたのは午後1:00だったので、約2時間で仕様が固まりました。
仕様がFIXした後は、リリースクオリティに仕上げるためにデザイナー側でFigma上でデザインデータを精緻にしていきます。
今回でいうと、「ボタン」「チェックボックス」などのコンポーネントは現状のデザインシステムとズレがあったので、そこは微修正しました。仕様レベルで修正するところはすでにないため、ここまで終わった段階でも午後2:00、つまり仕様共有されてから約3時間ですべての作業が完結しています。
このような流れでプロトタイプを生成することが、toC側の「カナリー」とtoB側の「カナリークラウド」の両方でできるようになっています。
デザイナーチームでの運用がかなり本格化してきたタイミングで、本来の目的であるチーム全体での価値検証速度を上げていくために、PdM・エンジニア・営業のメンバーに対してこのフローを浸透するためのワークショップを行いました。
浸透に向けてまずは職種別の期待や目的を整理していくことから始めました。
PdMと営業マネージャーに壁打ちさせてもらい、ここまでデザイナーで検証してきたことを伝えた上で期待や課題感をヒアリングします。
ヒアリングからそれぞれの職種で大きく課題感がある部分や、できるようになると嬉しいことが理解できたのでそれを一枚のスライドにまとめつつ、各職種に対して浸透に向けたワークショップ開催を呼びかけました。
プロダクト組織 (PdM/エンジニア) と、営業向けにそれぞれワークショップを開催しました。
ワークショップの冒頭では、目的を共有した上でできることのイメージを掴んでもらうために各サービスのプロトタイプ/Make生成ログを共有して触ってもらいます。
さらに、参加者に実際にその場でUI生成を試してもらいました。
まずはデータをつくってもらうところから。セッティング済みのマスターデータが壊れないように、必ず複製をしてもらうようにしています。
それぞれコピーしたデータを使って、手元でプロトタイプをつくってもらいます。
生成を試してもらった後は、精度を上げていくためのいくつかのTipsを共有しています。つくったプロトタイプの中で特定のdivを変更したい場合の手順などもインプット。生成のコツやイレギュラーな場合の対応についても現時点で検証できていることを伝えました。
ワークショップを経て、PdMや営業メンバーがプロトタイプをつくる行動が生まれるようになりました。
さらに組織としてこのフローを浸透していくために、プロダクト組織としてのワークフローを役割別に再整理して共有しています。
ここではプロトタイプを生成するのはPdMが担当するように意思決定していて、デザイナーはその後のLo-Fi、Hi-Fiなデザインデータを調整していくところに役割を持つこととしています。
このワークフローを導入したことで、カナリーでは冒頭にも書いたように新機能の仕様決定までの時間が大幅に短くなっています。
さらに、PdMのプロトタイピングコストが大きく下がり、仕様を自分でプロトタイプすることもすでに定着しています。これまでもデザインデータを自分でつくっているPdMは多かったのですが、そのような方でも1時間かからずプロトタイプがつくれるようになっていて全体で「つくるコスト」が下がっています。
まだタイムリーに検証している状態ですが、これから営業メンバーが自分で個社別の細かなプロトタイピングを行い受注率を向上させたり新機能のタネとなるインサイトを回収していく動きも増えていくだろうと考えています。
目的に立ち帰るとこのワークフローは、「価値検証を早める」という狙いでつくられたものです。
現在のカナリーの事業では、不動産事業者の課題を解決する新機能を速く検証していくこと、さらに個社別の細かなインサイトを取ってこれることが競争優位になります。
なので、プロトタイプが速くつくれるようになったということで終わらせるのではなく、ここからは価値検証をより精度高く進めていくための仕組みづくりにも着手していかなければいけません。
例えば、それぞれの営業メンバーが自分でどんどんプロトタイプをつくってお客さまに見せて、、という活動を自由に進めるのはリスクもあるだろうと思っています。具体物でお客さまからより深い要望や期待を引き出すことは大切ですが、つくる可能性が低いものを見せてしまうとミスコミュニケーションになってしまう場合もあります。
これは一例ですが、つまりは簡単にプロトタイプをつくることができるという状況をうまくコントロールしていかなければ価値検証は早まらないということを肝に銘じておく必要があります。
今後は「いかにチームとして何を検証するかを揃えられるか」「チーム全員で筋が良い検証を進められるか」ということが論点になります。そのためにもお客さまとの接点でどういうインサイトを回収し、どうその情報をプロダクト開発につなげていくかを仕組みとして整備していこうとしているのが現状です。
今回の検証によって、カナリーとしての関心が「どう早くつくるか？」というフェーズから「どう筋の良いものをつくるか？」というフェーズに変わってきています。
最後にこのような検証を進めているカナリーデザイン組織としてのスタンスをまとめておきます。
現在カナリーのデザイン組織はプロダクトデザイナー2名、あとは数名のパートナーで構成されています。私たちは、これからも最小のデザイン組織体制をできるだけ維持して組織を運営していきたいと考えています。
私たちは市場的には後発でデザイン組織を立ち上げている立場です。この状況をチャンスと捉えて、これまでと同じようなデザインプロセスで組織を設計するのではなく、最初から新しいデザイン・開発ワークフローに合わせて組織を構築しようとしています。
今回のようなフローを育てていけば「つくるための人員」はほとんど必要にならなくなります。一方で「組織全体でどうコスト低くプロトタイプができるか」「どうすれば価値検証が早められるのか」というように、事業フェーズに合わせた課題解決のために開発プロセス全体をアップデートさせていける人員はこれからも必要です。
私たちは、そのような「事業課題解決のための開発プロセスをデザインできる人」「インサイトをうまく集めて価値検証を強く進めていける人」をカナリーのデザイナーとして受け入れていけるようにしたいと思っています。
デザインからカナリーの事業フェーズを進めていくために、ここからも実験を重ねていきます。