CODEX 4. B2Bの顧客は一人ではない。
B2B製品を開発するスタートアップがよく陥る落とし穴があります。現場の担当者とのミーティングのあと、歓喜してしまうことです。「うちの製品をすごく気に入ってくれました!これは絶対に売れます!」。ところが、その人の上司であるチーム長とミーティングすれば予算の話を、役員とミーティングすれば戦略の方向性の話を聞かされ、結局プロジェクトは静かに消えていきます。なぜでしょうか?
顧客を「一人」だと勘違いしていたからです。現場の担当者は自分の業務効率を、管理者はチームの成果を、経営陣は会社の成長を見ています。彼らのニーズはすべて異なります。私たちの役割は、それぞれの演奏者のニーズをすべて満たしながら、同時に交響曲全体を完成させるたった一つの「中心課題」を見つけ出すことです。
表面の課題(Apparent Problem)と中心課題(Central Problem)を区別しなければなりません
利害関係者が複数いるときに課題の定義が難しいのは、それぞれが自分の「表面の課題」だけを語るからです。
表面の課題(Apparent Problem)とは、各利害関係者が自分の立場から感じている個別の痛みです。現場の担当者は「このソフトウェアは使いにくすぎます」と言い、管理者は「メンバーの業務状況がひと目で把握できません」と言い、経営陣は「競合よりもプロジェクトの処理スピードが遅い」と言います。
中心課題(Central Problem)とは、これらすべての表面の課題を貫く、たった一つの本質的なボトルネックです。顧客企業自身もはっきりとは認識していないことが少なくありません。たとえば、「受注・制作・納品へとつながる中核ワークフローが非効率である」といったものです。
この中心課題を解決すれば、現場の担当者の不便が解消され、管理者のニーズが満たされ、経営陣の戦略的な目標が達成されます。散らばった点(表面の課題)をつなぎ、一本の線(中心課題)にすることこそが、私たちの本当の課題です。
顧客は製品ではなく、成果を雇用します:Jobs to be Done
ハーバード・ビジネス・スクールのクレイトン・クリステンセン教授が提唱した「Jobs to be Done(片付けるべき用事)」理論は、この複雑な状況を見通す強力なレンズを与えてくれます。この理論の核心は、「顧客は製品を買うのではなく、自分の『用事を片付けるために(to get a job done)』製品を雇用する」というものです。
この理論は、複数の利害関係者が絡み合うB2Bの状況で、特に強力な洞察を与えてくれます。オーケストラの演奏者たちは同じ製品を見ていても、それぞれ異なる「用事」を任せるために雇用しようとします。
ユーザー(User)は、「繰り返しの報告業務を減らして、クリエイティブな仕事に集中したい」という機能的(Functional)な用事のために製品を雇用します。管理者(Manager)は、「チームの業務状況をリアルタイムで把握し、成果を予測したい」という管理的(Managerial)な用事のために製品を雇用します。経営陣(Decider)は、「会社の非効率を減らし、市場での競争力を高めたい」という戦略的(Strategic)な用事のために製品を雇用します。
結局、私たちが見つけるべき「中心課題」とは、これらすべての利害関係者が共通して解決を望んでいる、最も重要な「用事(The Job)」なのです。私たちの本当の役割は、それぞれが求める機能(Feature)を売ることではなく、組織全体が喜んで「雇用」するだけの価値がある、究極の「用事」を定義して解決することです。
Slackはいかにして組織全体を説得したのか
今日、最高のコラボレーションツールとして挙げられるSlackの初期の成長戦略は、購買組織を攻略した完璧な例です。
Slackは最初からCEOやCIOのもとを訪ねたわけではありません。開発者やデザイナーといった「ユーザー(User)」に、まず深く入り込みました。ユーザーはSlackの圧倒的な使いやすさに熱狂し、自発的な「インフルエンサー(Influencer)」となって、チームにSlackを広めていきました。
チームの「管理者(Buyer)」は、Slackの導入後にチームのコミュニケーションコストが減り、開発スピードが上がったことをデータで確認しました。そしてついに「決裁者(Decider)」が、「全社的なコミュニケーションの非効率」という「中心課題」を解決するために、Slackの全社導入を承認したのです。
Slackはそれぞれの演奏者に最適な楽器を提供しながら、最終的にオーケストラ全体の演奏を変えることに成功したのです。
利害関係者マップを描き、中心課題を貫く
ステップ1. 利害関係者をリスト化する
ミーティングに出てきた一人が顧客のすべてだと勘違いしてはいけません。自社の提案書が最終決裁されるまでに経由しなければならない、すべての人の役割をマップ上に描く必要があります。自社製品のチャンピオンになってくれる「ユーザー」は誰で、最終的に財布を開く「決裁者」は誰なのかを把握しなければなりません。
ステップ2. それぞれの課題(Pain)を聞く
各利害関係者に会い、彼らの言葉で課題を聞かなければなりません。このとき、「うちの製品はいかがですか?」と尋ねてはいけません。「チーム長の一番の悩みは何ですか?」「主にどんな業務で残業されていますか?」「CEOにどんな数字を報告するときに、一番ストレスを感じますか?」のように、彼らの成功と失敗にまつわる話を聞くべきです。
ステップ3. 中心課題(Keystone Problem)につなげる
それぞれの演奏者が奏でる音(表面の課題)の中から、彼らを一つに束ねる共通の和音(中心課題)を見つけ出さなければなりません。
「開発チームの頻繁な残業(ユーザーの課題)とプロジェクトの納期遅延(管理者の課題)、そして競合と比べて遅い市場投入スピード(経営陣の課題)は、すべて『開発・デプロイプロセスの非効率』という一つの中心課題から生じています」。
この一文を完成させられたとき、初めて製品は単なる「機能」ではなく、組織全体のための「ソリューション」になります。
brunch作家 jaha Kim氏の同意のもと、[Startup Codex 22]のコンテンツを活用して制作しました。
jaha Kim氏のほかのコンテンツが気になる方は、下のリンクからご覧いただけます。
© 2026 GritBD. 本サイトのすべてのコンテンツは著作権法により保護されています。All rights reserved



