デザイン思考のB2B導入実務──エンドユーザー不在の現場で何を捨てるか

B2Cの文脈で設計されたデザイン思考のメソッドをそのままB2Bに持ち込むと、最初の共感フェーズで詰まります。

「エンドユーザーにインタビューしてください」と言われても、顧客企業の現場担当者には会えない。あるいは会えたとしても、その人が「採用の決定権を持っているか」が分からない。B2B特有のこの構造的な問題を無視したまま5フェーズを進めると、「ユーザーには喜ばれたが稟議が通らなかった」という典型的な失敗が待っています。

デザイン思考をB2Bで機能させるには、いくつかのことを意図的に捨て、いくつかのことを強化する必要があります。

B2B特有の構造：なぜ共感が難しいのか

B2Cのデザイン思考が前提にしているのは「課題を抱えた個人」です。その人に会い、その人の体験を深く理解し、その人の生活を改善するためのソリューションを作る。このシンプルな構造が、B2Bでは成立しません。

B2Bには「顧客」が少なくとも3層に分離しています。

• 購買担当（バイヤー）：ベンダー選定・予算管理・稟議書を書く人
• 現場ユーザー：実際にプロダクトを使う人
• 意思決定者（エグゼクティブ）：最終的に「GO」を出す人

この3者は異なる職階にいて、異なる評価基準を持ち、異なる情報源で判断します。購買担当は比較表とコストで判断し、現場ユーザーは操作性とワークフローへの適合で判断し、意思決定者は投資対効果と組織リスクで判断する。

ワークショップでよく起こるのは、現場ユーザーにインタビューして「この機能があれば使いやすい」というインサイトを丁寧に積み上げたのに、意思決定者が「それでROIはどうなるんですか」と聞いて話が止まるパターンです。ユーザーの課題は解けているのに、組織の問いに答えていない。

さらに、B2B特有の時間軸の問題があります。顧客企業の意思決定サイクルは3ヶ月から1年以上かかることが珍しくありません。「ラピッドプロトタイピング」を旗印にした2週間スプリントは、承認プロセスの最初の関門さえ通過できない速度感で設計されています。

何を捨てるか

1. 「個人の喜び」を最終ゴールにする甘さ

B2Cでは「このプロダクトを使った人が笑顔になるか」が最終的な判断基準になり得ます。B2Bではそれは必要条件でしかありません。現場ユーザーが使いやすいと感じていても、それが組織の業務KPIに接続されていなければ、導入の根拠になりません。

感情的な価値をゴールとして設定することをやめ、「この課題が解決されると、組織のどの指標が動くか」を最初に問うことに切り替えます。

2. ラピッドプロトタイピングの「速度」

「とにかく速く作って反応を見る」という文化は、B2B文脈では逆効果になることがあります。精度が低いプロトタイプを持ち込むと、それ自体が「このベンダーは本当に分かっているのか」という不信感を生みます。

B2Bでは速度よりも精度のトレードオフを意識的に選びます。プロトタイプは「動くもの」より「判断できるもの」として設計する。ROIの試算シート、導入後のオペレーション変化を示したビジュアルフロー、既存システムとの接続イメージ——これらが「B2Bのプロトタイプ」になります。

3. エンドユーザー1名への深掘り

1名のユーザーを徹底的に理解することは、B2Cのデザイン思考では強力な手法です。B2Bでは、その1名が「組織のどのポジションにいるか」を無視すると危険です。

現場ユーザーの課題と購買担当の課題は別物です。それを統合して捉えないまま進むと、「買う人を説得できない解決策」が出来上がります。

何を強化するか

DMU（意思決定ユニット）単位の共感マップ

B2Bのリサーチ設計の起点は、「誰に会うか」を組織構造から考えることです。マーケティング学者のフィリップ・コトラーらが整理した DMU（Decision Making Unit） の概念がここで役立ちます。購買の意思決定に関与する人物の役割を——イニシエーター・インフルエンサー・デシジョンメーカー・バイヤー・ユーザー・ゲートキーパー——に分類し、それぞれが「何を心配しているか」「何で判断するか」を把握します。

共感マップを個人単位ではなくDMU単位で作ることで、「誰のどの課題を解くと、最も意思決定が前に進むか」が見えてきます。

Jobs-to-be-Done（機能的ジョブ）の精緻化

クレイトン・クリステンセンが提唱し、アンソニー・ウルウィック（Anthony Ulwick）がOutcome-Driven Innovationとして体系化した Jobs-to-be-Done（JTBD） の視点は、B2Bデザイン思考に特に有効です。

B2B文脈では、顧客のジョブを「機能的ジョブ」「感情的ジョブ」「社会的ジョブ」に分離することが重要です。購買担当の機能的ジョブは「適切なベンダーを選定して稟議を通すこと」ですが、感情的ジョブは「失敗のリスクを取りたくないこと」であり、社会的ジョブは「自分の評価を守ること」かもしれません。

実際にやってみると、感情的ジョブへの対処（「このベンダーを選んで失敗した場合の責任はどう説明できるか」という不安の解消）が、機能的な優位性よりも購買判断を動かすことが多い。これはBtoB特有の「リスク回避」心理が購買動機の中心にあることを意味しています。

Value Proposition Design との統合

アレックス・オスターワルダー（Alexander Osterwalder）らの Value Proposition Design は、デザイン思考のツールキットと高い親和性を持ちます。「バリュープロポジションキャンバス」の「カスタマープロファイル」（やること・悩み・うれしいこと）と「バリューマップ」（製品・ゲインクリエーター・ペインリリーバー）の対応関係を整理するフレームは、B2Bのエンパシーマップとして機能します。

DMU上の各ステークホルダーごとにバリュープロポジションキャンバスを作成することで、「この人には何が刺さるか」をロールごとに整理できます。

ROIストーリーテリングとしてのプロトタイピング

B2Bのプロトタイプは「体験させるもの」から「判断させるもの」にシフトします。具体的には「ペーパーROIプロトタイプ」という手法が有効です。

仮定の数値を使って「このソリューションを導入した場合、業務Xに費やす時間がY時間/週削減され、年換算でZ円のコスト削減になる」という試算を1枚にまとめたドキュメントです。数値の正確性よりも「どの変数を動かすと効果が出るか」という構造を示すことが目的です。

参加者からの声として多いのは、「数値が100%正確でなくても、試算の構造が見えると意思決定者との会話が変わる」というものです。意思決定者に「面白いですね」と言わせることより、「この前提で考えると我々の場合はどうなるか」という問いを引き出すことがゴールです。

実務ステップ：B2Bデザイン思考の5ステップ

Step 1: DMUマッピング

顧客組織の意思決定に関与する人物を洗い出し、購買プロセスにおける各人の役割・判断基準・懸念事項を整理します。図示するなら組織図の上に「誰がGOを出すか」「誰がNOを出せるか」を重ねるイメージです。

所要時間の目安は、既存顧客情報をベースに1〜2時間。新規開拓の場合は仮説ベースで作成し、初期の顧客接点で検証します。

Step 2: ロール別ジョブの分離

DMU上の各ロールについて、機能的ジョブ・感情的ジョブ・社会的ジョブを書き出します。

• 購買担当：稟議を通すこと（機能）／失敗リスクを回避すること（感情）
• 現場ユーザー：業務を効率化すること（機能）／既存の作業を壊されたくないこと（感情）
• 意思決定者：組織の競争力を高めること（機能）／投資の正当性を説明できること（社会）

感情的ジョブと社会的ジョブへの対処を解決策設計に組み込むことで、「論理的には正しいが組織が動かない」という壁を超えられます。

Step 3: ペーパーROIプロトタイピング

解決策の骨格が固まった段階で、ROI試算の構造を1枚のドキュメントに整理します。変数は「業務時間の削減」「エラー率の低下」「リードタイム短縮」など測定可能なものを選びます。

重要なのは仮定を明示することです。「前提：1名あたり週3時間の作業削減と仮定した場合」と書くことで、顧客が自社の数値を当てはめて考えられる余地を作ります。

Step 4: ステークホルダー別ストーリーテリング

同じソリューションでも、誰に話すかによって強調すべき価値が異なります。現場ユーザーには「操作性と既存ワークフローへの統合」、購買担当には「比較優位とコスト構造」、意思決定者には「ROIと導入リスクの最小化」を軸にしたナラティブを準備します。

ワークショップでよく起こるのは、「素晴らしいプロダクトを作ったのにどこに行っても同じ話をしてしまう」というパターンです。ステークホルダー別にメッセージを変えることは「嘘をつく」ことではなく、「その人が判断に必要な情報を適切な言語で届ける」ことです。

Step 5: パイロット導入と学習ループ

B2B文脈での「テスト」は、限定的な範囲での本番導入として設計します。「全社展開前に1部門で3ヶ月試す」という構造が、顧客にとっても意思決定のリスクを下げ、自社にとっても実データで学べる機会になります。

学習ループの設計で重要なのは、「何を測定するか」を導入前に合意しておくことです。3ヶ月後に何の数値が何%変化したら「成功」と見なすか。この合意がないと、テストフェーズの終わりに「評価基準が違う」という議論が始まります。

実在する B2B デザイン思考の取り組み

Salesforce のデザイン実践

Salesforceは、エンタープライズ製品のUX改善においてデザイン思考を組織的に取り入れています。Lightning Design System（LDS）の開発において、Salesforceのデザインチームは企業の管理者・エンドユーザー・開発者という異なるロールへのリサーチを組み合わせ、統一されたデザイン言語として結晶化させました。LDSの設計思想として公開されている原則には、「業務の文脈から切り離さない」という指針が繰り返し登場します。

Adobe の企業向けプロダクト設計

Adobe は2012年頃からCreative Cloudへの移行を進め、それに伴い企業向け製品（Adobe Experience Cloud等）の設計においてユーザーリサーチを体系化してきました。Adobe の公開している設計プロセスでは、企業のIT管理者・マーケティング担当・クリエイターという異なるステークホルダーのニーズを並行してリサーチする構造が示されています。エンタープライズ向けの製品において「意思決定者とエンドユーザーのニーズが異なる」という構造的な問いに正面から向き合ってきた事例です。

SAP のデザイン思考プログラム

SAP は2000年代後半から自社内にデザイン思考の実践拠点（Design Thinking Centers）を複数設立し、顧客企業との共同ワークショップを提供しています。SAP のアプローチは「顧客企業の内部に入ってワークショップを実施する」という形式で、購買担当・IT部門・現場ユーザーを一堂に集めたセッションを行います。異なる立場の人が同じ部屋で「自分たちの業務の課題」を言語化するプロセス自体が、DMU内の合意形成を促す機能を持っています。

SAP のDesign Thinking手法は、同社のイノベーション担当（SAP AppHaus等）が事例を含めて公開しており、エンタープライズ領域でのデザイン思考実践として参照価値があります。

B2Bデザイン思考の本質

B2C向けに設計されたデザイン思考を「そのまま使えない」と感じるのは、方法論の問題ではなく「誰を中心に置くか」の問いに答えられていないからです。

B2Bで「ユーザー中心」を維持するには、「ユーザー」を「組織の意思決定に関与する全ての人」として再定義する必要があります。エンドユーザー1名の深い共感は捨てず、しかしその共感を「組織が動く言語」に翻訳するプロセスを加える。この拡張が、B2Bデザイン思考の核心です。

「個人の喜び」から「組織の意思決定」への翻訳作業。これは理論的には地味ですが、実務の現場ではここで8割の勝負が決まります。

---

参考文献

• Alexander Osterwalder & Yves Pigneur, Value Proposition Design, Wiley, 2014
• Anthony Ulwick, Jobs to Be Done: Theory to Practice, Idea Bite Press, 2016
• Philip Kotler & Kevin Lane Keller, Marketing Management, 15th ed., Pearson, 2016（DMUの概念整理）
• Tim Brown, Change by Design, HarperBusiness, 2009
• SAP AppHaus, “Design Thinking at SAP”, sap.com/apphaus（公開情報）
• Salesforce, “Lightning Design System Documentation”, lightningdesignsystem.com（公開情報）