こんにちは、デザイナーの戸谷です。
事業推進において、プロダクト開発の次の一手をどうするか？を決めるのは難しい問題です。やりたいことや、取り組むべき課題の選択肢は無数にあります。
次の一手に「正解」はないからこそ、議論と対話を通じて、チームとして納得感のある仮説をもち、検証しながら前進できる工夫をすることが必要だと考えました。
今回は、Assuredで昨年12月にリリースした新機能の検討プロセスを振り返りながら、議論と対話を進めた実例を紹介します。一例として、読んでいただければ幸いです。
発散と収束を繰り返し、課題と解決策を考える
全体としては、お客様の業務フローがこうあったらいいのでは？という To-Be の体験を描き、現実とのギャップを、すでに提供しているプロダクトをどう発展させていけば解決しうるか？を考えていきました。
課題の発見と定義、解決策の幅出しと計画立て、そしてその仮説の検証というように、発散と収束を繰り返して進めました。ベタなフローではありますが、各フェーズでどんな手法を使うとよさそうか？は、チームの特性や雰囲気、事業フェーズによっても異なるところかなと思います。
事業の可能性を探るために、見えている景色を具現化する
数多あるお客様が抱える問題の全体像、そしてチームメンバーがそれそれ思い描くプロダクトの未来像を知るために、まずは事業部全員が参加してのワークショップを開催しました。妥当な選択のために、なるべく多くの選択肢を洗い出すことを目的にしています。
ワークの手法としては、「価値マップ」づくりを参考に企画しました。Assuredが解決するセキュリティリスク評価業務には、複数のステークホルダーが登場し、業務が複雑に絡みます。その全体像や依存関係を把握するために、この価値マップを参考にしました。
課題を見つけるには、ユーザーリサーチをすべきときもありますが、今回はそうしませんでした。もちろん、日々の商談や過去のインタビューでお客様の生の声を伺っている前提ですが、Assued は市場的にも新しい試みであるため、マーケットインの考え方だけでは発展させにくい部分もあるのではないかと考えたからです。
ワークショップでは3つのグループに分かれ、「お客様が困っていること」をテーマにアイデア出しを行います。日々の商談議事録やプロダクトへのフィードバック、自身がチェックシート回答者やセキュリティ担当者として感じている観点も参考にしながら、どんな価値が存在するかを次々に挙げていきます。
全員参加にしたことで、バリエーションが出せたこと以外に、各自の視座や見えている景色を把握することができて、組織開発の観点からもやってよかったと感じました。
事業とお客様の現状を具現化し、取り組む課題を探る
価値マップにすることで、複数の依存先がある、レバレッジが効きそうなポイントがあることがわかってきました。ここが今後の機能拡張の足がかりになったり、既存の機能に対しても良い影響を及ぼすのではないかと仮説をもちました。
その仮説がビジネスとユーザーの両面に具体的にどのような影響を及ぼすかを考えるために、「グロースサイクル」と「ストーリーマッピング」の考え方を参考に、収束をさせていきました。ビジネス観点が強くなりすぎてユーザーの体験を毀損しないように、逆に課題を解決できても収益性が考えられない、などといったことがないように、両方の視点を忘れずに議論していきます。
ビジネス上、詳細には触れられませんが、事業観点でグロースサイクルを描くことで、今回仮説をもったポイントがユーザーの継続的な利用や今後の収益性、プロダクト拡張の土台になるかなど、良い影響を及ぼしそうかを検討しました。
また、ストーリーマッピングで業務フロー観点での課題も整理しました。業務フローを横並びにした際に、現在提供している機能はどこにどんな価値をもたらしているか？仮説として考えている機能はそれを相互に増強するものになりうるか？などを考えていきました。
解決策のアイデアを具現化し、提供価値をシャープにする
ここからのフェーズは、アウトプットをシャープにするため、事業長、プロダクトマネジャー、ドメインエキスパート、私の4人で進めました。
取り組む課題と、理想的なユーザーストーリーが、サービス台帳やサービス検知の方向性に固まってきたところで、それをどのように実現していくかを考えました。
今回の機能では、どんな情報が管理できるとユーザーにとって嬉しいか、今後の機能拡張性がありそうかを考慮するために、「OOUI」でいうところのオブジェクトのプロパティ（= 台帳でどのようなデータを扱うか？サービスとどう関連するか？）を議論しました。
このフェーズでは、特にドメインエキスパートから「最低限ここまでの機能だけでも提供されれば、お客様に価値提供できる」「この情報は、このようなときに活用する」など、具体的な仮説をもらうことができ、議論も盛り上がりました。
その後、その結果をギュッと詰め込んだ画面のデザインを考えていきます。「Lo-Fi プロトタイプ」を FigJam 上で作成し、手描きの画面や付箋を使ってアイデアを出していきました。
はじめはあえて夢をすべて詰め込んだような全部入りのプロトタイプを作成し、それからどんどん削ぎ落としてシャープにしていくことで、プロダクトアウトすぎてお客様を置きざりにすることのないよう、もしくは足元の課題にフォーカスしすぎないように、バランスをとることに注意しました。
完成形に近い画面を具現化し、チームからの意見を引き出す
Lo-Fi プロトタイプをもとに、既存のプロダクトを拡張する際は、どのような順番で理想状態にもっていくとユーザーのハレーションが少ないか。実現可能性や事業計画を考慮すると、どこまでが MVP (Minimum Viable Product) となるのか、といったことを考えてつつ収束させていきます。
ある程度方向性がまとまった段階で、既存の Components を使い工数をかけずに Hi-Fi プロトタイプも用意しました。誰が見てもイメージしやすくなるため、チームに共有してビジネス開発メンバーから意見をもらったり、エンジニアと具体的な要件を詰めていくことができるようになりました。
ここでの議論を経て、より具体的に初期リリース時の要件と機能拡張時の要件にまわす部分の切り分けをしながら、プロトタイプも随時アップデートしていきました。
商談におけるデザインを活用した仮説の検証
ここまでで、チーム内の納得感はそれなりに醸成できましたが、まだまだ世の中に出ていない仮説のままです。
そのため、社外に向けたニーズ検証のアプローチとして、ビジネス開発メンバーが、プロダクトの構想と画面イメージを商談資料に掲載し、お客様にお見せして意見をいただくなどの動きもありました。Figma のデザインを見たメンバーが主体的に検証を進めてくれたことをとても嬉しく感じました。
具現化するとお客様も含めて、誰もが議論に参加しやすくなり事業がより前に進みやすくなるなと思いました。
こうしたプロセスを経て、初期バージョンの機能リリースに至りました。リリース後にもお客様から様々な声をいただき、PSF (Product Solution Fit) そして PMF (Product Market Fit) に向けてビジネス、プロダクトの両面で改善活動を続けています。
具現化によって議論と対話が生まれる
具現化すると、社内外問わず、プロダクトに関わる人々が議論に参加しやすくなり、次に提供すべき価値を考えやすくなります。「こういうイメージですか？」「こういうことって予定してますか？」「こうなった方がいいのでは？」「これお客様からも話が出たので次回話してみます。」などの声が挙がり議論と対話が生まれることは、とても嬉しいことです。
今回は、発散と収束をさまざまな手法で繰り返し、共創しながら価値を整理してきたプロセスを紹介しました。ここで紹介したやり方も、引き続きアップデートして精度を高められればと思います。今回作った機能を磨きつつ、次の一手をどうするべきか？お客様や組織の現在をつぶさに観察しながら引き続き考えていきたいと思います。
