BtoBのペルソナに感じていた違和感の正体 ─ 人ではなく、企業のコンテキストがジョブを生む

こんにちは、UXデザイナーの山本です。

今日はBtoBの意思決定を動かしているのは、個人の人格やジャーニーよりも、企業の人格とジャーニーの力学が強いのでは、という今の自分の考えについて書きたいと思います。

UXデザイナーとしてBtoBのプロダクトに関わる中で、個人のペルソナやカスタマージャーニーを軸にすることに、ずっと違和感がありました。この記事では、その違和感がどこから来ていたのか、そして代わりに何を軸にすると現場と話が噛み合うようになったのかを整理します。

ペルソナを共有すると「うちのお客様は違う」と言われる

ペルソナやジャーニーを作って営業メンバーに共有すると、返ってくる反応はだいたい同じでした。「うーん、うちのお客様はちょっと違うなぁ」。

それを無理に押し通そうとすると、どこかに歪みが出ます。資料の上ではきれいでも、現場の会話では使われなくなる。逆に、みんなが納得するところまで抽象度を上げると、今度は「それはそうだよね」で終わってしまい、何も意思決定ができなくなります。

• 個人に寄せる：具体的だが「うちとは違う」と言われる

• 抽象度を上げる：全員が納得するが、何も決められない

このジレンマを、長いあいだ「ペルソナの設計の仕方が違うのかなぁ…」と考えていました。でも、どうもそういう話ではなさそうでした。

現場ではユースケースのほうが通じた

実際の現場では、ペルソナよりもユースケースを使うようになっていました。そのほうが営業メンバーの腹落ち感があり、共通認識もつくりやすかったからです。

今振り返ると、理由ははっきりしています。ユースケースは「どんな状況で、何のために、どう使うか」をひとまとめにしたものです。そこには最初から、その企業の業務や体制、置かれている状況が含まれています。だから営業メンバーも「ああ、こういうお客様いるね」と自分の顧客に重ねて考えられた。

個人のペルソナでは具体的すぎ、抽象化したジョブでは遠すぎる。ユースケースは、そのあいだのちょうどいい粒度にありました。理論より先に、現場が正しい粒度を選んでいたのだと思います。

違和感の正体：ジョブは企業のコンテキストから生まれる

少しだけ前提を。ジョブ理論は、クレイトン・クリステンセンが提唱した考え方です。人は商品そのものが欲しいのではなく、ある状況で片づけたい用事（ジョブ）のために商品を「雇う」と捉えます。有名なのがミルクシェイクの話で、朝の長い通勤の退屈を紛らわせつつ午前中お腹を持たせるために、ミルクシェイクが選ばれていたというものです。

この例で鍵になっているのは、人の属性ではなく「朝の長い通勤」という状況でした。BtoBでは、この状況にあたるものが企業のコンテキストです。

BtoBでは、ジョブは個人からではなく、企業が持つコンテキストから生まれます。ここでいうコンテキストは、企業の目的、業務プロセス、権限、評価制度、システム構成などのことです。

きっかけは、ひとつの観察でした。担当者が変わっても、同じ行動や課題が繰り返されるんです。営業担当が入れ替わっても商談の入力は滞るし、担当が変わっても部門間の連携は同じところで詰まる。だとすると、その行動や課題は人に紐づいて生まれているものではない、と考えるほうが自然です。

もちろん、社員の意思や価値観がまったく作用しないとは言いません。ただ、その意思や価値観そのものが、企業のコンテキストから強く影響を受けています。

わかりやすいのが異動です。部署が変わったりポジションが変わったりすると、その人の「これがやりたい」も変わってしまう。個人の内側から湧いてくる意思だけで動いているなら、こうはなりません。「やりたいこと」の多くは、その人が今どの席に座っているかで決まっていきます。

そう考えると、個人のペルソナを営業に見せて「うちのお客様と違う」と言われたのも当然でした。営業が見ているのは個人ではなく、その個人を動かしている企業のほうだったからです。

分析の単位を、個人から「企業・組織・個人」の三層へ

BtoBでジョブを捉えるときは、少なくとも三つの層を分けて見る必要があります。

• 企業のジョブ：企業として、どんな成果を実現したいのか（例：営業生産性を上げたい）

• 組織のジョブ：部門や役割が、どんな責任を担っているのか（例：営業部長は売上予測の精度を上げたい）

• 個人のジョブ：その環境の中で、本人は何を前に進めたいのか（例：営業担当は目の前の商談を前に進めたい）

この三つは一致するとは限りません。それぞれは合理的でも、つながっていなければ、組織全体では非合理な行動が生まれます。

たとえば営業担当がSFAに入力しないとき、「入力が面倒な人」と捉えると、打ち手は入力画面の改善になります。でも、上司が記録を見ない、評価に関係ない、入力より顧客への連絡のほうが成果につながる、という環境なら、入力しないことは本人にとって合理的な選択です。ここで直すべきは個人の操作性ではなく、企業の目的が制度や業務を経て個人の行動に変わるまでのつながりのほうです。

そして、この層のずれ自体が、プロダクトにとっての機会になります。

実務で何が変わるか：要望を件数ではなくジョブで束ねる

この見方がいちばん効くのは、顧客要望の扱い方です。

たとえば「基幹システムとツールを連携したい。本当は自動がいいが、今はツールに入れるためにデータを手作業で加工している」という要望が来たとします。要望の件数だけを数えると、「これ、特定の顧客の要求じゃない？」となりがちです。

でもジョブに目を向けると、「複数のシステムに散ったデータを、手間なく正しく揃えて使いたい」というジョブを抱えている顧客は、ずっと多いはずです。まだ声を上げていない顧客や、手作業でしのいでいる顧客も含まれるからです。そうなると、「やろう」という判断に変わります。

大事なのは、HOWは変わってもジョブは変わらず、こちらからは変えられないということです。自動連携なのか、インポートの改善なのか、データ加工そのものを不要にするのか。手段はこちらが選べます。だから会話が「何社が欲しいと言っているか」から、「このジョブに最適なHOWは何か」「他社とどう差をつけるか」に移ります。

この見方で、リプレイスの説明もつきます。リプレイスとは、顧客がジョブに対して、より適した手段を見つけてしまった状態です。ジョブはそのままで、手段だけが入れ替わる。だとすると、リプレイスされないために守るべきものは、既存の機能ではありません。ジョブに対する最適な手段であり続けるよう、アップデートし続けることです。

もうひとつ、ジョブの粒度も判断材料になります。具体的すぎれば母集団が小さくなり、抽象的すぎれば打ち手が決まりません。そのジョブを抱える顧客の数と開発コストのバランスがいちばん良い粒度を探すことが、投資判断そのものになります。

個人が効かない、という話ではない

誤解のないように補足すると、個人の影響がゼロだと言いたいわけではありません。決裁者のこだわりや、社内で導入を推し進める人の熱量は、実際の意思決定を大きく左右します。現場には裁量もあるし、制度に対する工夫や抵抗もあります。

また、人が変わっても同じ行動が続くからといって、原因が必ず企業の環境にあるとも限りません。仕事そのものの性質や、技術的な制約が原因のこともあります。そこを切り分けるには、現場を観察するしかありません。ジョブは机の上で定義するものではなく、観察を積み重ねた結果として見えてくるものだと思います。

ここで言いたいのは、BtoBでは「主に効いている力学はどちらか」と問われたら、個人よりも企業のほうだ、ということです。

おわりに：主語を問い直す

ペルソナやジャーニーを捨てよう、という話ではありません。人間中心設計の考え方そのものも大切です。ただ、BtoBでは「誰が」を考える前に、「その人を動かしているのは何か」を問う必要があります。

個人を理解することと、個人の行動を生み出している構造を理解することは、同じではありません。BtoBのUXでは、ユーザーを理解するだけでは足りない。ユーザーを取り巻く企業が、その人に何をさせ、何をさせないのかまで見る必要があります。

人間中心設計に見えて、実は「環境因果設計」に近い。ずっと感じていた違和感は、分析の主語がずれていたことのサインだったのだと思います。