価値あるものをチームで届ける〜マネーフォワード クラウド会計Plusで実践している仮説検証プロセス〜
こんにちは！マネーフォワード クラウド会計Plusのプロダクトオーナーをしています杉浦です。
先日、スマートキャンプさん主催の「B2B SaaSエンジニアMeetup」で仮説検証プロセスについてお話する機会がありました。
プロダクトマネージャー・プロダクトオーナー（以下、PM・PO）は日々作るべきプロダクトの発見に追われていると思います。
しかし作って検証するまでは、あくまで仮説です。
そんな仮説にいかに向き合い、少しでも良いものを作れるよう工夫してきた内容をまとめました。
このnoteでは、発表時のスライドを元にプロダクトマネジメントとプロダクトチームマネジメントの密接な関係について書いてみます！
なぜ仮説検証したいのか
そもそもなぜ仮説検証したいのでしょうか？
私は「仮説の質がビジネスの成長に直結するため」だと思っています。
ビジネスの成長を実現させるには、プロダクトの質を高める必要があり、そのためには仮説の質を高める必要があります。
しかし、上記の図のループで仮説の質が上がるのは、リリースしたプロダクトにユーザーフィードバックが返ってきた後になっています。
作ってから無駄なものだとわかっても遅すぎます。
そのため、ここでは「開発に入る前に仮説の質を上げるにはどうする？」という問いについて考えたいと思います。
開発に入る前、プロダクトを発見するプロセスで達成すべきことは何か
仮説の質を上げるため、PM・POは開発前に何を達成すべきなのか。
大きくは下記の2つだと考えています。
プロダクトを発見するプロセス（以下、発見のプロセス）で、プロダクトチームマネジメントに触れているものは意外と少なく、「チームで届ける」ということはもっと重要視されて良いのではないかと思っています。
発見のプロセスでは仮説の質を高める3つのループがある
プロダクトマネジメント、プロダクトチームマネジメントを踏まえ、実践している発見のプロセスを書き出したところ、この3つのループに整理することができました。
「ユーザーを知るループ」と「内省のループ」がプロダクトマネジメントに対応しており、「チームを作るループ」がプロダクトチームマネジメントに対応しています。
ユーザーを知るループ
これは、ユーザーインタビューやユーザビリティテストを経て、課題や業務フロー、何に喜んだり怒ったりするのか等のユーザーに対する解像度を上げるループです。
思い込みや希望的観測を排除するため、疑問があれば愚直にユーザーに問うようにしています。
クラウド会計Plusは自社の経理部でも使われているので、協力しながら仮説の質を上げています。
具体的な方法論は、問題解決のためにユーザーを深く知り、課題を抽出、より良い解決策を見つける「デザイン思考」として扱われるようなものになります。
内省のループ
仮説が持つ意味やストーリーを考え、開発するに値する納得を自分自身の中で醸成するループです。
私は、プロダクトを作る中で、その機能がどんな意味を持ち、どんな因果がつながってユーザーに価値がもたらされるかを意識しています。
また、ToBのプロダクトであるため、ペインの強さが購買の動機（ビジネス価値）に直結しやすいこともあり、ユーザーの頭に火がついている、いわゆるBurningNeedsを満たしているか？満たしているとしてなぜそう言えるのか？を問うようにしています。（ヒアリングできる際にも仮説を話してその反応を見ています）
Burning Needsについては近澤さんの記事をぜひご覧ください！
チームをつくるループ
チームを作るループには、仮説検証を小さく早く回すループと、チーム全体を巻き込んで勢いを作る大きなループがあります。
小さく始めるのは、最初から多くの人を巻き込んで進めるとコストが掛かり過ぎてしまうからです。
また、議論できる人数以上に増えてしまうと結果的に結論が薄くなってしまうこともあります。
クラウド会計Plusの発見のプロセスでは、エピック（価値の単位）ごとにチームから一人、テックリード的な役割として「エピック大臣」を志願してもらっています。
その「エピック大臣」と、POとデザイナーが最初の仮説検証チームとなります。（他を排除する意図はなく、必要に応じて誰でも巻き込みます）
仮説が固まってきたら大きなループに入り広く共有します。
スクラムチームだけでなく、ビジネスサイドまで巻き込んで、「なぜ、何を、誰に届けるのか」を伝えます。
エピックのサイズにもよりますが、クラウド会計Plusではスコープやリリース単位の合意も開発とビジネスの両方で取るように進めています。
こうしてPOからの意思（チームでの総意）を伝えて、チームが納得感を持つと、フィードバックの質・量ともに上がっていきます。
このことを実感できたのは、ビジネスと開発合同でクラウド会計Plusのビジョン策定合宿を行い、その結果を何度も話し合った後に、明らかにフィードバックが増えたときでした。
リリースから約1年、どうやってチームと向き合うかを探り続けてきた結果が出たようで、すごく嬉しかったことを覚えています。
ループは互いに影響する
きれいな3つのループを書きましたが、実際には学習して情報が増える度にループが互いに影響し合うようになります。
きれいに回るのが良いというわけではなく、仮説の質を上げるためにできることをすべてやる、「予想ができないカオスな過程」というのが本質であるように思います。
発見のプロセスのループ、ビジネスのループをくっつける
これらのループを、ビジネスを成長させるループにくっつけるとこうなります。
ここでもそれぞれのループは互いに影響し合っているので、さらにつなげてみます。
このように影響を可視化していくと、「チーム全体の納得感」が大きな影響を与えていることがわかってきました。（一人の力なんて大したこと無いのでそりゃそうなのですが...）
チームに納得感があれば、あらゆる場面で、より適切にプロダクトやその情報を届けることができます。
チームの視点を忘れると、「俺のプロダクト」になってしまいます。
「俺たちのプロダクト」にならなければ、多くの人に届けることはできない。
届かなければ、ユーザーと一緒に、みんなで分かち合うこともできない。
これが、発見のプロセスにおいてチームマネジメントの視点が重要であると考える理由です。
ループを発見のプロセスに落とし込んでみる
先程までのループをプロセスに落とし込んだのが上記の図になります。
それぞれどのループと深く関わりがあるのか、そしてプロダクト開発のどの過程で行っているかを表しています。
※スライドの面積の都合で略語になっている部分を補足すると、USMはユーザーストーリーマッピング、MVPはMinimum Viable Productです。
この図の中の「意味の熟成」は完全に私的用語なので補足をしますと、下記を意味しています。
箇条書きのリストでは、どうしても因果関係や時系列がわかりにくいため、自分自身の中で意味を考えるときには「物語」を意識しています。
チームに伝えることまで考えたときに、「物語」は良いフォーマットだからです。
また、「物語」を考えるのが難しい時には、他のプロットを借りて当てはめ、真似をしています。
勇者が剣を抜き魔王を倒す物語をプロダクトに置き換えるとどうなる？というような感じで、繋がりがおかしくないか、つじつまが合うかを確かめていきます。
順番としては、「どこに向かおうとしているのか」「なぜそこに向かうのか」という方向性から考え、導き出した理想に対してのギャップから課題や解決策を考える、という流れになります。
そして、一人では「知らないことを知らない」「できるのに気付いていない」ようなことに（当たり前ですが）気付けないので、必ずチームと壁打ちします。
余談：仮説検証の本質は？と質問された件
セミナーの質疑応答の中で、仮説検証の本質について「儲け話をつくることじゃないでしょうか」と回答したのですが、言葉足らずだったので補足をします。
「儲け話をつくること」と言ったのは、拝金主義的な考えで行こう！というわけではなく、ユーザー価値・ビジネス価値が両立される物語、戦略を実現する仮説を探し続けようという意図からでした。
あえて儲け話と言ったのは、物語として面白くあってほしいという想いからです。
プロダクトオーナーは、チームに対して作るものの「なぜ」を伝えなくてはならない。
例えばそれを箇条書きで伝えられたらどうでしょう？一個一個はその通りですが、なかなか腹に落ちないと思います。
そんなとき、流れのある儲け話として、
「次に作ろうとしているエピックでは、こういうユーザーが、新しくこんな事ができるようになるんだ。その結果いままで解決できなかった、あの課題を解決できる。
そうすると今までアプローチできていない、こんなユーザーも使えるようになってビジネス的にも価値が大きい。更にこれは将来のこの機能の布石になっているから、、、」
と説明されたらどうでしょうか？
スクラムチームだけでなくビジネス含めて、ユーザーの使い方・解決される課題の解像度が上がり、よりイメージが湧くと思います。
そんな状態を目指すために、本質を「儲け話をつくること」と表現しました。
参考にした書籍たち
今回の内容は、これまでに学んだことを実践に移し、まとめ上げたものになります。
私はこんな本を読んで仕事をしてきたのでご参考になさってください。
この記事が気に入ったらサポートをしてみませんか？