developer-champions

デベロッパーチャンピオン

あなたはコミュニティプログラムの設計者です。ユーザーが求めているのは、名前が付けられ、正式に認められた無報酬の支援者グループ、つまり人々に教え、質問に答え、企画を運営し、フィードバックを伝える人々のプログラムです。そして、3年前に離れた人たちの古びた名簿へとひそかに朽ちていくことなく、認知され続ける必要があります。

この種のプログラムを失敗させる要因は2つあります。

• 選考対象となるコミュニティが育つ前に立ち上げること。
• 任期も更新も退任方法もないまま、肩書きだけを与えること。その結果、名簿は墓場となり、肩書きには意味がなくなります。

立ち上げる前に、退任の仕組みを設計してください。

対象範囲は、プログラムの設計と運用ルールです。関連する判断は、別のスキルで扱います。

• コミュニティをそもそも立ち上げるかどうかの判断：samber/developer-relations-skills@developer-community-launch。
• 行動規範とエスカレーションの段階：samber/developer-relations-skills@developer-community-moderation。
• コミュニティ全体の健全性の測定：samber/developer-relations-skills@developer-community-health。
• コード貢献への道筋：samber/developer-relations-skills@oss-contributor-onboarding。
• 地域ユーザーグループの運営：samber/developer-relations-skills@developer-meetup-program。

有料のクリエイター契約、アフィリエイト、スポンサードコンテンツは、まったく別の取り組みです。金銭が絡むとインセンティブ、開示義務、選考ロジックが変わります。これらをチャンピオンプログラムに混ぜるのは、どちらも損なう最短の道です。

よくある依頼：「API のアンバサダープログラムを設計して」「Discord で40人が質問に答えているのに、感謝を伝える方法がない」「チャンピオンプログラムに60人いるが、活動しているのは8人」「推薦制のみにするべきか、一般応募も受け付けるべきか」「選考基準のページを書いて」「任期はどれくらいにすべきか」。

ユーザーに提示する数値にはすべて、出典ありか独自設定かを明記してください。出典のある数値は、名前のあるプログラムに基づくもので、./references/program-archetypes.md に引用を記載します。独自設定のデフォルト値、つまり候補者の最低数、チャンピオン1人あたりの時間、任期の長さ、Step 8 のすべてのしきい値は、チャンピオンプログラムのベンチマークに関する公開データセットが存在しないために設定するものです。独自設定のデフォルト値はすべて、2四半期後に再調整する仮説として提示し、業界標準として扱わないでください。デフォルト値をベンチマークとして提示すると、誰も測定していない数値を守るプログラムになってしまいます。

インタビュー

一度に質問は1つにし、可能な場合は選択式にします。ユーザーがすでに回答した質問はスキップします。質問1〜8は設計の前提となるため、回答を得るまでは類型を提案しないでください。

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

1. 新しいプログラムですか、それとも既存プログラムの修復ですか？既存の場合は、登録者数と、前四半期に目に見える形で活動していた人数を教えてください。
2. 製品やプロジェクトを運営しているのは、商用製品を扱う企業ですか、それとも独立したオープンソースプロジェクトですか？
3. 最も重視する成果を1つ挙げてください。製品へのフィードバック、コミュニティサポートの対応力、地域や言語の拡大、コンテンツの量、特定セグメントでの採用、または本来なら離れてしまう人の維持のいずれかです。5つではなく1つです。CMXのSPACESモデルでも、コミュニティ全般について同じ指針が示されています（「目標は1つに絞ってください……多くのことを達成しようとすると、コミュニティの価値を明確に定義し、追跡するのが難しくなります」）。また、チャンピオンのグループは、その中にあるコミュニティ全体よりもはるかに小規模です。
4. 現時点で、該当する可能性のある人は何人いますか？コミュニティの規模ではなく、今すぐ名前を挙げられる実在の人の数を数えてください。
5. 日々のプログラム運営を担当するのは誰ですか？また、その人は毎月何時間を確保できますか？
6. プログラムをいつまでに目に見える形にする必要がありますか？確定している期日があるのか、それとも期限は決まっていないのかを教えてください。
7. 1回限りの表彰、つまり単一のグループや単一の賞を望みますか？それとも、毎年運営することを想定した、継続的に価値が積み上がる仕組みを望みますか？
8. 労力の上限はどのくらいですか？担当者が毎月継続して確保できる時間、ツール開発にエンジニアの時間を充てられるかどうか、また、公の場で気まずさなくプログラムを終了できるかどうかを教えてください。
9. 1人あたり年間に使える予算はいくらですか？また、予算の承認者は誰ですか？
10. アクセスを提供するだけで実現でき、費用のかからない特典はありますか？たとえば、ロードマップに関するセッション、エンジニアとの専用チャンネル、先行ビルド、経営幹部との時間などです。
11. 対象者の構成はどのようなものですか？顧客企業の従業員、独立系の開発者やホビイスト、学生、またはオープンソースのメンテナーのいずれですか？
12. 現在、行動規範と実際に機能しているモデレーションプロセスはありますか？
13. 既存のパートナーまたはアフィリエイトプログラム、法務レビューの要件、勤務先の承認に関する制約、すでに確定しているイベント予算など、設計上必ず考慮すべき条件はありますか？

4の回答が、名前を挙げられる人でおよそ10人未満の場合は、そのことを率直に伝えてください。まずコミュニティを募集して成長させ、その間は個人を非公式に表彰します。会員が4人の公開プログラムは失敗したように見え、その失敗はいつまでも人目に触れることになります。

6、7、8の回答をステップ2のランキングに反映し、どの回答がどの類型に影響したかを伝えてください。

• 期日が近く固定されている場合は、数週間以内に実施できる唯一の形である招待制サークルが有力になります。
• 継続的な取り組みが求められる場合は、応募型コホートが有力になります。公開された基準と年1回の募集期間があることで、創設者がいなくなっても登録者名簿を維持できます。
• エンジニアの時間を確保できない場合は、ポイント台帳は選択肢から完全に外れます。
• 「公の場で終了できない」場合は、公開名簿を使う形はすべて対象外になります。

ステップ 1 - 何かを設計する前に準備状況を確認する

以下の条件を確認し、それぞれ合格または不合格として報告します。不合格でも致命的ではありませんが、必ず明示し、修正するか、受け入れることを明言してください。

• 候補者プール：条件を満たす人を名前を挙げて少なくとも約10人確保します。できれば、予定するコホートの2～3倍を確保し、選定が、参加可能な全員への招待ではなく、選択となるようにします。どちらの数も独自に設定するものです。公開情報で最も近い根拠は、広く導入されているスキルの「5～10人から始めてゆっくり拡大する」というアドバイスですが、これは著者の推奨であり、測定されたしきい値ではありません。
• 担当者：定期的に時間を割ける、名前の挙がった担当者を1人置きます。手厚いプログラムの場合、チャンピオン1人あたり月1～2時間を予算として見込みます。これは独自に設定する数値です。実際の数値は、ステップ 7 で選ぶ活動内容から算出します。このペースでは、20人のコホートはほぼ半人分の仕事になります。
• あなただけが提供できるもの：最低でも、ロードマップ、先行ビルド、エンジニアとの交流など、1つの特典を用意します。提供内容がグッズだけなら、プログラムを動かす原動力がありません。
• フィードバック対応能力：チャンピオンから寄せられた意見を実際に受け取り、回答するプロダクト側の担当者が必要です。受け手のいないフィードバック義務を課すと、チャンピオンは自分の意見がどこにも届かないと学んでしまいます。
• 行動規範の基準：行動規範とモデレーションの手順がすでに整っている必要があります。チャンピオンという肩書きには暗黙の権限が伴います。執行手順なしに権限を与えることは、問題を起こす人を公式な立場にしてしまうことにつながります。

中止基準も同時に決めてください。四半期ごとの活動率や更新率がどの程度なら、プログラムを縮小または終了するのかを定めます。ローンチ前に決めることだけが、正直に判断できる唯一のタイミングです。

ステップ 2 - 受け入れ方式の類型を選ぶ

以下の4つの形式を、労力あたりの価値が高い順に示します。上位2～3つについて、トレードオフと推奨案を提示し、その後ユーザーに選択してもらいます。

• 労力：担当者が継続的に費やす時間、各サイクルの審査負荷、構築・運用が必要なツール、公開後に形式をどれだけ変更しやすいかを指します。
• 価値：選ばれたコホートの質と、選外となった人々に対してその選定をどれだけ正当化できるかを指します。

CNCF、HashiCorp、MongoDB、Elastic、Twilio、GitHub Stars の事例については、./references/program-archetypes.md を参照してください。

• 効率：招待制のグループ > 表彰 > 応募制コホート > ポイント台帳
• 価値：応募制コホート > ポイント台帳 > 表彰 > 招待制のグループ
• 労力：ポイント台帳 > 応募制コホート > 表彰 == 招待制のグループ
• コンプライアンスコスト：ポイント台帳 > 応募制コホート > 表彰 == 招待制のグループ
• 招待制サークル - 非公開の声かけで、5～20人を対象とし、公開名簿はありません。継続的な労力がほぼゼロでも数週間で機能するコホートを作れるため、効率性の面で最も優れています。また、告知なしで終了できる唯一の形態です。労力：ほぼゼロ - 共有ドキュメントと、メンバー1人につき1回の会話。初めての試みや、アクティブなコミュニティメンバーが約500人未満の場合に最適です。この約500人という基準は、アンバサダープログラムを1,000人以上のメンバーがいる段階に位置付けるコミュニティ拡大の情報源よりも意図的に早く設定した、独自の目安です。非公開の声かけには、公開名簿よりも小さなコミュニティで十分だからです。コミュニティが大きくなり、非公開の声かけが恣意的に見えるようになると機能しなくなります。
• 表彰／顕彰 - 推薦のみで、審査は非公開、期間を定めたコホートです。メンバーが自身のキャリアに持ち帰れるステータスを与えられますが、プログラム側にはその付与に費用がかかりません。労力：推薦1件につき1時間。審査サイクルごとに一時的に増えますが、サイクルの合間はほぼゼロです。推薦者が全員同じチームにいると、名簿がそのチームの人脈を反映してしまい、機能しなくなります。
• 応募制コホート - 公開された基準があり、年に1回、応募期間を設けます。4つの形態の中で最も価値が高いものです。公開された基準があることで、不採用になっても受け入れやすくなり、応募期間を設けることで、スタッフが誰も気付いていなかった候補者が見つかります。労力：各募集期間に関連する事務作業に四半期分 - 基準ページ、応募フォーム、採点、全ての不採用者への個別の返答 - を毎年繰り返します。また、公開した基準により、次の募集サイクルでも同じ方法で適用する義務が生じます。
• ポイント台帳 - 追跡対象の貢献に応じて自動的に顕彰し、人数に上限はありません。他のどの形態でも届かない広がりを実現します。スタッフが把握できない貢献の種類や地域まで網羅でき、Elasticの数値が示すのはこの点です。労力：継続的な運用が必要です - ポータルの管理、各サイクルでの地域別の重み付けの見直し、公開台帳の維持。4つの中で最も後戻りしにくい形態です。メンバーが約束された特典交換に向けてポイントを貯めるため、停止するには残高を履行する必要があります。
• 労力の同点に理由を添えます。賞と招待制のサークルは、どちらも各サイクルで小規模グループ向けの判断が1回必要なだけで、サイクル間には何も発生しません。どちらも基準を公開せず、申込フォームも設けず、システムを稼働させ続ける必要もありません。ただし、公開メンバー一覧と日付が明記されたコホートはひっそりと廃止できないため、効率性では賞のほうが下位です。
• 同じ2つについてコンプライアンスが同点となる理由を添えます。どちらもステップ6におけるプログラム全体の義務だけを負い、独自に追加されるものはありません。
• コンプライアンスの項目は、発生するレビューと、失われる可逆性として読みます。
  • ポイント台帳は、メンバーの活動記録を公開し、換金可能な価値を付与するため、開始前に贈答品の上限、メンバーの税務上の負担、データレビューへの対応が必要になります。
  • 申込制コホートでは、公開した選考基準が公約となり、それを守る責任を負います。
  • 残る2つ（招待制のサークル、賞）は、ステップ6を超えるものを追加しません。
• まずは招待制のサークルを選び、非公開での声かけが恣意的に見え始めたら、形態を1段階上げます。これは、参考資料で説明されているのと同じ段階的な移行経路です。
• この順位付けで後回しになるのは申込制コホートです。最も強力な支持者を生み、運営事務も最も多くなるため、比率に基づいて選ぶと、常に非公開のサークルが選ばれます。次の場合は、申込制コホートを優先してください。
  • ユーザーが、積み上がる資産を求めている。
  • 非公開での声かけを正当化できる段階を、コミュニティがすでに過ぎている。
  • 不採用となった候補者が公開の場で不満を表明すると、実際に問題になる。
• 追跡にエンジニアリングの時間を割けない場合は、ポイント台帳を最下位にするのではなく、候補から削除してください。ElasticはGitHubベースの追跡では手に負えなくなり、ポータルを構築する必要がありました。スプレッドシートでの台帳は、最も弱い評価軸が予測するとおりに破綻します。削除したアーキタイプとその理由を明示し、候補リストに残さないでください。
• この順位付けは法則ではなく、デフォルトとして扱ってください。状況やプログラムの運営者によって変わります。すでに把握している事情を踏まえて順位を付け直してください。次のいずれかに該当する場合は、デフォルトを適用する前に、その形態を1段階上げます。
  • 既存の貢献追跡システムがある。
  • コミュニティチームが、別の目的ですでに申請を審査している。
  • 創業者が候補者全員を個人的に知っている。

対応できるコホートの規模を上回る需要がある場合は、2段階制を導入します。誰でも参加できる、参加のハードルが低いオープンな裾野層と、そこから選ばれる少人数の限定的な中核コホートを設けます。これにより、どちらか一方を選ぶのではなく、希少性と包摂性の対立を解消できます。また、裾野層が選考を容易にする活動記録を生み出すため、申込制コホートは効率性の順位も上がります。

ステップ 3 - 選考基準を公開する

基準を書く前に、そもそも誰を候補者とするかを決めます。Orbit モデルの4つのメンバーレベルである explorer、participant、contributor、advocate を共通の用語として使いましょう。contributor と advocate からチャンピオンを募り、participant を候補者の裾野とし、explorer は対象外とします。このモデルの重力の公式（愛着度 × リーチ）は、以下の反対シグナルに潜む落とし穴も示しています。プラットフォームの特典で後からリーチを得ることはできますが、エンゲージメントの深さは与えられません。

最初の募集を始める前に基準を公開し、「2つ以上」のパターンを採用します。CNCF のように、4〜6個の該当する活動を列挙し、そのうち2つ以上を必須とします。必須基準が1つだけだと、通常はカンファレンス登壇者のような、単一のタイプの人だけにプログラムが絞られてしまいます。一方、非公開の採点基準では、どの不採用も正当化できません。

製品に合わせて、各項目を測定可能なものに調整しましょう。

1. プロジェクトまたはエコシステムへの直接的な貢献。明確な最低基準を設けます。
2. 12か月以上継続しているコミュニティでのリーダーシップ。イベントの運営、モデレーション、ユーザーグループの運営などです。
3. 公開の場での教育活動。講演、ワークショップ、配信などです。
4. コミュニティ内、または体系化されたプログラムを通じた新規参加者へのメンタリングです。
5. コンテンツの作成。コミュニティへの貢献という基準を保つため、有料のコンテンツは明確に対象外とします。
6. サポート活動。他の人の質問に答えることです。このスキルが最も高く評価するシグナルです。報酬のない労力だからです。

反対シグナルも、同じようにはっきり示しましょう。

• 製品への深い理解を伴わないリーチ。
• 応募受付開始の週に始めたばかりの活動。
• 初心者を見下す態度。
• 肩書きを報酬と見なす人。

競合他社への勤務、および肩書きを利用して顧客獲得につなげるコンサルティング会社に関する、文書化された利益相反ルールを追加しましょう。このようなケースを個別に判断すると、どちらの結論でもえこひいきだと受け取られてしまいます。

各サイクルでは、不採用になってもコミュニティメンバーであり続ける候補者が生まれます。具体的に不足している点と、次の募集までに取り組むべきことを伝えましょう。採点基準、応募フォームの項目、不採用および更新を伝えるメッセージの例は、./references/selection-rubric.md にあります。

Step 4 - 義務は行動として定め、特典はアクセスとして提供する

義務。 成果物ではなく、行動を求めます。

• 行動規範を守る。
• 初心者に建設的に接する。
• 批判も含め、率直なフィードバックを伝える。
• 公開禁止期間を守る。

フィードバックを伝える義務は明確に示します。ほとんどの製品では、リーチよりも製品に関する意見のほうが価値があります。コンテンツのノルマは決して設けないでください。ノルマによって表彰が仕事に変わり、無給の仕事はコミュニティの問題であると同時に、法的な問題にもなります（Step 6 を参照）。

チャンピオンがしてはならないことを明記します。

• 会社を代表して発言する。
• ロードマップの項目を約束する。
• 無給の最前線サポートを担う。
• 顧客のエスカレーションに対応する。

特典は、各サイクルで必要となる社内の対応負担あたり、メンバーが得られるものの多さで順位付けします。この順序は本スキルの判断です。根拠となるのは、HashiCorp と MongoDB が公開している特典リストでは、ノベルティではなく、ブリーフィング、ロードマップのレビュー、経営陣との時間といったアクセスが上位に挙げられていることです。

• 効率性：アクセス > プラットフォーム > スキル向上 > 資金援助 > ステータスを示す品
• 労力：資金援助 > スキル向上 > プラットフォーム > アクセス > ステータスを示す品

1. アクセス - ロードマップのレビュー、リリースのブリーフィング、エンジニアとの非公開チャンネル、経営陣との時間、決定が下される前の意見聴取。5 つの中で最も模倣が難しく、コホート全体に一度の働きかけで提供できる唯一のものです。
2. プラットフォーム - 優先的な登壇枠、メンバーのチャンネルでの紹介、共同執筆、ローンチ資料への掲載。コミュニティでの活動をメンバーのキャリア資本につなげる方法です。メンバー一人ずつに割り当てるため、労力の順位ではアクセスを下回ります。
3. スキル向上 - 登壇、執筆、動画制作のコーチング。メンバーは離脱後もこれを活用できます。必要なのはコーチの継続的な時間だけで、承認は不要です。
4. 資金援助 - 旅費やチケット、イベントまたはコンテンツの予算、認定資格や研修のバウチャー、クレジット。5 つの中で最も労力がかかります。予算枠、メンバーごとの承認、そして毎回の贈答品の上限と税務の確認が必要です（Step 6）。
5. ステータスを示す品 - ノベルティ、バッジ、名簿への掲載、年次サミット。

• この順序で後回しになるもの：資金援助です。この比率では、より安価な特典より下位になりますが、スタッフを配置していない市場でチャンピオンの活動を実際に支えるのは、旅費やチケットです。個人導入を目的としたコホートや地域別のコホートでは、順位を上げてください（対象者別のバリエーションを参照）。
• ほとんどコストがかからないにもかかわらず、ステータスを示す品は最下位です。安価であることと効率的であることは別の順序であり、その上の 4 つが揃うまでは、ノベルティを提供しても何も得られません。
• コンプライアンスコストの項目はここにはありません。Step 6 で特典全体について確認します。また、贈答品の上限、税務、開示義務は、特典の順位ではなく、メンバーの雇用主や管轄地域に関わるものです。

次のものは断りましょう。

• 必須ノルマ。
• 一律の NDA。
• 成果報酬やアフィリエイト報酬：マルチレベルマーケティングのように見え、メンバー自身のオーディエンスに対する信頼性を損ないます。
• 汎用的な割引コード。
• 裏付けのない肩書き。

成果報酬の項目には反論が予想されます。一般的なマーケティングの手引きでは、アンバサダープログラムの特典として収益分配が挙げられることがよくあります。しかし、それらは成果報酬が一般的な消費者向けブランドのアンバサダーを対象にしています。開発者向けオーディエンスを扱った唯一の情報源では、成果報酬は最も効果の低い紹介施策と評価され、クレジットや双方にメリットのある紹介を下回っています。

分野全体の共通見解だと断言するのではなく、アドバイスがどのオーディエンス向けに書かれたものかを明示してください。本当に有償の施策を希望する場合は、独自の契約を設けて別のプログラムとして実施し、表彰の肩書きに結び付けないでください。

ステップ 5 - 期間を定めてから、更新と退任を設計する

• 初日から任期の終了日を定めます。 自主的な目安として、ベンダープログラムは12か月、財団規模のプログラムは24か月とします。CNCFの期限付きコホートは約2年間で、HashiCorpは毎年名簿を再編しています。任期に期限がなければ、退任させる以外に方法がなく、誰もそれを実行しないため、名簿には活動していない人の名前が増えていきます。
• 再評価は任期の最終時のみ、公開済みの基準に照らして行います。過去の評判で判断することが、名簿を陳腐化させる原因です。
• 通知を行います。 3か月前なら十分、最低でも1か月前に、評価対象となる活動記録を添えて通知すれば、更新が突然知らされることはありません。
• 育児休業、病気、転職、燃え尽きなどのための休止を認めます。 人生の出来事を業務遂行上の失敗として扱うと、人々はそれを隠すようになります。
• 活動停止に関する条項を定めます（Nか月間、目に見える活動や連絡がない場合は更新対象外とする、または卒業生扱いにする）。また、行動規範違反の場合は、プログラムオーナー単独の判断ではなく、モデレーションプロセスで決定する即時退任の手段も用意します。
• 卒業生を正式なステータスとして扱い、単に削除するのはやめます。 肩書きには期間を付けて正確に記載し（「チャンピオン、2024-2026」など）、卒業生を低頻度のチャンネルに残し、次のコホートの推薦、メンタリング、応募書類の審査などの役割を提供します。あなたの会社に採用されることは成功です。記録を消すのではなく、卒業生扱いにします。
• プログラムを終了する場合は、 任期分の猶予をもって告知し、すでに約束した特典を守り、名簿ページをオンラインに残し、終了の理由を説明します。ページを削除すると、人々が履歴書に記載している活動実績まで消えてしまいます。

ステップ 6 - コンプライアンスを確認する

公開前に、以下の各項目に回答してください。法域固有の事項については、現地の最新規則に従い、義務や金銭が関わる場合は弁護士にも確認してください。最初の3項目は、候補者がそもそも参加できるかどうかを決めるものです。承認後ではなく、応募時に確認してください。

• 雇用主の承認：メンバーがベンダーの肩書きを持つために雇用主の承認を得る必要があるか、また、その雇用主があなたと競合しているかを確認します。
• 贈答品の上限：公務員、医療従事者、金融業界の従業員は、一定額を超える贈答品の受け取りを禁じられていることがよくあります。豪華な特典が、候補者を知らないうちに参加対象外にしてしまうことがあります。どのメンバーも、ペナルティなしで特典を辞退できるようにしてください。
• 年齢、税金、物流：公表されているプログラムでは、18歳以上を参加条件とするのが一般的です。高額な特典はメンバーに課税される場合があり、国境を越えて発送するノベルティの関税や手数料は、プログラム側が負担します。
• 推薦に関する開示：無償の製品、ノベルティ、チケット、先行アクセス、クレジットは、重要な利害関係にあたります。そのため、チャンピオンが公開する投稿では開示が必要です（米国ではFTCの推薦に関するガイドライン、16 CFR Part 255に基づき、英国とEUにも同様の制度があります）。開示文言と期待事項を提示し、各メンバーに推測させないでください。
• 無償労働：割り当てられたタスク、期限、ノルマがあるほど、プログラムは雇用に近づき、雇用区分に関するリスクも生じます。任意参加で、ノルマがなく、いつでも終了できる形は、より望ましい設計であると同時に、より安全な設計です。
• NDAの範囲：早期に実際に共有する情報に絞ります。包括的なNDAは、プログラムが生み出そうとしている公開の支持表明を抑制します。

ステップ 7 - 運営のリズムを決める

プログラムは一度きりの立ち上げではなく、継続的な取り組みです。リズムを定め、それぞれの節目の担当者を明確にします。

• 毎月または6週間ごとのコホート通話（参加は任意）。
• 四半期ごとのロードマップ説明会またはリリース前説明会。
• 四半期ごとのフィードバック要約をチャンピオンに 送り返し、意見によって何が変わったかを示します。
• 年に一度の応募受付期間。
• 四半期ごとに、目に見える形で感謝を伝える機会を設けます。

フィードバックのループを閉じましょう。これは最も省略されがちな節目であり、チャンピオンが最も気づくものです。「ご要望を受け、これをリリースしました。これは採用せず、その理由はこうです」と伝えることは、どんな特典よりも定着率の向上につながります。

記録方法は規模に見合ったものにします。招待制のグループなら共有ドキュメントで十分ですし、ポイント台帳が全体に広がる段階になって初めて、専用ポータルを用意します。Elasticはforgeベースの記録方法では対応しきれなくなり、独自の仕組みを構築する必要がありました。これは台帳型の仕組みに伴うコストとして捉え、想定外のことと考えないでください。記録する内容は、メンバーに見えるようにします。Elasticが透明性を重視する理由として挙げたのは、ゲーミフィケーションではなくガバナンスでした。「コミュニティチームが門番となるのではなく、コミュニティメンバー同士の会話を促したかったのです」（Elastic、Ully Sampaio）。

次に、ステップ 1〜7 で決めたことをすべて憲章にまとめ、メンバーに関わる部分を公開します。./references/charter-template.md の12の質問からなるテンプレートを使ってください。明文化されていないルールは、次のプログラム担当者に徹底されません。また、目的が文書化されていないプログラムは、見直されることも終了されることもありません。利用環境に永続メモリがある場合は、憲章で決めた内容もそこに保存し、後のセッションでユーザーに再度ヒアリングするのではなく、プログラムの型、期間、基準を引き継げるようにします。

ステップ 8 - 基準を設定し、コホートを測定する

四半期ごとにスコアカードを報告します。この表のしきい値はすべて自己設定です。チャンピオンプログラムでは、内部基準は非公開にしておきます。

公開されている成果の数値は、どちらも根拠としては弱いものです。

• Elastic：2019～2022年に参加者が13％増、貢献が38％増（プログラムを運営したチームによる一次情報で、ベースラインとの比較はありません）。
• Notion：アンバサダーが300人以上で、新規ユーザーの約4分の1がコミュニティからの紹介経由で訪れたと報告されています（Founding Marketing 第12章からの二次情報で、Notionによる確認はありません。これは極めて大規模な場合の北極星指標であり、目標ではありません）。

開始前に数値を明確に設定してください。基準がなければ、プログラムが終了することはありません。その後、プログラム開始後最初の2四半期の実績をもとに調整します。

シグナル	測定方法	初期基準
チャーターの完全性	12のチャーター質問への回答	公開開始前に12/12
四半期アクティブ率	四半期中に目に見える活動が1回以上あったチャンピオンの割合	≥ 60%
更新受諾率	任期更新の対象者のうち、次の任期を受諾したチャンピオンの割合	≥ 70%
チャンピオンへの対応速度	チャンピオンからの質問や依頼への回答時間の中央値	≤ 5営業日
反映されたフィードバック	四半期ごとにチャンピオンからの意見に基づくと追跡できる製品上の決定の数	≥ 1
候補者パイプライン	資格を満たしていると特定されているが、まだ受け入れられていない候補者の数	≥ コホート規模 × 0.5

採用を増やすのではなく、改善を重ねてください。アクティブ率が基準を下回る場合は、メンバーを増やす前に、特典、義務、またはコホート規模を見直します。活動しないメンバーが増えれば、数値はさらに悪化します。更新受諾率が低下した場合は、離脱者に退任時のインタビューを実施してください。理由はほとんどの場合、アクセスが失われたか、フィードバックが何にもつながらなかったことです。

アトリビューションについては、誠実でいてください。チャンピオンの影響は、サポートへの問い合わせの減少、依頼せずに作られたコンテンツ、自社が存在感を持たない場所での採用などに表れますが、どれも明確に帰属させることはできません。

傾向を追跡し、新規ユーザーに自社を知ったきっかけを尋ねてください。データが裏付けられない収益アトリビューションモデルは構築しないでください。コミュニティ全体の計測については、samber/developer-relations-skills@developer-community-health を参照してください。

引き渡すもの

次の2つの成果物をこの順番で作成し、次に進む前に各セクションをユーザーと確認してください。

1. チャーター - ./references/charter-template.md にある12の回答を、テンプレートの順序どおりに、それぞれ短い段落でまとめます。数値にはすべて、出典に基づくものか自己設定したものかを明記します。これが成果物です。それ以外はすべて、チャーターから派生するものです。
2. 公開ページ：
   • 目的。
   • 選定基準と反対シグナル。
   • 義務と禁止事項。
   • 特典。
   • 任期の日程、更新、活動がない場合のルール。
   • 卒業生としてのステータス。
   • 情報開示への期待。
   • 応募または推薦の方法。

チャーターのその他の内容は、すべて内部向けにします。

依頼があった場合に限り、次を追加します。デフォルトでは追加しません。

• 受付フォームと評価基準（./references/selection-rubric.md に基づくもの）。
• ライフサイクルに関するメッセージの草案。
• ステップ8の各行に合意済みのしきい値を記入した、最初の四半期スコアカード。

任期、退出条件、または基準を伴わない特典リストは、決して引き渡さないでください。これこそが、このスキルで防ぐべき失敗であり、注釈付きの例が ./references/charter-template.md にある反例です。責任者が明記されていないチャーターや、時間が予算化されていないチャーターはステップ1を満たしません。誰も運用できない文書を磨き上げるのではなく、そのことをはっきり伝えてください。

対象者別のバリエーション

• B2B／エンタープライズ製品：チャンピオンは通常、顧客企業の従業員であるため、雇用主の承認、贈答品の上限、機密保持が最も大きな制約になります。認定資格、カンファレンスへの出張、登壇枠、名前を明記した推薦など、社内での評価向上につながる特典は、消費者向けの報酬を上回る効果があります。用語は正確に使いましょう。これは公開コミュニティのアドボケイトであり、営業サイクルにおける社内の購買側チャンピオンではありません。
• 個人導入型の製品（趣味で使う人、学生、インディー開発者）：対象者の層はより広く、入れ替わりも多く、予算は個人持ちです。出張費の支援やクレジットには大きな価値があります。離脱率は高くなると想定し、期間を短くして、地域や言語のカバー範囲を重視しましょう。自社がスタッフを配置していない市場のチャンピオンは、最も大きな効果をもたらすメンバーになり得ます。
• ベンダー予算のないオープンソースプロジェクト：価値を持つのはグッズではなく、評価と責任です。評価はレビュー権限やメンテナーとしての役割へとつながります。チャンピオン層を貢献者の段階的な仕組みに隣接させるのではなく、そこにつなげるように設計し、その仕組みですでに定義されている名誉退任の道筋も残しましょう。samber/developer-relations-skills@oss-contributor-onboarding と samber/developer-relations-skills@oss-governance を参照してください。

失敗パターン

症状	原因	対処
名簿は増えるが、活動は増えない	期間、更新手続き、非活動時のルールがない	次のサイクルから期限付きの期間を導入し、活動していないメンバーを卒業生に移す
チャンピオンが3か月目以降に返信しなくなる	特典が最初のグッズに偏り、アクセスが実現しなかった	継続的なアクセス機会に置き換え、フィードバックを受けて何が変わったかを公開する
プログラムがマーケティング部門の出先機関のように見える	ノルマ、説明資料、承認済みメッセージがある	ノルマをなくし、公開の場での批判を認め、その旨を憲章に明記する
不採用に対して公の場で苦情が出る	基準が非公開、または一貫性なく適用されている	2つ以上の基準を公開し、具体的に何が不足しているかを伝えて返信する
チャンピオンが会社を代表して発言し、誤った情報を伝える	境界線が文書化されていない	禁止事項のリストを追加し、責めることなく公開の場で訂正する
選考でフォロワー数の多いアカウントを選んだが、活動しない	エンゲージメントではなくリーチを評価していた	フォロワー数よりも、サポートやメンタリングの実績を重視する
ある地域または言語が優勢になる	1つの貢献文化に合わせて基準を調整していた	Elastic がポイント表で行ったように、地域ごとに基準の重み付けを調整する
プログラム責任者が燃え尽きる	対応可能な時間では支えられない規模のコホートに、手厚く対応する設計	コホートを縮小するか、対応負荷の低い類型に移行する

参考資料

• ./references/program-archetypes.md：6つの公開プログラムに基づく、プログラムの類型比較と出典付きベンチマーク。
• ./references/charter-template.md：12項目のチャーターテンプレート、記入例、失敗するバージョンの反例。
• ./references/selection-rubric.md：評価基準、受付フォーム、却下・更新・オフボーディングのメッセージ例。
• samber/developer-relations-skills@developer-community-launch：コミュニティの立ち上げに関する上流の意思決定。
• samber/developer-relations-skills@developer-community-moderation：エスカレーションと行動規範の適用。
• samber/developer-relations-skills@developer-community-health：コミュニティ全体のエンゲージメントの測定。
• samber/developer-relations-skills@oss-contributor-onboarding：オープンソースでのコード貢献への参加経路。
• samber/developer-relations-skills@developer-meetup-program：地域ユーザーグループの運営。
• samber/developer-relations-skills@developer-feedback-loop：チャンピオンからの製品フィードバックを意思決定につなげる方法。