developer-community-moderation

開発者コミュニティのモデレーション

小規模で疲弊したチームでも実際に運用できる行動規範を作成する、コミュニティ運営の責任者です。成果物は、公開する行動規範と、それを実効性のあるものにするための非公開の運用手順書です。

以下のすべてを貫くルールは、「執行されない（または執行できない）行動規範は、行動規範がないよりも悪い」（opensource.guide）ということです。ですから、文書だけを公開してはいけません。それを実効性のあるものにするプロセス、人員、プラットフォームの制御機能も併せて用意してください。

このルールが最も厳しく問われるのは、執行に関する唯一の実務者向けの書籍形式のハンドブックである Valerie Aurora と Mary Gardiner の How to Respond to Code of Conduct Reports（Frame Shift Consulting、2019年）が示す点です。コミュニティは、その中で「最も権力のある人々にも適用されない」行動規範を採用してはなりません。創設者が適用対象外となる行動規範を公開してはいけません。

まず依頼内容を見極める

聞き取りを始める前に、目の前の課題が次の4つのどれに当たるかを判断してください。それぞれ、最初に行うべきことが異なります。

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

1. 進行中のインシデント - 誰かが今まさに被害を受けています。文書の作成は後回しにします。references/incident-response-runbook.md に進み、状況を安定させてください（全員の安全を確認し、証拠を保全し、被害を止めるプラットフォームの制御機能を使い、報告者に応答します）。その後、事案から明らかになった点を踏まえてポリシーを作成します。
2. 行動規範がまだない - 以下のワークフローを最初から実施します。
3. 行動規範はあるが、執行できない - 公開ゲートに照らして監査し、不備のある箇所だけを修正します。コミュニティにすでに知られている文書を書き直してはいけません。
4. モデレーションは行われているが、仕組みがない - チームがその場しのぎで対応しています。ステップ6（チャネル）とステップ7（チーム）から始め、これまでの判断に基づいて対応段階を作成します。

インタビュー

一度に質問するのは1つだけにし、可能な場合は選択肢を提示してください。ポリシーを書ける状態になったら、すぐに質問を終えてください。質問2と3によって、ポリシーの草案を作成できるかどうか、また何を草案にできるかが決まります。何かを草案する前に、両方の回答を得てください。

1. どの場を対象にしますか。リポジトリとイシュー、チャット、フォーラム、メーリングリスト、プロジェクトのソーシャルアカウント、対面またはオンラインのイベントですか？
2. コミュニティを支える組織はありますか。企業、財団、財政的な受け入れ先、またはボランティアだけでしょうか？モデレーターの意見がまとまらない場合や、決定に異議が申し立てられた場合、モデレーターの上位に位置するのはどの組織ですか？
3. このポリシーは創設者、最上位のメンテナー、または最大の顧客にも適用されますか？適用されない場合は、今ここでそう明言してください。
4. 現在、誰がモデレーションを担当していますか。また、対応できる労力の上限はどのくらいですか。何人が担当し、それぞれ週に何時間かけられますか。また、プラットフォームの設定を変更したり、費用を使ったりする権限を持つ人はいますか？
5. いつまでに導入する必要がありますか。現在進行中の事案、ローンチ、イベント、理事会または財団の期限などはありますか？
6. この事案だけを解決したいですか。それとも、作成に携わった人が去った後も機能し続ける仕組みが必要ですか？
7. メンバーはおよそ何人で、メッセージ、イシュー、新規参加者は毎日どのくらいありますか？
8. 既存の行動規範や一連のルールはありますか？メンバーが今でも覚えているほど、対応がまずかったインシデントはありましたか？
9. 現在、実際によく起きている問題は何ですか。ハラスメント、自己宣伝のスパム、質の低い投稿やAI生成投稿の大量流入、話題の脱線、敵対的な技術的議論、外部からのブリゲーディングですか？
10. メンバーは主に仕事でこれを使う雇用されている開発者ですか。それとも、自分の時間を使う個人ですか？未成年者、契約を結んでいる顧客、競合他社は参加していますか？
11. 制約について教えてください。対応が必要な言語とタイムゾーン、記録に適用されるプライバシー法、匿名での報告が必要かどうかです。

ユーザーが質問2に回答できない場合、その欠落自体が調査結果です。ルールを1つでも書く前に、その点を明示し、それを前提に設計してください。質問3の答えが「いいえ」の場合は、例外をなくすか、行動規範の強制に関する文言を含まないコミュニティガイドラインを公開するかが、誠実な選択肢だと率直に伝え、どちらにするかユーザーに選んでもらってください。

質問4、5、6への回答に応じて、以下の優先順位付きメニューの順位を変更し、どの項目をどう動かしたかを伝えてください。

• 進行中の事案がある、または期限が厳しい場合は、今日すぐに被害を止める対応、つまりプラットフォームの制御、コンテンツの削除、報告窓口の優先順位を上げ、効果が後から現れる構造的な取り組みの優先順位を下げます。
• 「自分たちが去った後も機能し続ける仕組みがほしい」という回答の場合は、体系的な改善と、実績に基づく信頼レベルの優先順位を上げます。これらは単一の事案では労力に見合わず順位が下がりますが、1年を通して見れば効果を発揮します。
• 労力の上限が低い場合は、項目を下位に回すのではなく、段階や成果物を完全に削り、チームが実際に実行できる内容だけに公開する段階表を短縮します（項目11「公開の条件」）。

ワークフロー

1. 適用範囲と管轄を定めます。 対象となる場と人々のカテゴリーを列挙し、場外での行為について明確な方針を選びます。コミュニティが規則を適用できるのは、自らが管理する場の内部だけですが、場外での証拠をもとに、その場の内部で対応することはできます（プロジェクト、財団、イベント部門など複数の組織がある場合は、どの報告をどの組織が扱うのかを明記します）。

2. 基本文書を選び、内容を調整します。 独自に文章を考えるのではなく、確立された公開行動規範を土台にします。執行に関する節は、このコミュニティが実際に行う手順を説明するよう書き換え、役割名もここで使われている名称に変更します。参照するバージョンを確認してください。Contributor Covenant 2.1 と 3.0 では節の名称が変わっています。references/code-of-conduct-outline.md を参照してください。

3. 実際の事例をもとに基準を書きます。 抽象的な美徳の羅列を、コミュニティが実際に経験した行動（被害を与える側と受ける側の両方）に置き換えます。モデレーターが指し示せる明確な基準が必要です。基準の一覧には「善意を前提とする」ことを含めないでください。そうすると、被害を与えた人が会話を自分の意図へとすり替える余地を与えてしまいます（Frame Shift Consulting、2022年）。

4. 段階的な対応を設計します。 Contributor Covenant の公開されている両バージョンで採用されている4段階は、訂正／警告、警告／活動制限、期間を明示した一時的な停止、永久追放です。これに加えて、実際に多くの事例で必要となる、段階に当てはまらない対応（違反なしとの判断、コンテンツの削除、役割の剥奪、メンタリング、システム上の改善）も用意します。各段階の発動条件と結果を公開し、その段階で可能な最大限の対応ではなく、コミュニティを守るために必要な最小限の対応を選びます。段階は門であり、選択肢のメニューではありません。「段階は門であり、結果はメニュー」を参照してください。

5. 何を公にするか決めます。 通知は非公開で行い、対応は見える形で行います。この2つのルールは、それぞれ異なるものを定めています。本人には非公開の通知で決定を伝え、違反を目撃した人々にはコミュニティが対応したことがわかるようにし、集計統計は定期的に公表します。対応が見えなければ、対応がなかったと受け取られます。Aurora と Gardiner の事例研究では、ハラスメントの被害者が、何も起きなかったと思い込んでコミュニティを離れています。

6. 報告窓口を整えます。 誰が報告を読むのかがわかれば、人々はより多く報告するようになります。

   • 主となる非公開の窓口
   • 主な受信担当者について報告するための別の窓口
   • 実現可能であれば匿名での報告方法
   • 守ることのできる、報告への受領確認の目標時間
   • 報復を禁止する規則
   • 報告を受け取る担当者の氏名

7. チームに人員を配置します。 日常的に対応するモデレーターと、制裁を決定する組織を分けます。決定を行う組織は、構成員の3分の1が不在でも機能する規模にし、次の事項を定めます。

   • 段階別の権限
   • 忌避の義務
   • 1人あたりの担当件数の上限
   • コミュニティが実際に活動している時間帯と言語を網羅する体制
   • 任期と、単一の雇用主から選出できる役職数の上限

   references/platform-controls.md を参照してください。

8. 対応手順書を作成します。 内部用として非公開にします。チームが独自の手順を守ったかどうかをめぐる争いを避けるため、内部の手順書ではなく「報告後の流れ」の概要を公開します。次の事項を扱います。

   • 期限の計時、受付、証拠の保全
   • 忌避の段階、聞き取りの順序、決定のルール
   • 通知のテンプレート、事案記録のスキーマ、記録の保持期間

   references/incident-response-runbook.md を参照してください。

9. プラットフォームの制御機能を事前に設定します。 信頼レベルまたは実績に応じた役割に相当する仕組み、すぐに有効化できる投稿頻度や交流の制限、自動フィルター、参加条件、可逆性の高い順に並べたコンテンツへの対応を用意します。大量投稿による攻撃が頻発する問題であれば、その対策も含めます。各機能を有効にする速さではなく、モデレーターの作業1時間あたりに防げる流入量を基準に、制御機能を順位付けします。

   • 効率性：レート制限とインタラクション制限 ＞ 参加ゲート ＞ 信頼レベルの獲得 ＞ 自動フィルター ＞ 個別の禁止措置 ＞ すべての項目の手動トリアージ

   • 労力：レート制限 == 自動フィルター（設定を一度変更すれば、その後は自動で動作）＞ 参加ゲート（設定を一度変更するだけですが、参加率の低下というコストが継続して発生）＞ 信頼レベルの獲得（設計に1週間かかり、その後は自動で動作）＞ 個別の禁止措置（1件あたり数分かかり、攻撃者に合わせて増え続けるため、いつまでも終わらない）＞ 手動トリアージ（継続的な作業となり、コミュニティの成長に伴って増えていく）

   • 価値：信頼レベルの獲得（今後参加するすべてのメンバーの基準を恒久的に引き上げる）＞ レート制限と参加ゲート（流入を根本から抑える）＞ 自動フィルター（既知のパターンだけを検出し、新しいパターンは決して検出しない）＞ 個別の禁止措置（1人を排除しても、その人は新しいアカウントで戻ってくる）＞ 手動トリアージ（各項目を解決するだけで、何も未然に防がない）

   • コンプライアンスコスト：レート制限 == 自動フィルター == 信頼レベル（プラットフォーム標準の機能で、新たな情報を収集しない）＞ 参加ゲート（メールアドレスや本人確認で個人データを収集するため、プライバシーに関する通知が必要になる場合があります。未成年者が参加する可能性が十分にある場合は、特に注意が必要です）＞ 個別の禁止措置（行為に関する判断であるため、事例記録と異議申し立ての手順が必要）

   • レート制限と自動フィルターは、どちらも一度設定を変更すればメンテナンスが不要なため、必要な労力は同じです。

   • コンプライアンスコストが同じになる3つの対策は、いずれもプラットフォームがすでに保存している情報以外は保存しないためです。

   • 効率性を重視すると、最も価値が高く、設計に1週間かかる信頼レベルの獲得は後回しになり、荒らし行為の最中にいるチームは決して導入しません。モデレーターの負荷が合意した上限を超えた時点、またはコミュニティが2度目の大量荒らしを乗り越えた時点で、すぐに導入しましょう。

   • 場所によって利用できない対策は、今後の課題として挙げるのではなく、対策一覧から削除しましょう。借りている公開スペースには、レート制限も信頼レベルも禁止措置もありません。誠実な対策一覧に残るのは2項目です。ホストに報告すること、そして会話を自分が管理する場所に移すことです。

10. 公開し、告知し、リハーサルを行います。 文書を公開し、法的通知のようにではなく、その理由とともに告知します。また、最初の実際の事例が発生する前に、簡単な事例と、モデレーターが対象となる事例の2つを使って、チームで手順を確認します。新しいメンバーがチームに加わるたびに、リハーサルを繰り返します。

11. 見直しのサイクルを設定します。

    • 固定した間隔で集計統計を確認します。
    • 年1回、匿名化した傾向レポートを作成します。
    • チームが判断に迷った事例があれば、対応の段階を見直します。

12. 決定事項を記録します。 環境に永続メモリがある場合は、このコミュニティでの後続の作業で同じ議論を繰り返さないよう、以下を記録します。

    • 適用範囲に関する方針
    • 対応の段階
    • エスカレーション先
    • 対応時間の目標

はしごはゲートであり、対応策はメニューです

深刻な行動規範違反――ハラスメント、脅迫、執拗な標的化など、誰かが今まさに被害を受けている状況――はゲートです。違反の内容によって段階が決まり、比率に決定権はありません。禁止措置は「コストが高い」わけではなく、警告は「効率的」なわけでもありません。モデレーターの作業時間は、被害を受けた人が支払う通貨ではありません。

労力を理由に、深刻度で決まる段階を引き下げてはなりません。また、検討すべき選択肢として、このはしごをユーザーに提示してはなりません。

モデレーターが、いずれも案件を収束させられる対応策の中から本当に選べる場合に限り、優先順位を付けます。話題からの逸脱、自己宣伝、敵対的な技術議論、初回の不適切な行為、悪意のない大量投稿などが該当します。この場合、はしご以外の対応策は、同じ限られた資源――モデレーターの作業時間と、チームへの信頼をコミュニティが保ち続ける意志――を奪い合います。次のように、費やした資源あたりの再発防止効果で順位を付けます。

• 効率：システム的な修正 > コンテンツの削除 > 権限の剥奪 > 適用されるはずだった対応についての公式声明 > メンタリング
• 労力：コンテンツの削除 == 公式声明（数分、モデレーター1人、調整不要） > システム的な修正（ルール、テンプレート、またはチャンネル変更を1つ設計するのに1日） > 権限の剥奪（話し合いとガバナンス上の決定が必要） > メンタリング（数週間にわたる継続的な取り組みで、それでも失敗することがあります）
• 価値：システム的な修正（問題の種類そのものをなくすため、それ以降に防げるすべての事例に追加コストはかかりません） > 権限の剥奪（有害な行動を可能にしていた権限をなくします） > メンタリング（心から善意を持つ貢献者をコミュニティに留めます――まれですが、実際にあります） > コンテンツの削除（目に見える事例を解決するだけで、構造的な問題は残ります） > 公式声明（基準が守られたことをコミュニティに伝えます）
• 関係へのコスト：コンテンツの削除 == システム的な修正（どちらも個人を名指しせず、関係を損ないません） > 公式声明（誰も名指しせずに基準を示します） > メンタリング（モデレーターの善意と作業時間、そしてメンター対象者の時間を使います） > 権限の剥奪（その人の立場を恒久的に変え、通常はその人を失うコストをコミュニティに負わせます）
• コンプライアンス上のコスト：システム的な修正 == コンテンツの削除（個人データも、個人に関する判断も、異議申し立てもありません） > 公式声明（事案に関する事実の主張となるため、特定可能な情報を含める場合は法務レビューが必要です） > メンタリング（コミュニティが履行を求められる取り組みです） > 権限の剥奪（行動に関する決定です。事案記録、異議申し立ての権利、そして企業運営のコミュニティでは人事および労働法との連携が必要です）

同順位は2つあり、どちらも実質的なものです。

• コンテンツの削除と公式声明の労力は同じです。どちらも1人が数分で書き上げ、誰にも相談する必要がありません。
• コンテンツの削除とシステム的な修正が関係に与えるコストは同じです。どちらも誰も名指ししません。疲弊したチームがまず頼るべきなのは、まさにこの2つです。

この順位付けでは、関係への投資が最も大きく、効果が出るまでに最も時間のかかるメンタリングの優先度が下がります。被害が発生した場合、メンタリングを制裁の代わりにしてはなりません。それでも、次の3つの条件がすべてそろう場合は、メンタリングを優先してください。

• その人がプロジェクトに不可欠である
• 行動の問題が価値観のずれではなく、スキル不足によるものである
• 特定のモデレーターが、必要な時間を割く意思を示している

この順位付けは基本方針であり、絶対的なルールではありません。インタビューですでに分かっていることに照らして、順位を調整してください。

• ガバナンス組織のないボランティアプロジェクトでは、権限の剥奪をまったく実行できないため、選択肢に含めるべきではありません。
• よくある問題が投稿の大量流入であるコミュニティでは、システム的な修正だけでほぼすべてが解決し、それ以外の対応策では何も解決しません。
• 人事部門との連携が可能な企業運営のコミュニティでは、財団なら四半期かかる対応を、権限の剥奪によって1週間で実行できます。

成果物

• CODE_OF_CONDUCT.md - リポジトリのルート、またはプラットフォームのルール表示領域で公開します。
• 行動規範への対応手順書 - 非公開のチーム専用文書で、手順書テンプレートに従います。
• 「報告するとどうなるか」の公開ページ - 報告者向けに、対応手順書の概要をまとめます。
• モデレーター名簿と合意書 - 誰がどの権限を持つか、担当範囲、負荷の上限、忌避と守秘義務を記載します。
• プラットフォーム管理シート - どの管理機能がどの状況に対応するか、誰が適用できるかを記載します。
• 告知投稿 - 何が変わったか、その理由、報告先、今後の流れを伝えます。

各成果物をセクションごとに提示し、次に進む前にユーザーの合意を得てください。実行するつもりのない段階的な対応策は、ないよりも悪いものです。それが明らかになるのは、読み返したときだけです。

チームが一度に6つすべてを作成できない場合は、次の順番で作成してください。最短の文書からではなく、作成時間あたりの報告者保護の効果を基準にします。

• 効率：報告経路（担当者名と代替経路を明記） > 対応段階 > CODE_OF_CONDUCT.md > 手順書 > プラットフォーム管理シート > モデレーター名簿と合意書 > 告知投稿
• 作業量：報告経路 == 告知投稿（各1時間） > 対応段階（実際の過去の事例を使い、チームで1セッション） > CODE_OF_CONDUCT.md（基本文書を調整してから、基準について話し合う） > プラットフォーム管理シート（設定を一つずつ確認し、それぞれの機能を記録するのに1日） > 手順書（ここでは最長の文書で、草案作成とチームレビューに1、2日かかり、事例が発生するまで誰も読まない文書です） > モデレーター名簿と合意書（担当者の同意が必要なため、数週間）
• 価値：報告経路（報告が誰かに届くようになるまでは、リストのほかの項目は何の役にも立ちません） > 対応段階（各事例を議論ではなく、規定に照らして判断できるようにします） > 手順書（対応上もっとも多い誤りである遅延を防ぎます） > CODE_OF_CONDUCT.md（ほかの文書が実現する公開の約束です） > モデレーター名簿（Publish ゲートの項目11を満たせるかどうかを左右します） > プラットフォーム管理シート > 告知投稿

これは作成の順番であり、公開の順番ではありません。Publish ゲートを通過するには、公開前に11項目すべてが必要です。告知投稿が効率の面で最後なのは、告知する内容がなければ価値がなく、実際の作成にほとんど手間がかからないためです。公開するのと同じ1時間で作成してください。

呼び出し例

おおむね次のような依頼が想定されます。それぞれ、異なる段階から始まります。

• 「オープンソースプロジェクトのチャットサーバーに400人いて、雰囲気が険悪になってきました。行動規範を書いてください。」 → 作業2、全ワークフロー、チャット系プラットフォームの管理機能。
• 「メンテナーの1人について、メンテナー用のエイリアス宛てに報告がありました。どうすればよいですか？」 → 作業1、まず手順書を作成し、その後、気まずい状況を招いた代替報告経路の不足を解消します。
• 「2年前にContributor Covenantをコピーして以来、一度も使っていません。内容は問題ありませんか？」 → 作業3、Publish ゲートに照らして監査し、各項目の合否を報告し、不合格の項目だけを修正します。
• 「課題管理ツールに、AIが作成したバグ報告が大量に押し寄せています。」 → 作業4。ただし、行動に対する段階的な対応ではなく、投稿量を抑える対策に振り分けます。エスカレーションの対象となる悪意がない場合がほとんどです。

全工程を実施する場合に期待される出力形式 - 最後の2セクションは、公開する文書ではなく、ユーザー向けのレビュー結果です。

## Scope and jurisdiction
Surfaces · people covered · off-platform stance · which body handles what

## Enforcement ladder
Table: rung | trigger | consequence | who may apply it
Non-ladder outcomes available

## Reporting
Primary channel (named recipients) · alternate path · anonymous option
· acknowledgment target · no-retaliation clause

## Response team
Roster · powers per tier · coverage map · recusal rules · escalation body

## Runbook summary
Deadline clock · intake · investigation · decision rule · notification · records

## Platform controls
Control → situation → who applies it, per surface

## Publish gate
Each of the 11 items: pass / fail / how to fix

## Open questions for the user

回答がコミュニティの種類によって変わる点

適用範囲、段階の構成、報告窓口、記録、プラットフォームの制御は、コミュニティの種類が変わってもそのまま適用できます。異なるのは4つの点です。

• 企業が運営する、プロフェッショナル向けのコミュニティ。 メンバーを特定でき、多くの場合、顧客やパートナーの従業員です。インシデントが発生する前に、人事部門と法務部門との連絡窓口を明確にし、誰が公に発言できるかを決め、対応チームに加わるベンダーの従業員全員について、恒常的な利害の対立が生じることを想定しておきます。料金を支払っている顧客の従業員に制裁を科すことは、行動規範上の判断であると同時に、商業上の判断でもあります。誰がその決定を下すか、事前に合意しておきます。
• 企業が運営する、個人開発者向けのコミュニティ。 匿名性が高く、使い捨てアカウントや荒らしが多くなります。本人確認に基づく対策よりも、参加時のゲートやレート制限を重視し、未成年者が参加している可能性が十分にあるか確認します。その場合、モデレーションとデータの取り扱いの両方が変わります。
• ボランティアが運営するオープンソースプロジェクト。 人事部門も予算もありません。それでも、チームより上位のエスカレーション先を明確にします。財団、資金管理団体、または上級メンテナーによる書面化されたグループなどです。上位のエスカレーション先がないチームには、行き詰まった案件を解決する手段がありません。
• 借りている公開スペース。 自分たちが所有していないプラットフォームでは、ホスト側のルールが自分たちのルールより優先され、誰かを禁止することもできません。現実的な手段は、ホストに報告することと、自分たちが管理する場所へ会話を移すことです。

事態を悪化させる対応

最初の案では、思いやりがあるように聞こえるため、次の対応が選ばれがちです。Aurora と Gardiner は、1つ目、3つ目、4つ目、5つ目を、被害を止められない、またはさらに悪化させる対応として挙げています。この4つは、対応段階にも対応手順書にも含めないでください。

• 謝罪を強制すること、または被害を受けた人に謝罪を受け入れるよう求めること。強制された謝罪によって、読み取る価値のある唯一の兆候、つまり本人が促されなくても謝罪したかどうかが失われます。Contributor Covenant 2.1 の最初の段階には「公開の場で謝罪を求めることがある」とあり、これはオープンソースで最も広く採用されている基本文書（opensource.guide によると40,000以上のプロジェクト）に引き継がれていますが、3.0では削除されています。
• 決定の代わりに、または双方の同意なしに仲裁すること。 「誰かがここで人々に害を与えている」という状況を「この2人はそりが合わない」と捉えることで、チームはひそかに対応する責任を免れます。また、誰も同意していない仲裁自体が害になります。Django のマニュアルに従い、当事者間の話し合いを仲介することは認められていますが、チームが独自に判断を下して記録した後の追加対応としてのみ、また全員のインフォームド・コンセントがある場合に限ります。決定の代わりにしてはならず、被害を受けた人への対応として提案してもいけません。
• 報告された人に、報告者を避けることを条件としてコミュニティに残すこと。 脅威ではないのであれば、その条件は不要です。脅威であるなら、コミュニティも安全ではありません。
• 被害を受けた人に、どのような結果にするか選ばせること。 対応を公表する前に、提案する対応をその人に見せてください。そうすれば、見落としていた事実や報復のリスクに気づけます。結果を決めさせると、その人が結果について責任を問われるおそれがあります。
• アカウントが削除された、または本人が特定できないことを理由に、何もしないこと。 どのような対応になったかを公に述べてください。

これらに沿った通知文面（悪い例と良い例を対比した例を含む）については、references/incident-response-runbook.md を参照してください。

公開前のゲート

11項目すべてを満たすまで公開しないでください。項目1はAuroraとGardinerのルールで、残りの10項目はそれぞれ、文書化された失敗要因を示しています。この11項目はここでまとめたものであり、公開済みのチェックリストではありません。

1. 規約は、書面上だけでなく実際に、コミュニティで最も力を持つ人々にも適用されます。
2. 適用範囲の条項で、対象となる場所や人々を明示し、プラットフォーム外での行為について立場を示します。
3. 段階的な措置の各段階に、発動条件と結果の両方を定めます。
4. 期間を限定した制裁には、その期間を明記します。
5. 非公開の報告窓口があり、担当するグループを明示します。
6. 主な報告先について報告するための、別の窓口があります。
7. 受領確認の目標は、現在の件数に対してチームが達成できる数値です。
8. 報復を禁止する声明を公開します。
9. モデレーションチームより上位のエスカレーション先を明示します。
10. 案件記録の保管場所、アクセスできる人の一覧、保存ルールを文書化します。
11. 段階的な措置で約束するすべての対応を、少なくとも2人が実行できます。

4段階の措置を定めていても、担当者が疲弊した1人しかおらず、項目11を満たさないなら、その措置は実行できない絵空事です。コミュニティが破られるのを目の当たりにする約束を公開するのではなく、1人で実行できる内容まで縮小し、そのことを明記してください。

運用指標

5つの指標を追跡し、統計レポートと同じ頻度で見直してください。この5つはここで選定したものであり、公開済みの標準ではありません。

• 目標時間内の受領確認：公開した時間内に受領確認を行った報告の割合です。
• 結果を記録した案件：すべての案件に結果が記録されていないなら、段階的な措置が記憶頼みで運用されています。
• 報告から解決までの所要時間の中央値：報告者が実感する時間であり、次の人がわざわざ報告するかどうかを左右する指標です。
• モデレーターの負荷：合意した上限に対する、1人あたり週ごとの対応件数と案件数です。人員が変わらないまま負荷が増え続ければ、次の辞任が予測されます。
• 違反の再発率：制裁を受けたメンバーが再び違反する割合です。率がほぼゼロでも、段階的な措置が機能している可能性もあれば、もう誰も報告しなくなった可能性もあります。報告件数と併せて確認し、単独では判断しないでください。

大量投稿型の問題では、投稿率と有効な投稿の割合も加えてください。この場合の目標は、禁止措置を増やすことではなく、流入率を下げることです。

数値の出所。 公開されていて、引用できる受領確認の期限があります。Djangoは1営業日、CNCFは3営業日、AuroraとGardinerの実例では受領確認まで24時間、判断まで10営業日です。これらの期限に対する遵守率は別の話です。受領確認の目標達成率95％、結果が記録された案件の割合100％を、ここで定める初期基準として扱ってください。設計時に目指す妥当な基準であり、業界標準ではありません。

数値をユーザーに提示する際は、どれがどちらなのかを明確にし、チーム独自の最初の四半期のデータを基に初期基準を再調整してください。references/published-findings.mdには、このスキルで出典を示したすべての数値について、その出典と限界を記載しています。

失敗パターン

症状	対処
行動規範はあるが、これまで一度も適用されたことがない	まずチームと対応手順書を整え、実際の手順を定めてから再公開します
創設者や主要メンテナーにルールが明らかに適用されていない	いったん停止します。例外をなくすか、行動規範としての位置づけを取り下げます。選択的に適用される規範は、ないよりも悪いものです
報告先のメールアドレスが、報告対象者本人のものしかない	代替の報告経路を追加し、主な報告先と同じ段落に掲載します
事案の発生後に制裁を考案する	次の事案が起きる前に制裁の段階を公開します。事後にルールを整えると、事案がガバナンスの危機に変わります
すべてがDMで処理され、コミュニティには何も知らされない	通知の内容は非公開にしつつ、対応した事実を公表し、定期的に統計をまとめて公開します
類似した事案で異なる結果になる	事案の記録を残し、判断前に過去の違反を確認します
すべての事案で審議が行き詰まる	事前に判断ルールと判断期限を定めます。執行上の最大の誤りは、急ぎすぎることではなく、遅れすぎることです（Aurora & Gardiner）
チームがスパムや質の低い投稿に圧倒されている	個別の禁止措置から、レート制限、参加条件、投稿要件へ切り替えます
すべてを一人のモデレーターが担当している	当番をローテーションし、週あたりの負荷に上限を設け、コミュニティ内で活動を確認できた協力者を勧誘します
メッセージが削除され、チャットの証拠が消えてしまった	削除前にアーカイブします。事案の記録には、チャットに残らない証拠も保存します
停止措置が、定めた終了日を過ぎても続いている	制裁を適用したその日に、復帰の予定を設定します
事案に関してチームメンバー全員に利害の対立がある	指定された機関にエスカレーションします。そのような機関がない場合は、まずその不足を解消します
チームが公開済みの手順を破ったとメンバーが主張している	報告者向けの要約を公開します。詳細な手引きは内部向けとし、必要に応じて改訂できるようにします

参考資料

• references/code-of-conduct-outline.md - 文書の骨子、2.1と3.0のセクション対応表、適用範囲の表現、段階表、弱い例と実用的な例のペア
• references/incident-response-runbook.md - 期限の起点、報告受付チェックリスト、忌避の段階、判断ルール、通知テンプレートとその悪い例、事例記録のスキーマ、透明性レポート
• references/platform-controls.md - 場所の分類ごとの管理策、獲得型の信頼レベル、レート制限、量的攻撃への防御、モデレーター名簿の設計
• references/published-findings.md - 出典と限界を記した、出典のあるすべての数値と主張

スキル間の参考資料：

• samber/developer-relations-skills@developer-community-health - コミュニティの健全性の測定
• samber/developer-relations-skills@oss-issue-triage - 技術的な課題のワークフロー（ラベル、テンプレート、古い課題への対応方針）
• samber/developer-relations-skills@oss-governance - プロジェクトの意思決定権と後継者選定
• samber/developer-relations-skills@oss-contributor-onboarding - 初回貢献までの道筋
• samber/dev-event-organizer-skills@event-code-of-conduct - 単一イベントの行動規範と現地での対応向け。このスキルは、複数の活動場所の一つとして開催するイベントも含め、継続的なコミュニティを対象とします