こんにちは。Uniposでデザイナーをしています、ごきげんぱつじ(@gokigen_patsuji)です。
今年はスクラムチームのデザイナーとして新機能の価値仮説・ソリューション仮説の検証に捧げた1年でした。先日無事にベータ版をリリースでき、一安心しています。
今回はこの1年の検証期間中に直面した失敗と、それにどう対処してきたかについてまとめます。

失敗①：ステークホルダーの「これがあったほうがいいかも」を全部プロトタイプに反映しようとした

今回の検証テーマは「特に管理職の方を巻き込めるイメージが湧かず”ウチではうまくいかない”と感じるプロダクト利用前のお客さまに、どうしたらできそうだと自信をもってもらえるか？」でした。そのため、利用前のお客さまと話す機会が多いPMMメンバーと協力しながらプロジェクトを進めることになりました。

スクラムチームメンバーが知らないことをたくさん知っているPMMからのフィードバックはどれも確からしく見え、今思えば当時の私はいつの間にか「PMMに”これでイケそう！”と言ってもらえる仮説のプロトタイプを作ること」が目的になっていました。その結果「もっとこういう価値や機能があったほうがいいかも」「こういう感じのほうがお客さまに説明しやすいかも」を表面的に受け取ってプロトタイプに反映しては、なんか違うかも…と右往左往。この時のスクラムチームは、PMMが考える仮説を形にする人たちになりかけていました。

対処：フィードバックの背景を深掘りながら事実・解釈・仮説を切り分ける。仮説を評価してくれる人ではなく、お客さまにぶつける仮説を一緒に考える人として共創する。

ある日フィードバックをもらった際に「どこまでファクトなんだろう」という疑問が湧き、なぜそのようなフィードバックに至ったかを深掘って聞いてみました。すると、PMMが見聞きした事実、解釈、それらを踏まえての仮説が混在していることがわかりました。

そこから向き合う姿勢を変えました。PMMやその他のステークホルダーからのフィードバックの背景を深掘り対話する過程で、何が事実で何が仮説かが共通認識になるようにしました。また、メインターゲット以外のユースケースや、将来の展望的な価値についてのフィードバックについては「今私たちが確かめるべき仮説は何か？その仮説に必要な要素か？」という観点で議論をしました。

「PMMはお客さまにぶつける仮説を一緒に考える人」であり「スクラムチームとPMMあわせてひとつのチームだ」と考えて、事実や仮説が何かを共通認識化して取り組んだことで、いま本当に必要な価値に集中してスクラムチームが主体的に検証を進めることができました。

失敗②：社内での「こういう懸念・ネガティブなフィードバックがありそう」を全部解消しようとした

ソリューション仮説が具体的になるにつれ、色々なお客さま・色々なユースケースでの懸念事項が明らかになってきました。CSメンバーなど、スクラムチーム外からのフィードバックも多く集まってきました。

あらゆる懸念事項を解消しようとするあまり「検証のために最低限必要な価値・機能」が膨らみすぎて、到底終わらない激重プロダクトバックログになりかけていました。仮説Aを検証したいだけなのに、機能B(激重)と機能C(激重)を整備しないと機能提供できないかも…という状態です。

対処：「リリースして価値を届けるために、その懸念事項にどう対処するか？プロダクト以外で工夫できることはないか？」という思考に変える。

ある日もらったフィードバックをきっかけに、向き合い方がガラッと変わりました。

その後「こういう反応は仕方がない（受け止めつつ静観する）」と「これは絶対に回避すべき」の基準を決め、その基準をもとに作る作らないを判断するようにしました。またその基準をステークホルダーとも共有し、その懸念事項についてプロダクト以外の方法でどう工夫するかを一緒に考えました。
どのような思想作っているかや懸念事項への対処方法を伝えて期待値を調整することで、結果として機能Bや機能Cは実装せずとも活用いただける状態になっています。

さいごに

ここまでお読みいただきありがとうございます。
本当はあと2つプチ失敗があるのですが、全部書いているとクリスマスが終わってしまいそうなので後日続編を書こうと思います（圧倒的準備不足）。

不確実な問題に取り組むのは楽しいな〜！また明日から頑張ります。