予算を先に聞くのは三流だ─本質を問うヒアリングが成果を変える

多くの案件が「ご予算は?」で始まり、そこから迷走する。予算確認は必要だが、目的・制約・供給能力の設計に先んじてはならない。本稿は、初期ヒアリングの原則→事例→設計を提示し、手戻りの核を断つ方法を示す。

予算を聞く前に、問いを立てよ

多くのベンダーは第一声で「ご予算は?」と問う。だが、発注側が常に適正な目安を持つとは限らない。予算確認が目的化した瞬間、企画はほころび始める。勝敗を分けるのはヒアリングの質である。

三流と一流を分ける質問力

三流は「予算・納期・欲しい機能」をなぞるだけ。二流は要件を整理できるが、「なぜ必要か」に踏み込まない。一流は違う。背景・制約・供給の処理能力まで掘り下げ、発注側も言語化しきれていない懸念を言葉にする。
準備で差がつく。事業概況/決算・IR/主要商材/競合動向/検索傾向を押さえ、面談は仮説提示→確認で深度を上げる。
例:「○○事業の強み△△を踏まえると、直近の課題は□□か?」

盲点を潰す:集客×供給のトレードオフ設計

「売上を伸ばしたいのでサイトを刷新したい」。典型的な依頼だ。だが一流はまず問う。「なぜ今か」「なぜ過去は違ったのか」
多くの場合、集客を増やしたい一方で、問い合わせ増に現場が耐えられないという現実が露呈する。表の主張は「売上拡大」でも、裏の本音は「業務過多の回避」だ。この矛盾を解かねば、企画は前に進まない。

結論:集客設計と供給の処理能力は同じ土俵で設計する。どちらかが欠ければ、成果は長続きしない。

「ブランド/価値観」を3問で掘る

デザイン議論の手前に、伝える骨格を固める。次の3問で十分に深くなる。

  • 御社らしさは3語で?(例:誠実・専門性・スピード)
  • 避けたいイメージは?(NG表現/NG色/NGトーン)
  • 競合の“らしさ”との差分は? どこまで違えば「勝ち」と定義できる?

典型的なジレンマは3種類ある

【BtoC/来店】歯科クリニック

  • 表の課題:古いサイトで見劣り。刷新すれば予約は増える。
  • 裏の懸念:人員が限られ、既存患者対応が遅延する。
  • 解き方スロット制予約で上限を可視化し、適応条件Q&Aでセルフスクリーニング。既存患者優先レーンを設け、継続受診率の維持と満足度の向上につなげる。

【BtoB/見積】中小製造業

  • 表の課題:旧態化した検索クエリの傾向サイトで信頼を損失。刷新で引き合い増加見込み。
  • 裏の懸念:営業・技術が少数精鋭で、見積が詰まる。
  • 解き方見積プリセット(型番/ロット/公差/納期)を構造化フォームで収集し、入力時に営業前トリアージ(A=即提案/B=追加確認/C=非対象)。希少リソースを価値へ再配分し、見積リードタイムの短縮を実現する。

【人材/面談】人材紹介会社

  • 表の課題:導線改善で応募増を狙う。
  • 裏の懸念:コンサルタントの面談の処理能力不足
  • 解き方面談可能枠のダッシュボードで処理能力を常時監視し、応募前段で求職条件を厳密化(必須→希望の順にふるい)。面談の歩留まりを上げ、成約率の底上げにつなげる。

非機能・連携を先に決める:手戻りのコアを断つ

“見える機能”に目を奪われた刷新は失敗する。実際に炎上を招くのは、非機能(可用性・応答時間・監視・権限・セキュリティ等)システム連携(基幹・在庫・倉庫管理(WMS)・マーケ自動化(MA)・顧客管理(CRM)・決済・配送・SSO)を曖昧にしたときだ。

  • 既存/予定連携:基幹・在庫・WMS・MA・CRM・決済・配送・SSO
  • 非機能:可用性SLA/ピークトラフィック/応答時間/監視・ログ/バックアップ/権限設計/セキュリティ要件
  • 資料要求:現行構成図/API仕様/データ項目表/バッチ運用カレンダー

結論: 機能より先に「連携」と「非機能」を確定する。ここが曖昧だと「作ったのに繋がらない・耐えない」で手戻りが雪だるま式に膨らむ。

一流が踏む5ステップ(探索設計→最小実装(MVP))

  1. 背景・目的の確認 —— なぜ今か。なぜ過去は違ったのか。
  2. KPI(重要目標指標)と制約の把握 —— 売上・利益・供給の処理能力。
  3. 仮説提示と検証 —— 先に仮説を置いて正誤を詰める。
  4. トレードオフの合意 —— 売上増 vs オペ負荷、集客数 vs 顧客生涯価値(LTV)。
  5. 次ステップの設計 —— 探索設計課題と制約の初期検証)→ 最小実装(MVP) → 本実装。

    結び:この順序が崩れると、提案は現実に耐えない。

対話の型を設計する

現状 → 課題 → 理想 → 制約 → 施策/最小実装(MVP)の順で進め、各段で要約→確認を挟む(例:「要は◯◯を△△までに達成したい。合っていますか?」)。尋問ではなく“仮説付きの対話”にする。

狙い:対話で仮説の確度実装の順序を同時に高める。

実務チェックリスト

  • 問い合わせ30%増で、どこが詰まるか。
  • 断りたい顧客は誰か。
  • 最優先で通す顧客は誰か。
  • 優先は売上か、利益か。
  • 最終決裁者・稟議ルートはどこか。
  • 当日サマリは全案件で出せているか(決定事項/未決と決め方/次アクション:仮説検証フェーズ範囲・必要資料・初期KPI・日程)。

次アクション:探索設計の範囲/必要資料/初期KPI(重要目標指標)/KGI(最終目標)/日程(当日中に同内容を共有)

一流ヒアリング診断(70/85の一度限りの提示)

この記事で論じた7領域をスコア化する。70点未満は要注意レベル、85点以上で完成度高。 単なる自己チェックに留めず、組織内の対話を促す“火種”として使ってほしい。

  • G1 背景・Why Now:トリガーの特定/過去にやらなかった理由の言語化/事業モデル共有
  • G2 KPI(重要目標指標)・制約:KPIの数値・期限/外せない制約/予算の上限レンジ
  • G3 供給の処理能力・負荷:安全処理能力の算出/ボトルネック可視化/下振れ耐性
  • G4 スコープ・トレードオフ:Must3の限定/優先ルールの合意/除外範囲の明記
  • G5 意思決定・稟議:決裁者・稟議ルート/中間ゲート/選択肢見積
  • G6 次ステップ(仮説検証フェーズ→最小実装(MVP)):目的目的・成果・期間・上限費用/ 最小実装(MVP) のKPI/変更管理
  • G7 証拠・計測:現状ログの可用性/計測イベント計画

適正ヒアリング診断ツール

固定テンプレ(確定値)

項目リスト(id/label/weight)

  • G1 背景・Why Now(3)
  • why_now_trigger / 「なぜ今か」の外部・内部トリガーを特定している / 1.5
  • why_not_before / 「なぜこれまでやらなかったか」の暗黙制約を言語化 / 1.5
  • biz_model_context / 事業モデルと収益構造をヒアリング冒頭で共有 / 1.0
  • G2 KPI・制約(3)
  • kpi_numeric / 今期KPI(重要目標指標)/KGI(最終目標)の数値・期限を確定 / 2.0
  • hard_constraints / 法務・セキュリティ・ブランド等の外せない制約を定義 / 1.5
  • budget_guardrail / 予算は上限レンジの合意 / 1.0
  • G3 供給の処理能力・オペ負荷(3)
  • capacity_calc / 1日/週の安全処理能力を人数×時間×処理件数で計算 / 2.0
  • bottleneck_map / ボトルネック工程(面談、見積、制作等)を可視化 / 1.5
  • seasonality_buffer / 欠員・繁忙期の下振れ耐性を前提化 / 1.0
  • G4 スコープ・トレードオフ(3)
  • moscow_must3 / Mustを3点に限定(MoSCoW) / 1.5
  • tradeoff_rule / 売上増⇄オペ負荷の優先ルールを合意 / 1.5
  • exclusions / 除外事項・非対象範囲を明記 / 1.0
  • G5 意思決定・稟議(3)
  • decision_owner / 最終決裁者・稟議ルート・必要資料を確定 / 1.5
  • checkpoint_plan / 中間合意のゲート(例:仮説検証フェーズ成果承認)を定義 / 1.0
  • optioned_estimate / 見積は選択肢(3案)で提示合意 / 1.0
  • G6 次ステップ(仮説検証フェーズ→ 最小実装(MVP))(3)
  • 仮説検証フェーズの範囲明確化/ 仮説検証フェーズの目的・成果・期間・上限費用を定義 / 2.0
  • mvp_kpi / 最小実装(MVP)のKPI(例:自己解決率、Aルート(主要選考ルート)通過率)を設定 / 1.5
  • change_control / 変更管理(CR)の手順・責任分界を定義 / 1.0
  • G7 証拠・計測(2)
  • data_ready / 現状ログ(意図クラスタ、処理時間)の取得可否を確認 / 1.5
  • analytics_events / 計測イベント計画(開始/送信/エラー)を準備 / 1.0

しきい値(min/label/advice を降順)

  1. { min: 85, label: ELITE, advice: 漏れゼロ・深さ充分。仮説検証フェーズ即開始。ケース別に供給側のスロット設計を並走し、需要解放を段階投入。 }
  2. { min: 70, label: SOLID, advice: 実装に耐える基礎は揃った。ボトルネック・トレードオフの明文化が弱い。Must3の再定義と変更管理ルールの補強を先行。 }
  3. { min: 50, label: AT_RISK, advice: 裏懸念が未露出のまま。供の見立てと稟議ルートの確定が不足。仮説検証フェーズを先に置き、意図クラスタと処理時間を実測。 }
  4. { min: 0, label: RED_FLAG, advice: 予算質問駆動の三流域。背景・KPI・処理能力の骨格が欠落。記事のチェックリストに従い、7領域の最低項目から順番に埋める。 }

段階別視覚(tierカラー 16進)

  • ELITE:#1E7D57
  • SOLID:#2A6FBD
  • AT_RISK:#C77F1A
  • RED_FLAG:#B61E2E

読み込み/適用順

テーマCSS → ベースCSS → 本カスタムCSS / テーマJS → 既存ランタイム(該当時) → 本カスタムJS

差分適用方式

本文のカスタムHTML/JS/CSS で差分適用(enqueue不要)

イベント出力方式

dataLayer に統一

G1 背景・Why Now
「なぜ今か」の外部・内部トリガーを特定している
「なぜこれまでやらなかったか」の暗黙制約を言語化
事業モデルと収益構造をヒアリング冒頭で共有
G2 KPI・制約
今期KPI(重要目標指標)/KGI(最終目標)の数値・期限を確定
法務・セキュリティ・ブランド等の外せない制約を定義
予算は上限レンジの合意
G3 供給の処理能力・オペ負荷
安全処理能力を人数×時間×処理件数で計算
ボトルネック工程(面談、見積、制作等)を可視化
欠員・繁忙期の下振れ耐性を前提化
G4 スコープ・トレードオフ
Mustを3点に限定(MoSCoW)
売上増⇄オペ負荷の優先ルールを合意
除外事項・非対象範囲を明記
G5 意思決定・稟議
最終決裁者・稟議ルート・必要資料を確定
中間合意のゲート(仮説検証フェーズ成果承認)を定義
見積は選択肢(3案)で提示合意
G6 次ステップ(仮説検証フェーズ→MVP)
仮説検証フェーズの目的・成果・期間・上限費用を定義
最小実装(MVP)のKPI(自己解決率、Aルート(主要選考ルート)通過率など)を設定
変更管理(CR)の手順・責任分界を定義
G7 証拠・計測
現状ログ(意図クラスタ、処理時間)の取得可否を確認
計測イベント計画(開始/送信/エラー)を準備
— / 100
回答後にアドバイスを表示

※本診断は一般的な指針を提供する。個別の判断は自社の要件と専門家の助言に基づくべきである。

提言:業界の常識を更新する

ヒアリングは案件獲得の儀礼ではない。事業成長の起点だ。「予算を聞く文化」から「本質を問う文化」へ。ベンダーが変われば業界が変わる。業界が変われば、クライアントの未来は確実に強くなる。
いま必要なのは、課題の探索設計持続可能な実装順序を当たり前にすることだ。

小長谷直登のイメージ
株式会社ユニバーサルマーケティング代表取締役|ビジネスアナリスト
小長谷直登
1984年神奈川県足柄上郡生まれ。 WEBマーケティングとシステム開発で54社のビジネスを支援。 SEOに強い会員サイトの構築を得意とし、新規会員獲得と既存顧客のLTV改善に寄与。 stripeを使った月額課金システムやキントーンやsalesforceとの連携。 実績として動画配信サイト、ポイントシステム構築、フリマサイト、旅行予約サイト、オンラインサロン、モノのサブスクなど一般消費者向けのサービス設計とサイト設計を得意としています。 2025年7月 AIパスポート取得済

本コンテンツはコンテンツ制作ポリシーにそって、当社が独自の基準に基づき制作しています。 >>コンテンツ制作ポリシー
考察ラボ

HYPOTHESIS