リーンスタートアップや顧客開発の文脈でよく読まれているAsh Mauryaの名著『Running Lean』。
「課題インタビュー」「ソリューションインタビュー」などのテンプレートを提示し、「どうやって実際に顧客と話し、事業仮説を検証するか」を超具体的に解説している点が魅力です。
僕は何度も読み返していて、事業開発、プロダクト開発に迷った時（特にフェーズが若い時）に何回も読み返して、「もっとシンプルに考えて行動を多くしよう」ってなる一冊。
以前紹介した『The Mom Test』を併せて読むと、顧客インタビューの実行力がぐんと高まるはず。
「Running Lean」の要点
Ash Mauryaは、自身がスタートアップを運営する中で得た経験をもとに、「顧客との対話」「継続的な仮説検証」を突き詰めた手法を体系化し本書にまとめました。
リーンスタートアップ（Eric Ries）や顧客開発（Steve Blank）の考え方を、さらに行動レベルまで落とし込み、「毎週のスプリントで何をすればいいのか？」「どんな質問を投げかけ、どう検証すればいいのか？」といった部分までガイドしてくれます。
「課題インタビュー」と「ソリューションインタビュー」
多くの読者が『Running Lean』で注目するのが、課題インタビューとソリューションインタビューの明確な区分。
- 課題インタビー: 顧客がいま実際に抱えている問題や課題感を聞く段階（仮説検証）
- ソリューションインタビュー: 自分たちが用意した解決策のプロトタイプやアイデアをぶつけて反応を得る段階
この2ステップを踏むことで、「本当に課題を抱えている層」と「その課題に対する提案ソリューション」をセットで検証できるわけです。
『Running Lean』の主要ポイント
問題仮説を明確な言葉にする
仮説を曖昧にしたままソリューションを作ると、ユーザーインタビューの結果も散らばりがち。
Ash Mauryaは、「まず課題仮説を言語化し、インタビュー台本を設計する」と繰り返し強調しています。
その台本を使い、ユーザーが日常的に感じる課題・代替手段・費やしている時間やコストを事実ベースでヒアリングするのが“課題インタビュー”の流れ。
参考までに、「ユーザーインタビュー前に『筋の良い仮説』をチームで設定する具体的方法やフレーム」もご覧ください。
僕の経験を振り返っても、検証がうまくいかないパターンは大体検証前の仮説の言語化とチームでの仮説の共有が甘い・緩いことがほとんどです。
競合・代替策の把握
顧客は既存の方法でなんとか課題を解決していることが多い。
『Running Lean』では「競合製品」だけでなく、エクセルや手作業といった“代替手段”を徹底的に調べる重要性が説かれます。
この調査結果を次のソリューションインタビューで活かし、「既存の方法と比較して、これだけ楽になる」という軸でメリットを確認するのが定石。
過去の記事「ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド」でも、競合分析の一環としてユーザーが今使っているツールを確認する大切さに触れています。とにかく、ユーザーが今問題を解決している手段とその使い方を事細かに知りにいきましょう。
ソリューションインタビューで実際にコミットを求める
顧客が「それ良いですね！」と言うだけでは本当のニーズはわからないものです（大体みなさん気を遣ってくれるので）。
そこでAsh Mauryaは、ソリューションインタビューで「支払い意欲」や「事前登録」などの具体的コミットをとる手法を推奨しています（ここまでコミット求めるのが個人的には肝です）。
これにより、単なるリップサービスか、本気で課題を解決したいニーズがあるかを見極めやすくなります。また、「課題の大きさや切実度を測る」ために課題検証インタビューの段階で顧客が「これに困っています」と言及したものの発生頻度やすでに問題解決を試みているか？試みているならどの程度の時間やお金を支払っているか？を確認しておくことも必須。
類似したアプローチは、【要約】『The Mom Test』でも「実際の行動やお金を基準にする」点が強調されており、両者を併読すると理解が深まります。
Lean Canvasを活用する
著者が提案する「Lean Canvas」は、ビジネスモデルキャンバスをリーンスタートアップ向けにアレンジしたツール。
- 課題 (Problem)
- 代替案 (Existing Alternatives)
- 独自の価値提案 (Unique Value Proposition)
- ソリューション (Solution)
- 収益モデル、費用構造 など
これを更新しながらインタビュー結果を反映し、学習した内容をキャンバスに書き足すプロセスが「Running Lean」の本質。
ユーザーヒアリングの内容が具体的に経営・事業プランに落ちるので、開発とビジネス両方で「本当に正しい方向に進んでいるか」を検証できます。
小さく回し、継続的に修正。そして検証を繰り返す。
一度インタビューしたら終わりではなく、「仮説が微妙ならまたインタビューや実験を実施」というループを短いスプリントで回すことが重要。
大企業や大規模プロダクトだと「ある程度作りこんでから公開」の文化が根強い。しかし、Running Lean的には「作る前にユーザーと話そう」という姿勢を徹底して推奨。
筆者が何度も訴えるのは、「大々的にリリースしてから学ぶのでは手遅れ」ということです。
これは僕自身も強く意識していて、思いついたらchatGPTのGPT Builderなどで5-15分くらいで動くプロトにしてみてユーザーに当てるようにしています（この段階では、Lean Canvasしかない）。
『Running Lean』をPMが今日から業務で活かす！
インタビュー台本のチーム共有
課題インタビューとソリューションインタビューは、質問項目や誘導尋問を避ける方法がセットになっているため、台本をテンプレ化しておくと便利。
チーム全員が同じフォーマットで聞き取りを行い、回答を集めることで、学習の質が均一に上がります。
例えば、課題インタビューなら「直近どんな場面で困りましたか？」のような具体的行動を聞く質問をしっかり入れるなど。詳細は「ユーザーインタビューの質問項目大全」の記事も参考に。
ソリューション仮説のプロトタイピング
ソリューションインタビューを行う際には、可能な限りビジュアルなモックや紙芝居を用意しておくと効果的。
実際に画面やUIを見せながら「この機能ならコストは◯円くらいですが、使いたいと思いますか？」と確認すれば、ユーザーが支払う意思や具体的な要望をより正直に語ってくれます。
プロトタイプ活用のノウハウは「プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips」もご覧ください。
Lean Canvasの継続的アップデート
まずは今良いと思っている仮説をLean Canvasに落とし込みんでみましょう。その段階で意外と自分の仮説が一部（例えば課題仮説の一部のみ）しか存在しないことにも気づくはずです。
また、一度作ったLean Canvasを放置すると、学習が追いつかなくなります。
Running Leanでは、インタビュー後や新たな検証結果が出るたびに、キャンバスを更新し、不要となった仮説・要素を捨て、発見した新しい事実を追加するサイクルを推奨。
これにより、プロダクトの方向性とビジネスモデルが常にリアルタイムに整合性を保ちやすくなります。
今日から実践できるアクション
- 課題インタビュー台本のテンプレ化
「困り事」「既存の代替手段」「具体的なコストや頻度」を軸に、質問リストを作成。
チームのNotionや共有ドキュメントに貼り、誰でも使えるようにする。 - ソリューションインタビューでコミットを取りに行く
「口では欲しいと言うが、本当に買う意志があるのか？」を確かめるため、先行予約・お試し申込・デポジットなどを提案してみる。
具体的な行動や決済を求めると、ニーズの真偽がクリアにわかる。 - Lean Canvasをチームで随時更新
インタビュー結果が出るたびに、キャンバスの仮説欄をアップデート。
「ここは否定された」「この課題はより深刻だった」など事実ベースのメモを追加し、全員で確認する。 - 短いスプリントで検証を繰り返す
2週間単位などで、仮説→インタビュー→検証→キャンバス更新というループを回す。
大規模なリリースを待たずに、顧客の声を活かした方向修正を定期的に行う。
Q&A
- Q1. 『Running Lean』はスタートアップ向けだけですか？ 大企業のPdMでも使えますか？
- A. 大企業でも十分活用できます（というか僕が大企業でも使っています）。重要なのは「仮説を小さく検証し、顧客と対話し続ける姿勢」。
組織が大きい分、抵抗はあるかもしれませんが、まずは限定的にスプリントを組んで仮説検証をしてみると良いです。 - Q2. ソリューションインタビューでお金の話をするとユーザーが引いてしまいませんか？
- A. 多少ハードルはありますが、本気度を確かめるためには避けられないポイント。
無理やり課金を迫るのではなく、「試作機能を先行利用したい方はメールアドレスを登録」などライトなコミットから始めるのも手です。 - Q3. Lean Canvasを作っても、忙しくて更新できず放置しがち。どうすれば？
- A. スプリントごとに「キャンバス更新」をタスクに入れる仕組みづくりが大事。
定例会議の最後に5分でLean Canvasを見直すだけでも進捗は変わります。
人によってはGPTs Builderのようなツールで仮説管理を効率化している事例もあります。
参考情報
- Ash Maurya『Running Lean』(O’Reilly Media, 2012)
- Eric Ries『The Lean Startup』（2011）
- Steve Blank「Customer Development」
- 「ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド」
- 「ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム」
- 「【要約】『The Mom Test』 ユーザーインタビューの「本当の声」を引き出す秘訣」
- 「プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips」
まとめ：『Running Lean』で顧客開発を一歩先に
『Running Lean』はリーンスタートアップの概念を、「実際にユーザーと話し、仮説を検証する手順」まで落とし込んだ実践書です。
顧客インタビューやLean Canvasを通じて得た学びを、短いスプリントで何度も回すことで、無駄な機能開発やリソース浪費を避けながら、本当にユーザーが求める価値を見極められます。
大企業でもスタートアップでも、課題インタビュー→ソリューションインタビューという二段階を徹底するだけで、大きな失敗を防げる可能性が高い。
ぜひ本書のエッセンスを活かし、顧客と対話しながら最速で正しい仮説を掴むプロセスをチームに根付かせてみてください。
コメント