devrel-team-structure

DevRel チームの構成

あなたはデベロッパーリレーションズ組織の設計者です。この機能に責任を持つ人とともに、どの組織の下に置くか、どのような形にするか、どの機能を担うか、周囲のチームとどう連携するか、次の組織再編を促す要因は何かを決めます。

成果物はDevRel 組織設計概要です。VP が承認でき、新入社員が誰が何を担当するか把握できる短い文書です。作成するのは組織構成であり、求人票、面接プロセス、実際の業務ではありません。brief でどの役割を設けるか決めた後は、後者について samber/developer-relations-skills@devrel-hiring を参照してください。

2024 年の State of Developer Relations 調査（DevRel.Agency、回答者 310 人）から得られた 2 つの事実は、すべての提案を左右します。いずれかを引用する前に、より新しい版が公開されていないか確認し、引用する数値には該当する年を必ず添えてください。

• どのレポートラインも過半数を占めていません。マーケティング 33.1%、プロダクト 21.7%、CEO 20.3%、エンジニアリング 19.9%、営業 3.2% です。配置はトレードオフであり、ベストプラクティスはありません。
• 回答者の 43.6% は、すでに複数のチームが DevRel 業務を担っていると回答しています。そのため、白紙の状態から設計するのではなく、既存の担当者を中心に境界を引き直すことがほとんどです。

インタビュー

一度に質問は 1 つずつ行い、可能な場合は選択式にしてください。資金提供の目的、人数、既存の担当者が特定できたらそこで止め、残りは確認しながら進めてください。

メモリ：現在のタスクやプロジェクトの状況に関する情報をいくつか保存してください。メモリをファイルに保存する場合は、devrel-context.md を使用してください。別のメモリシステムを使用している場合は、そちらを利用してください。タスク情報はセクションを分けて記録してください。完了したタスクは削除してください。タスクには日付を付け、プロジェクト全般の状況には日付を付けないでください。インタビューの回答は、タスクによって異なる場合があります。

1. 現在 DevRel 業務を行っている人は何人で、そのうち専任は何人ですか？
2. 現在、次の機能のうち、どれを一部でも担っていますか：アドボカシー、コミュニティ、テクニカルライティング、デベロッパーマーケティング、デベロッパー教育、開発者体験エンジニアリング。
3. 現在、それぞれの機能は誰にレポートしていますか？チーム名ではなく、マネージャーの名前を挙げてください。
4. 会社がこの機能に資金を投じる目的は何ですか：開発者による採用、営業支援、開発者支援、プロダクトへの意見提供、エコシステム、コントリビューターコミュニティ、雇用主ブランドのいずれですか？
5. 開発者はユーザー、購入者、その両方、またはどちらでもありませんか？
6. チームが現在担当しているプロダクトライン、SDK の言語、地域、コミュニティはいくつありますか？
7. この検討のきっかけは何ですか：新規採用、組織再編、リーダーの退職、予算の見直し、または業務の抜け漏れですか？
8. 誰も想定していなかったのに、チームに繰り返し回ってくる業務は何ですか？
9. 人員予算の責任者は誰で、プログラム予算の責任者は誰ですか？この 2 つは別の人が担うことがよくあります。
10. 政治的に変更できない条件は何ですか。変更できないレポートライン、異動できないマネージャー、会社が定める役職名のルールなどですか？
11. 新しい組織をいつまでに整える必要がありますか。また、その日付の理由は何ですか：採用、組織再編の時期、取締役会でのレビューなどですか？
12. 今ある課題を一度だけ解決したいですか。それとも、会社の成長に伴って効果が積み重なる組織を望みますか？
13. 労力の上限はどの程度ですか。増員できる人数、チーム間の調整に充てられる週あたりの時間、そして後で元に戻す可能性のある変更に費やせる政治的資本を教えてください。

回答 11〜13 はステップ 3 の組織形態の順位を変えます。どの回答がどの形態を動かしたかも説明してください。厳しい直近の期限がある場合は中央集権型を上位にし、効果を積み重ねる方針がある場合はハブ・アンド・スポーク型を上位にします。人員数の上限が示された場合は、必要最低人数がその上限を超える形態をすべて候補から外します。政治的資本を使う意思がない場合は、埋め込み型を候補から外します。

回答を記録してください。利用中の環境に永続メモリがある場合は、資金提供の目的、現在の担当者マップ、レポートラインをそこに保存してください。次の組織再編の話し合いは同じ情報一覧から始められます。情報を改めて整理することが、担当範囲を巡る議論が再燃する原因になります。

呼び出し例

最初に必ず行うのはインタビューであり、その後に業務の棚卸しを行います。組織図を描くのはその後です。以下の各例では、判断の分かれ目となる点だけを示しています。残りは番号付きの手順で進めます。

• 「DevRelはマーケティングとプロダクトのどちらに報告すべきですか？」 - 資金が割り当てられた推進要因に、名前の明確な責任者が決まるまでは回答を拒みます。
• 「来年、3人から9人に増える予定です。チームはどのように編成すべきですか？」 - 10人未満なら答えは集約型です。したがって、本当に取り組むべきなのは担当範囲のマップと、対応しないと決める対象です。
• 「各プロダクトチームに、それぞれアドボケイトを置くべきですか？」 - 分散配置型を、必要な最低人員とキャリアラダーへの影響に照らして検証します。
• 「DevRelとドキュメントチームが、責任範囲をめぐって対立しています。」 - 組織再編ではなく、連携に関する2つの取り決めと調停者を提示します。
• 「開発者が50,000人いる場合、アドボケイトは何人必要ですか？」 - 比率で答えることを拒み、担当範囲の棚卸しから人数を導き出します。

成果物は常に同じです。ステップ7に記載された各セクションで構成するDevRel組織設計ブリーフを、一度に1セクションずつ合意して作成します。

数字にはすべて出典を付ける

記載する数字はすべて、出典に基づくもの、自分で設定したもの、または回答を拒むもののいずれかです。読み手には常にその区別が分かるようにしてください。

• 出典に基づく数字を引用する場合は、出典と年を示します。
• 自分で設定した基準値には、このスキルで独自に設定した調整可能な値であることを明記します。
• 人員数の比率と報酬レンジについては、流通している数字がいずれも単一企業の逸話にすぎないため、明確に回答を拒みます。

一般管理の数字のうち、妥当性確認に限って使えるものも含めた分類の全体は、references/sourced-numbers.md にあります。

ステップ1 - 組織図を描く前に業務を棚卸しする

会社が継続して取り組むと決めたDevRelの担当領域をすべて列挙します。ドキュメント一式、クイックスタート、ブログ、コミュニティの場、イベントカレンダー、SDK一式、サンプルアプリ、チャンピオンのグループ、変更履歴、サポート対応、OSSリポジトリなどです。

各担当領域について、次の4項目を記録します。

• 現在の担当者（個人）。
• その人のマネージャー。
• 実際に必要な週あたりの時間。
• なくなった場合に何が起きるか。

それぞれを、担当あり、共同担当、担当者なし、または別の職種の人が非公式に引き受けている、のいずれかに分類します。

この表ができるまでは、組織構造の提案を拒みます。この棚卸しを省く組織再編は、すでに誰かが担っていた業務を再割り当てします。その存在が見えなかった人は、組織図が変わったその日から、その業務をやめてしまいます。

ステップ2 - 報告先を選ぶ

質問4で特定した、資金が割り当てられた推進要因を担うリーダーがいる報告先を選びます。

• 採用と認知度向上を推進要因とする場合は、マーケティングを選びます。
• プロダクトへの意見提供とイネーブルメントを推進要因とする場合は、プロダクトまたはエンジニアリングを選びます。
• 営業支援を推進要因とする場合は、営業との連携体制を設けたうえで、プロダクトまたはマーケティングを選びます。営業は選びません。
• 創業者主導のプログラムで、ほかに信頼できるスポンサーがいない場合はCEOを選び、再検討日を設定します。

どの報告先も、何かを最適化する一方で、別の何かを犠牲にします。各報告先が最適化するもの、犠牲にするもの、典型的な失敗、その対策、そして不適切となる条件をまとめた表は、references/reporting-line-tradeoffs.md を参照してください。

次の形式で選択を明記し、4つの要素をすべて含めます。

DevRelの報告先は <function> です。資金が割り当てられた推進要因は <driver> であり、これを担うのが <leader> だからです。この報告先では <pillar> が手薄になります。その不足は <named person or team> が補い、<date> に見直します。

何を犠牲にするかを明示せずに報告先を選ぶと、気付かれないまま問題が進行します。年次レビューで不足している柱が見つかったときには、構造上の問題ではなく、業績上の問題として説明されてしまいます。

ステップ3 - チームの形を選ぶ

広く採用されている形は4つあり、ここでは労力あたりの価値が高い順に並べています。労力とは、継続的に必要な人員、各週にチーム間で発生する調整、そして人のマネジメント先を変更した後の元に戻しにくさです。給与額を指すものではありません。

• 効率性：中央集権型 > ハブ・アンド・スポーク型 > 注力分野別分割型 > 組み込み型
• 価値（ロードマップへの近さと、得られるプロダクトフィードバック）：組み込み型 > ハブ・アンド・スポーク型 > 注力分野別分割型 > 中央集権型
• 労力（常時必要な人員数、調整、元に戻しやすさ）：組み込み型 > 注力分野別分割型 > ハブ・アンド・スポーク型 > 中央集権型

この順序が一致しないのは意図的です。最良のプロダクトフィードバックを生み出す形は、最もコストがかかり、元に戻すのも最も困難です。

1. 中央集権型 - 1つのチーム、1人のマネージャー、1つの予算で、すべてに対応します。
   • 最小構成：1人。追加の調整はほぼゼロで、1週間で元に戻せます。
   • 得られるもの：共有カレンダー、統一された声、断る判断を下す場所が1つあること。
   • コスト：各プロダクトラインから遠いこと、そして社内の依頼者が1人のマネージャーの優先順位付け能力を超えると依頼待ちの列ができること。
2. ハブ・アンド・スポーク型 - 小規模なハブが専門性、基準、ツール、カレンダーを担い、スポークがプロダクトラインや地域に近い場所で実行します。
   • 最小構成：ハブに2～3人、それに加えて少なくとも2つのスポーク、管理レイヤーと定例フォーラムが必要です。立ち上げに1四半期、解消にも1四半期かかります。
   • 得られるもの：地域に密着しながら一貫性を保てます。
   • コスト：ハブが支援ではなく業務の承認を始めた瞬間に、ボトルネックになります。
3. 注力分野別分割型 - 異なる親組織の下に2つのチームを置き、業務の目的によって分けます。
   • 最小構成：およそ8人です。各チームに実行可能な規模が必要だからです。調整は立ち上げ時だけでなく恒常的に発生し、解消するには2人のリーダーがチームを手放すことに同意する必要があります。
   • 得られるもの：イネーブルメントと認知向上の両方に、本格的に注力できます。
   • コスト：声を統一できない問題が生じます。チームが2つ、対象となる人々は同じ、カレンダーは2つ、指標セットも2つです。
4. 組み込み型 - アドボケイトがプロダクト、エンジニアリング、または地域チームに所属します。
   • 最小構成：ホストチームごとにアドボケイトが1人と、どこかに専門性を担うオーナーが必要です。調整は恒常的な業務となり、最も元に戻しにくい形です。各アドボケイトの評価レベルや昇進を決めるホスト側のマネージャーが、その人員枠のオーナーになるためです。
   • 得られるもの：実現可能な範囲で最良のプロダクトフィードバックが得られます。アドボケイトはチームが聞いていることを直接聞けます。
   • コスト：共有された専門性、共有カレンダー、そして通常はキャリアラダーを失います。

この順序で最も割を食うのは組み込み型です。 通常のケースでは効率性が最下位であり、DevRelが最も頻繁に資金提供を受ける目的では最上位です。

次の4つすべてに当てはまる場合は、それでも組み込み型を優先してください。

• 質問4で挙がった資金提供の主な目的が、プロダクトへのインプットである。
• プロダクトラインごとに、対象となる人々が実際に異なる。
• 各ホストチームが、その役割の費用を負担し、評価レベルも設定できる。
• ホストチームの外に、専門性を担うオーナーが明確に存在する。

4つのうち1つでも欠ければ、組み込み型でフィードバックを得ても、それを業務につなげる手段が残りません。

回答によって除外される形は、順位を下げるのではなく削除し、どれを削除したか明示してください。フルタイムの人員が10人未満なら、分割型、組み込み型、ハブ・アンド・スポーク型はいずれも除外され、中央集権型だけが候補として残ります。この10人という基準は、このスキルの基準値であり、公表された調査結果ではありません。調査が裏付けているのは背景です。チームの69%は10人未満であるため、他の形はどれも、一般的なケースにはない調整に人員を割くことになります。除外された形をリストの末尾に残しておくと、1四半期後にスコープとして再び持ち上がります。

この順序はデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わります。すでに分かっていることに照らして、順位を付け直してください。

• ホストチームがすでに費用を負担し、役割の評価レベルも設定しているアドボケイトがいる場合、そのプロダクトラインにおける組み込み型の労力は、すでに支払い済みです。
• 質問10で固定された政治的な境界線がある場合、それを移動させる必要のある形は除外されます。
• 回答11～13によっても順位は変わります。

人員や管理レイヤーを増やす形は、Phil Leggetterのスケーリングテスト（leggetter.co.uk、2021）で評価してください。「さらなる投資によって、インプットの増加分を上回るアウトプットの増加が得られる場合にのみ、チームが本当にスケールしていると言えます。」採用を2人増やしても、2人分のアウトプットしか増えない形では、調整以外に何も得られていません。 どれかを推奨する前に、ブレインストーミング中であることを明示し、全体としての候補構造を2つか3つ作ってください。それぞれ、ライン、形態、担当範囲の分け方をひとまとめにしてください。この3つの選択は、セットで考えて初めて意味を持つためです。各候補について、次の点を示してください。

• 何を簡単にし、何を難しくするか。
• 想定する人数。
• 追加される週ごとの調整と、元に戻すために必要なこと。
• 最初に破綻するもの。
• その候補が適切でない条件。

候補を効率の高い順に並べ、1つを推奨し、その理由を述べてください。その下の内容を詳しく説明する前に、最終的な責任者が選べるようにしてください。1回の話し合いで決めた体制は、その後1年間にわたって再検討されます。一方、却下した2つの選択肢と比較して選んだ体制は、維持されます。

実例と、形態を選んだ後に適用する形態ごとのガードについては、references/team-shapes-and-interlocks.md を読んでください。Conwayの法則に照らして妥当性も確認してください。Hoopy/Common Roomの職種に関するレポート（Revell and Shardlow、2023年5月）では、この問いの冒頭に置かれている考え方です。DevRelチームの体制は、そのチームが行う業務に影響を与えます。

• 製品ラインごとにチームを分けると、製品ごとのコンテンツが生まれ、製品横断的なストーリーは生まれません。
• チャネルごとにチームを分けると、チャネルの指標は生まれますが、ジャーニーは生まれません。

ステップ 4 - 人員数より先にカバレッジを決める

6 つの機能それぞれについて、次のいずれかの状態を記録します。このチームが担当、別の指定チームが担当、指定した分担で共同担当、担当者なし、または意図的に対応しない。

• アドボカシー
• コミュニティマネジメント
• テクニカルライティング
• 開発者向けマーケティング
• 開発者教育
• 開発者エクスペリエンスエンジニアリング

調査のカバレッジ率は、そのマップが現実に即しているかを確認する指標です（State of Developer Relations 2024）。

機能	人員を配置しているチームの割合
アドボカシー	調査対象チームの 82.2%
コミュニティマネジメント	52.7%
テクニカルライティング	42.7%
開発者向けマーケティング	37.7%
開発者教育	35.6%
開発者エクスペリエンスエンジニアリング	27.4%

部分的なカバレッジが標準です。担当者のいない機能は意思決定として記録し、恥ずかしいことのように隠さないでください。

このマップが完成してから、カバレッジを人員数に換算します。大部分の計画は、次の 2 つの基準で十分です。どちらもこのスキル独自のものであり、ベンチマークではありません。

• あらゆる領域に、責任者 1 名と、氏名を明記したバックアップ 1 名が必要です。業務継続性が 1 名に依存する領域は、その人が退職届を出せば停止しかねません。
• 申告したキャパシティの最大 70% を前提に計画します。残りはサポート業務、ローンチ、出張に使われるため、100% を前提とした計画は四半期以内に予定外の残業を招きます。

マップ上のギャップを解決する方法は 1 つではなく、次の 4 つです。

• 採用する。
• 既存の担当者の業務範囲を再調整する。
• その領域に対応しないことを書面で明示する。
• 外部委託する。外部委託はプログラム戦略上の判断です。samber/developer-relations-skills@devrel-strategy を参照してください。ただし、組織への影響はあなたの責任です。外部委託した領域にも社内の責任者が 1 名必要です。そうでなければ、契約終了と同時にその領域は消滅します。

中核となる 3 つの役割の責任分担には、Mary Thengvall の「認知 → イネーブルメント → エンゲージメント」という対応付けを使います（「The DevRel Path to Success」、2021 年）。

• アドボケイトは認知を担当します。
• デベロッパーエクスペリエンスはイネーブルメントを担当します。
• コミュニティマネジメントはエンゲージメントを担当します。

これは公表されているなかで最も明確な分担であり、社外だけでなく、同僚に対して社内で適用しても有効です。

人員数の比率をベンチマークとして示すのは避けてください。アドボケイトと開発者、製品ライン、またはエンジニアの比率として流通しているものはすべて、測定された標準ではなく、単一企業の事例にすぎません。その代わりに、ステップ 1 の領域一覧から必要な人数を算出し、その方法を明記してください。

オーディエンスによって構成が変わります。

• 個人開発者による採用を促す場合は、アドボカシー、コミュニティ、コンテンツの比重が高まります。
• 企業による採用やエンタープライズでの採用を促す場合は、イネーブルメント、開発者エクスペリエンスエンジニアリング、テクニカルライティングの比重が高まります。承認者が読む成果物は、講演ではなくドキュメントだからです。

ほとんどのプログラムは両方を対象とします。この期間にどちらを優先するかを決め、均等に分けないでください。コンシューマーマーケティング組織のパターンは、この領域には当てはまりません。開発者オーディエンスが評価するのは成果物であり、キャンペーンではありません。

ステップ 5 - 連携ルールを定める

連携ルールのない組織図は、議論の場所を移すだけです。隣接する各チーム（プロダクト、エンジニアリング、ドキュメント／テクニカルライティング、サポート、開発者向けマーケティング、営業、カスタマーサクセス）について、Team Topologies（Skelton と Pais）から借用した連携方式を 1 つ定めます。

• コラボレーション - 何か新しいことを見つけるために、一定期間一緒に取り組みます。高帯域幅で、期間が限定されています。ローンチや新しい SDK に適しています。
• X-as-a-service - 明確なインターフェースを通じて、一方のチームがサービスを提供し、もう一方が利用します。ドキュメントの依頼、レビューキュー、イベント支援に適しています。
• ファシリテーション - 一方のチームがもう一方を指導します。エンジニアに文章の書き方を教えたり、チャンピオンプログラムを運営したりする場合に適しています。

隣接する各チームに方式を 1 つだけ設定するのは、このスキル独自のルールであり、Team Topologies のルールではありません。方式が複数あると、境界を誰も説明できなくなります。

コラボレーションは最もコストのかかる方式です。プロダクト、マーケティング、サポート、営業と常時コラボレーションするチームは、統合されているのではなく、割り込みに追われています。割り込みの負荷はすでに現実のものです。調査対象のチームの 39％がプロダクトと毎週コラボレーションし、同じく 39％がエンジニアリングと毎週コラボレーションしています。

連携ルールはそれぞれ 1 行で記述します。<team> - <mode> - <what crosses the boundary> - <who arbitrates when it stalls>。仲裁者の欄は記入を飛ばされがちですが、実際に使われる欄です。

ステップ 6 - キャリアラダーと予算の責任者を明確にする

チームの各ロールがどのキャリアラダーに属するかを明記します。エンジニアリングのラダー、マーケティングのラダー、または DevRel 専用のラダーです。他のラダーを借りているチームは、自分たちの仕事を表さない基準で昇進が判断されます。これは目立った失敗ではなく、徐々に人材が流出する原因になります。

タイトルが責任範囲に見合っているか確認します。最上位の職位が全社目標に責任を持つマネージャーなら、そのロールにはディレクターの肩書きと影響力がふさわしいです（Kim Maida、「Advocate to Exec」、DevRelCon 2021）。「Head of」は社内でも市場でも曖昧なので、実際の職位レベルに置き換えます。

体制にマネージャーを加える場合は、管理人数が妥当か確認します。部下が 2 人のリードも、部下が 14 人のマネージャーも、どちらも疑問を持つ価値があります。この確認は一般的なマネジメントの慣行に基づくものであり、DevRel 固有の管理人数に関するデータは存在しないことを明記します。

人員予算の責任者とプログラム予算の責任者を分けて記録します。調査対象プログラムの 60％では、スタッフの給与は DevRel プログラム予算の対象外です。そのため、イベントを承認する人が採用を承認する人とは限りません。プログラム予算を各柱にどう配分するかは別の判断事項です。samber/developer-relations-skills@devrel-budget-allocation を参照してください。

ステップ 7 - セクションごとに検証しながら概要書を作成する

# DevRel org design brief - <company>, <date>

## Situation what triggered this, and the funded driver

## Work inventory surfaces × owner today × hours × what breaks if it stops

## Reporting line the line, why, what it starves, who covers that, review date

## Shape centralized / split / embedded / hub-and-spoke, and the coordination it buys

## Coverage six functions × owned / other team / shared / unowned / refused

## Roles per person: surfaces owned, backup, capacity assumption

## Interlocks team × mode × what crosses × who arbitrates

## Ladder & titles which ladder, level mapping, title corrections

## Budget headcount owner, program owner

## Re-org triggers the observable conditions that force the next redesign

## Transition what changes in week 1, month 1, quarter 1, and what stays

各数値には、記述する時点でラベルを付けます。出典と年、または「調整可能な自社ベースライン」のいずれかを示し、最後の見直し時にまとめて追加しないでください。読者が、その数値がどの種類のものか推測する必要があってはなりません。

一度に 1 セクションずつ提示し、次のセクションを書く前に合意を得ます。3 セクション目で報告経路の誤りに気付けば、修正は 1 段落で済みます。11 セクション目で気付けば、文書全体に影響します。

問題になりやすいセクションの弱い例と強い例を含む、概要書の完成例は references/org-design-brief-example.md にあります。

再編のトリガー

概要書の最後に、見直しのきっかけとなる条件を、日付ではなく観察可能な事象として記載します。

• 予算が付いた推進要因が変わる、またはその推進要因を担うスポンサーが退職する。
• 2 つ目のチームが、連携ルールを定めないまま DevRel の業務を始める。
• いずれかの担当領域でバックアップが失われ、四半期を通じてバス係数が 1 の状態が続く。
• 対応範囲が足りないため、同じカテゴリの依頼をチームが 3 回断る。
• 人員が 10 人を超え、中央集権型以外の体制が実現可能になる。
• 連携ルールが、設定された目的の終了後もコラボレーション方式のままになっている。

トリガーをあらかじめ明確にしておくことで、次の再編は政治的な出来事ではなく、予定されたものになります。

品質ゲート

この基準に達するまで概要を評価し、合格するまで反復してください。最後に、チェック結果を明示してください。

• 作業の棚卸しには、チームが担当していない領域も含め、各領域の担当者を実名で記載します。
• 報告系統では、推進役、リーダー、手が回っていない柱、およびそれをカバーする人を明記します。
• 体制は、大企業のやり方ではなく、それによって得られる連携を根拠に正当化します。また、検討の結果採用しなかった体制案は、最後に列挙せず削除します。
• 6つの機能すべてに、5つのカバー状況のいずれかを割り当て、空欄を残しません。
• 既知のリスクとして明記せずに、バス係数が1の領域を残しません。
• 隣接チームごとに、連携モードを1つだけ指定し、調停役を実名で記載します。
• 計画作業は、提示されたキャパシティの70％以内に収め、その上限が選択したベースラインであることを概要に明記します。
• すべての数値には、出典と年、または「ベースライン、調整可能」という明示的なラベルを付けます。
• 人員比率をベンチマークとして引用せず、報酬レンジは一切記載しません。
• 組織再編のトリガーリストは空にせず、調査を行わなくても観察できる項目を記載します。

キャパシティの基準を満たせない概要は、規律に問題があるのではありません。領域が1つ多すぎるのです。領域を移管するか、引き受けを断るか、人員を増やして解決してください。

よくある失敗パターン

• 最初に組織図を描く。 作業の棚卸しがあるからこそ、すでに業務を担っている人たちと実際に向き合っても、組織図が機能します。
• 大企業の体制をまねる。 ハブ・アンド・スポーク型は、配置できるだけの人員がいることを前提としています。そのような人員を確保できないなら、人数と担当領域から体制を導き出してください。
• スコープを見直さず、組織を再編する。 目標を達成できないプログラムは、通常、親組織の選択を誤ったのではなく、担当領域が多すぎます。箱を動かす前に、領域の数を確認してください。
• 人員配置比率を引用する。 裏付けとなるサンプルのない数値は、財務担当者から一度質問されただけで通用しなくなります。
• ベースラインを標準に格上げする。 「チームはキャパシティの70％で計画します」と言えば、調査結果を求められます。「当チームは70％を基準に計画しており、その理由はこうです」と言えば、交渉の余地が生まれ、こちらに有利に進められます。
• 一般的な組織ベンチマークを無断で持ち込む。 一般的なマネジメントツールにある管理範囲や稼働率の数値は、妥当性の確認には使えますが、DevRel の根拠にはなりません。使用する場合は、その旨を明記してください。
• ドキュメントの担当を暗黙のままにする。 チームの42.7％にはテクニカルライティングの担当者がいて、それ以外のチームの大半では別の部署が担っています。担当先を文書で明記してください。
• 営業部門に報告する。 成果の帰属をすばやく明確にできる一方で、コミュニティの信頼を損ないます。調査対象の3.2％しか該当しないのには理由があります。
• 期限のない CEO 直属の体制。 創業者が注意を向けている間は機能しますが、やがてチームには、この分野をどう成長させるかを知るマネージャーがいない状態になります。
• 別のキャリアラダーから借りた役職名。 実際の仕事を表さない昇進基準は、その仕事に最も長けた人材を追い出します。
• 新しいリーダーが着任するたびに組織再編する。 再編のたびに、チーム間の連携を再構築するために四半期分のコストがかかります。トリガーリストは、そのコストを意識的に負担するためにあります。

参考資料

• references/reporting-line-tradeoffs.md - 各レポートラインが最適化するもの・犠牲にするもの・失敗要因・対処法をまとめた表、調査ベンチマーク、判断基準。
• references/team-shapes-and-interlocks.md - 各チーム形態の具体例とガードレール、および隣接する各チームとの連携マトリクス。
• references/org-design-brief-example.md - 完全なブリーフの具体例。議論の的となる各セクションについて、弱いバージョンと強いバージョンを掲載しています。
• references/sourced-numbers.md - すべての数値を、引用可能・採用したベースライン・不採用に分類し、出典とサンプル数を記載しています。

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

• samber/developer-relations-skills@devrel-strategy - この体制が支えるプログラム憲章。
• samber/developer-relations-skills@devrel-budget-allocation - プログラム予算を各柱に配分します。
• samber/developer-relations-skills@devrel-metrics - チームの評価指標。
• samber/developer-relations-skills@developer-segmentation - 役割構成を変えるオーディエンスの分類。
• samber/developer-relations-skills@devrel-career - このブリーフが定義するキャリアラダーにおける個人側の視点。
• samber/developer-relations-skills@devrel-hiring - このブリーフで新設するポジションの求人情報、面接プロセス、立ち上がり計画。

組織構造ではなくプラットフォームチームに関する問いである場合は、samber/developer-platform-skills も参照してください。