The Lean Product Playbook、なぜ日本語版がないのか不思議なぐらい素晴らしい本です。 私は本は斜め読みすることも多いのですが、The Lean Product Playbook はじっくりと時間をかけて読みました。読み進めるのと並行して、自分の仕事に活かしたい点をまとめていたので、それをnoteにして公開したいと思います。

The Lean Product Playbook では Product-Maket Fit をリーンスタートアップにおける最も重要な概念の一つとし、その達成までのプロセスを解説しています。Product-Maket Fit の定義は次の通りです。

your product meets real customer needs and does so in a way that is better than the alternatives

意訳すると「プロダクトが顧客の本当のニーズを満たし、またそのやり方が他の選択肢よりも優れている」でしょうか。マーケットには様々なニーズがありますが、その中で既存プロダクトで満たされていないニーズを見つけ、そこを解決する為の提供する価値を定義し、実際の機能セット・ユーザー体験を作っていきます。

ここで重要なのはプロダクトよりもマーケットに目を向けることです。The Lean Product Playbook の中では、Problem Space VS. Solution Space として Problem を重要視することを開発プロセスの上位概念として置いてあります。「何の課題を解決するか？」は「どのように解決するか？」よりも重要であることは、こうしてテキストにしてみれば自明なのですが、開発現場では「この技術を使いたい」が先行してしまうことが多々あります。

さて、Product-Maket Fitと Problem Space の紹介ができたところで、開発プロセスの話題に進みたいと思います。自分が本を読みながら感じたことをまとめていますが、内容に興味を持たれた人はぜび原書を読むことをお薦めします。英語ですが一読の価値ありです。

Step 1. 顧客ターゲットの決定

最初のステップは顧客ターゲットの決定です。以下の3つの観点と手法を用いて、顧客ターゲットを定義していきます。しかし、ここに時間を必要以上に費やす必要はありません。仮説を持つことは非常に重要ですが、プロダクトをリリースしてみたらターゲットとは違うターゲットに評価を受けることは往々にしてある話です。仮説・検証のサイクルを素早く回すことがリーンなモノづくりの大事な考えです。

マーケットセグメンテーション
・人口統計学的属性 ... 性別、年齢、居住地域、収入、職業、学歴など
・心理学的属性 ... ライフスタイル、立場や意見、興味・関心など
・行動学的属性 ... 特定の行動の有無やその頻度など
・ニーズベースの属性 ... 特定のニーズ（遠隔カメラを必要としている人）

イノベーター理論
・イノベーター （Innovators: 革新者）
・アーリーアダプター（Early Adopters: 初期採用者）
・アーリーマジョリティ（Early Majority: 前期追随者）
・レイトマジョリティ（Late Majority: 後期追随者）
・ラガード（Laggards: 採用遅滞者）

ペルソナ
名前、写真、座右の銘、職業、人口統計学的属性、ニーズ、関連する動機、既存ソリューションに対して感じる課題、知識 / 練度、利用シーン、イノベーター理論の属性など

Step 2. 満たされていない顧客ニーズの究明

このステップはさらに細かくプロセスを分けることができます。
まず最初にすることは Problem Space を掘り下げ、顧客のニーズを見つけることです。その為に、仮説を立てて顧客へのインタビューを行います。ここで大事なことは、顧客は往々にして Solutuin Space のことを話したがり、Problem Space の潜在的な課題について議論するのは苦手という事実です。顧客の言うこと鵜呑みにせず、本質に迫るための仮説立てやインタビュー結果の分析が重要です。インタビューでは次の質問やテクニックを用います。

顧客へのインタビュー
・この文章の意味は何ですか？（質問したい仮説の理解度を問う）
・これがどのようにあなたの役に立ちますか？
・あるプロダクトがこれを提供した場合、あなたにとってどの程度価値がありますか？（5段階評価で定量的に問う）
・その低 / 高 評価の理由を教えてください。

なぜなぜ分析
・Why? の質問を課題の真因に辿り着くまで繰り返す。インタビューの中では、顧客から新しい答えが引き出せなくなるまで Why? を繰り返す。

Problem Space から顧客ニーズが見つかれば、どのニーズがより重要で他のソリューションで満たされていないのかを検討します。これによって、ニーズの優先度が決定します。

重要度と満足度のマトリックス
・ニーズを重要度と満足度で分けた象限に分類する。重要度が高く、他のソリューションでの満足度が低いものが狙い目。
・「○○だった時、☓☓はあなたにとってどの程度重要ですか」や「過去6ヶ月の間、○○の時のXXの満足度はどの程度ですか」という問いかけを、5段階、または7段階評価で質問し、重要度と満足度を調査する。

Step 3. 提供する価値の定義

顧客のニーズ、またその優先度が見えてきた今、次はそのニーズのどれに実際に取り組み、どれに取り組まないかを決めます。このどれに取り組まないかという観点は非常に重要で、あれもこれもと対応範囲を拡げると逆に不便なプロダクトになってしまいます。そこで、狩野モデルという品質管理のフレームワークを使って取り組むべきニーズを詰めていきます。

狩野モデル - 3種類の品質
・当たり前品質 ( Must-have ) は、あって当たり前のもの。あっても顧客満足度は上がらないが、なければ下がる。
・一元的品質 ( Performance: more is better ) は、あればあるほど顧客満足度が上がる。なければ下がる。
・魅力品質 ( Delighter: wow ) は、なくても仕方がないもの。なくても顧客満足度は下がらないが、あれば上がる。

これらの組み合わせで取り組むべきニーズを考える。当たり前品質は最低限やらなければいけないもので、ここで競合と差別化ができることはない。むしろ、競合とは似通ったものになる。一元的品質と魅力品質でどのように差別化をするかがポイント。競合と自社プロダクトで比較表を作り、提供する価値（以下、Value Proposition）を決定する。

Step 4. MVP （実用最小限のプロダクト）機能セットの検討

Value Propositionが定義できたところで、次はMVPの機能セットを考えていきます。MVPはMinimum Viable Productで実用最小限のプロダクトという意味です。いきなりValue Propositionの全てを満たすプロダクトを作るのはリスクが高いです。開発の方向性が正しいかの検証ができる最小限のプロダクトから作っていきましょう。

機能案をブレインストーミングで出す
・質よりも量を重視する
・アイディアに対して批判や評価はしない
・最後に出たアイディアを顧客に提供できる価値という観点で整理する

機能案からユーザーストーリーを作る
・ユーザーストーリーをテンプレートに則って書く。日本語であれば<Who>として、<what>がほしい。それは<benefit>のためだ。

ユーザーストーリーはINVESTであること
・Independent ... 独立している。他のストーリーと依存関係にないこと
・Negotiable ... 交渉可能。具体については議論の余地があること
・Valuable ... 価値がある。一つのストーリー単体で顧客に価値があること
・Estimable ... 見積もり可能。見積もれるだけの情報があること
・Small ... 小さい。実現するのに時間がかかりすぎないこと
・Testable ... テスト可能。完了の条件が明確であること

ユーザーストーリーをさらにブレイクダウン
・スコープを狭める。例えば、「写真をシェアする」というストーリーであれば、Instagramでのみシェアが可能にするなど。
・リミットをつける。例えば、「写真をシェアする」であれば、写真にタグやメッセージをつけることは制限するなど。

ユーザーストーリーに優先度をつける
・工数と顧客価値を見積もる。ストーリーポイントをつけても良いが、簡易的にはそれぞれ高中低の3段階でつけても良い。
・工数が少なく、顧客価値が高いものほど優先度が高くなる。

機能セットを決定する
・当たり前品質は最低限やらなければいけないものなので、該当するユーザーストーリーはMVPに含めることになる
・一元的品質、魅力品質に該当するユーザーストーリーは、ユーザーが競合との差別化を感じてもらえる最低限のものに絞る
・最低限のものを選んでいくので、当然全てのストーリーが開発対象にならない。ここで漏れたものはリリース第2弾に繰り越す（ただし、この後の検証によって計画を変えることはよくある）

Step 5. MVPプロトタイプの開発

リーンなモノづくりで最も重要なのは仮説・検証のサイクルを高速でまわすことです。ここではその為のMVPプロトタイプの開発をしていきます。このステップは検証に入る為の開発ですが、ステップの途中途中でテストを挟み、プロダクトに本当に価値があるか確認しながら進めるようにします。 検証には様々な手法があります。自分のプロダクトにあったものを選んで使いましょう。

マーケティング資料
ランディングページ、プロモーションビデオ、広告などを見込顧客に見せて、フィードバックをもらう。打ち出している価値が顧客に刺さっているかを検証できる。

ランディングページ
アカウント作成やメルマガ登録などをゴールにして、ランディングページを作り、そのコンバージョン率を見ることで、打ち出している価値が顧客に刺さっているかを検証する。また、ランディングページにアクセスを集めるために、リスティング広告やディスプレイ広告に出稿する。

クラウドファンディング
プロダクト完成前から実際にどのぐらいの人がお金を払ってまでプロダクトを欲しているか検証することができる。

ワイヤーフレーム => モックアップ
デザイン段階から見込顧客に見せてフィードバックをもらう。ここではまだエンジニアは手を動かす必要なく、IllustratorやSketchなどを用いて、画像ベースで見込顧客がプロダクトに価値を見出すか検証する。

プロトタイプ
インタラクティブに動くプロトタイプで見込顧客がプロダクトに価値を見出すか検証する。ここで書くコードは製品に載るものとは別と考え、スピード重視で技術選定をする。サーバーサイドの開発もする必要はない。

フェイクドアテスト
新しい機能へのリンクやボタンを用意しておいて、全体の何%のユーザーがクリックするかを計測する。これによってどの程度の需要がその機能にあるかを検証できる。

また、ここで重要なのは最終的なMVPの品質です。MVPは機能が制限されているだけで、低レベルのUXやバグだらげのプロダクトということではありません。魅力的品質は必ずしも完成している必要はないですが、機能が安定して稼働する、使い勝手も良い、というレベルに達成していないと適切な検証を行うことができませんので注意しましょう。

Step 6. MVPプロトタイプの検証

MVPプロトタイプが完成したらユーザーテストを行います。開発メンバーはどうしてもプロダクトに慣れてしまい、客観的に良し悪しを判断するのが難しくなってきます。ユーザーテストをして、外部の人間にフィードバックをもらうことで、適切に検証をすることができます。
※ユーザーテストの実施方法については別のnoteにまとめます

Step 7. 継続的な検証

ユーザーテストで得られたフィードバックを掘り下げ、そこから新たな仮説・検証のサイクルを回していきましょう。このサイクルを高速で回すことでなるべく早いPMFを狙います。しかし、検証を続けるなかで自分達の仮説が誤りであったことが判明することもあります。そういうときは改めて Problem Spaceに立ち戻り、取り組むべき課題を再設定してピボットをしましょう。

終わりに

いかがでしょうか。ここまで具体的にプロダクト開発のプロセスを解説してくれている本は珍しいのではと思います。本のなかでは、こうしたプロセスが実際のプロダクト開発の事例と合わせて紹介されています。最後に数値分析のフレームワークについても触れらていたりと、いずれのトピックも勉強になることばかりでした。こういうモダンな手法を日本のモノづくりでも活かしていきたいですね。