顧客が捨てる代替案を見つけるまで、製品はまだ存在しない

「良い製品を作れば、顧客は使ってくれる」。この考えは、半分だけ正しい。実際には、顧客は製品の良し悪しを単独で評価しているのではない。目の前にある代替手段と比べて、乗り換える価値があるかを判断している。

ここに、需要仮説とアジャイルの意外な接点がある。需要仮説は「顧客の仕事を、現在の方法より良くできるか」という問いであり、アジャイルは「その答えを、できるだけ小さく早く確かめるにはどうするか」という方法である。

つまり、アジャイルとは単に開発を速くする技術ではない。顧客にとっての代替案を基準に、製品の存在理由を継続的に検証する経営システムである。

製品は単独では評価されない

顧客が買うのは、機能の集合ではない。顧客が買うのは、ある仕事を今より簡単に、速く、安心して終わらせる手段である。

たとえば、音楽配信サービスを考えてみよう。iTunesで曲を一曲ずつ購入していた人にとって、Spotifyの価値は「大量の曲があること」だけではない。曲を探し、購入し、管理するという一連の作業を、定額で聴くという体験に置き換えたことにある。競争相手は、別の音楽アプリだけではない。購入を我慢すること、動画サイトで探すこと、手元の音源を繰り返し聴くことも競争相手になる。

この視点に立つと、需要仮説は次のように書き換えられる。

「誰が、どの仕事を、現在どの方法で行っていて、その方法よりも自分たちの提案を明確に好むのか」

ここで重要なのは、「困っている人がいるか」という抽象的な問いではない。顧客が実際に使っている代替手段が存在するかどうかである。困りごとを語る人がいても、時間やお金を使って解決しようとしていなければ、それはまだ事業上の需要とは限らない。

反対に、顧客が不便な方法を使い続けているなら、そこには強い手がかりがある。最近三か月以内にiTunesで曲を購入した人は、音楽を入手する仕事を現在も行っている。その人にとって、Spotifyの提案は比較可能な現実的選択肢になる。過去に一度だけ購入した人と、毎月購入している人では、同じ「音楽に関心がある人」でも検証対象としての意味が違う。

この違いを無視すると、製品開発は簡単に自己満足へ変わる。チームは機能を追加し、画面を整え、計画通りに進捗を出す。しかし顧客は、既存のやり方を変える理由を見つけられない。

アジャイルの本当の対象は開発速度ではなく、不確実性である

アジャイルはしばしば、「短い期間で開発する方法」と説明される。しかし短い期間で大量の機能を作っても、顧客価値が増えるとは限らない。速さだけを追求すると、間違った方向へ進む速度が上がるだけである。

アジャイルが本当に扱っているのは、不確実性を小さな賭けに分解することだ。

製品開発には、少なくとも三種類の不確実性がある。

・望ましさの不確実性: 顧客は本当にその問題を解決したいのか ・実現可能性の不確実性: 技術や運用によって実現できるのか ・実行可能性の不確実性: 事業として継続的に提供できるのか

この三つのうち、最初に確認すべきなのは望ましさである。誰も欲しがらないものを、技術的に完璧に作っても意味がない。逆に、顧客が強く望む価値が見えれば、実現方法や収益モデルは後から調整できる場合がある。

ここで「小さく作る」という言葉の意味を取り違えてはいけない。小さくする対象は、単なる機能数ではない。検証したい仮説の単位を小さくするのである。

たとえば、飲食店向けに「予約業務を効率化するサービス」を作るとする。最初から顧客管理、決済、分析、メッセージ配信まで搭載する必要はない。まずは、予約の電話を減らすという仕事に絞り、特定の時間帯だけウェブ予約を受け付ける仕組みを試すことができる。

この試作品の目的は、完成度の高い予約サービスを提供することではない。店員が本当に電話対応の削減を価値と感じるか、顧客がウェブ予約へ移行するか、店側が運用を続けられるかを観察することである。

開発チームが作るべき最初のものは、製品そのものではない。顧客の行動から学べる実験装置である。

「成果物を出す」と「価値を出す」は別の仕事

多くの組織では、アジャイルを導入しても、古い評価方法が残っている。スプリントの完了数、実装した画面数、消化したタスク数が進捗として報告される。すると、チームは自然に「何を作ったか」を最適化し始める。

しかし、ボタンの色を青に変えることも、複雑な検索機能を追加することも、顧客の仕事を改善しなければ価値ではない。成果物は価値の証拠ではなく、価値を生むかもしれない仮説にすぎない。

ここで有効なのが、代替案差分という考え方である。新機能を評価するとき、「この機能は便利か」と問うのではなく、次の三つを問う。

一つ目は、顧客が現在何をしているか。二つ目は、その方法のどこに摩擦があるか。三つ目は、新しい提案によって、その摩擦がどれだけ減るかである。

たとえば、社内申請システムに高度な通知機能を追加したとする。通知が届くこと自体は便利だが、申請者が本当に困っているのが承認基準の不明確さなら、通知は問題の周辺を改善しているにすぎない。現在の代替手段が「申請後に担当者へチャットで確認すること」なら、通知機能の価値は、チャットで催促する回数をどれだけ減らせたかで測るべきである。

この見方は、プロダクトマネージャーの仕事も変える。プロダクトマネージャーは、要望を機能一覧へ変換する人ではない。顧客の仕事と代替案を理解し、検証可能な賭けへ変換する人である。

ユーザーストーリーも、単なる仕様文ではない。「誰が、何をしたいか」を書くだけでは不十分である。そこに現在の方法と、期待する行動変化を加える必要がある。

たとえば次のように書ける。

「毎週レポートを作成する営業担当者が、表計算ソフトへ手作業で転記する代わりに、五分以内に自動集計できるようにする。試用後も週一回以上利用し、手作業での転記時間が半分になることを検証する」

この形なら、作るものだけでなく、観察する結果も明確になる。開発の完了条件が「集計画面を実装した」から、「営業担当者が既存の転記方法を置き換えた」へ変わる。

本当の進捗とは、作った機能の量ではなく、顧客の行動を変える根拠が増えた量である。

学習速度を上げるには、問いを先に設計する

短い反復が有効なのは、早くリリースできるからだけではない。問いと答えの距離を縮められるからである。

大きな計画では、企画、設計、開発、テスト、販売が順番に進み、顧客の反応を知るまでに数か月かかる。その時点で問題が見つかると、修正費用も心理的負担も大きい。多くの関係者が関わっているため、「ここまで作ったのだから続けよう」という埋没費用も働く。

小さな実験では、間違いが安くなる。たとえば、十人の顧客に手作業でサービスを提供し、既存の方法より喜ばれるかを確認する。裏側が自動化されていなくても構わない。最初に検証すべきなのが「自動化技術」ではなく「顧客がこの結果を望むか」だからである。

この方法は、いわゆる手作業による試験提供として理解できる。オンライン学習サービスを作る前に、講師が毎週メールで教材を送り、受講者が継続するかを確かめる。家計管理アプリを作る前に、利用者が一週間、共有スプレッドシートへ支出を記録し続けるかを見る。こうした実験は見栄えがしないが、顧客の代替行動との比較には非常に強い。

ただし、実験には順序がある。最初からすべてを測ろうとすると、データが増えるだけで判断できなくなる。まずは「顧客が現在の方法を変えるほどの価値を感じるか」という最重要仮説に集中する。

その後で、実現可能性を検証する。十分な価値が確認できたら、次に処理速度、セキュリティ、運用コストなどを改善する。実行可能性については、継続利用、支払い、紹介、サポート負荷などを観察する。

この順序は、製品開発を三段階の門として捉えると理解しやすい。

一つ目の門は、顧客が欲しいか。二つ目の門は、繰り返し使えるか。三つ目の門は、事業として続けられるか。各門を通過する前に、次の門の最適化へ進まないことが重要である。

すぐ使える「仮説から反復」フレームワーク

現場でこの考え方を使うには、会議で抽象的な議論を続けるのではなく、一枚の仮説シートに落とすとよい。最低限、次の項目を埋める。

・対象顧客: どのような状況にいる誰か ・顧客の仕事: 顧客は何を終わらせたいのか ・現在の代替案: 今は何を使い、何をしているのか ・不満の証拠: 時間、費用、失敗、諦めなど、観察できる摩擦は何か ・新しい提案: 何をどのように置き換えるのか ・行動指標: 顧客が何をすれば、価値を感じたと判断できるのか ・停止条件: どの結果なら仮説を捨てるのか

特に最後の停止条件が重要である。仮説検証が機能しない組織では、都合のよい兆候だけが採用される。「何人かが興味を示した」ではなく、「初回利用者の半数が二週間以内に再利用する」「既存の手作業を週三回以上置き換える」など、行動に結びついた基準を先に決める。

インタビューでも、意見より行動を聞くべきである。「この機能があれば使いますか」ではなく、「最後にその問題が起きたのはいつですか」「そのとき何をしましたか」「その方法にどれくらい時間や費用を使いましたか」と尋ねる。

人は未来の行動を正確に予測できない。しかし、過去の具体的な行動については、比較的正確に語れる。需要仮説を強くするのは、熱意のある賛成意見ではなく、現在の代替案に対して顧客がすでに支払っている時間、金銭、注意力である。

Key Takeaways

・製品を評価するときは、機能の魅力ではなく、顧客が現在使う代替案との差分を見る。

・大きな構想を小さくする際は、機能数ではなく、検証したい仮説の単位を小さくする。

・開発の完了条件を、成果物の完成から顧客行動の変化へ置き換える。

・インタビューでは意見よりも、最近の具体的な行動、頻度、費用、時間を聞く。

・実験を始める前に、成功指標と仮説を捨てる停止条件を決めておく。

結論: 製品開発は、建設ではなく比較である

製品開発を建設作業として考えると、計画を立て、機能を積み上げ、完成を目指すことになる。しかし顧客の世界にあるのは、完成した製品と未完成の製品の比較ではない。新しい提案と、顧客がすでに使っている現実的な代替案の比較である。

そのため、優れたチームは「何を作るか」より先に、「顧客は今、何で代用しているか」を問う。さらに、作ったものを成果物として誇る前に、「顧客は本当に行動を変えたか」を確かめる。

アジャイルの価値は、予定を守ることではない。予定が間違っていたとき、損失を小さくしながら方向を変えられることにある。需要仮説の価値は、未来を言い当てることではない。現実との比較によって、思い込みを早く壊せることにある。

最も強い製品は、最も多くの機能を持つ製品ではない。顧客が捨ててもよいと思える古いやり方を、最も早く見つけた製品である。

次に作る機能を決める前に、顧客が今日どのように問題を解決しているのかを見に行こう。そこに、製品の本当の競争相手と、まだ誰も証明していない価値の入口がある。