ここ1年ほど新規サービス企画などをやってきた。その際に重視していたのがユーザーゴール・プロダクトゴール・ペルソナ・シナリオ・など多層に渡るステップを経て進めることだった。しかし、それは果てしない検討の旅でしかなく、それよりも「とっとと」アイデアを顧客に見える状態にして検証を始める方がチームにとって（自分にとっても）良いのでは、と最近思うに至った。企画に時間を使いすぎて、時を逸してしまう場面に何度か直面したのだ。

そんなこんなで、今自分の中で採用しているプロセスをここに書き記しておく。

前提

新サービス、もしくは新機能を企画しているチーム。コアは3-4人ほど。もしくは、会社の事情的に「来期のプロダクト戦略」的なナニカを作らないといけないシチュエーション。

1.仮説キャンバス

「正しいものを正しくつくる」という本で書かれているキャンバス系フレームワーク。他キャンバス系のフレームワークに漏れず、プロダクトの検証の始点で使われることを想定しており、チームが「今何が分かっていて、逆に何が分かっていないのか」の理解を手助ける。具体的な事例は別途 note にまとめたいと思う。

事例はここなどを参照（https://kray.jp/blog/canvas-workshop/）

自分はこれを企画初期にメンバーそれぞれが考えていることの可視化に用いる。1時間ほどディスカッションの時間を取り、その内容をこのフレームに落としていく。

2.構造化シナリオ

仮説キャンバスで全体感や目指す方向がぼんやり見えたら、すかさず構造化シナリオ、特にバリューシナリオとアクティビティシナリオをチームで書いてしまう。（構造化シナリオについてはここでは説明しないので、上記に貼ったURLリンクを参照されたし。またシナリオテンプレートについてはこちらからダウンロードできる）

シナリオは捉え方が難しいが、要するに「現時点で考える、ユーザーがめちゃくちゃハッピーになる流れ」だと思っている。チームの練度にもよるが、このフェーズはワークショップ形式で3-4時間ほど要する（2つのシナリオの場合。ユーザー種類が増えるとさらに時間はかかる）

なお構造化シナリオのうち、インタラクションシナリオはここでは書かない。次フェーズのユーザーストーリーマッピングで行うからだ。

3.ユーザーストーリーマッピング

構造化シナリオでユーザーのコンテキストを大まかに描いたら、アクティビティシナリオをベースにユーザーストーリーマッピングを行う。

まずはアクティビティシナリオからシーンを選定。それを「現時点のユーザーがどのように対処しているか」を詳細に描いていく。インタラクションシナリオの as-is といった感じだ。その後「我々が新しい何かを提供したら、そのシーンでユーザーはどのように振る舞うか」を描く。to-be のインタラクションシナリオに相当する。この2つのギャップが解決すべき課題であり、それらを解決するアイデアを発散していく。

あとは一般的に言われているユーザーストーリーマッピングの手順よろしく、アイデアの優先順位付けと、仮のスコープ決定を行う。

ユーザーストーリーマッピングはワークショップ形式で、2-3時間は最低でも掛かってしまう。特にインタラクションシナリオの「詳細なユーザーの手順」に慣れ不慣れに出るので、経験者がうまくファシリテートする必要がある。

4.ワイヤーフレーム・プロトタイピング

ここまで出来たら、ワイヤーフレームを描いてしまう。細かいことは決まっていないが、チームに選出されたユーザーストーリーに従って、画面遷移図や画面イメージをざっくりと描いてしまう。ついでにコンセプトボード的なアウトプットがあれば、企画内容を顧客や社内に説明する際に有用になる。

このワイヤーフレームは将来捨ててしまうこと前提になるので、形式は問わない。チーム内で議論するためのツールと割り切って、スピード優先で作り・共有する。議論を巻き起こすことができれば成功としてしまっていい。ビジネス上・開発上の実現可否や難易度、これを作るために必要なリソースなど、議論は多岐に渡る。それを経て最低限「これは夢物語じゃないよね」ということが判明した時点で、これを顧客に持っていって検証してしまう。

5.ユーザーリサーチ

いよいよ目的の顧客検証。コンセプトボードとプロトタイプを持っていって、受容調査をしてしまう。

大まかな企画意図やプロトタイプを触ってもらったあとは、ユーザーストーリーひとつひとつを書いた紙を見せて優先順位をつけてもらうのも面白い。順番をつけてもらうことが目的ではなく、その順番にした理由・背景を聞くことができると、これまで作ってきた構造化シナリオや仮説キャンバスに変更を加える必要性を感じるかもしれない。また、不要なユーザーストーリーを発見したり、逆に欠けているストーリーに気付くかもしれない。

その発見こそが、最短で顧客検証にたどり着くことで得られるベネフィットになる。

リサーチの設計については、こちらも参考までに。

最後に

ここからプロダクト開発に至るために必要なステップはまだまだ続くが、今回は「最短で顧客検証に至る」にフォーカスしてみた。ターゲットをしっかり決めて、ペルソナを定義して（もしくはそのためのリサーチをして）、コンセプトを決めるためにチームで延々議論して、という手順的・合理的な活動はそれはそれで重要かもしれないが、何も決まっていない時間が長すぎると感じたため、今このようなプロセスを試している。

ただ、SPT定義やペルソナ設計などが無駄と言いたいわけではない。チームのコンティションによって採る手法や進め方が変わってくる、その一例として今試しているプロセスでしかない。

また目的は「最短で」なので、このプロセスも削れるところは削ってしまいたい。チームのサイズ・保守度合い・コミットの強度（兼務ありなし etc）・リサーチ難易度（顧客との関係性）などなど諸ドライバーを見極めて、調整していくことになるだろう。