partnerships-architect

partnerships-architect

目的

提携候補が現れたとき、パートナーシップ責任者、事業開発責任者、創業者兼CEOが次の4つの問いに答えるための支援をします。

1. これは本物のパートナーでしょうか。それとも、独自の需要がないのに優遇条件を求めている相手でしょうか。
2. どのティアで契約すべきでしょうか。（紹介／再販／OEM／SI・コンサルティング／戦略的提携）
3. 提携が機能することを実証する、90日間の共同GTM計画はどのようなものでしょうか。
4. 経済的に妥当なレベニューシェアはいくらで、提携が直接販売を上回るのはどの時点でしょうか。

このスキルは、ティアの判定、GTM計画、レベニューシェアの範囲を、明確な中止基準とともに提示します。契約を締結することはありません。このスキルを実行した後、判断するのは人間です。

使用するタイミング

• 提携候補が接触し、再販／OEM／「戦略的」な条件を求めている
• 新しいパートナープログラムのティア構成を設計している
• 成果の出ていない既存の提携を見直し、ティア変更、GTMの再構成、解消のどれにするかを判断する必要がある
• 大手企業が「戦略的提携」を求めており、それがベンダーロックインを演出するだけのものではなく、本物かどうかを検証する必要がある
• コンサルティング会社またはSIが、自社製品のサービスレベニューシェアを求めている
• プラットフォームベンダーがOEM／ホワイトラベルを提案しており、採算をモデル化する必要がある
• 「パートナー起点」の案件が、実際には自社のパイプラインをマージン分だけ抜き取っているのではないかと疑っている

次の用途には使用しないでください：

• 技術デモやPOC → business-growth/sales-engineer
• 既存チャネルのサービス提供コストとROIの計算 → 同階層の channel-economics
• 会社全体の収益戦略 → c-level-advisor/cro-advisor
• 提携ではなく会社を買収する場合 → c-level-advisor/ma-playbook
• 署名済みのパートナー契約における案件ごとの値引き承認 → deal-desk

ワークフロー

ステップ1 — インテーク（約20分）

assets/partnership_intake_template.mdに記入します。次の情報を記録します：partner_name、partner_type、独自の需要を示す証拠（相手が獲得した企業名、エンドカスタマーとの関係、相手の営業チームの規模）、戦略的価値（地域／製品／ブランド／チャネルの採算性）、相手が提示したコミットメント（共同マーケティング費用、専任人員、認定、販売目標）。

インテークテンプレートに正直に記入できない場合、提携候補の実態を評価するには情報が不十分です。中止してください。相手に確認を求めてください。

ステップ2 — ティアを分類

python scripts/partner_tier_classifier.py --input intake.json --profile saas --output markdownを実行します。 出力では、決定論的な最低基準に基づき、パートナーを5つのティアのうち1つに分類します — REFERRAL / RESELLER / OEM / SI-CONSULTING / STRATEGIC。STRATEGICには、named_accounts ≥ 5、複数年のコミットメント、専任リソースが必要です。このスキルは、判定理由と中止基準を提示します。

ステップ3 — 共同GTM計画

python scripts/joint_gtm_planner.py --input gtm.json --profile saas --output markdownを実行します。 出力は、ローンチ前のマイルストーン（トレーニング、認定、資料）、ローンチの進め方（ターゲットアカウント、営業施策、MDFの配分）、四半期中間のチェックポイント、90日間の成功基準を含む計画です。次の条件を検証します：REFERRALティアではチャネル主導のGTMを計画できません。OEM以外のティアではホワイトラベルを計画できません。

ステップ4 — レベニューシェアのモデル化

python scripts/revshare_modeler.py --input revshare.json --output markdownを実行します。案件ごとの直接販売とパートナー経由の利益率、パートナーの貢献度（案件の創出 > 影響 > デリバリー）に基づく推奨レベニューシェア率の範囲、パートナーROIの損益分岐点、長期的な採算性を計算します — 想定規模で、パートナー経由の採算性は直接販売を上回るでしょうか。

ステップ5 — 判断

ティア、GTM計画、レベニューシェアの範囲を提携委員会に提示します。このスキルがパートナーと契約を締結することはありません — 締結するのはあなたです。発動時に提携を機械的に解消できるよう、中止基準を契約書に記載します。

スクリプト

• scripts/partner_tier_classifier.py — 各ティアの決定論的な最低基準を設けた5段階の分類ツール
• scripts/joint_gtm_planner.py — ティアに基づいて進め方を検証する、90日間の共同GTM計画ジェネレーター
• scripts/revshare_modeler.py — レベニューシェアの範囲、損益分岐点となるROI、長期的な採算性のモデル化

すべてのスクリプトは標準ライブラリのみを使用します。3つすべてで--helpと--sampleを使用できます。

クイック例

# Emits a 5-tier partner classification with deterministic floors per tier for the built-in sample partner
cd commercial/skills/partnerships-architect && python3 scripts/partner_tier_classifier.py --sample

参考資料

• references/channel_partner_canon.md — HP の間接販売チャネルに関する Caro、チャネル経済学に関する Chintagunta、パートナープログラムに関する Hessling、Forrester のチャネルソフトウェアスタック、IDC のチャネル調査、サブスクリプション型チャネルモデルに関する Tien Tzuo、全体製品パートナーシップに関する Geoffrey Moore
• references/joint_gtm_canon.md — Aaron Ross 著 Predictable Revenue（コールドソース対パートナー）、Winning by Design、共同販売に関する Jay McBain、Microsoft Partner Network のプレイブック、AWS Partner Network の調査、SiriusDecisions のパートナーベンチマーク、Bridge Group の SaaS パートナーデータ
• references/partnership_anti_patterns.md — パートナー主導を自社のパイプラインから始めることに関する Forrester の調査、チャネル競合に関する Tom Tunguz、Hessling の失敗分析、不均衡な戦略的レベニューシェアに関する MIT Sloan、HP のチャネル事後分析、IBM のチャネル競合事例、Salesforce AppExchange の調査

前提

• 独立した需要の証拠（具体的な顧客アカウント、エンドカスタマーとの関係、自社の営業チーム）を示せないパートナーは、パートナーではなく、有利な条件を狙っているだけです。
• 業界プロファイル（--profile）はデフォルト値を調整しますが、あなたのデータに優先するものではありません。
• レベニューシェア率の範囲は推奨値です。契約交渉、MDF ポリシー、独占条件は、このスキルの対象外となる人間による商業上の判断事項です。
• 「パートナー起点」とするには、パートナーが案件を紹介し、主要な顧客関係も主導している必要があります。「パートナー影響」はより低い料率が適用されます。スライド資料上の主張よりも、支払いに関する帰属の定義が重要です。
• このスキルはパートナーシップの設計を対象とし、契約締結済みパートナーの案件管理は対象外です。契約締結後の案件ごとの商業レビューは deal-desk に引き継がれます。
• 終了基準は必須です。書面による解消条件のないパートナーシップは、問題のあるパートナーという課題を何年にもわたって悪化させます。

アンチパターン

• 「パートナー＝問い合わせてきた相手なら誰でも。」 独立した需要のないパートナーは、割引目当てです。階層分類を実施してください。紹介階層は、リセラーマージンを譲ることなくこうした相手を受け入れるためにあります。
• サポート費用を賄えるだけのマージンなしに OEM／ホワイトラベル条件を与える。 OEM では、自社が所有していない顧客をサポートすることになります。レベニューシェアで Tier-2 サポートの費用を賄えない場合、その OEM 案件は損失を招きます。
• 影響のみの案件に、起点案件向けのレベニューシェア率を支払う。 影響は起点とは異なります。その案件は、いずれにせよ成立していたでしょう。影響案件向けの料率を適用してください。
• 成果の出ていないパートナーに対する終了基準がない。 サンセット条項のない「戦略的提携」は、経営幹部のスポンサーが退任した後も、恒久的な義務になります。
• 営業担当者が辞めるまでチャネル競合を放置する。 自社の営業担当者とパートナーの両方が同じ顧客アカウントに現れた場合、失うのは営業担当者かパートナーのどちらかです。エンゲージメントのルールは、その後ではなく事前に決めてください。
• 実力のないパートナーに独占地域を与える。 これにより、実際に案件を創出できる有力なパートナーを締め出すことになります。
• 投資対効果の説明責任がない MDF。 具体的なパイプライン、報告済みの投資対効果、四半期ごとの精算がない市場開発資金は、投資ではなく補助金です。
• パートナーシップ終了時のオフボーディング計画がない。 顧客対応の継続、データの返却、知的財産の整理、ブランド表示の撤去は、事前に交渉しておく必要があります。関係が悪化した後では交渉できません。

明確な違い

• business-growth/sales-engineer — 技術的な営業：デモ、POC、統合作業の範囲策定。 パートナーシップの決定後、取引が進行中の段階で対応します。
• channel-economics（兄弟スキル）— 既存チャネルのサービス提供コストとROIの計算。 契約済みのパートナーが利益を生むかどうかを定量化します。partnerships-architect は、そもそも契約するかどうか、またどのティアにするかを判断します。
• c-level-advisor/cro-advisor — CROとしての戦略的判断（チャネル担当VPを採用するタイミング、全社的な収益構成に関する決定など）。partnerships-architect は個々のパートナーシップを対象とします。
• c-level-advisor/ma-playbook — 答えが「提携する」ではなく「買収する」である場合。トリガー：パートナーが自社では再現できない独自の堀を持つ場合、またはインセンティブを一致させるために提携に株式が必要な場合。ma-playbook に振り分けます。
• deal-desk — 契約済みパートナー契約の個別取引における割引承認。

強制質問ライブラリ（Matt Pocockの精査規律）

/cs:grill-commercial またはオーケストレーターが、1問ずつ順に確認します。各質問には推奨回答と 典拠を記載しています。まとめて質問することはありません。4〜6を始める前に、1〜3を確定してください。

1. 「このパートナーが過去12か月以内にすでに販売したエンドカスタマーを5社挙げてください。あなた自身がターゲットにする企業の顧客ですか？」 推奨：挙げられない場合、独自の需要はありません。契約するなら、紹介ティアに限ります。リセラー／OEM／戦略的ティアの最低条件を満たすには、エンドカスタマーとの関係が実証されている必要があります。 典拠：Joe Hessling — パートナープログラムの失敗分析では、「独自の需要がない」ことが、機能しないパートナーティアの最大の根本原因として特定されています。

2. 「このパートナーは優遇された商業条件を求めていますか、それとも顧客を紹介する方法を尋ねていますか？」 推奨：値引きを狙う相手は条件の話から始め、本当のパートナーは顧客企業の話から始めます。初回ミーティングの最初の30分を聞いてください。 典拠：Forresterのチャネル調査 — 初期段階のSaaSに寄せられる「パートナーに関する問い合わせ」の60％超は、チャネルへの投資ではなく、値引き狙いです。

3. 「共同の価値提案を一文で説明してください。また、それが役立つ具体的なエンドカスタマーは誰ですか？」 推奨：どちらか一方だけの提供価値とは異なる共同の価値提案がないなら、パートナーシップではありません。あっても、せいぜい共同マーケティングです。 典拠：Geoffrey Moore（Crossing the Chasm）— どちらか一方だけでは顧客の求める成果を実現できない場合に、製品全体を提供するパートナーシップが成立します。

4. 「このパートナーシップが直接販売の採算性を上回るのは、割引率／レベニューシェアが何％で、どの程度の規模に達した場合ですか？」 推奨：損益分岐となるパイプラインの量をモデル化してください。直接販売を上回るには、パートナー経由の案件がチャネル全体の30％を超える必要があるのに、パートナーが現実的に5％しか提供できそうにないなら、赤字になるプログラムを作ったことになります。 典拠：Pradeep Chintagunta（Chicago Booth）のチャネル経済学に関する研究 — 取引量の下限を設けないチャネルパートナーシップは、理論上は損益分岐点に達しても、実際には赤字になります。

5. 「このパートナーシップを解消するための具体的な終了基準は何ですか。また、契約に明記されていますか？」 推奨：四半期ごとのパイプライン最低基準、認定済みリソースの最低数、成約した共同案件の最低数、90日間の是正期間を定めてください。事前に合意した基準なしに解消しようとすると、2年に及ぶ法廷闘争になります。 典拠：IBMのチャネル競合に関する事例研究（1990年代の事業分離後）— 文書化されていない終了基準によって、問題のあるパートナーが恒久的な義務になりました。

6. 「このパートナーがあなたの直接取引先の1社に販売した場合、誰が優先されますか？あなたの担当者ですか、それともパートナーですか？」 推奨：キックオフ前に、取引ルール（Rules of Engagement）を書面で作成し、署名してください。テリトリーは、指定アカウント、セグメント、または地域単位で定めます。競合の解決責任者は、委員会ではなく、実名を指定した担当者とします。 典拠：Jay McBain（Canalys）— チャネル競合はパートナープログラムを失敗させる最大の要因です。パートナーが署名する前に書面の取引ルールを公開すれば、紛争の80％を防げます。

7. 「これはパートナーシップですか。それとも買収すべきですか？」 推奨：パートナーに、あなたが再現できない独自の競争優位性があり、複数年の独占契約が必要で、さらに株式保有に近い利害の一致が必要なら、あなたが説明しているのは買収です。ma-playbook に振り分けてください。 典拠：HPのチャネルに関する事後分析（Indigo、EDSの部分統合）— 株式を伴わない買収として構成されたパートナーシップは、どちらか一方の純粋な形態よりも多くの価値を損ないます。

深掘りは一度に1つずつ進めます。4〜7を始める前に、1〜3（本当のパートナーかどうか）を確定してください。7つすべてに回答した後、partner_tier_classifier.py → joint_gtm_planner.py → revshare_modeler.py の順に実行します。