- 「ユーザーは製品を使うが、支払い権限者ではない」状況では、核心は 誰が実際の権限と影響力を持っているか を見極めること
- 実際の権限を持つ 意思決定者 が、必ずしも 購入者や最初のユーザー と 同一人物ではない 可能性がある
- 小規模組織では時間短縮が重要なため、開発者が直接ツールを導入し、上層部を説得して購入 につながる可能性が高い
- 大規模組織ではセキュリティや手続き上の制約が強く、購入決定権が CTO や経営陣にあり、長い営業サイクルが必要 になる
- 購入権限者は必ずしも予算保有者と一致せず、製品価値を最も強く感じて推進できる人 が中核ターゲットになる
- 効果的な戦略は、ユーザーが経営陣を説得できるよう 具体的なデータと説得資料 を提供し、その過程を支援すること
- 最終的な成功 は、ユーザーが社内セールスの役割を果たせるよう それを支えるプロセスを設計すること にある
序文 – 問いの出発点
- 製品を実際に使うユーザーと、購入を決定する顧客が異なるとき、どのようにアプローチすべきか？
- 典型的には 開発者 が製品を試し、CTO または Director of Engineering が最終意思決定を行う B2B ソフトウェア営業 の文脈を前提としている
権限に関する本質的な問い
- 「本当に力を持っているのは誰か？」という問いが 最も重要なポイント である
- 単なる カード決済権限 や 製品試用の優先順位 ではなく、実際の影響力と動機 が購買フローを左右する
組織構造ごとのシナリオ
小規模組織の場合 : 組織構造がフラットで意思決定が速い
- 開発者 が製品を調べ、実際に導入を主導するケースが多い
- CTO の主な動機は 迅速な市場投入と反復 であるため、開発者のツール提案が 意思決定に重大な影響力 を持つ
- 開発者が無料で素早くツールを試し、その後有料に転換する Trojan-horse 型の拡散 がよく見られる
大規模組織の場合 : セキュリティ・コンプライアンスが主要な制約
- セキュリティなど 時間以外の制約条件 が存在し、リーダーシップの意思決定 がすべての過程で重要に作用する
- ユーザー（開発者）の自律的なインストールや購入は認められず、営業サイクルは長く複雑 になる
- 価値/リスクの認識基準 は UI/UX や DX よりも セキュリティと最終成果物 に集中する
真の影響力と価値の観点
- 予算権限者が常に実質的な権限者 とは限らない
- 重要なのは「誰がレバレッジを持っているか」「誰のインセンティブがプロセス進行に最も強く作用するか」である
- 価格に見合う 価値を実際に交換できる主体 が誰なのかを、現実的に把握する必要がある
具体的な製品導入フローの例
- ユーザー/開発者が製品にサインアップする
- 無料トライアルをローカル環境で使う
- 実際の機能価値（例: Pull Request 前後の比較、問題箇所のハイライト）を直接体験する
- 価値を認識 → 業務効率・自動化への期待が生まれる
- ユーザーがリーダーシップに必要性を説得する
- リーダーシップが社内テストと予算検討の後、承認または却下する
- リーダーシップが最終購入を承認する
- 製品購入完了、組織内でさらに拡大する
双方のインセンティブに関する問い
- 開発者がツールを提案する本質的な動機 を把握する（業務の利便性、個人の能力アピール、会社目標の達成など）
- リーダーシップの購入動機 を把握する（開発効率の向上、会社目標の迅速な達成など）
- こうした中核的な動機が存在するなら、次のような戦略を提案できる
実践的な対応戦略
- ユーザーがリーダーシップを説得できるよう、正確な導入前後の比較レポートなどの説得ツール を提供する
- この過程では 抽象的な助言ではなく、定量データに基づく結果 が重要
- 「以前の方法と比べてどれだけ時間が短縮されたか」といった 実数値 が説得の鍵になる
- 実際の購入対話がどう進むかを 顧客（開発者）インタビュー で把握し、説得プロセスの障害要因 を事前に解消する
- つまり、購入権限者を直接説得するより、ユーザーが社内セールスの役割 をうまく果たせるよう、あらゆる環境面の支援と具体的な資料を提供すべきである
- このプロセスでは ユーザーの成功がそのままベンダーの成功 に直結する（ユーザー・ベンダー・リーダーシップ・会社の全員が win する構造）
結論と要約
- ユーザーが製品の 社内セールスの役割 を成功裏に果たせるよう支援することが最良の戦略である
- リーダーシップを説得するために必要な 定量的根拠と具体的な価値資料 の提供に焦点を当てるべきである
- 組織規模と制約条件ごとに意思決定構造を綿密に分析 する作業が先行されなければならない
- 最終的に、ユーザーが成功すればベンダーと会社の双方が同時に成功する構造であることを強調する
1件のコメント
Hacker Newsの意見
何かをダウンロードしようとすると連絡先情報を要求され、その直後から営業担当が電話やメールで連絡してきて、丁重に断っても無視してミーティングの依頼を繰り返す状況にうんざりしている。自分には購買権限はないが、チーム内に不満を広めることはできるので、結局は製品イメージが悪くなる。エンジニアに推薦を聞かれれば、当然こうした点を伝えることになる。Veeam、AWS、Keyenceがそうだった
IT Managerとして、ほぼ毎週こうした経験をしている。私から返答が得られないと、同僚や社内の別の人に無差別にメールを送って迂回してくることがあるが、そうされるとそのドメインをすぐ全体ブロックしたくなる。それに、見積もりを1つもらうために無理やりデモを見せないでほしい。すでに製品は調べていて、必要ならトライアルも試しているはずなので、営業プレゼンやデモより先に見積もりを知らせるほうが合理的だ
Auth0やOktaでも同じ問題があった。実際に購買権限も予算も持っていたが、連絡があまりにしつこすぎて、ただ嫌になった
「不満のパワー」という概念はとても良い。特に無料で提供していても、セールスやマーケティングのチームが熱心すぎると、かえって会社の印象が悪くなりうる。顧客が望む方法で連絡すべきであって、自分たちの望むやり方だけを押しつけると逆効果だ。ただし、これはインセンティブ設計の面で難しさがある
一部のSaaSマーケティングチームでは、5〜15分ごとにメールを送ってくるような極端な経験をしたことがある。時には個々の社員の暴走かもしれないが、組織の上層部やCEOがメールマーケティングツールの設定を最大まで上げてしまっているケースもあるようだ
Microsoft製品もここに加えるべきだ。登録するには「プロフェッショナルアカウント」を作る必要があり、そのためにgmailアカウントは許可しないなど参入障壁が高い。30日トライアルを使って製品を評価しようとしても、アカウントの問題でそもそもアクセスすらできないことがある。こうした不便のせいでトライアルすら大変なのに、実際の導入プロセスは想像もしたくない。AIベースのCRM、ERP、Dataverseなどを使う気が起きない
こうした現象はプリンシパル＝エージェント問題に由来する。会社の経営陣が予算を握っている一方で、実際に製品やツールを使うのは開発者や現場の従業員だ。創業者の立場では、ユーザーを味方につけてリーダーシップを説得させるべきだと助言されるが、要点は実際にクレジットカードを持っている人と話せないのだから、ユーザーがリーダーシップを説得できるよう最大限支援すべきだということだ。つまり、ユーザーや開発者に実質的なセールスの役割を担ってもらう形になる。ただ、このアプローチはフリーミアムモデルなどには当てはまっても、病院システムやEHR（電子健康記録）のように、購買判断を管理者が一方的に下す業界では、実質的にユーザーが製品を試す機会すらないので、これをどう乗り越えるのかが気になる
実際の現場では、その逆の状況もよくある。洗練された営業担当が予算権限者を狙い、実際のユーザーとのコミュニケーションを遮断したまま先に契約を結んでしまう。利用者が不満を感じて問題を指摘するときには、すでにお金が支払われた後だ
「リーダーシップを説得する最適な機会を与え、リーダーシップにこうした選択肢を知らせられるだけでもユーザーを目立たせるべきだ」という助言を実践するために、私たちも「CEO Page」を別途作ったことがある https://www.rsync.net/products/ceopage.html
エンタープライズセールスのやり方について補足すると、意思決定者本人でさえ、実際の企業内のパワーダイナミクスをきちんと把握していない場合がある。さらに確認すべきなのは、その人がコストセンターに属しているのか、収益を生む部門に属しているのか、新しい技術導入を推進しているのか、それとも標準化された製品なのか、そして誰がこの製品をリスクや権力への脅威とみなすかを事前に考えることだ。誰に売り、誰を避けるべきか、いつ小さく入るか、大きく仕掛けるかを決める戦略には、こうした情報を反映させる必要がある
SlackとPostmanがよく使うやり方は、「すでに御社チームの96%が私たちの製品を使っています。もう購入したほうが合理的ではありませんか？」という形のアプローチだ
すると「みんなもう使っているのに、わざわざ買う必要がありますか？」という切り返しを受けることがあり、これは買い手とユーザーの乖離の大きさを示す質問だ。特に中小企業の環境ではその乖離が大きい
学生にソフトウェアを無料で提供するのも同じ理由だ
大企業内の小規模チームでも、こうしたことはよく起きる。セキュリティチームがあると、複数のSlackワークスペースに分散した利用を問題視することがあるため、「400人が12個のワークスペースを使う代わりに、1つの公式アカウントで管理しませんか」という理屈が通る
商用オープンソースや類似モデルの隠れた利点は、個人ユーザーの採用が増えるほど、会社としての採用も増える点にある
以前に起業した会社でもこの問題に直面した。実際の購買決定権のない開発チームに対してセールスをする必要があり、規模の小さな会社や例外的に権限者がいる場合は契約が容易だったが、大半は長いセールスサイクルの中でコスト削減を上位意思決定者に説得しなければならなかった。結局このプロセスは長引き、成功率も低く、会社が失敗した主因の1つになった。こうした話題がもっと公に扱われるのはうれしい。多くの小企業が経験しているが、公式な助言は意外と少ない
ユーザーが直接製品を使え、かつ同じ組織に属しているなら、このモデルはうまく機能する。しかし、ユーザーが意思決定者と直接関係していなかったり、購買の妥当性を証明しにくかったりする場合（例: 車向けのキーレスエントリーのポップ）には、どうアプローチすべきかが気になる。ドライバーにとっては大きな利点があっても、FordのCTOから見ればミーティング提案自体が不要に感じられるかもしれない。こういう状況で、製品開発後にどう市場へ入るべきか助言を求めたい
こういう場合はボトムアップ戦略が魅力的だ。Ford本社ではなく、中古車ディーラー、自動車修理店、アクセサリー販売店をターゲットに始めるのが有効だ。リモートスターターを例にすると、ユーザーには必要でも自動車メーカーは関心が薄いため、最初はオーディオショップでのクロスセルのような形で市場が形成され、その後メーカーもオプションとして採用するようになった。私も盗難防止装置でこうしたやり方を経験したことがあるが、小さく始めて顧客基盤を作り、徐々に大企業へアプローチしていくのが効果的だ
競合がすでにそのポップを導入している事実を強調して、FOMO（取り残されることへの恐れ）を刺激するやり方もある
エンタープライズでは、CTOだけにセールスすればいいわけではない。AWSやAzureのように本当に中核的な役割を担う企業なら、CTOと主要エンジニアだけを説得すれば全社的な変更も可能だが、大半のソフトウェアはラインマネージャーやディレクター、あるいは部門長が決めることが多い。しかも各部門ごとに導入するソフトウェアが異なるため、ターゲットを細分化する必要がある
B2B2Cマーケットプレイスは特に面白い。「B2B」ユーザーには料金を課さず、取引ごとに手数料を取るモデルでは、ユーザーを分散型のセールスフォースとして活用する。各ユーザーが自分専用のインスタンスを通じてB2C顧客を獲得できるよう支援しなければならない。創業チームの立場では開発すべきものが増え、混乱して感じられることも多いが、初期参入障壁が低く、各アカウントが最終顧客にうまく価値を届けるたびに自然と売上が大きく伸びる利点がある
私たちの会社もこの話に共感する。私たちはentity resolution関連のビジネスインテリジェンスAPIを作っているが、エンジニアリング、プロダクト、データサイエンスの各チームが関わるため、買い手とユーザーの分離が複雑になる。エンジニアは複雑な社内データマッチングの難しさを直感的に理解するが、経営陣は単にプロジェクトが遅れているとしか見ない。そのため最近は「チームがデータマッチングに何か月も費やしています」という言い方のほうが説得力がある。ある会社は10年間も内製構築を試みたが、いまだにまともに動いていない。もちろん、会社や状況によってアプローチが異なることも感じている
TikTokのように、取引ごとに仲介でパーセンテージだけを受け取る方式も1つのモデルになりうる