Running Lean第3版では、リーンキャンバスを作成した後すぐにインタビューやMVP構築・検証をするのではなく、需要性・事業性・実現性の三つの観点でストレステストを行うべきであると説いている。

実はこれ、なかなか衝撃的なことだったりする。
というのも、改訂前のRunning Leanではリーンキャンバス作成後、リスクの確認や他者からのフィードバックなどを推奨してはいるものの、数ページ説明した後はすぐに「顧客インタビュー」に移る。

一方で、2023年に改訂されたRunning Lean第3版では、リーンキャンバスの作成後、ストレステストやエレベーターピッチの作成など、机上での検討・検証の説明に100ページ弱割いている。

これは、「検証による学び」を重視する従来のリーンスタートアップの思想に反しているとさえ思えてしまうほどだ。しかし実際のところ、MVP重視、現場重視といった姿勢が失敗を生むことが多いのだろう。実際、本書では、起業家の熱意に合わなかったり、うまくスケールしないがために頓挫するケースを危惧してストレステストを推奨している。

「検証による学び」と言えば簡単だが、実際現場に出てインタビューしたりMVPを作ろうものなら、イノベーターのバイアスで元のアイデアの小改善に留まりがちであり、本来的なピボットが行われることは少ない。私自身、新規事業に携わった身として、また他者の新規事業開発支援に取り組んだ経験からしてそう思う。

アイデアが間違ったまま検証やインタビューに臨んでしまえば、その時点で半分失敗したようなもの。だから、スタートラインに立つ前に万全の準備を行おうというのが本書の伝えたいことだろうと推察する。

需要性のストレステスト

さて、最初のストレステストは「需要性のストレステスト」だ。
本書では本題に入る前にジョブ理論について熱く語っている。熱く語ってはいるものの、ジョブ理論自体を理解したいのであれば『ジョブ理論 イノベーションを予測可能にする消費のメカニズム』を読んだ方がいいと思う。絶妙にしっくりこない説明だった。

ジョブの定義について少し紹介しておこう。

本書でのキーワードも交えながら、顧客/ユーザーとジョブの関係性について、私の理解をベースに説明していこう。

ある特定の条件下でジョブが発生する（トリガーイベント）。ジョブを解決するために既存の代替品に頼ろうとするわけだが、そのときにひどい体験をしたり認識や事情が変わったりすることで（スイッチングトリガー）、新たな手法を使うモチベーションが生まれる（プッシュ）。そこで新しい手法の魅力を信じられれば（プル）、新しい手法を使うようになる。とはいえ、摩擦や惰性によって古いやり方に戻る力が生じるため、新たな手法は既存の代替品よりも圧倒的に優れたものでなければならない。

語義をゆるくインプットしたところで肝心の需要性のストレステストを説明しようではないか！！（以下、本書p.81の内容を私の言葉で表現）

1. 「顧客セグメント」をシンプルにする

2. 「アーリーアダプター」にスイッチングトリガーを列挙する（デモグラとかペルソナとか書かないよ）

3. 「既存の代替品」を列挙する（カテゴリを超える）

4. 「課題」では既存の代替品の課題を列挙する

…..いや、どこがどうテストなんだ！！？？
単にブラッシュアップしてるだけじゃん！！？？

そう思っただろ？そうだよ。これはブラッシュアップだよ。誰だ？テストって名前つけたのは。今すぐ出てこいよ…

と言いたいところだが、一旦置いておこう。
本書を見て驚かされたのは（そしてこれまでのサービス開発で私自身意識できていなかったのは）、「既存の代替品」にこれでもかというほど重点を置いているということ。

需要性のストレステストでは、「課題を解決する、ちょっといい感じのソリューション作ったよ！おもしろそうじゃない？ﾃﾍｯ」という詰めの甘さを、浮ついた心をテストしているのだ（！？）。

本書では、イノベーターは「既存の代替品」を「ない」と思い込みがちであることを指摘した上で、あらゆる新たな商品・サービスは必ず代替品が存在することを主張している（意訳）。

たとえば、SNSのない世界で「トゥイッター作ったんやで！競合存在しないんやで！！」と言ったとして、一瞬そうかとも思うが、ツイートするという行為は日記に何か書いたり、友達や家族に今日あったことを話したりすることの代替行為であり、「既存の代替品」は存在している。

需要性のストレステストは、「既存の代替品は必ず存在している」「新しい手法から遠ざかる摩擦・惰性は必ず働く」といった大前提があったうえで、「新たな手法を雇用してくれる蓋然性が本当にあるか？」というクリティカルな問いに答える取り組みなのである。

す、すげえ… Running Lean… 何て素晴らしい本なんだ。ありがとう、Running Lean。今週はここまで！と言いたいところだが、自分のアイデアをテストしなければならない。

私が解決しようとしていたテーマは「ネットワーキングイベント、本当の意味で"ネットワーキング"できない問題」であった。実際ストレステストをしてみると、いろいろと検討課題が出てくる。

・企画者をメインとすべきか、参加者をメインとすべきか
・イベントのスコープはどこまでか（社内の同じ組織内のネットワーキングか、異業種交流会みたいなものも含めるのか）
・イベント自体にフォーカスするか、イベント後のつながりにフォーカスするか
・ツールとしての立ち位置はどうすべきか（調整さん的なツールか、アイスブレイクツールか、イベントへのフィードバックツールか、連絡先共有用のツールか、出欠最終確認用のツールか、イベントの規約に同意させるためのツールか、会話したことを記録するツールか、チェックインツールか、イベントでの多数決や投票を管理するツールか…）
・その他無数の検討課題

悩みに悩み、リーンキャンバスをブラッシュアップした。

うーん、イベント企画者側の課題設定が相当弱い。
そもそもネットワーキングイベントを企画した側に立ったことがないので感覚がわからないというのもあるが、直感的にはそんな困ってないのでは？とすら思えてしまう。

とはいえ、仮にネットワーキングイベントを活性化するためのサービスを作るのであれば企画者側をまずは動かさないといけない。今はそれにフィットしてない気しかしない。誰か教えてください経験者！！！！何に困ってますか？？？

いっそのことツール的な利便性にフォーカスしてもいいのかなと。調整さんみたいな日程調整とか、そういう入り方。うーん… ちょっと先行きが怪しい。

と、とりあえず、次回は事業性、実現性のストレステストにトライしてみようと思う。正直がっつりお金儲けする気ないのでやらなくても… と思ったりもするけど、せっかくなので愚直にやっていきます。

続く。