カナリーのプロダクトデザイナー小澤です。
不動産会社向けSaaS「カナリークラウド」では、メイン機能の改善だけでなく、ユーザーボイスを丁寧に拾い上げ、新しい価値を生む機能開発を行っています。その一つとして先日ホーム画面を新設、および「要対応タスクの管理機能」のリリースを行いました。
サービスの構造から理想的な体験を考え、お客様の要望を解釈して、ミニマムに新機能リリースをしていく流れをまとめます。
まず、カナリークラウドがサポートする「不動産仲介」の仕事をざっくり整理します。
仲介会社のゴールは「顧客を契約締結まで導く」こと。
問い合わせから希望物件の提案、内見、審査、契約手続き…とステータスを前に進めていくために必要なことを、日々のタスクに落とし込みながら働いています。
そして、カナリークラウドは、その顧客の状態を仲介会社が管理するためのデータベースを提供しています。
この顧客データベースは「顧客」というオブジェクトをベースとした画面です。
一方で、カナリークラウドを使うお客さまは、顧客のステータスを「成約」に近づけていくために、顧客それぞれの状態から「次にやるべきタスク」を読み取っていることがわかってきました。
しかし、カナリークラウドがもともと想定していた主要オブジェクトは「顧客」や「メッセージ（やり取り）」のみ。顧客やメッセージ画面から、必要に応じてユーザーが “自分でタスクを考え、管理しなければいけない設計” だったのです。
当時、お客さまからは「カレンダー機能の改善要望」が多く寄せられていました。
ですが、それらを改めて分類すると、
スケジュール改善を本当に望む声（カレンダー自体をもっと見やすく・使いやすくしてほしい）
実はタスク管理の必要性を訴えている声（顧客のステータスに連動してタスクを一括管理したい）
という2種類に分けられるとわかりました。ここから「ユーザーは単に日時管理を望んでいるのではなく、顧客の状態に応じて発生するタスクを一元的に把握したいのでは？」という見方が強まりました。
ここまで整理していくと「やはり、お客さまは、タスクを中心に考えたい時もあるのでは？」と確信が得られてきます。そこで、タスクというオブジェクトを中心とした画面を、新しい価値として提供できないかデザイナー主導で検証を進めることにしました。
開発リソースが限られた本ラインで、いきなり新機能開発を始動させることは現実的ではありません。本ラインの外で、業務委託のデザイナーに協力をお願いし、先回りしてUIプロトタイプをつくることにしました。
理想のUIを一気に発散しつつ、既存のコンポーネントにとらわれず、「もしカナリークラウドをゼロから設計し直すなら、タスク管理を中心にどう組み立てるか？」を考えます。
これは、すぐに実装に進めるためのものではなく、可能性を検証するためのものです。既存のコンポーネントも一旦使わず、今の機能・UIの課題を解決できそうな理想的な案をひと通りつくってみることを目的としています。
例えば「顧客データベース画面」「顧客詳細画面」「メッセージ画面」などの既存の画面も、今集まっている要望をひと通り解決できるようなアイデアとしてつくり変えてみます。
理想のUIを用意しながら、想定を深めつつ、「タスクの管理機能」の開発タイミングを探っていました。
同時期に、「お客さまから要望が集まってきたので、カレンダー機能の改善を行いたい」という相談をPdMからもらいます。
当初の相談内容としては「すでに提供しているカレンダー機能の改修」がメインだったのですが、ここまでにまとめたような準備をしていたため、自分としては「これはタスク管理機能の話なのではないか？」とあたりがつきました。
なので、少し話を整理して、「カレンダー機能の改善」と「タスクの管理機能の新規開発」の両方が必要であることを示します。
さらに、チームで合意をつくるために、「カレンダー機能の改善で解決する要望」と「タスク管理機能で解決する要望」の2つに要望を分類しました。
これら2つの要望の区分ごとに、カレンダー機能のプロトタイプと、タスク管理機能のプロトタイプを用意。「要望+プロトタイプ」を同時に見せながら、要望解決の方向性をすり合わせています。
タスク管理機能に着手していくことが決まった後は、より厳密に体験を整理するためにサービスブループリントをつくったり、理想のUIを引用しつつ、実現可能性を踏まえたデザイン案を用意していくことを行いました。
少し補足すると、カナリーではこのように施策の意思決定に要望を引用できるように、お客さまからの要望を一覧で探せるデータベースを用意しています。これらの声を用いて、上記のような施策の根拠づけを行います。
新しい機能は不確実性が高いため、大きな画面改修を伴う実装をいきなり行わず、まずは「ホーム画面」という独立ページを新設し、リリースする戦略を取りました。
「タスクの管理機能」は、今後はどこかの既存画面に組み込むこともありえますが、この段階では「タスクというオブジェクトを中心にした体験」が求められるのかどうかを速く見極めることが重要なので、検証しやすいよう独立したページとして切り出しています。
また、速く検証を行うためには多くのユーザーに触れてもらう必要もあるので、全ユーザーが気づくであろうトップページに表示するようにしました。(これまではトップページ、という概念はカナリークラウドにはなかったのですが、今回の検証に際して新規に追加しています。)
このような経緯で、2024年7月、ホーム画面が新設され「要対応タスクの管理機能」が無事リリースされました。
すでに、多くのユーザーの利用が起こっています。既存のユーザーからも好評で、かつ、新規のお客さまと話すタイミングでも価値に感じてもらえており、受注が起こりやすくなっています。
カナリークラウドでは、新規機能の開発や事業のバーティカル展開を今後ますます進めていきます。そのために必要なのは、より早い段階での機能検証と、施策意思決定を支えるデザイン基盤です。
例えば、すでに、以下のような仕組みは構築してきました。
==
- ユーザーボイスのリソース化
- ユーザーからの声をデータベース化し、いつでも施策検討の材料にできる仕組みがある。
- 複数プロダクトに横断できるデザインデータ管理
- 前回の事例でも公開したように、共通デザイン基盤を整え、UI検討のスピードを上げる。
==
今回のタスク管理機能は、デザイナーが先行して仮説検証をリードし、プロダクト開発全体を進めるうえでの「成功パターン」を一つつくった事例です。これをきっかけに、チーム体制をさらに強化し、常にユーザーボイスから隠された「本当の要求」を読み解き、プロダクト価値の最大化につなげていきます。
