こんにちは、大平です。
プロダクトを作っている人と話していると、何度も出てくるテーマがあります。
それが、いいものを作れば売れるのか問題です。
僕もエンジニアなので、気持ちはよく分かります。 いい設計で、ちゃんと動いて、使いやすければ売れるはずだと思いたい。 しかし、技術的な完成度と、顧客が購入を決めることの間には、いくつもの条件があります。
売れないときに「機能が足りない」と判断して開発を続けると、原因が価格や販売導線にあっても、技術予算だけが減っていきます。 意思決定者が先に見るべきなのは、追加機能の候補ではなく、顧客が購入に至らない場所です。
この記事では、売れない理由を「相手、課題、価格、導線、タイミング」の五つに分け、実装前に価格付きで確かめる手順と、投資判断に使う指標を整理します。
技術品質は必要条件だが、購買理由とは限らない
技術的に良いものは大事です。 安定して動き、データを安全に扱い、変更を続けられる品質がなければ、顧客へ価値を届け続けられません。 とくに法人向けプロダクトでは、セキュリティ、運用、監査、障害時の復旧まで含めて商品です。 技術品質を事業の論点として捉える考え方は、コード品質が事業競争力になる理由でも詳しく書きました。
ただし、品質が高いことだけでは、購入の十分条件になりません。 顧客が社内で予算を確保するには、業務時間の削減、売上機会の増加、損失やリスクの低減など、投資する理由を説明できる必要があります。 コードの設計は、その価値を安定して届ける手段です。 顧客が最初に買うのは、コードそのものではなく、導入後に変わる業務や事業の状態です。
この区別は、イノベーションの定義にも表れています。 OECDの「Oslo Manual 2018」は、プロダクトイノベーションを、自社の従来の製品やサービスと大きく異なる新規または改善された製品やサービスが、市場へ導入された状態と定義しています。 社内で完成したことと、市場へ導入されて価値を生んだことは、同じではありません。
売れない理由を五つに切り分ける
売れないという結果だけを見ても、次に何を変えるべきかは決まりません。 機能を増やす、価格を下げる、広告を増やすという施策は、それぞれ別の原因に効く打ち手だからです。 まずは原因を次の五つに分けます。
- 相手：困りごとを持つ企業ではなく、業種、規模、役割、業務量が違う相手に提案している
- 課題：困りごとはあるが、現状の代替手段を変えるほど強くない、または予算を使って解決する課題ではない
- 価格：提供価値に対して高い、安すぎて導入支援を賄えない、または顧客の予算区分と合っていない
- 導線：対象顧客へ届いていない、価値が伝わっていない、比較や稟議に必要な情報が足りない
- タイミング：課題はあるが、予算、担当者、法改正、システム更改などの購入契機がまだ来ていない
五つは相互に影響しますが、同じ問題ではありません。 たとえば商談がほとんど生まれていないなら、機能不足より先に、相手と導線を疑うべきです。 デモの評価は高いのに価格提示後に止まるなら、課題の優先度、価格、稟議材料を調べます。 契約後すぐに使われなくなるなら、購入前の訴求より、実際の価値、導入設計、対象顧客との適合に問題がある可能性があります。
原因を切り分けずに「もっと良いものを作る」と決めると、あらゆる問題が開発チームへ流れ込みます。 その結果、ロードマップは要望で膨らみますが、受注率が変わらないという状態が起きます。
相手と課題は、属性ではなく現在の行動で確かめる
対象顧客は「中小企業」「経理担当者」のような広い属性だけでは決まりません。 同じ規模や役割でも、月に処理する件数、ミスが起きたときの損失、既存システム、決裁権限によって、購入理由は変わります。
確認したいのは、「その課題があるか」だけではありません。 いつ起きたのか、現在はどう対処しているのか、誰が何時間を使っているのか、放置すると何が起きるのか、過去に解決を試したのかを聞きます。 すでに表計算、外注、人手による確認などへ費用や時間を使っているなら、少なくとも課題へ対処する行動は存在します。 何もしていない場合は、未解決だから機会があるとは限らず、優先度が低い可能性も残ります。
Christensen Instituteが解説するジョブ理論では、顧客が特定の状況で成し遂げようとする進歩に着目します。 この見方を使うと、「どの機能が欲しいですか」ではなく、「どの状況を変えるために、今の手段から乗り換えるのか」を問えます。
インタビューの具体的な質問と、既存顧客と見込み顧客の声を分ける方法は、顧客の声を聞く方法大全にまとめています。 ここで得たいのは賛成意見ではなく、顧客の過去と現在の行動です。
価格は最後に付ける数字ではない
価格を伏せたままプロダクトを見せると、検証できるのは興味の有無までです。 購入判断では、顧客が得る価値だけでなく、予算、比較対象、契約期間、導入支援の範囲も評価されます。 したがって、価格は完成後に営業が決める付属情報ではなく、実装前から検証する事業仮説です。
価格に反応がなかったとき、すぐに値下げするのは早計です。 想定した効果が伝わっていない、効果を得るまでの手間が大きい、稟議の予算区分に合わない、契約単位が顧客の利用単位とずれている、といった可能性もあります。 価格、提供範囲、導入条件を一つずつ変え、どの条件が判断を止めたのかを確かめます。
安くすれば受注しやすく見えますが、導入支援やサポートを含めて採算が合わなければ、売上が増えても事業は苦しくなります。 低価格を選ぶ前に確認すべき事業構造は、AI時代に見直したい低単価戦略の罠でも扱っています。
導線は認知だけでなく、稟議まで含めて設計する
対象顧客が存在し、課題と価格が合っていても、購入までの導線が欠けていれば売れません。 BtoBでは、利用者が価値を感じた後に、上長、情報システム部門、法務、セキュリティ部門、購買部門などが判断へ加わることがあります。 最初の担当者向けのデモだけでは、後から参加する意思決定者の疑問に答えられません。
導線を診断するときは、対象顧客へ接触できているか、商談へ進むか、価格付き提案を出せるか、社内の検討が進むか、契約できるかを順に見ます。 各段階で止まった理由を分ければ、広告、営業資料、デモ、セキュリティ回答、契約条件のうち、どこへ投資すべきかが見えてきます。
「問い合わせが少ない」と「提案後に失注する」では、必要な施策が違います。 前者に機能追加をしても対象顧客へは届かず、後者に広告を増やしても同じ理由で失注が増えるだけです。
タイミングは需要の有無と分けて記録する
「今は買わない」という回答は、「課題がない」と同義ではありません。 年度予算が確定した直後、担当者が異動した直後、既存契約の更新直後では、価値が伝わっても購入できないことがあります。 反対に、法改正、監査指摘、採用難、システム更改、事業拡大などが、検討を始める契機になります。
タイミングが原因なら、機能を増やすより、次の予算策定時期、契約更新日、社内プロジェクトの開始条件を記録します。 営業管理には「失注」とだけ残さず、「対象外」「課題が弱い」「価格」「稟議」「時期」に分けて残すべきです。 この分類がなければ、同じ失注件数でも、市場を変えるべきなのか、次回の接点を待つべきなのかを判断できません。
作る前に一人の顧客へ価格付きで見せる
売れるかを確かめる最小の一歩は、次に作ろうとしているものを、実装前に一人の顧客へ見せることです。 画面のモック、提案資料、手作業を含む試験提供でも構いません。 ただし、機能の説明だけで終わらせず、価格と導入条件まで添えます。
顧客開発を提唱したSteve Blankは、Harvard Business Reviewの記事で、事業モデルを固定した計画として扱うのではなく、顧客との接触を通じて検証する仮説として扱う方法を説明しています。 この考え方を実務へ落とすと、次の順番になります。
- 仮説を一文にする：誰の、どの状況にある課題を、どの状態へ変え、その対価としていくら受け取るのかを書く
- 候補顧客を一人選ぶ：知人だからではなく、想定する業種、規模、役割、課題の発生頻度に合う相手を選ぶ
- 一枚の提案にする：課題、導入後の変化、提供範囲、提供しない範囲、価格、開始時期を一枚にまとめる
- 現在の行動を聞く：過去に同じ課題が起きた場面、今の解決方法、使っている時間や費用、決裁者を確認する
- 価格付きで提案する：「便利そうですか」ではなく、この条件なら次の手続きへ進めるかを聞く
- 次の行動を決める：再商談、決裁者の同席、試験導入の合意、見積依頼など、双方の具体的な行動を日付付きで置く
- 止まった理由を記録する：相手、課題、価格、導線、タイミングのどこが仮説と違ったかを残す
一人への提案で市場全体は判断できません。 一方で、一人へ具体的に売れない提案を、対象も条件も変えずに大規模開発する根拠もありません。 最初の一人は市場規模を証明するためではなく、仮説の大きな誤りを低い費用で見つけるために選びます。
「欲しい」という言葉より、次の行動を見る
顧客が好意的だったかどうかだけでは、投資判断に使えません。 商談では、関係を悪くしないための称賛や、条件を精査する前の興味も含まれるからです。 反応は、発言ではなく、相手が引き受けた行動の強さで読みます。
- 弱い証拠：便利そう、あれば使いたい、社内で共有すると言った
- 中程度の証拠：決裁者を紹介した、データや現行業務を開示した、次回の検討日を確保した
- 強い証拠：価格と範囲を記した試験導入へ合意した、発注手続きを始めた、開始日と担当者を決めた
もちろん、契約前に発注を確約できない企業もあります。 その場合も、セキュリティチェックを始める、稟議に必要な資料を指定する、実データを使う検証日を確保するなど、その組織で可能な次の行動を見ます。 無理に先払いを求めることが目的ではなく、称賛より費用のかかる行動を取る意思があるかを確かめることが目的です。
検証結果に応じて、変える場所を限定する
検証で否定的な反応が出たとき、提案全体を一度に変えると、何が原因だったのか分からなくなります。 五つの分類に戻り、次の一手を限定します。
- 相手が違う：機能は変えず、課題の発生頻度や損失が大きいセグメントへ提案する
- 課題が弱い：要望を足す前に、予算を使って解決されている別の課題を探す
- 価格で止まる：値下げの前に、効果の示し方、提供範囲、契約単位、導入支援を見直す
- 導線で止まる：利用者以外の決裁条件を確認し、比較、稟議、セキュリティ、契約の資料を補う
- タイミングが合わない：購入契機と次回接点を記録し、開発案件としては保留する
機能を増やすのは、必要な機能がないために、対象顧客が価格と導入条件を受け入れられないと分かったときです。 この順番なら、営業上の問題を開発で解こうとする誤投資を減らせます。
意思決定者が見るべき指標
指標は、プロダクトの成熟度に応じて変えます。 実装前に継続率は測れず、販売前に売上だけを求めても学習できません。 決裁者は、検証、販売、利用の三段階を分けて見ます。
実装前の検証指標
- 対象顧客との接触数：想定条件に合う相手へ、何件提案したか
- 価格提示数：金額と条件を曖昧にせず、何件へ提示したか
- 次の行動への移行率：決裁者同席、試験導入、見積依頼などへ進んだ割合
- 否定された仮説の内訳：相手、課題、価格、導線、タイミングのどこで止まったか
接触数だけを増やしても、対象がばらばらなら学びは蓄積しません。 同じ仮説を複数の対象顧客へ提示し、反応の共通点と差分を見ます。
販売段階の指標
- 対象顧客から商談への移行率：狙った相手に価値提案が届いているか
- 商談から価格付き提案への移行率：課題と決裁条件を具体化できているか
- 提案から契約への移行率：価格、稟議材料、契約条件が購入を妨げていないか
- 販売サイクル：最初の接点から契約まで、どの段階に時間がかかっているか
率の高さを単独で評価するのではなく、業種、企業規模、流入経路、提案内容ごとに分けます。 全体平均だけを見ると、反応の良い小さな市場と、反応の悪い大きな市場が混ざり、次の投資先を誤るためです。
利用開始後の指標
- 初期価値への到達率：契約した顧客が、想定した最初の成果まで進んだか
- 価値到達までの時間：導入から成果を確認できるまで、何日、何工程かかったか
- 継続率と利用頻度：一度使われただけでなく、対象業務へ定着したか
- 拡張と解約の理由：利用人数や契約範囲が広がった理由、継続しなかった理由は何か
- 顧客別の粗利：売上に対して、導入支援、個別対応、運用にどれだけ費用がかかったか
契約は需要の証拠ですが、価値を届けられた証拠ではありません。 導入後に使われない場合は、販売時の約束、初期設定、業務への組み込み、プロダクト品質のどこに問題があるかを改めて分けます。
作る前と作った後で、品質への投資判断を変える
実装前の検証では、完成品と同じ品質は要りません。 モックや手作業で顧客の判断に必要な体験を再現できるなら、まず需要と価格を確かめられます。 ただし、実現できない機能を実現できるように見せたり、手作業を自動処理だと説明したりしてはいけません。 試験提供であることと、本番時に変わる条件を明示します。
購入意思が確認できた後は、品質への投資が必要です。 デモで動くことと、監視、権限管理、例外処理、保守を含む製品として運用できることには差があります。 この差は、デモは作れた、で製品はいつ出せるのかで整理しています。
つまり、品質を軽視するのではなく、投資する順番を変えます。 売れる理由を検証する前に本番品質へ作り込まず、購入意思を確認した後は、約束した価値を継続して届けるために品質を上げます。
市場を見ることは、営業職になることではない
エンジニアが市場を見るとは、全員が営業職になることではありません。 誰が何に困り、どの条件なら購入し、利用後にどの状態を実現したいのかを、仕様判断の入力にすることです。
経営者や事業責任者は、対象顧客、解く課題、価格、投資上限を決めます。 営業は、顧客の意思決定過程と、提案が止まった理由を持ち帰ります。 エンジニアは、最も費用の低い検証方法と、本番で守るべき品質条件を示します。 どれか一つの職種だけに任せると、事業仮説と実装判断が分断されます。
作る人が顧客の判断材料に触れると、仕様の切り方も変わります。 「この機能は作れるか」だけでなく、「この機能がなければ購入できないのか」「本実装の前に何を確かめられるか」を問えるようになるからです。
まとめ
- 技術品質と購買理由を分ける：品質は価値を届け続ける条件だが、顧客が予算を使う理由は導入後の変化にある
- 売れない理由を五つに分ける：相手、課題、価格、導線、タイミングを混ぜず、止まった場所に合う施策を選ぶ
- 実装前に価格付きで見せる：一人の対象顧客へ条件を提示し、称賛ではなく次の行動が生まれるかを確かめる
- 段階に合う指標を見る：実装前は仮説と行動、販売時は転換と期間、導入後は価値到達、継続、粗利を追う
- 品質への投資順序を変える：需要を確かめるまでは小さく検証し、購入意思を確認した後は本番運用に必要な品質を作り込む
いいものを作る力を、必要な人へ届き、継続して使われるところまでつなげる。 そのために、次の機能を作る前に、一人の顧客へ価格とともに見せてみてください。