作る前に顧客の行動、制約、既存の工夫を確かめれば、需要のない開発を減らせる

1. いちばん伝えたいことと、本書固有の射程

いちばん伝えたいことと、本書固有の射程

『Lean Customer Development』の核は、作る前に顧客の行動、制約、既存の工夫を確かめれば、需要のない開発を減らせるという主張にある。仮説を明示し、適切な顧客へ開かれた質問を行い、観察事実から最小実験を作るという考え方は、施策を増やすための型ではない。現状の意思決定で何を成果と誤認し、どの前提を検証できていないかを明らかにするために使う。

課題があると語るが、実際には代替へ時間や費用を払っていない見込み顧客を見極める状況では、表面上の要望より、失敗を避けたい、前へ進みたい、自分や所属を守りたいという欲求が選択を動かす。ただし本書に欲求理論を読み込むのではなく、当サイトの分析仮説として、観察できる行動と結びつけて扱う。顧客の発言、実際の代替、支払った金額、費やした時間が一致するかを確認する。

2. 誰に・何を届けるかと根源欲求から読み直す

WHOは属性でなく、課題があると語るが、実際には代替へ時間や費用を払っていない見込み顧客を見極める状況に置く。

WHATは機能でなく、その状況で得たい変化である。主な障壁は将来の希望や機能評価を需要の証拠と誤認し、丁寧な賛同を購入意思とみなすこと。企業が便利さを訴えても、顧客が失敗、損失、孤立、面倒を強く避けているなら、選択理由は性能表だけでは作れない。

同じ目的を満たす別の選択肢は表計算、社内の工夫、外注、既存サービス、何もしないことまで含む。HAVEは手に入れたい状態、DOは実行したい行動、BEはなりたい自分や保ちたい所属として分ける。どの欲求が最も強いかを最初から断定せず、選択前後の行動差、継続、解約理由で検証する。

3. 企業事例で因果を分解する

Microsoft：業務ソフトの要望より既存作業の頻度と損失を観察する。

ここでは施策名より、誰のどの状況で何が選択理由になり、どの行動が先に変わるかを見る。マネーフォワード：家計の不安と入力負荷を行動履歴で分ける。同じ原則でも、購買頻度、意思決定者、導入負荷、提供原価が違えば有効な接点と回収期間は異なる。

さらにメルカリ：出品意向より撮影、価格設定、発送の離脱点を実地で確かめる。成功企業の表面を移植せず、固有資産、供給能力、顧客接点、収益構造を分ける。売上増が新規需要なのか、既存需要の移動なのか、値引きによる前倒しなのかを確認し、企業名を置き換えただけの一般論を避ける。

4. KPI・PL・BS・CFへわかりやすく言い換える

財務への橋は、有償実験率、初回価値到達、開発工数、CAC、継続粗利を検証段階ごとに見る。

仮説と見直すサインを書くことで対象を定め、過去の行動と代替を聞くことで早めに変化が表れる指標を置く。その変化が顧客数、頻度、単価、継続、粗利のどこへ届き、販売費、開発費、在庫、設備、運転資本を通じて営業利益と営業CFをどう動かすかを一続きで描く。

5. 適用限界、見直すサイン、読後の実務

少数インタビューの頻度を市場規模へ外挿せず、行動データと購買で補強する必要がある。

この限界を注記で終えず、見直すサインへ変える。主要行動が動かない、顧客不利益が増える、想定期間で粗利へ届かない、追加投資を止めると効果が消える場合は、実装だけでなく本書から借りた前提を見直す。

読後は有償行動で需要を確かめる。対象顧客と状況を一つに絞り、現在の代替、最大障壁、根源欲求の仮説、変更する接点、早めに変化が表れる数字、財務KPI、停止条件を一枚にする。一購買周期で証拠を集め、本を正解集ではなく、損失を抑えながら学習する仮説装置として使う。