技術面の評価担当と購入の決裁者：評価者が回答した役割

この違いは、購入に際してその人が担う仕事にあります。テクニカルバイヤーは、製品がどう動き、組織のニーズに合うかを評価する役割です。MEDDICCの枠組みでいうエコノミックバイヤーは、購入判断の全体的な権限を持つ人を指します。どちらも確認すべきことですが、役職名だけでは分かりません。^[3][4]

本分析では、それより範囲を絞り、直接確認できる指標を使いました。調査で回答者が選んだ業務です。回答者は、組織でソフトウェアを選んだり使ったりする際の役割を複数選べました。評価・推奨・候補の絞り込みを選んだ人に注目し、最終的な購入決定と予算の承認または管理も選んだかを調べました。^[5]

調査の選択肢と、営業の枠組みで使う役割の名称は同じではありません。評価者が必ず技術の専門家とは限らず、ツールの予算を管理する人が購入全体の権限を持つとも限りません。決定と予算の両方を選んでも、同じツールについて両方を担当しているとは確認できません。

この区別を保つことで、実務で尋ねるべきことが明確になります。見込み客から技術的な比較を求められたなら、情報を必要としていることは分かります。次の会話では、何を評価しているのか、何を決められるのか、ほかに誰が根拠となる情報を必要としているのかを確認できます。

Stack Overflowの任意参加の国際調査（2026年）で評価・推奨・候補の絞り込みを選んだ9,664人のうち、7,505人は最終決定の項目も、予算の承認または管理の項目も選びませんでした。この評価者グループの77.7%に当たり、下の表の四つの区分で最も多いグループです。^[1]

ほかの区分を見ると、評価者と購入者を単純に分けては捉えられない重なりがあります。1,041人の評価者は両方の役割を選び、744人は最終決定を選んで予算の項目は選ばず、374人は予算の項目を選んで最終決定は選びませんでした。それぞれ10.8%、7.7%、3.9%です。

各評価者は、必ず一つの区分に入ります。割合は同じ回答者グループを表しているため、組み合わせて読むことができます。丸めた割合の合計は100.1%ですが、人数の合計はちょうど9,664人です。

「どちらも選ばなかった」という表現には注意が必要です。回答者が二つの選択肢を選ばなかったことを記録しているだけで、権限がない、影響力がない、ほかの人を紹介できないと確認したわけではありません。また、この調査から特定の一件の購入に関わる人々を再構成することもできません。

最初の回答は、評価者の質問に沿って組み立てます。連携について知りたい人には、対応している接続方法、必要な設定、重要な制約を具体的に説明します。全体的なビジネス上の価値を伝えることは後で役立つかもしれませんが、未解決の互換性の質問への答えにはなりません。

次に、その情報を何に使うのかを尋ねます。製品を試すためでしょうか。候補を絞って推奨するため、予算の相談を準備するため、それとも決定するためでしょうか。答えは一つとは限りません。調査で役割の重なりが見られることは、ブリーフでもその可能性を考慮する理由になります。

業務用ソフトウェアを紹介するクリエイターにとっては、依頼の組み立て方が変わります。デモは具体的な評価の問いに答えつつ、視聴者が共有できる参照先も提供できます。ブリーフでは、デモで何を確認できるのか、製品情報の根拠をどこで確認できるのかを明確にします。購入権限があることや、販売が成立したことをクリエイターにほのめかさせるべきではありません。

代理店では、コンテンツ担当から営業担当への引き継ぎにこの区別を残します。担当者から受けた質問と、提供した根拠を記録します。予算や最終承認に関する回答は分けて残し、今回の購入についての回答かも記します。そうすれば、コンテンツへの反応を未確認の購入者区分に置き換えずに、次の担当者が状況を理解できます。

マーケターにとって有用な示唆は、申告された評価、予算、決定の役割に、それぞれ別の記入欄を設けることです。相手が実際に話した内容を保ち、次に確認すべき問いを見えるようにできます。

以下の問いを、一つの予定されている購入について使います。確認できていない答えは空欄のままにします。空欄なら未解決の問いが見えますが、役職名から推測して埋めると見えなくなってしまいます。

検討中の購入：どのツール、プラン、変更を検討していますか。想定用途と利用するチームを明記します。新規購入、置き換え、利用拡大のどれについて話しているかも記録します。

評価すること：担当者は何を確かめる必要がありますか。必要な作業手順に連携が対応しているかなど、相手の言葉で問いを書きます。どのような答えなら十分か、製品の詳細を誰が確認できるかも記します。

提供する根拠：どのデモ、仕様、具体例、参照資料がその問いに答えますか。担当者と確認日を記録します。現在対応している機能と、提案段階の機能や説明用の例を分けて示します。

予算に関する役割：相手は予算を承認する人、管理する人、申請を準備する人、それとも別の役割でしょうか。検討中の購入について具体的に尋ねます。異なる仕事を「予算責任者」という一つの呼び方にまとめず、まだ分からないことを記録します。

最終決定：今回の購入を承認できるのは誰で、その決定までに何を済ませる必要がありますか。相手が別の人だと説明した場合は、推奨する人と最終決定する人を区別します。

ほかの関係者と次の行動：ほかに誰が根拠を確認する必要がありますか。次に用意する資料や会話、その準備担当、相手が希望する時期を決めます。クリエイター、マーケター、営業担当が同じ明示された問いを基に動けるようにします。

これは会話の記録として使います。予定する購入や関係者が変わったら各欄を見直し、相手の回答と、まだ確かめる必要がある仮定を区別してください。

あるソフトウェア企業が、代理店向けのデモを準備しているとします。代理店の業務責任者は、承認済みのキャンペーンを、その製品から既存のレポート作成手順へ引き渡せるかを知りたいと考えています。これはブリーフの使い方を示す架空の例であり、実際に観察した回答者や測定したキャンペーンではありません。

最初のブリーフは、次のように書けます。「検討中の購入：代理店のキャンペーン引き継ぎ用ツール。評価すること：業務チームが必要とする具体的な引き継ぎ方法の確認。提供する根拠：対応済みの連携を使った、資料で確認できる例。必要な設定も併記する」。これでクリエイターや製品担当者に、焦点の定まった依頼を渡せます。

デモを収録する前に、チームは連携を確認します。未対応なら、その事実をブリーフと次の会話に含めます。特定のプランや設定でのみ動くのであれば、その条件を例の中ではっきり示す必要があります。

次に、マーケターが技術面の確認後の流れを尋ねます。相手はツールを推奨し、経理担当の同僚が予算申請を確認し、部門長が最終決定すると説明したとしましょう。これらは、この例のために仮定した回答です。今回の購入における別々の役割として、相手が挙げた人と未完了の手順を記録します。

ここまで分かれば、コンテンツ計画を具体化できます。評価者には確認済みの業務フローのデモと参照資料を渡します。予算申請を準備する人には、現在の価格、対象範囲、把握している導入費用を伝えます。最終決定の相談には、想定用途、確認済みの要件、残る問いを短くまとめた資料が使えます。

三つの資料は、同じ製品の事実を基に作る必要があります。ビジネス向けの要約で、デモにはない機能を約束してはいけません。技術ページで、価格に影響する重要なプラン条件を隠してもいけません。重点を変えることは、事実を変える理由にはなりません。

一方、相手が評価、予算管理、最終決定をすべて担当すると話したなら、その重なりをブリーフに反映できます。内容を明確に区分した、簡潔な資料一式を渡す方法もあります。この代理店にどちらの形が当てはまるかは、調査ではなく会話で分かります。

次にすることは具体的です。求められた作業手順を確認し、合意した根拠を送り、残る問いを記録します。返答が来たら、購入の状況を一から把握し直すのではなく、該当する欄を更新できます。

Stack Overflow Developer Survey 2026の公開データを使用しました。別の分析者が同じ入力を取得できるよう、アーカイブのバージョンを固定しています。データは30,903件の回答を含みます。調査実施者によると、調査期間は2026年6月23日から8月5日で、回答者は169か国から参加しました。参加は任意であり、結果はこの公開回答群を表します。あらゆる企業やソフトウェア購入者を代表する標本ではありません。^[1][2]

ソフトウェアの役割に関する質問は任意回答で、複数選択が可能でした。公表された質問全体の集計を確認する際には、回答した20,042人全員を対象としました。その後の主分析には、評価・推奨・候補の絞り込みを選んだ9,664人全員を含めています。主表の割合はすべて、この評価者数を分母とします。^[1][5]

回答の組み合わせを読む前に、入力のバージョン、選択肢の正確な表記、欠測の扱い、対象に含める条件、四つの区分を固定しました。ソースファイル、列の定義、回答IDの一意性、質問の表示条件、欠測でない回答数を確認しています。独立して作成した二つのプログラムは、質問の回答者数と、公表された六つの選択肢の人数をすべて正確に再現しました。

各評価者について、最終決定と予算の承認または管理の選択肢を選んだかを確認しました。選択に応じて、各回答は四つの区分のいずれかに入ります。各区分の人数を9,664で割り、割合を個別に小数第1位まで丸めました。この分析では、調査ウェイト、母集団の信頼区間、因果効果の推定は用いていません。

事前に二つの追加確認も定めました。役割がないという選択肢も同時に選んだ評価者を除く集計と、固定した五つの勤務先規模グループによる内訳です。事前の公表基準を満たさなかったため、感度分析の結果も規模別の内訳も、全体を掲載していません。いずれの未公表結果も、結果の安定性や勤務先規模による違いを主張するためには使っていません。

主分析のグループは500人以上で、ゼロを超える集計セルに十人未満のものがないことを条件とします。感度分析も500人以上で、結果の正のセルと、除外した回答者の正のセルのいずれにも十人未満のものがないことが必要です。最後の条件は、引き算によって少人数のグループが分かることを防ぐためです。規模別内訳では、固定した五つのグループがすべて100人以上で、それぞれの正のセルに十人未満がないことを求めます。条件を満たさなければ、該当する表全体を掲載しません。回答を見てから区分をまとめ直すこともしていません。

これらは、掲載に必要な人数と報告上の保護を定めた編集上の基準です。統計的な代表性や、正式なプライバシー保証を意味しません。調査実施者が公開した回答群をそのまま保持しています。公開ファイルには、同意、品質、ボットに関する内部フラグが含まれていないため、その回答群を作る際の判断をすべて独立に再現することはできません。^[2]

質問が表すのは組織での役割であり、確認済みの取引ではありません。一人が選んだ仕事が、別々のツールに関するものかもしれません。選択しなかったことは権限がない証拠ではなく、回答から購入グループのほかの人を特定することもできません。調査の割合を顧客との会話に用いる際は、この範囲を守る必要があります。

ダウンロードには、公表基準を満たす集計結果、計算コード、正確な分析方法を含めています。個別の回答記録や回答者の識別子は含みません。元の調査はOpen Database LicenseとDatabase Contents Licenseの下で別途入手できます。再現用パッケージにも、必要な出典表示と通知を保持しています。^[6][7]