ガバナンスモジュール
正本文書: modules/ja/governance/README.md / 編集を提案
ガバナンスモジュールは、協力基盤および組織連盟の意思決定、権限管理、変更手続きを扱います。初期運用は 提案、意思決定、ガバナンスプロセス に接続します。
管理者や意思決定者は支配者ではなく、透明な手続きを維持するための責任を持つ参加者です。
このモジュールが解決する問題
Section titled “このモジュールが解決する問題”組織は成長すると、権力集中、不透明性、腐敗、形骸化を起こしやすくなります。
この設計では、透明で、離脱可能で、フォーク可能なガバナンスを設計します。
- 意思決定
- 権限管理
- 役割
- 投票
- 提案
- 意思決定
- フォーク手続き
- レビューと異議申し立て
- 個人の思想統制
- 強制参加
- 永続的な特権階級
- 密室での不可逆な意思決定
他モジュールとの関係
Section titled “他モジュールとの関係”ガバナンスは、すべての モジュール の変更手続きと接続します。
アイデンティティ から参加資格や役割を参照し、仲裁 と連携して異議申し立てや紛争を扱います。ただし、ガバナンスが生活支援や経済アクセスを恣意的に支配しないようにします。
初期設計メモ
Section titled “初期設計メモ”初期段階では、Issue、Pull Request、提案、意思決定を使って、軽量な意思決定プロセスを運用します。
貢献者が少ない間は速度を優先しつつ、重要な判断理由は必ず残す方針にします。
腐敗耐性の設計原則
Section titled “腐敗耐性の設計原則”このガバナンス設計では、善意や人格だけに依存しません。
腐敗、停滞、権限集中は、どの組織にも起こり得る前提で扱います。そのため、権限を持つ人を信じるだけでなく、権限の範囲、判断理由、変更履歴、異議申し立て、フォーク可能性を制度として残します。
1. 権限の明示
Section titled “1. 権限の明示”誰が何を決められるのかを文書化します。
管理者、メンテナー、レビュアー、提案者、参加者の役割は、できるだけ曖昧にしません。権限が曖昧なままだと、実質的な決定権が見えない場所へ移ります。
2. 判断理由の記録
Section titled “2. 判断理由の記録”重要な変更は、結論だけでなく理由を残します。
採用した案、却下した案、リスク、悪用ケース、未解決の問いを記録することで、後から見た参加者が判断を検証できます。
3. 権限の分離
Section titled “3. 権限の分離”1人または1組織が、提案、承認、実行、監査、異議申し立てのすべてを握らないようにします。
初期は人数が少ないため完全な分離は難しいですが、少なくとも重要な判断ではレビューの目を増やし、意思決定に理由を残します。
4. 異議申し立て
Section titled “4. 異議申し立て”参加者は、判断や運用に対して異議を出せる必要があります。
異議申し立ては、人格攻撃や混乱を増やすためではなく、見落とし、権限乱用、リスク、少数意見を検討するための手続きです。
5. 任期と見直し
Section titled “5. 任期と見直し”管理者やメンテナーの役割は、永続的な特権ではありません。
参加者が増えた段階で、任期、再任、交代、停止、権限縮小の仕組みを検討します。
6. 利益相反の開示
Section titled “6. 利益相反の開示”意思決定に個人的、経済的、組織的な利害が関係する場合は、可能な範囲で開示します。
利益相反があること自体を必ずしも禁止するのではなく、見えない利害によって判断が歪むことを防ぎます。
7. フォーク可能性の維持
Section titled “7. フォーク可能性の維持”合意できない場合や運営が腐敗・停滞した場合に、別の実装や組織へ分岐できる余地を保ちます。
フォーク可能性は脅しではなく、参加者が離脱可能性を実質的に持つための安全装置です。
8. 最小権限
Section titled “8. 最小権限”権限は、目的を達成するために必要な最小範囲にします。
便利だから、早いから、信頼できるからという理由だけで権限を増やし続けると、後から腐敗耐性を取り戻すのが難しくなります。
9. 公開可能な範囲の透明性
Section titled “9. 公開可能な範囲の透明性”意思決定、会計、権限、変更履歴は、可能な限り公開・検証可能にします。
ただし、透明性はプライバシーや安全と衝突する場合があります。その場合は、何を公開し、何を保護し、誰が確認できるのかを分けて設計します。
10. 小さく試して記録する
Section titled “10. 小さく試して記録する”大きな制度を一度に作らず、最小実行可能制度として小さく試します。
うまくいったことだけでなく、失敗、反対意見、悪用可能性も記録し、次の設計へ接続します。
初期ガバナンスプロセス
Section titled “初期ガバナンスプロセス”初期段階では、次の流れを基本とします。
- 小さな修正はPull Requestで提案する
- 重要な変更はIssueで背景を共有する
- 設計判断が必要な場合は提案を書く
- 採用・却下・保留の理由をレビューで残す
- 重要な判断は意思決定として記録する
- 運用上の問題はProblem Issueとして扱う
- 翻訳や用語の揺れは翻訳 Issueとして扱う
未解決の問い
Section titled “未解決の問い”- 意思決定速度と透明性の両立
- 専門性と民主性の両立
- 腐敗した運営をどう検出するか
- 管理者権限の移譲や停止をどう扱うか
- 利益相反の開示範囲をどう決めるか
- フォーク時に用語集や意思決定ログをどう引き継ぐか
- 参加者が増えたときの投票権やレビュー権限をどう設計するか