Lean UX×蠱毒でプロダクト戦略の意思決定サイクルを爆速で回した話
私は現在、GaudiyというWeb3×エンタメ領域のスタートアップで、プロダクト全体のUX設計に携わっています。
昨年末に発表されたプロダクトの新戦略の方針を踏まえ、今年の初めから新戦略に基づくグランドデザインの作成と検証を進めてきました。
その過程において、Gaudiy 独自の意思決定プロセス「蠱毒(こどく)」という制度に、Lean UXの開発プロセスを取り入れた結果、新戦略のグランドデザインとそれに基づくプロトタイプ(MVP)を、従来よりも圧倒的に短いスパンで完成させることができました。
そこで今回は、その具体的な進め方をご紹介してみたいと思います。フィードバック・ループをうまく回しながら、意思決定のスピードを圧倒的に高める手法として、スタートアップのプロダクト開発に携わる方にご参考になれば嬉しいです…!
Lean UX において大事な意思決定
Lean UX に馴染みのない方向けに、簡単にご説明しますと、Lean UXとは「デザイン思考」「アジャイル開発」「リーンスタートアップ」を統合させた開発プロセスです。
Lean UX について詳しく知りたい方は、以下の note をご参考ください。
Lean UX では「なにをつくるべきか(Build)」「なにを検証するのか(Measure)」「学びをどのように活かすのか(Learn)」などの連続した意思決定が求められます。
このフィードバック・ループを効率よく回すためには、各プロセスにおける意思決定の質を上げ続けることが重要ですが、この部分に関してはチームの意思決定の質に依存せざるを得ず、Lean UXを実践する上で最も難しい部分だと言えます。
その質を高める手段として、今回取り入れたのが「蠱毒」です。実際には、プロダクト新戦略の蠱毒を実施する際に Lean UX のプロセスを持ち込んだのですが、この組み合わせはかなり相性がよく、有効な手法だと感じています。
蠱毒と Lean UX の相性がよい理由
なぜ、蠱毒とLean UXは相性が良いのでしょうか。その理由としては、2つ考えられると思います。
1. 蠱毒の本質が「プランの練度や思考回数を高めていくプロセス」であること
そもそも蠱毒とは、Gaudiy独自の意思決定にまつわる制度で、限られた時間内に、あらゆる課題やテーマに対して参加者2名以上がディベート形式で解決策やプランを戦わせ、結論を出す活動です。
代表の石川が note に詳しくまとめています。
この「戦わせる」というのがポイントで、最終的には参加者による投票で勝ち負けが決まります。ただ、勝ち負け以上に大事だと思っているのは、互いに鋭い質問を投げかけ、プランの練度や思考回数を上げていくことです。
個人で思考を巡らせても知識量に限界はありますし、視点がどうしても偏ってしまいます。また、蠱毒は承認の場でもレビューをする場でもないため、全員にオーナーシップが求められるようになります。
だからこそ、Lean UX のサイクルにおける意思決定の質を高める上で、蠱毒は強力なメソッドになります。
2. Lean UX が「フィードバック・ループを繰り返し回すプロセス」であること
プロダクト新戦略の蠱毒は、CEO、PO、デザイナーを含むチーム戦で行われました。
なぜなら、プロダクト戦略という抽象度が高い議題を扱うにあたっては、「モノ」なしでは議論を前に進めることはできないからです。プロトタイプありきの議論を展開することで、プロダクトの戦略から戦術までの整合性を同時に図ることができます。
そして、今回の蠱毒には、
プロダクト新戦略の方向性を固めるために継続的に蠱毒を行いたい
2つのチームに分かれて同じ活動をするのはコストがかかるため、それぞれのチームに役割を与えて、意思決定速度を上げたい
という意図がありました。ここにおいて、継続的な蠱毒と Lean UX の「フィードバック・ループを繰り返し回す」プロセスの相性がよく、さらに Build と Measure の役割をチームごとに持たせることで、高速な Lean UX の検証サイクルを回すことができました。
Lean UX × 蠱毒の進め方
ここからは、具体的な「Lean UX × 蠱毒」の進め方をご紹介していきます。
まず初回の蠱毒では、両方のチームがプロダクトのコンセプトと、それを体現したプロトタイプをもって戦いました。残念ながら負けてしまいましたが、勝ったチームのプロダクトコンセプトとプロトタイプをもとに、Lean UX のプロセスに沿って進めていきました。ポイントとしては、ここでチームを一度再編し、それぞれに役割を与えます。1つはつくる(Build)を担当するチーム、そしてもう1つは検証(Measure)を担当するチームです。
以降のステップについて、詳しくご紹介します。
Step 1: はじめに Build チームが蠱毒の内容を受けて、勝者のプロトタイプをアップデートします。
Step 2: Build チームはつくったプロトタイプを蠱毒の場に持ち込み、Measure チームにインプットします。その際に、Measure チームはプロトタイプに対して論理の矛盾をついた問いを投げかけ、検証すべきポイントを決めます。
Step 3: Measure チームは検証に向けたリサーチプランを立案し、実行に移します。このとき、Measure チームは蠱毒後にユーザーリサーチが円滑に進むよう、Build チームがプロトタイプをアップデートしている最中にリサーチのリクルーティングを同時並行で行います。ユーザーリサーチの実施からまとめは、2日以内で終わらせます。
Step 4: リサーチのまとめは Measure チームが行い、次の蠱毒にて学び(Learn)と改善案を提案します。これを Learn の場としました。その際に、Build チームは STEP 1 と同じように、今度は逆の立場で論理の矛盾についた問いを投げかけます。検証ができていれば、つくるべきもの(機能)を決定します。一方、多くの見直しが必要であれば Measure チームは改善案を持ち帰り、ブラッシュアップします。
以降はこの繰り返しです。3周目以降はソリューションがかなり洗練されてきたため、蠱毒は開催せずに、通常の Discovery フェーズに移行しました。
自分は Measure チームに所属していましたが、蠱毒が何週にもわたって開催されたため、検証結果を蓄積し、最新の状態を維持し続けるための仕組みとして、仮説検証ボード(Validation Board) を活用しました。
これを改善されたプロトタイプと共に Learn の場に持ち込みました。こうすることで前述したフィードバック・ループを効率よく回しながら、議論を前に進めることができました。
同時に意思決定スパンが圧倒的に短縮され、初回の蠱毒から約半月で戦略とそれを反映した忠実度の高いプロトタイプ(MVP)を完成させることができたのが非常に大きかったです。
最後に
最後に...自分は何度か蠱毒を経験していますが、今回は初めてのチーム戦ということで、振り返りも兼ねて、よかったことと困難だと思ったことを記して終わりにしたいと思います。
いかがでしたでしょうか?蠱毒は相手を倒すことが目的なのではなく、アウトプットの練度を上げることが目的です。負けた場合でも、それは意思決定をする上では必要な過程ですし、全く採用されないという訳ではありません。そのため、負けたからといってモチベーションが下がるとかは、今のところないです(笑)
今回は Lean UX を蠱毒に応用するという難易度が高いチャレンジでしたが、蠱毒はプロダクト開発においても有効であることが証明できた、貴重な機会だったと考えています。また、プロダクトについてより真剣に向き合う機会が生まれたのは個人としても非常に大きく、いい意味で思考のクセづけができたと思います。これは今後の社会人生活を送る上で、とってもお得です。
Gaudiy は、これまで自分が在籍していた企業と比べて、プロフェッショナルとして更なる成長を遂げることができる、とてもいい環境です。蠱毒をはじめ、ここで得られるスキルは Gaudiy に限らずキャリアの中で絶対に活かせられると確信しています。今後のキャリア設計のひとつに、Gaudiy を加えていただけると嬉しいです😀
少しでも気になる方や、詳しいお話を聞きたい方は、YOUTRUST や Twitter の DM などでお気軽にご連絡ください。