こんにちは。スマートバンクでプロダクトマネージャーをやっているinagakiです。
これまで、新規プロダクトの立ち上げや既存プロダクトに新たな価値を付加するためのディスカバリーを行うことが多かったのですが、検討初期に議論で時間をかけすぎてしまったと感じることが多かったりします。
特にソリューションの方向性に関する議論が空中戦になりがちで、手よりも口ばかり動いて検討の進みが悪くなるという感覚があります。
今回はその課題意識と直近でやってみた工夫で良かったことについてシェアしてみます。
📝 前提
- 今回の話はtoCプロダクト固有な話な気がしており、toBプロダクトにおいても当てはまるかはわかりません。当てはまりそうなら教えてください。
- “空中戦”を防ぐために具体的なたたきをつくって議論すべきという観点では、プロダクトマネージャーに限らず、幅広く参考になりそうな話です。
抽象的な議論で時間を浪費しがち
0→1のプロダクト立ち上げや既存プロダクトに新たな価値を付加する状況において、課題の探索からソリューションの特定までの間に、抽象と具体を行き来して検討を深めることが重要になるのではないかと思います。
最初はN1の具体的な仮説から始まり、抽象化しながら探索を深め、普遍的で解決インパクトのある課題を特定。その後、その課題を解決するためのソリューションの方向性を決め、具体的なプロダクトに落とし込んでいきます。
この一連のプロセスの中で、ソリューションの方向性を決めるというステップに抽象議論の罠が潜んでいるのではないかと思います。
こんな経験はないでしょうか？
- 散々A案とB案どちらが良さそうかと長時間議論した結果、実はみんな最初からA案推しだった
- ソリューションのコンセプトに対してみんな賛成していたが、進むにつれて、実はコンセプトの粒度で認識が異なっていた
- 議論の結果C案にしましょうとなったものの、「概ね良さそうなんだけど、う〜ん…」という反応をする人がいる
- みんなあまりイメージが湧いていないのに「もはや決めの問題なので、この方向性で！」と正しそうでなんだかモヤモヤの残る結論になる
このような事象になるのは、ソリューションの方向性を決める検討がもっと具体的であるべきはずなのに、抽象的な議論に終始してしまうからです。
ソリューションの方向性を決める議論は、最終的に具体のアウトプットに落ちることが期待された議論であり、議論参加者の中でも自然と意識が具体に向きがちです。
一方で、課題特定の最後のフェーズが抽象化であるため、検討が抽象的な議論から始まり、抽象的な議論のまま方向性を決めようとしてしまうことで、議論参加者の期待値と議論の流れにズレが生じてしまいます。
だからこそ、ソリューションの方向性は具体的なイメージを伴って議論されることが必要です。
とにかく早めにモックベースの議論をしてみた
もちろん、一般的にソリューションを検討する流れのなかでモックを作成するステップは存在します。
方向性を決めてそれを具体化し、モックという形に落とし込んだ上でソリューションテストなどを実施し、その仮説を検証する流れが一般的でしょう。
前述の課題意識があったため。今回は方向性を決める前の、方向性の検討をする早い段階からモックベースで議論するという進め方をしてみました。
具体的には、ターゲットとその課題を定義した後、ソリューションの方向性が複数パターンあったため、それぞれのモックを作った上で、各種論点を整理して意思決定をする流れを取りました。
モック作成の労力を上回るメリットがあった
方向性の検討段階からモックベースで議論したことで、以下のような良い点があります。
✅ 論点を揃えながら議論できる
抽象的な議論が空中戦になりがちの要因として、論点のズレが挙げられます。
抽象的な議論では論点が絞られているはずですが、裏を返すと、より具体レイヤーの論点が大量に埋もれている状態であり、「そういえば、これってどうなるんでしたっけ？」といくらでも掘り出すことが可能な状態です。
その上で、具体のイメージが共有されていないため、挙がってきた論点がどこに位置する話なのかの認識を揃えることが難しく、議論として混乱していきます。
もちろん一般的なファシリテーションの工夫で回避する余地もありますが、具体的なモックベースで議論できると、「今はここの話で、それはそこの話」というように、論点を位置を確認しながら進めやすくなります。
✅ 言語化されていなかった論点を洗い出せる
さきほどの通り、抽象的な議論に終始すると、実は具体レイヤーの大量な論点が埋もれたままになっています。
もちろん具体で方向性の意思決定に影響しないものがほとんどですが、一方で、意思決定に左右しうる重要な論点が埋もれていることもあります。
具体のモックを作る過程で、気づかなかった重要な論点に早めに気づくことができ、より確からしい方向性の意思決定をしやすくなります。
✅ 情緒的な側面も議論できる
ユーザー体験を言語的に表現するのには限界があります。そのため抽象的な議論に終始してしまうと、ソリューションの方向性を決めるにあたって、体験や情緒的な価値を加味しきれないことがあります。
特にtoCプロダクトでは情緒的な価値を加味して方向性を決めることが重要であり、そのためにも意思決定に関わるメンバーが自分の感覚としても「行けそう！」と思えることが必要です。
モックベースで検討することで「ワクワク」「楽しそう」「面白そう」といった情緒・感覚的な観点も含めて、ソリューションの方向性を決めていきやすくなります。
手触り感をもってイメージできるレベルのモックが必要
ただ、モックを作るといっても思っている以上にちゃんと作る方が良さそうです。
例えば、構成と要件だけざっくり画面に当てこんだだけでは、結局具体的なイメージが沸かず意味がありません。また、”雑コラ”のようなものだと、方向性としては良さそうな案が意図せず悪く見えてしまい、判断を歪めてしまう可能性があります。
また、2~3ページ分だけ作成した雰囲気だけ伝えるものも、結局課題解決ができない場合があります。重要なのは、ユーザー体験の一連の“流れ”とその体験であればソリューションとして機能しそうかを関係者でイメージできる水準でモックを作ることです。
アセット活用と集中でモックづくりをコスパ良く
かといって、検討初期の段階でこれだけのモックを作るのは大変です。また、初期であるほど捨て案になる可能性は高く（というかほとんど捨てモックになります）、できる限りコスパ良く行いたいものです。
今回やってみてよかった工夫について紹介します。
💡 検討の初期段階からデザイナーと一緒に進める
今回に限らず、スマートバンク社ではディスカバリーの初期段階からPMとデザイナーがニコイチで検討を進めることが一般的です。
この段階からデザイナーが検討に入ることで、文脈を理解した上で機動的にモックづくりに参加していただくことが可能になります。
抽象から具体の要件化はプロダクトマネージャーで進めつつ（この時点では雑コラ）、それをベースにした議論やモックとして仕上げる部分をデザイナーにお任せすることで、スピーディーにアイデアを形にすることができました。
💡 デザインシステム（特にコンポーネントライブラリ）をフル活用する
スマートバンク社ではデザインシステムが整備されており、Figma上であらかじめて定義されらカラーやフォント、コンポーネントを活用することで、簡単に高品質なモックを作成することができます。
また、既存のプロダクトのほぼ全てのUIがFigmaファイル上で管理されているため、構成が似ているページが存在すればコピペでコスパ良く作成することができました。
（デザインシステムが整っている環境で本当に感謝🙏）
💡 モック作成合宿をする
モックを作りながら議論を進めようと思うと作業時間が必要になりますが、会議があふれたスケジュールの隙間時間で作ろうとすると効率が大幅に悪くなってしまいます。
そのため、合宿という形式でまとめて作業時間を作ってみました。といっても、オフィス近くの貸し会議室で、かつほとんどが個人作業ですが、集中してモックづくりをすることで効率よく進めることができました。
やってみてポイントだと感じたのは以下の点です。
✅ とにかく集中する
内職は一切NGで、途切れなく集中する
✅ まずは俺/私の考える最強の案をつくる
何も具体が決まってないフェーズなので議論し出すとキリがなく、たたきとしてまずは自分が良いと思うものを1人で考える
✅ 周りはポジティブフィードバックを
何も決まっていない段階でのたたきであるため、変更や修正が当たり前。とはいえ自分が良さそうと思う案を持ち寄ることになるため、たたきを持ち寄ってくれたリスペクトの念を込めてポジティブフィードバックを意図的にし合う。
初案に引っ張られないように地図を作る
さて、ソリューションの方向性を決める初期段階からモックを作ろうとすると、一方で、最初の1案に検討が引っ張られてしまうのではないかという懸念もあります。
アンカリング効果ではないですが、一番最初の案に心理的には引っ張られてしまうし、その案で検討が進んでしまうと他の案を検討する意識も下がってしまいます。
それを回避するために、モックを作る前に選択肢を整理することが重要になりそうです。取りうる選択肢を洗い出した上で、モックを作る方向性を選ぶ理由を明確にしておきます。
そうすることで、いざモックとして作ってみたときにNGであれば、次の選択肢に移りやすくなりますし、他の選択肢をフラットに比較して意思決定しやすくなりました。
さいごに
個人的には「最初にたたきを作るやつが一番偉い」理論の信奉者であり、プロダクトマネージャーこそ議論をドライブさせるためにたたきを作るべきだと思っています。議論で扱うテーマの性質によってどのようなたたきを作るかは異なりますが、体験に関する議論の場合はいかにフットワーク軽くたたきとしてのモックを作れるかが重要だと感じました。
（手前味噌ですが）検討の早い段階からモックで具体的なイメージを持ちながら議論できるのは、デザインシステムを含め、スマートバンク社で積み上げてきたアセットがあるからだと改めて感じています。
こうした環境でのプロダクトづくりに興味のあるプロダクトマネージャーの方はぜひお声掛けください！
