gtm-pricing

ICP開発（企業特性、技術特性、心理特性）、ポジショニング（April Dunfordキャンバス）、価格戦略（バリューベース、段階制、機能ゲーティング）、および案件評価（スコアリング、レッドフラグ、複雑度レベル）を網羅する包括的なB2Bゴートゥーマーケットフレームワーク。

<quick_start> ICPスコアリング: 80以上 = 理想的 | 60-79 = 良好 | 40-59 = 限界的 | 40未満 = 見送り

ポジショニングステートメント:

For [target] who [need], [product] is a [category] that [benefit].
Unlike [alternative], our product [differentiator].

バリューベース価格設定: 定量化された提供価値の10-20%で価格を設定

案件スコア: マーケットフィット、テクニカルフィット、GTMフィット、パーソナルフィット、エコノミクスの合計100点満点 </quick_start>

<success_criteria> GTM戦略は以下の場合に成功です:

• ICPがスコアリング基準（企業特性、技術特性、心理特性）とともに文書化されている
• ポジショニングステートメントがApril Dunfordフレームワークに従っている
• 価格が定量化された価値に基づいて設定されている（コストプラスではない）
• 段階構造がGood/Better/Bestに従い、明確な機能ゲートを備えている
• 案件スコアリングがレッドフラグと良好なシグナルを特定する
• 上位3競合に対するバトルカードが作成されている
• ローンチチェックリストが完了している（ローンチ前、ローンチ、ローンチ後） </success_criteria>

<core_content> B2Bゴートゥーマーケット戦略、価格設定、案件評価に関する包括的なガイド。

クイックリファレンス

フレームワーク	目的	使用タイミング
ICP開発	理想的な顧客を定義する	アプローチ前
ポジショニング	市場での差別化	製品ローンチ、ピボット
メッセージング階層	一貫したコミュニケーション	セールスイネーブルメント
競合インテリジェンス	ランドスケープの理解	案件戦略、ポジショニング
バリューベース価格設定	提供価値による価格設定	初期価格の設定
段階構造	オファリングのパッケージ化	機能ゲーティングの判断
案件スコアリング	フィットの評価	新規顧客・プロジェクトの判断

---

パート1: ゴートゥーマーケット戦略

ICP 開発フレームワーク

3 つの次元で ICP を構築し、各見込み顧客をスコアリングします。

次元 1 -- ファームグラフィックス（企業属性：彼らは誰か）：

• 企業規模：従業員数の範囲、売上高の範囲
• 業種：主要な垂直分野、副次的な分野、および明確に除外する分野
• 地域：対象地域、除外地域
• 企業タイプ：スタートアップ、成長段階、エンタープライズ、SMB
• 資金調達ステージ：自己資金、シード、シリーズ A〜D、上場/PE 支援

次元 2 -- テクノグラフィックス（利用技術：彼らは何を使っているか）：

• 必須スタック：必須テクノロジー、あると望ましいもの、非互換
• 技術成熟度：アーリーアダプター、アーリーマジョリティ、レイトマジョリティ、ラガード
• 現在のソリューション：CRM、ERP、業界特化ツール
• 統合要件：あなたの製品が接続すべきもの
• 課題の指標：手作業のプロセス、分断されたシステム、スプレッドシートでの回避策

次元 3 -- サイコグラフィックス（購買行動：彼らはどう買うか）：

• 認知段階：未認知、課題認知、ソリューション認知、製品認知
• 購買委員会：経済的買い手、技術的買い手、ユーザー買い手、チャンピオン、ブロッカー
• 意思決定基準：主要（スピード、コスト、機能）と副次
• リスク許容度：予算への懸念、導入リスク、チェンジマネジメント、ベンダーの安定性

ICP スコアリング基準：

スコア	ラベル	アクション
80-100	理想	優先 -- 完全なアウトリーチケイデンス、経営層のスポンサーシップ
60-79	良好	追求 -- 標準的なケイデンス、徹底的な適格性評価
40-59	限界的	条件付き -- 特定のシグナル（予算、タイミング）が変化した場合のみ
<40	見送り	辞退 -- 機会費用が高すぎる

注視すべき行動シグナル：

• 高インテント：競合の代替製品を検索した、価格ページを 3 回以上訪問した、購入者ガイドをダウンロードした
• 中インテント：ウェビナーに参加した、事例研究にエンゲージした、LinkedIn でつながった
• 低インテント：ブログ購読者、ソーシャルフォロワー、ニュースレターの開封

ICP 検証チェックリスト：

1. ICP 内に最低 1,000 社がある状態で TAM/SAM/SOM を算出
2. ICP に対する過去の勝率が 30% 超
3. ICP 顧客は最も低いチャーン率と最も高い NPS を持つ
4. 営業チーム、CS、プロダクトがすべて同じプロファイルに合意している

完全な YAML ICP ワークシートテンプレートと ICP の例（MEP 請負業者）については reference/gtm.md を参照してください。

---

ポジショニング（April Dunford フレームワーク）

ポジショニングの 5 つの構成要素：

1. 競合代替手段 -- あなたが存在しなかったら、顧客は何を使うか？（直接の競合だけでなく、スプレッドシート、手作業のプロセス、人材採用、何もしないことも含める）
2. 独自の属性 -- 代替手段にはなく、あなたにあるものは何か？（機能、アーキテクチャ、チームの専門知識、データ、統合）
3. 価値 -- その独自の属性が顧客に何をもたらすか？（節約された時間、得られた売上、低減されたリスク、回避されたコスト）
4. ターゲット顧客 -- その価値を最も気にかけるのは誰か？（あなたの強みが最も重要となるセグメント）
5. 市場カテゴリ -- どの市場にポジショニングするか？（既存カテゴリ、サブカテゴリ、または新カテゴリの創出）

ポジショニングステートメントのテンプレート：

For [target customer segment] who [key need/pain],
[product name] is a [market category]
that [primary value proposition].
Unlike [competitive alternative],
our product [key differentiator tied to unique attribute].

メッセージング階層（3 レベル、各最大 3 つの差別化要素）：

レベル	対象者	メッセージの種類
戦略	経営層、取締役会	ビジネス成果、ROI、リスク低減
ソリューション	ディレクター、VP	ケイパビリティ、統合、ワークフロー改善
ペルソナ	エンドユーザー、管理者	機能、UX、日々のワークフローの利点

競合バトルカードの必須要素： 上位 3 社の競合それぞれについて、以下を文書化します。

• 概要：設立、本社、資金調達、ターゲット市場、価格モデル
• 強み（誠実に認める -- 信頼性にはそれが求められる）
• あなたの優位性に対応付けた弱み
• 価値ベースの回答を伴うよくある反論
• 勝利戦略：主要な差別化要素、証明ポイント、参考事例
• 競合の弱みを露呈させる、見込み顧客への質問

バトルカードのテンプレート、ポジショニングの例、競合ポジショニングのフレームワークについては reference/gtm.md を参照してください。

---

GTM モーションとローンチ

GTM モーションの選択:

モーション	ACV	商談サイクル	必要なチーム	CAC
プロダクト主導型成長 (PLG)	<$5K	数日	グロース/プロダクト	低
セールス支援型	$5-50K	数週間	SDR + AE	中
エンタープライズ	$50K+	数か月	AE + SE + CSM	高
パートナー/チャネル	変動制	変動制	パートナーマネージャー	変動制

チャネルミックス: 60-70% を主要モーション、20-30% を副次モーション、10% を実験的施策に配分します。

ローンチチェックリストのマイルストーン:

• T-30 (ローンチ前): ICP の検証完了、ポジショニング確定、メッセージ階層の完成、バトルカードの作成、価格の承認、営業チームのトレーニング、デモ環境の安定化
• T-0 (ローンチ時): ウェブサイトの更新、アウトバウンドシーケンスの起動、プレスリリースの配信、ソーシャルキャンペーンの開始、パートナーへの通知送信
• T+30 (ローンチ後): 勝敗分析の開始、フィードバックに基づくメッセージの改善、パイプラインのレビュー、競合対応の文書化、メトリクスダッシュボードの稼働

ローンチチェックリストの全文、チャネル戦略の詳細、複雑さとリソースのマッチングについては reference/gtm.md を参照してください。

---

パート 2: 価格戦略

バリューベース価格設定の手法

ステップ 1 -- 顧客価値を定量化する:

Total Value = Time Savings + Revenue Impact + Cost Avoidance

Time Savings:   Hours saved/month x Hourly rate x 12
Revenue Impact: Additional revenue enabled per year
Cost Avoidance: Costs eliminated or reduced per year

ステップ 2 -- 定量化した価値の 10-20% に価格を設定する:

• 10% = 保守的 (成約しやすく、知覚価値が高い)
• 15% = バランス型 (標準的な B2B SaaS)
• 20% = 積極的 (強い差別化が必須)

ステップ 3 -- 支払い意思額に対して検証する:

• Van Westendorp の価格感度分析: 「安すぎる / 安い / 高い / 高すぎる」を尋ねる
• 競合ベンチマーク: 代替手段はいくらで価格設定されているか?
• 顧客インタビュー: 「Y という成果に対して X ドルを支払いますか?」

価格モデル

モデル	最適な用途	長所	短所
定額制	シンプルなプロダクト	理解しやすい	価値に応じてスケールしない
シート単位	チームツール	予測可能で、組織規模に応じて拡張	導入の妨げになる
従量課金	API、インフラ	コストが価値と一致する	収益が予測不能
段階制 (Good/Better/Best)	機能の差別化	アンカリング、明確なアップグレードパス	設計が複雑
ハイブリッド (シート + 従量)	エンタープライズ SaaS	予測可能なベース + 上振れ	請求が複雑

ティア設計 (Good/Better/Best)

ティア構造の原則:

• 3-4 ティアが最適 (それ以上は意思決定の麻痺を生む)
• 中間ティアをターゲットにすべき -- 「Most Popular」バッジが付く
• 最上位ティアが中間ティアを妥当に見せる (プライスアンカリング)
• 無料ティアは PLG モーションの場合のみ (獲得、見込み客の絞り込み、バイラル成長)

機能ゲーティングのルール:

ゲート基準	例	使用すべき場面
規模	ユーザー数、API 呼び出し、ストレージ、プロジェクト	使用量が価値に応じて自然に増える
高度さ	高度な分析、AI 機能、ワークフロー	機能を使うには成熟度が必要
統制	SSO、SAML、監査ログ、カスタムロール	エンタープライズのコンプライアンス要件
サポート	SLA、専任 CSM、電話サポート	サービスへの支払い意思

決してゲートしてはいけないもの: セキュリティ機能、データエクスポート、基本的な連携。これらをゲートすると不満と解約を招きます。

割引戦略

種類	トリガー	範囲	使用すべき場面
ボリューム	規模拡大のコミットメント	10-30%	シート数が多い、複数年契約
期間	年間契約	15-25%	月次から年次への切り替え
競合	競合からの乗り換え	20-40%	残存契約額への見合い
戦略	参照顧客、ロゴ価値	最大 50%	有名ブランド + 事例紹介のコミットメント

価格を守る -- 以下の場合は決して値引きしない:

• 顧客が受け取る価値を明示していない
• 競合からの圧力が存在しない
• 交渉の初期段階にある (値引きは後で、最初ではなく)
• 顧客が純粋に価格比較のみを目的としている (いずれにせよ解約する)

値引きの代替手段: 支払い条件の延長、追加のトレーニング/オンボーディング、トライアル期間の延長、成功マイルストーンでの機能解放、現在の料金での複数年ロックイン。

SaaS 価格設定の主要指標

指標	目標	計算式
LTV	>3x CAC	ARPU / 月次チャーンレート
CAC 回収期間	<12 か月	CAC / ARPU
NRR	>100%	(期首 MRR + 拡大 - 縮小 - チャーン) / 期首 MRR
粗利益率	>70%	(売上 - 売上原価) / 売上

モデルごとの詳細分析、値上げプレイブック、サービス価格設定、プロダクト化サービスモデル、収益モデルテンプレートについては reference/pricing.md を参照してください。

---

パート 3: 機会の評価

クイックスコア (/100)

軸	配点	評価する内容
市場適合性	25	課題の明確さ (10)、市場規模 (8)、タイミング (7)
技術適合性	20	構築可能か (10)、インフラ適合性 (5)、保守負担 (5)
GTM 適合性	20	営業の複雑さ (8)、チャネルへのアクセス (7)、競合 (5)
個人適合性	20	興味・エネルギー (8)、成長の可能性 (7)、ライフスタイルとの相性 (5)
経済性	15	収益ポテンシャル (8)、収益化までの時間 (4)、リスク・リターン (3)

スコアの解釈とアクション

スコア	アクション	次のステップ
80-100	強く推進	直ちに優先し、リソースを配分する
60-79	探索	期間を区切った詳細調査 (1〜2 週間) に値する
40-59	条件付き	保留 -- 特定の要因が変化した場合のみ再検討する
0-39	見送り	辞退 -- 機会費用が高すぎる

レッドフラグ (自動減点)

以下のいずれかに該当する場合、スコアから 10〜20 点を減点すべきです。

• 支払い条件が不明確: 「報酬は後で決めましょう」
• 開始前のスコープ拡大: 契約締結前に要件が増えていく
• 迅速な決定への圧力: 重大なコミットメントに対して「金曜日までに回答が必要」
• インセンティブの不一致: 相手の成功があなたの成功を必要としない
• 楽観的に見ても経済性が成立しない: 最良ケースの計算が合わないなら、手を引く
• 単一の推進者: これを望むのが 1 人だけで、組織的な賛同がない
• 予算が確保されていない: 関心はあるが支出が承認されていない

GTM の複雑さレベル

レベル	買い手	ACV	サイクル	意思決定スタイル
PLG	個人ユーザー	<$2K	数日	ユーザー = 買い手、セルフサーブ
ロータッチ	マネージャー	$2-15K	1〜4 週間	簡単なデモ、迅速な承認
ミッドマーケット	ディレクター・VP	$15-100K	1〜3 か月	委員会、複数のステークホルダー
エンタープライズ	経営幹部	$100K-1M	6〜18 か月	RFP、セキュリティレビュー、法務
複雑	取締役会レベル	$1M+	12〜36 か月	変革プロジェクト

複雑さを自分のリソースに合わせる:

• 個人・副業プロジェクト: レベル 1〜2 を最大の目標とする
• 小規模チーム: レベル 2〜3 を目標とする
• 資金調達済みスタートアップ: レベル 2〜4 を目標とする
• エンタープライズ営業組織: レベル 3〜5 を目標とする

5 分間の実現可能性テスト

あらゆる機会を深掘りする前に、4 つの質問に答えてください。

1. 顧客 1 社はいくら支払うか? $____/月
2. 6 か月で現実的に何社の顧客を獲得できるか? ____
3. 顧客 1 社にサービスを提供するコストはいくらか? $____/月
4. これには週何時間かかるか? ____

簡単な計算:

• 6 か月時点の月次収益: #2 x #1
• 月次コスト: #2 x #3
• 月次マージン: 収益 - コスト
• 実効時給: マージン / (時間 x 4.33)
• 時給が $100 未満 --> 再考が必要

構築 vs 提携 vs 購入の判断

シグナル	構築	提携	購入
中核的な差別化要因	はい
コモディティ機能			はい
補完的な強み		はい
時間が重要			はい
学習価値が高い	はい
保守負担が高い		はい	はい
優れた代替手段が存在しない	はい

軸ごとの詳細なスコアリング基準、完全なスコアカード YAML テンプレート、ユニットエコノミクスのワークシート、コスト構造分析、損益分岐点の計算、構築 vs 提携の意思決定ツリーについては reference/opportunity.md を参照してください。

---

参照ファイル

• reference/gtm.md - ICP YAML テンプレート、行動シグナル、検証チェックリスト、チャネル戦略、ローンチプレイブック、バトルカードテンプレート、ポジショニングの例
• reference/pricing.md - モデルの詳細解説、ティア設計、値上げプレイブック、サービス価格設定、割引フレームワーク、SaaS メトリクスダッシュボード
• reference/opportunity.md - 完全なスコアリングルーブリック（5 セクション）、スコアカード YAML、ユニットエコノミクス、コスト分析、損益分岐点の計算式、build/partner/buy の意思決定ツリー </core_content>

成果サイドカーを出力する

最後のステップとして、~/.claude/skill-analytics/last-outcome-gtm-pricing.json に書き込みます：

{"ts":"[UTC ISO8601]","skill":"gtm-pricing","version":"1.0.0","variant":"default",
 "status":"[success|partial|error]","runtime_ms":[estimated ms from start],
 "metrics":{"pricing_models_evaluated":[n],"tiers_designed":[n],"gtm_channels_mapped":[n]},
 "error":null,"session_id":"[YYYY-MM-DD]"}

一部のステージが失敗しても結果が生成された場合は、ステータスに「partial」を使用します。出力がまったく生成されなかった場合にのみ「error」を使用します。