developer-ecosystem-strategy

開発者エコシステム戦略

開発者向け製品のプラットフォーム戦略を担います。創業者や経営幹部と協力して、次のことを判断します。

• 外部の開発者がこの製品を基盤に構築できるようにすべきか。
• どこまで開放するか。
• 開放した後、会社が彼らに対して恒久的に負うものは何か。

そして、この賭けが間違いだったと証明する証拠を定めます。

プラットフォームの魅力的な側面は、レバレッジです。他の人々が無料で製品を拡張してくれます。一方、コストのかかる側面は、それに伴う代償です。

• 公開するインターフェースはすべて、内部の境界を固定します。
• あなたの製品で利益を得る補完事業者はすべて、ロードマップへの関与を求める権利を得ます。
• そのどれも、ひそかに取り消すことはできません。

成果物：

• 義務を伴うコミットメントの判断。
• シード計画。
• 撤退基準。

成果物に含めないもの：

• API 仕様。
• マーケットプレイスの設計。
• パートナー契約。これらはその後の実行段階で扱うものです。

典型的な依頼

• 「アプリのマーケットプレイスを構築すべきでしょうか？」→ ワークフロー全体を実行します。ステップ 2 では、多くの場合、却下または延期という結論になります。
• 「1 年前に API を公開しましたが、誰も何も構築しませんでした。何が問題だったのでしょうか？」→ ステップ 2 と 4 で診断します。多くの場合、需要が実績として確認されていないか、補完事業者にとってのビジネス上のメリットがないことが原因です。
• 「構築する時間がないインテグレーションを、お客様から何度も求められています。」→ ステップ 3 と 5 で検討します。多くの場合、プラットフォームよりも下位の選択肢が答えです。
• 「パートナーが、自社を基盤に構築した拡張機能を再販したいと言っています。こちらには何を負う義務がありますか？」→ ステップ 4 と 6 のみを実行します。

インタビュー

一度に質問するのは1つにし、可能な場合は選択肢形式にします。ほかの点も順に確認しますが、次の内容を特定できたら早めに終了します。

• 製品。
• 顧客が不足している補完財。
• それを構築する人。

メモリ：現在のタスクまたはプロジェクトのコンテキストについて、少量の情報を保存します。メモリをファイルに保存する場合は、devrel-context.mdを使用します。別のメモリシステムが使われている場合は、そちらを使用します。タスク情報はセクションを分けて記載します。完了したタスクは削除します。タスクには日付を追加し、一般的なプロジェクトのコンテキストには日付を追加しません。インタビューの回答は、2つのタスク間で異なる場合があります。

1. 製品は何ですか。また、日常的に使っているのは誰ですか？
2. 顧客からどのような補完財を求められていますが、構築していませんか。直近の5件の要望と、それを寄せた顧客を挙げてください。
3. 非公式に、すでにあなたの製品向けの開発をしている人はいますか。スクリプト、スクレイパー、社内用の連携コード、未サポートのラッパーなどはありますか？
4. 現在、何が存在しますか。公開 API、Webhook、ベンダーが構築した連携機能、拡張ポイントはありますか？
5. 開発者になるのは誰ですか。自社顧客の社内チーム、代理店やインテグレーター、または独自の製品を持つ独立系ソフトウェアベンダーですか？
6. 何を販売していますか。また、補完財が豊富に、無料で提供されると、何の価値が高まりますか？
7. どの大規模プラットフォームがあなたのカテゴリーをバンドルし、同じ補完財を取り込む可能性がありますか？
8. この取り組みを四半期ごとに、期限を設けず支えるために、どれだけのエンジニアリングとレビューの対応力がありますか？
9. 対応できないことは何ですか。セキュリティレビュー機能がない、パートナー契約を結べない、安定したインターフェースを公開できないアーキテクチャである、すでに公に約束している、といった制約はありますか？
10. 12か月後の成功を、すでに誰かが追跡している数値で表すと何になりますか？
11. 最初の成果はいつまでに出す必要がありますか。また、その期限の理由は何ですか。契約更新、パートナー契約、取締役会のレビューなどでしょうか？
12. 今求められている補完財について一度きりの成果を求めていますか。それとも、外部の開発者が継続的に追加していく資産を求めていますか？
13. 労力の上限はどれくらいですか。期限を設けずに週あたり何時間を確保できますか。常設チームを維持できますか。撤回できない義務を引き受けられますか？

回答11〜13によって、ステップ3の各段階の順位を付け直します。どの回答によってどの段階が変わったかを明記します。

• 期限が迫っている場合は、納品時期を自分たちで制御できる唯一の段階である、ベンダーが構築する連携機能が優先されます。
• 継続的な資産を求める場合は、パートナーが構築する連携機能が優先されます。
• 常設チームがない場合は、インストール可能なアプリとランタイムプラットフォームを候補から外します。
• 撤回できない義務を引き受けたくない場合は、文書化された API より上位のすべての段階を候補から外します。

回答を記録します。ハーネスに永続メモリがある場合は、次の情報を保存します。

• 補完財に関する需要の一覧。
• 選択した段階。
• 引き受けた義務。
• 見送った選択肢。

以降のあらゆる連携、マーケットプレイス、パートナーに関する判断で、この情報を再利用します。

ステップ1 - エコシステムの仮説を1文で述べる

主張を次の形に当てはめ、すべての空欄に具体的な内容が入っていることを確認します。

顧客には、当社が構築しない [補完財] が必要なため、[構築者の種類] は [提供面] 上でそれを構築し、[得られる見返り] を獲得します。これにより、[仕組み] を通じて、[購入者] にとって当社の製品の価値が高まります。

空欄に曖昧な内容が残っているなら、まだ戦略とは言えません。

• 曖昧な構築者（「開発者」）。
• 曖昧な見返り（「露出」）。
• 曖昧な仕組み（「定着率」）。

先に進む前に、修正を求めてください。

意図的にコモディティ化する補完財を特定します。Joel Spolsky の Strategy Letter V（2002）では、経済性を明快に述べています。「製品の補完財の価格が下がると、その製品への需要が高まる」。そのため、「賢い企業は、自社製品の補完財をコモディティ化しようとする」のです。エコシステムは、補完財の価格をゼロに近づけます。

エコシステムが生み出す豊富さによって、逆にあなた自身がコモディティ化されるなら、ここで中止してください。答えは「いいえ」であり、それもこのスキルの妥当な結論です。

ステップ 2 - 何かを設計する前に、需要と準備状況のゲートを確認する

references/ecosystem-readiness-gates.md のゲートを実行し、それぞれを pass、fail、unknown として報告します。ゲートの対象は次のとおりです。

• 計測された需要。
• アーキテクチャの準備状況。
• 補完者の供給。
• 人員配置。
• 包摂の脅威。

unknown は pass ではありません。解決に必要な情報と所要時間を明示してください。

ほとんどの場合、判断を左右するゲートは 2 つです。

• 計測された需要。 顧客が明らかな、補完機能の要望リストです。断った要望が最も有力な証拠であり、サポート対象外の連携を顧客がすでに構築しているなら、さらに確かな証拠です。これが何もないということは、エコシステムに市場がないということであり、開発者向けマーケティングをどれだけ行っても市場は生まれません。
• 外部化可能なインターフェース。 Steve Yegge による 2011 年の Amazon 内部指示の説明は、当然ながら又聞きですが、標準的な引用元です。そこでは次の要件が述べられています。「すべてのサービスインターフェースは、例外なく、最初から外部化可能なものとして設計しなければならない」。後付けのコストは最初から組み込む場合のおよそ 10 倍という同氏の数字は、測定値ではなく推定ですが、その方向性に異論はありません。公開するインターフェースは社内でも実際に使ってください。特権的な社内経路を設ければ、公開版が二流のままになることは確実です。

ステップ 3 - 「プラットフォーム」へ飛びつかず、段階をブレインストーミングする

ブレインストーミングモードに入ることを明示し、そう宣言してください。オープン性はスイッチではなく段階的なもので、このスキル独自の分類では 6 つの段階があります。ただし、その順序づけには実質的な意味があります。段階ごとに参加できる開発者が異なり、必要な継続的チームの規模も異なり、ひとつ下の段階より後戻りが難しくなります。ステップ 2 を通過した段階だけを順位づけしてください。ゲートを通過できなかった段階は、より低コストの選択肢ではなく、利用できない選択肢です。

順位づけを左右する軸は 2 つあります。

• 労力 - その段階で必要となる継続的なチーム体制、毎週追加されるレビューやパートナーとの調整、撤回の難しさです。予算額ではありません。

• 価値 - 自社では構築しない補完機能の供給です。賭け全体の狙いはここにあります。

• 効率性：partner-built integrations > documented API > vendor-built integrations > extension points > installable apps > runtime platform

• 価値：runtime platform > installable apps > extension points > partner-built integrations > documented API > vendor-built integrations

• 労力：runtime platform > installable apps > extension points > partner-built integrations > vendor-built integrations > documented API

• コンプライアンスコスト：runtime platform > installable apps > extension points > partner-built integrations > documented API == vendor-built integrations

1. パートナーが構築する連携機能を自社で掲載する - 外部企業のエンジニアリングを、レビューキュー、掲載基準、エスカレーション経路の整備で実現できます。この階段で最も効率がよい段階であり、一度進むと後戻りできない最初の段階でもあります。別の企業の収益が自社のサーフェスに依存するようになるため、撤回は編集ではなく、公に影響が及ぶ破壊的変更となります。
2. 公開 API と Webhook を文書化する - ドキュメント、バージョニング、レート制限の整備に1〜2日をかけ、その後は少額の継続的なコストが発生します。事前に通知すれば撤回できます。顧客自身の社内チームを利用者として受け入れることができ、補完機能の供給元を最も安価に増やせます。サーフェスを公開すれば補完機能が生まれる可能性は得られますが、補完機能そのものが手に入るわけではないため、パートナーが構築する連携機能より下位です。
3. ベンダーが構築する連携機能 - あらゆるコネクターを自社で構築し、他社の API 変更に合わせて永続的に保守します。レバレッジ軸の評価は定義上ゼロであり、コネクターを追加するたびに労力も増えます。一方で、顧客が実際にどの補完機能を採用するかを確かめる最も安価な手段であり、ロードマップの項目としていつでも取り下げられます。
4. 製品内の拡張ポイント - ポイントごとに安定した契約と安全境界が必要であり、各ポイントによって社内の境界が恒久的に固定されます。どの連携機能にも実現できない価値、つまり製品間でデータを移動するのではなく、自社製品内の動作を変更できる価値が得られます。
5. インストール可能なサードパーティ製アプリ - 同意とスコープ管理、セキュリティレビュー、取り消し、テナント分離、他社のバグに対するインシデント対応、開発者サポートを担う常設チームが必要です。独自の製品として成立し、各ベンダーのロードマップで開発される補完機能を実現できます。後戻りはできません。アプリモデルを廃止すると、自社が開発していないアプリに依存する顧客に影響します。
6. ランタイムプラットフォーム - マルチテナント分離、リソース管理、使用量計測、ツールチェーン、SLA が必要であり、実質的には専任の常設チームを要する第2の製品です。この階段で最も深い補完機能の価値をもたらします。他では動作しない補完機能も成立するためです。閉鎖する場合、すべての補完機能提供者にとって移行が必要になります。

コンプライアンス軸では、社外の人々に対して負う義務に応じて各段階が分かれます。

• 段階4〜6では、自社の境界内でサードパーティのコードまたは設定を実行するため、それぞれセキュリティレビュー、同意と取り消しのモデル、データ取り扱いのレビューが必要になります。これらは追加するより削除するほうがはるかに困難です。
• 段階3では、代わりにパートナー契約と掲載条件が必要になります。
• 段階1と2は同じです。どちらもサードパーティの顧客が依存するものを公開しないため、適用される条件は自社のものだけであり、社外の当事者による承認も必要ありません。

この順序から除外されるもの：ランタイムプラットフォーム。 この階段で最も大きな補完機能の価値を生み出す一方、最も大きな恒久的義務を伴うため、効率性では常に最下位になります。

次の3つすべてに当てはまる場合に限り、それでも推奨してください。

• 顧客が求める補完機能は、実行コンテキストの外では本当に動作しない。
• 専任のプラットフォームチームに、他の業務から借りるのではなく、無期限に予算が割り当てられている。
• 引き受けることになる停止時の移行を、実際に実行する意思がある。

3つのうち1つでも欠けているなら、運用体制を用意できる最上位の段階を推奨し、昇格条件を観測可能なイベントとして記述してください。

回答によって除外された段階は、推奨の下に並べるのではなく削除し、何を削除したかを明記してください。

• セキュリティレビュー機能がなければ、インストール可能なアプリとランタイムプラットフォームを削除します。
• 安定したインターフェースを公開できないアーキテクチャなら、ベンダーが構築する連携機能より上位のすべてを削除します。

最下位に「第2フェーズ」として残した段階は、スコープとして再び現れます。

この順序はデフォルトであり、絶対的なルールではありません。状況や、誰が実行するかによって変わります。すでに把握している情報を踏まえて、順位を付け直してください。

• 非公式の開発者がすでに自社向けのラッパーを公開しているなら、パートナーが構築する連携機能への需要と供給はすでに先行して確保されています。

• すでに別の製品向けのセキュリティレビュー機能を運用している企業は、段階5の常設コストの大半をすでに負担しています。

• 回答11〜13によって、順位はさらに変わります。 references/extension-surface-ladder.md の各段階を確認し、根拠に照らして 正当化される、時期尚早、または 人員を確保できない と評価してください。そのうえで、効率の高い順に、候補となる段階を2つまたは3つ提示してください。1つだけにしてはいけません。それぞれについて、以下を説明してください。

• 誰が構築するのか。

• 何を得られるのか。

• 何を運用しなければならないのか。

• 何ができなくなるのか。

• 機能していることを示す最も早い兆候は何か。

最後に、推奨案とその理由を述べ、それ以上詳しく説明する前にユーザーに選んでもらってください。

ステップ 4 - 補完財の経済性と価値の分配を検証する

補完財が構築されるのは、外部の事業者の損益計算が成り立つときであり、戦略資料にそう書かれているときではありません。頼りにしているビルダーの類型ごとに、references/ecosystem-readiness-gates.md のワークシートに記入してください。成否を決めるのは、次の4つの入力です。

• 到達可能な需要 - 自社の顧客数ではなく、補完財を必要とする可能性がある自社顧客の数です。
• 相手のリターン - ライセンス収益、導入にかかる時間、案件の流入、または回避できる社内コストです。
• 構築・保守コスト。こちらが相手に強いる移行はすべて含めます。
• 相手にとっての代替案 - より大きなプラットフォーム上で同じものを構築するか、そもそも構築しないことです。

価値の分配は、この計算からそのまま導かれます。ビルダーが構築するのは、自分の側に残る余剰が代替案を上回る場合だけです。また、流動性が生まれる前にテイクレートを課すと、その余剰がまさに失われます。そのため、課税するに値する市場ができるまでは、テイクレートをゼロにしておいてください。

ただし、この最後のステップは、実測値ではなく計算に基づいて導いた、このスキル独自の設計ルールです。確定事項として扱わず、明示的に議論してください。料金、請求、掲載の仕組みはその後の話であり、ここでは扱いません。

同じワークシートでも、ビルダーの類型ごとに試算は異なるため、提供内容も変わります。

• 独立系ソフトウェアベンダーには、製品ラインを成り立たせるだけの大きな市場と、寛大さより予測可能性が必要です。
• 代理店やインテグレーターは稼働時間を収益化するため、収益分配ではなく、紹介案件の流入と認定を提供してください。
• 顧客の社内チームには、事業上の採算性を示す必要はなく、必要なのは導入の手間が少ないことだけです。そのため、最初の供給元として最も低コストです。

次に、ビルダー候補それぞれに、次の質問をして適格性を見極めてください。これを実施しないとしたら、あなたには何が変わりますか？

• 「必要な認定を失います」は、構築する理由になります。
• 「実際には何も変わりません」は、補完者ではなく、ロゴがあるだけだということです。

自分自身にも鏡のテストを適用してください。双方がコストなしで立ち去れるなら、これは握手であり、エコシステムではありません。どちらのテストも、実務家によるヒューリスティックです。

Step 5 - フライホイールと最初の1回転を設計する

ループを因果関係として書き、それが自律的に回るのか、それとも毎四半期あなたが押しているのかを正直に述べてください。パートナーシッププログラムも正当な答えですが、別の答えです。

シードは、任意の慈善行為ではありません。Gawer と Cusumano は、プラットフォームを目指す企業のビジネス上の課題の中心に、シードを位置づけています。つまり、主要な補完要素を自ら作るか、サードパーティ企業がそれらを作るよう促すインセンティブを与えるかです（MIT Sloan Management Review、2008年1月）。

どちらもしないことが、公開された拡張ポイントを空のままにする理由です。以下の計画では両方を行います。

• 補助金を出す側を選びます。 価格への感応度が高い側に補助金を出し、もう一方の側が成長したときに需要が最も大きく伸びる側に料金を課します。これは、Rochet と Tirole による二面市場の価格設定ルールです（Journal of the European Economic Association、2003年）。価格への感応度が高い側は、開発ツールのエコシステムではほぼ常に補完要素の提供者である（無料のツール、無料のサンドボックス利用環境、無料の掲載）という見解は、このルールそのものではなく、このスキルによる判断です。
• 創設時のコホートを手作業で集めます。 ロゴの価値ではなく、顧客から最も多く求められる補完要素を幅広く網羅できるよう選びます。
• 最初の補完要素は自ら構築します。 拡張ポイントの有用性と手本を示したうえで、引き継ぐか廃止します。
• 自社の流通経路から補完要素へ誘導します。 プロダクト内の配置、オンボーディング、ドキュメント、営業での会話などを活用します。プラットフォームが自分たちを紹介しなくなると、補完要素の提供者は離れていきます。
• 信頼できる最低限のプールを定義します。 エコシステムを見た顧客が「放置されている」と感じる一歩手前の、件数とカテゴリーの網羅範囲を定めます。

ステップの最後に、あなたの制御が及ばないものの、この賭けの成否を左右する要素を列挙し、それぞれに期限を記してください。補完要素の準備状況は、些細な点ではなく現実的なリスクです。Ron Adner のイノベーション・エコシステムに関する_Harvard Business Review_ の記事（2006年4月）は、制作機器、圧縮規格、放送インフラといった補完的な要素が整っていなかったために、高精細テレビの普及が何年も停滞した事例から始まります。

Step 6 - 引き受ける義務のコストを見積もる

選んだ段階によって、恒久的な義務が生じます。確約する前に、担当者とともにそれらを明記してください。

• 拡張ポイントの安定性と廃止ポリシー - 公開されたインターフェースをどれだけの期間維持するか、互換性を損なう変更の前にどれだけ通知するかを定めます。
• ロードマップの境界 - 自社での構築をどこで止めるかを定めます。補完要素をコアに取り込むのが正しい場合もありますが、予告なく行えば、他の誰もが自社への投資は安全ではないと学んでしまいます。境界を公開し、越える前に通知すると約束し、変わり得ることを認めましょう。変わらないふりをしてはいけません。
• サポートとエスカレーション - サードパーティのバグが、自社の障害として持ち込まれます。
• 審査と安全性 - 必要な段階に応じて、セキュリティ審査、スコープと同意、アクセス取り消しに対応します。
• 終了条件 - 通知期間、移行経路、データのエクスポートを、コストの低いうちに今、文書化します。

公開する拡張ポイントを一つ残らず、責任の台帳に追加してください。次のリファクタリングを予算内で実行できるかどうかを示すのは、アーキテクチャ図ではなくその台帳です。

Step 7 - メモを書き、セクションごとに検証する

チームがあなた抜きで実行できる意思決定を作成します。

# Ecosystem strategy - <product>

## Hypothesis the one-sentence claim from step 1

## Evidence counted demand, with customers named

## Gates each gate: pass / fail / unknown, with the resolver for unknowns

## Rung the chosen rung, the rungs rejected, and why

## Complementor case the arithmetic per builder archetype, and the value-share principle

## Flywheel the loop, the subsidized side, the founding cohort, the minimum pool

## Obligations what we permanently owe outsiders, with owners

## Measurement the metrics, the baseline today, the target and its date

## Kill criteria what makes us stop, de-escalate or wind down, with dates

次のセクションを書く前に、現在のセクションを提示し、合意を得てください。構築者の類型を誤って判断すると、その下のすべてが無効になります。9つ目の見出しまで進んでからではなく、5つ目の見出しの時点で見つけるほうがはるかに低コストです。

完成したメモの例が2つ、references/ecosystem-memo-example.md にあります。1つはエコシステムを承認するもので、各セクションの弱い例と強い例を並べて示しています。もう1つは承認を見送るものです。ゲートを通過できない場合は、見送りのメモを書いてください。再検討の条件を記した文書化された「いいえ」が成果物です。それを省くと、同じマーケットプレイスの検討事項が2四半期ごとに再び持ち上がります。

組織と個人開発者

メモを完成させる前に、エコシステムが常に抱える2つの対象者それぞれの視点で、すべてのセクションを確認してください。対象者によって重視するものは異なります。

• 組織 - 自社製品の購入者であり、補完的な製品やサービスを提供する企業の大半にとって雇用主です。組織が求めているのは、リスクを取り除くことです。

  • 安定性の保証。
  • 監査人に提示できるセキュリティレビュー。
  • サードパーティ製アプリが壊れたときのサポート窓口。
  • 3年後も事業を続けているベンダー。

  これが、ステップ6の義務こそが本当の製品である理由です。

• 個人開発者 - 社内開発者、独立系の補完的な製品・サービスの開発者、ホビイストは、初期の活気と信頼性をもたらします。契約を結ばせるよりも、障壁を取り除くことが大切です。

  • 数分で使えるサンドボックス。
  • 正直なドキュメント。
  • 最初のビルドで門前払いしないこと。

  個人開発者は、罠のように感じられるものを他のどの対象者よりも厳しく批判します。また、告知のない破壊的変更が1つあるだけで、何年にもわたって築いた信頼が損なわれます。

両者に同じように当てはまることが1つあります。開発者自身の計算が成り立つ場合に限り、補完的な製品やサービスが開発されます。個人開発者についてもステップ4を実行してください。個人開発者にとっての通貨はお金ではなく時間であり、時間も同じように有限です。

測定と合格基準

以下の数値はすべて、このスキルが議論の土台として設定したデフォルト値であり、業界ベンチマークではありません。提示する際は、そのことを明記してください。自分で設定したデフォルト値を業界の数値のように装えば、経営チームは疑問を持たなくなります。チーム独自の過去データがある場合は、そちらを優先し、デフォルト値を置き換えたことを記録してください。

メモを完成させる前に、以下の基準を満たすまで判断内容を見直してください。

• 仮説の文に曖昧な箇所がなく、コモディティ化された補完的な製品やサービスが明示されている。
• 数え上げた需要には、顧客がひも付いた要望のある補完的な製品やサービスが少なくとも5つ含まれている。ペルソナではありません。5つという数はこのスキルのデフォルト値です。数千のアカウントを持つ製品では増やし、引き下げる場合は理由を書面に残してください。
• すべてのゲートが合格または不合格になっており、残る不明点にはそれぞれ、解決担当者と日付が設定されている。
• 選んだ段階は1つだけであり、その実行に必要な常設チームが明示され、確保されている。
• 回答によって対象外となった段階は、メモに列挙するのではなく削除されている。また、選ばれなかった段階のうち、なお候補に残るものすべてについて、妨げとなる理由が明記されている。
• それぞれの開発者類型について、補完的な製品やサービスを提供する側の収支計算が記載され、そのうち少なくとも1つでプラスのリターンが出ている。
• ステップ6のすべての義務に、担当者が明示されている。
• 以下の各指標について、現時点のベースライン値があり、目標には日付が設定されている。
• キル基準に、しきい値と日付を伴う失敗条件が少なくとも1つ含まれている。

その後、実行中のプログラムは業界横断的な数値ではなく、自社のベースラインと比較して測定してください。

• 補完的な製品やサービスの供給：四半期あたりの純増数、および需要リストのカバレッジ。
• 開発者の利用開始：登録済みの開発者のうち、実際に何かを公開した人の割合、および最初に動作する補完的な製品やサービスを完成させるまでの時間。
• 顧客の導入：少なくとも1つの補完的な製品やサービスを有効に利用しているアカウントの割合、およびそうしたものを利用していないアカウントと比べた継続率と利用拡大率の差。この数値がプログラムの資金源になります。
• 集中度：エコシステムの利用において、上位5つの補完的な製品やサービスが占める割合。高い場合、エコシステムではなく、5つの提携関係しかないことを意味します。
• コスト：拡張ポイントとの互換性維持に拘束されるエンジニアリング時間、およびサードパーティ製コードに起因するサポートチケット数。

よくある失敗パターン

• 需要のない拡張ポイント。 拡張ポイントを公開しても、誰も構築しません。チームは開発者向けマーケティングのせいにします。ほとんどの場合、原因は事前に需要を数えなかったことです。
• 自社の補完事業者をシャーロッキングする。 サードパーティの補完機能を無意味にする機能を出荷することです。この用語は、AppleのSherlockがSpotlightに取って代わられたことに由来し、MacおよびiOS開発者の間で定着した語彙です。正しい判断である場合もありますが、事前に告知しないのは決して正しくありません。
• 隣からの包摂。 Eisenmann、Parker、Van Alstyneは、2007年のHarvard Business Schoolのワーキングペーパーでプラットフォームの包摂について説明しました。隣接するプロバイダーが自社のプラットフォームにあなたの機能をバンドルし、市場を吸収します。賭けに出る前に、これをあなたに対して実行できるプラットフォームを特定してください。
• 凍結したアーキテクチャ。 公開済みの拡張ポイントが増えすぎると、製品をリファクタリングできなくなります。需要が正当化する最小限のサーフェスを公開し、初日からバージョン管理してください。
• ガバナンス負債。 レビュー待ちの案件、セキュリティ関連のエスカレーション、非推奨化の告知、パートナーサポートが、担当者不在のまま一斉に押し寄せます。人員を配置できない段階には進まないでください。
• エコシステムの見せかけ。 パートナーのロゴを並べた壁と、誰もそこからインストールしないディレクトリです。発表済みのパートナー数ではなく、アカウントあたりのアクティブな補完機能の数を報告してください。
• 生き残れないほど脆弱な補完事業者。 競争が激しいカテゴリ、到達可能な需要の少なさ、あるいは早すぎるテイクレートの設定によって、補完機能は衰退し、顧客は壊れたインテグレーションに直面します。
• 終了基準がない。 撤退が恥ずかしいため、エコシステムプログラムを誰も終了しません。判断のコストがまだ低いうちに、終了基準を明文化してください。

参考資料

• references/ecosystem-readiness-gates.md - 合格条件付きの準備状況ゲートと、補完事業者の経済性ワークシートです。
• references/extension-surface-ladder.md - 6つの段階について、誰が構築するのか、何を運用するのか、可逆性、そして選択した段階が適切でないことを示すシグナルを説明します。
• references/ecosystem-memo-example.md - 各セクションの弱い例と強い例を示す承認済みメモと、再検討条件を記した却下済みメモです。

このスキルが依拠する概念の出典です。いずれも概念的なもので、数値を示すものではありません。

• Joel Spolsky、Strategy Letter V（2002年）、補完財のコモディティ化について。
• Steve Yeggeによる、Amazonのインターフェース義務化に関する2011年の説明。
• RochetとTirole（Journal of the European Economic Association、2003年）、両面市場の価格設定について。
• GawerとCusumano（MIT Sloan Management Review、2008年1月）、プラットフォームのリーダーシップにおける2つの課題について。
• Eisenmann、Parker、Van Alstyne（2007年のHarvard Business Schoolワーキングペーパー）、包摂について。
• Ron Adner（Harvard Business Review、2006年4月）、補完機能の準備状況について。

このコレクションに含まれる関連スキル：

• samber/developer-relations-skills@open-source-company-strategy - サーフェス自体をオープンソースにすべきかどうか。
• samber/developer-relations-skills@developer-first-gtm - 導入を促進する取り組み。
• samber/developer-relations-skills@devtools-pricing-strategy - 価格設定とパッケージ化。
• samber/developer-relations-skills@developer-segmentation - 補完機能が対象とする顧客セグメントの特定。
• samber/developer-relations-skills@developer-journey-map - 補完機能が位置する導入経路。
• samber/developer-relations-skills@open-standards-strategy - 拡張サーフェスを共有のマルチベンダー標準の候補とする場合の方針決定。

段階を選択した後は、samber/developer-platform-skills も参照してください。この判断から引き継がれる実行レイヤーを扱います。

• インテグレーションサーフェスそのもの。
• コネクタマーケットプレイスの運用モデル。
• パートナーアプリのオンボーディング。
• レビュースタンダード。
• マーケットプレイスの経済性。
• アプリ所有のフィールドから分離されたパートナーサブグラフまでを対象とする、公開GraphQLグラフのパートナー拡張：samber/developer-platform-skills@graphql-federation-offering。