スタートアップ初期のプロダクトにしても、すでにPMFしているプロダクトにしても「施策をやりっぱなしにしない」ということは大切なことです。 以下の図は、施策をやりっぱなしにしないために、個人的に作っていた表です。これを作ったあと、開発チーム内でも共有したり、いくつかの案件で事例紹介をすることがありました。

個人的には「施策意図管理フレーム」と呼んでいます。 この枠組みを作った大きな目的は、施策をやりっぱなしにしないこと・施策から学びを得ること・施策の目的をはっきりさせることの3点です。 事業開発系の友人と議論したり、開発チームのメンバーと施策について議論する中で、情報を整理しているうちに出来上がったものです。

これを作ったのはだいぶ昔のことなので、事実の前後関係の記憶があいまいですが、「リーンスタートアップ（エリック・リース）」や「起業の科学（田所雅之）」などの書籍を読んでいた時期でもあった気がします。そのため、おそらくリーンキャンバス・バリュープロポジションキャンバス・ジャベリンボードなどから影響を受けていると思います。

また注意点として、これを使い始めてすぐに私が開発チームを離れることになり、その後使われているかはわかりません。つまり、これを使うことによる効果の証明としては弱いです。 ただ、私がその後関わる案件で、仮説検証のサイクルに課題を持ったチームでは、過去の事例として紹介することで課題解決への一助になっています。

使い方 #

使い方はシンプル。なにか新しい施策をする際に、その時点で決まっていることを書いていくだけです。枠が埋まっていないところは、チームで議論したり、データを探してくるなどして埋めていきます。

「ユーザーの課題」と「解決手法」 #

課題とソリューションの対応を確認します。ざっくりPSFチェックをします。

「施策の目的」と「目的達成の判断基準」と「変化しうる数値やチェックする指標の仮説」 #

施策の目的と仮説の整理をします。判断基準についてはガチガチにする必要はないですが、最低限、目的と仮説は明確にしておきます。

「結果」 #

施策を実施したあとに得られた事実を書きます。ここはあくまでフラットな気持ちで、得られた量的・質的のデータを記載します。

「得られた学び」 #

結果の考察を書きます。次の施策につなげるための、気付きや学び、振り返りを書きます。施策を実施する責任者（PO）自身が記載しても良いですが、できればチームで振り返りを行った上で書いたほうが、より深い学びにつながると思います。

実際に使ってどうだったか #

施策の意図や目指す成果を共有しやすくなります。また、施策実施後に振り返るサイクルができあがります。 実施した施策が増えてくると、これ自体が、気付きや学びがたまったポートフォリオになります。

先述したとおり、「得られた学び」については、自分だけで書くよりはチームで議論した上で書いたほうが良いでしょう。私は個人で書いていたのですが、もったいなかったなと感じます。振り返りはチームで行い、それぞれの視点視座から得た学びを開発チーム内で共有したほうが、チーム全体のプロダクト理解が促進される期待があります。

これから仮説検証を回し始める人に #

この枠組みをそのまま実施するというよりは、アイデア整理のための切り口の例として、役立つことができると嬉しいです。 こうした情報整理を行うことで、施策が思いつきにならず、明確な目的・仮説・根拠を持って、施策から学びや気づきを得ながら、プロダクトを大きくしていけるのではないでしょうか。このような仮説検証を繰り返していくことで、近視眼的だった施策や計画が、ゆくゆくは長期的な見通しを持った目標になり、さらには現実的・飛躍的などのバリエーションを持って立てられるようになると思います。