PSF（Problem Solution Fit / 解決策検証）

前ステージのCPF（Customer Problem Fit / 課題検証）を通じて、顧客の理想の状態と、そこへ至る道筋を阻む問題は確かに存在すると確かめられました。
これらを解消するための解決策を顧客に見せると、思いのほか多くの反応や要望が次々に返ってきます。

熱量のある声を聞くと、チームの誰もが早くその要望に応えたプロダクトを作りたくなります。
課題が見えたことで不確実性が一つ減り、開発という目に見える作業に入れば、事業が着実に進んでいるという実感を得やすいからです。
ある報告会で「10社にインタビューして全社が点検記録の紙運用に悩んでいました。ニーズは確実です」と報告された途端、仕様や作る時期、作り方の議論が始まるケースはよく起こります。
案件リソースを投じて何かを作り始める動きは、周囲の期待も高めていきます。

しかし、顧客から返ってくる発言は、そのまま作って進めて構わないという指示書にはなりません。
「こんな機能がほしい」という言葉を真に受けて要望に応え続けると、多機能なだけで誰の業務にも入り込めないシステムが出来上がります。
作ること自体が目的化し、気づいたときには後戻りできないほどリソースをロックしてしまいます。

本章では、打ち手の分岐から顧客の依存が生まれる枝を選び抜く進め方を扱います。
顧客の発言にとらわれず、要因まで掘り下げて検証していく手順の整理です。

このステージの問いとゴール

このステージのメインの問いは、「解決策を体験すると顧客は依存するか？」です。
そしてゴールは、「プロトタイプあるいはトライアル営業を通じて、リリース後の契約意向と最初に狙う顧客層（ICP）の反応が確認できている」状態とします。

ここで「依存」という強い言葉を基準にするのには理由があります。
ある体験会で、担当者が用意した画面を見た顧客は「見やすくて便利そうですね」「導入されたらぜひ使いたいです」と盛り上がりました。
ところが、実際の導入時期や料金の話になると、「今期は予算がなくて」「別部門の承認も要るからまた連絡します」と急にトーンが下がったそうです。
顧客の満足や好意は、単なる社交辞令やその場の雰囲気でも生まれます。
一方で、依存は行動にしか表れません。
「これがないと元のExcel管理には戻れない」「トライアルが終わったら明日からどうやって点検すればいいのか」と顧客が焦る状態が、代替手段との置き換え不能性を測る確かな基準になります。

元のやり方を取り上げたとき、顧客は本気で怒るか？

課題・問題・解決策の違いで触れたように、CPFで確定させた理想と問題に対し、課題を埋める打ち手は複数分岐します。
PSFの位置づけは、その打ち手の分岐の中から、顧客が依存する枝を選んで解決策として仮決めすることです。
着手する前にこの強い判定ラインを言い切っておくことで、「反応は良かった」という曖昧な報告で評価がぶれるのを防げます。

成立条件と達成条件

このステージを通過するには、大きく分けて2つの論点が成立している必要があります。
解決策への依存度と、最初に狙う顧客層（ICP）の広がりについて、成立条件と達成条件の表を作ります。
達成条件には、保全部門の点検記録を例とした仮の判定ラインを置いておきます。

解決策への依存度は、証拠の強度を段階的に上げて確かめます。
まずは言葉だけで価値を想像できるかを確認し、次に一部を体験してもらって継続利用の意思を確かめ、最終的に契約の約束を取り付けます。
判定ラインの数字を先に決めておくことで、どこまで到達すれば検証完了かが明確になります。

条件を洗い出したら、反事実思考で検査します。
「この解決策がなくても、少し手間をかければ今の運用で乗り切れるのではないか」と疑ってみると、その条件の必要性を確かめられます。
条件にモレやムダがないかを問う手順は、すべての根本となるスキルで扱った通りです。
十分に厳しい基準を設けることで、ゾンビ化のリスクを防ぎます。

見せ方は三段ある：モック・プロトタイプ・トライアル

打ち手の分岐を顧客に見せる手段は、大きく三段に分かれます。
①イメージを見せる、②一部を体験してもらう、③実際の業務や生活の中で使ってもらう、または対価を伴う約束を取る、という三段です。
モック・プロトタイプ・トライアルは代表的な呼び名であり、事業によって呼び方も形も変わります。
それぞれで確かめられることと、確かめられないことの範囲は異なります。

どこまで試せるかは、業種よりも、体験を作り直すのにかかるお金と時間で決まります。

大きなものほど「実際に使ってもらう」状態を作ることはできません。
そのときの依存の証拠は、申込金や予約、基本合意、購入の覚書のような対価を伴う約束で取ります。

この三段には、それぞれ典型的な誤読があります。
イメージを見せたときの「いいですね」という感想を依存と読んでしまうこと。
一部の体験での継続利用を、単に無料だから続いているだけと取り違えること。
そして実際の試用や約束で熱狂してくれた1社の熱量を、市場全体の熱量と錯覚することです。

プロトタイプや試験の環境は製品ではありません。
裏側が手作業の張りぼてでも、顧客が価値を体験できれば成立します。
小さく作り直せるものであれば、画面から入力されたデータを裏でチームが手作業で集計し翌朝返す形や、仕組み化する前にまず人が手作業で提供する形です。
試作にお金と時間がかかるものであれば、量産の型を作る前に手作りの試作品で使ってもらいます。
作ったら後戻りできないものであれば、本体を作る前に完成予想図と試験の数字で約束を取りに行きます。
ここで適用しているのはQuick & Dirtyの考え方です。
手作業や試作品で崩したのは体験の品質であって、顧客がそれを必要とするかという検証項目は崩れていません。
品質保証（SLA）や料金体系、提供体制を整えるのは次章のSPF（プロダクト検証）の役割です。

また、売る行為そのものが検証になります。
無料であれば誰でも使ってみたいと言いますが、確かめたいのは対価を伴う反応です。
複数の打ち手を並べて提示し、どれに対してなら対価を払うかという分岐を比べてみるアプローチも選択肢に入ります。

要望に応えるほど、課題から離れていく

解決策を見せると、顧客からは多くの要望が返ってきます。
あるインタビューで、A社からは「データはCSVで出したい」、B社からは「上長の承認画面がほしい」、C社からは「この点検項目も入力欄に入れてほしい」と言われました。
これらの要望にすべて応えると、仕様が3つ増えます。
しかし、CPFで確かめた「点検結果が当日中にそろわない」という本来の問題は、仕様が増えても小さくなりません。
モノやサービスでも同じで、「もっと軽くしてほしい」「担当を固定してほしい」といった要望が返ってきますが、これらに応えても状況は変わりません。

要望は、顧客自身が考えた打ち手であり、顧客ごとに異なります。
それらに応え続けると、1社には深く刺さっても、他の会社には使われない複雑なものに膨らんでいきます。
全体の期待値と不確実性のバランスが崩れ、開発の案件リソースをただ費やす結果に終わります。

欲しいと言われたものを渡し続けることが、相手のためになるとは限りません。
課題・問題・解決策の違いで触れた湿布の例のように、求めに応じるのが正しいのは、その求めが相手の理想の状態に向かっているときだけです。
要望をそのまま形にするのではなく、その奥にある問題を小さくする打ち手を探す手順を踏みます。

この要望に応えたら、CPFで確かめた問題は小さくなるか？

この問いを挟むことで、顧客の要望に振り回されることなく、解決策を絞り込めます。

発言は氷山の一角。要因をたどる

要望や不満、あるいは称賛といった水面の上の発言の下には、それを生んだ要因の連なりが存在します。
Whyを繰り返して下へたどり、CPFで確かめた問題に照らし合わせる作業が求められます。

先ほどのB社の「承認の画面がほしい」という要望を一本たどってみます。
要因を聞くと「上長の確認待ちで記録が止まるから」と返ってきます。
さらに聞くと「点検結果が当日中にそろわないと会議で遅れを説明できない」という背景が見えます。
行き着いた先は、CPFで確かめた問題そのものです。

3社の異なる要望が同じ問題に行き着くなら、その問題を小さくする1つの打ち手で3社とも依存する可能性があります。
たとえば「点検の当日中に結果がそろう流れを作る」という打ち手です。
こうしてCPFの問題につながる発言は、問題を小さくする打ち手を選び直すための材料になります。

一方で、つながらない発言もあります。
「帳票のデザインを自社仕様にカスタマイズしたい」という要望をたどっても、当日共有という問題には行き着きません。
これは、私たちが解こうとしている問題とは別の問題を見つけているか、最初に狙う顧客層（ICP）の外にいる相手のサインです。
捨てずに記録しておき、ターゲットの境界線を見極めるために使います。
「便利そう」という称賛も同じで、その下に何があるかをたどることで確かな価値が見えます。

注意したいのは、要因を聞くときの聞き方です。
「なぜ」を詰問のように繰り返すと、相手は責められていると感じてしまいます。
「そのとき現場で何が起きましたか」「それで誰が困りましたか」と、過去の事実として聞くとうまく引き出せます。

ICPは一点で決める

最初に狙う顧客層（ICP）は、市場全体ではなく狭い一点で決めます。
プロトタイプを見せたとき、10社のうち1社は飛びつき、5社はまあまあという反応で、残りの4社は見向きもしない結果になったとします。
このとき、飛びついた1社の特徴を探すのと同じくらい、見向きもしなかった4社の特徴を記録する作業が必要です。
「従業員数が50人未満の企業には刺さらない」「専任の保全担当者がいない現場では使われない」といった事実を拾い上げます。

刺さらなかった相手は、検証の失敗例ではありません。
私たちが提供する解決策がどこまで通用するのか、その境界線を教えてくれる貴重な観測点です。
誰には刺さらないのかという反証ケースを集めて初めて、ICPの明確な輪郭が描けます。
境界線が見えないまま進むと、誰にでも売ろうとして結果的に誰にも刺さらないプロダクトに行き着きます。

ICPの外への広がりについては、この段階で完全に検証しきる必要はありません。
「今は狙わないが、こういう条件が揃えば隣の業界にも刺さるかもしれない」という可能性とその根拠、未確認の範囲を言語化しておくにとどめます。
ここで残した記録が、後のステージで期待値と不確実性を評価し、市場の大きさを問われたときの確かな材料として活きます。

通過の目安と出口

このステージを通過できるのは、次のSPFステージに進んで提供体制への投資を無駄にしない状態になったときです。
達成条件がすべて揃い、顧客の依存が行動で示されていれば、自信を持ってプロダクトを作り始められます。
一方で、検証の結果として終わらせる判断を下すこともあります。

ここでいうピボットとは、課題（CPFの結果）を持ち越し、解決策（打ち手の選択）だけを捨てて、打ち手の分岐に戻ることです。
たとえば、アプリでの自動化を提案しても反応がなく、人が支援する形に変えれば対価を払うかもしれないというケースです。
課題が残っている限り、アプローチを変えて再挑戦することは前進です。
もし課題の定め方自体が崩れたのであれば、CPFへ戻って検証をやり直します。
撤退基準に達した場合は、サンクコストにとらわれず速やかに終了します。

よくある落とし穴

PSFステージで陥りがちな落とし穴をまとめます。

• 試作品や試験の環境を作り込む：検証に必要な体験を超えて作り込むと、品質保証や提供体制を検証するSPFの先取りになり、検証の速度が落ちます。
• 無料トライアルの「使ってみたい」を依存と読む：言葉ではなく、行動として手放せない存在になっているか、対価を払ってでも使いたいかを見極めます。
• 要望をそのまま作る：顧客の言う通りに仕様を追加すると、本来の問題から離れます。
• 1社の特殊事情に引きずられる：最初の1社に深く刺さっても、その会社の特殊な事情に合わせすぎると再現性がなくなります。
• 刺さらなかった相手を記録しない：境界線が見えず、誰にでも売ろうとして結果的に誰にも刺さらなくなります。

課題と解決策という事業の核が検証され、顧客の依存が確認できました。
次章のSPF（Solution Product Fit / プロダクト検証）では、この価値を提供可能な形に整えられるかを確かめます。