Skip to content
Published on

バス係数は知っている人の数ではなく、決められる人の数だ

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — リポジトリはそのままなのにリーダーシップが消えた

2026年8月7日、NixOS DiscourseにNixpkgsのコアチームが解散するという記事が上がりました。qylissが@alyssaisと@emilazyに代わって書いたもので、同じ日にNixOS/orgリポジトリのPR #277がマージされ、@NixOS/nixpkgs-coreチームの定義そのものが削除されました。

Nixpkgsは10万個を超えるパッケージを収めたリポジトリです。私が2026年8月9日にGitHub APIで直接数えてみたところ、直近2週間ほど(2026年7月24日以降)にマージされたPRは4,468件でした。

curl -s "https://api.github.com/search/issues?q=repo:NixOS/nixpkgs+is:pr+is:merged+merged:>=2026-07-24&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"
# 4468

ところがこのリポジトリの委任された技術リーダーシップを担っていたチームの人員は二人でした。その二人が退きながら、発表文はこう書きます。私たちの管轄に属していた事案は、現在直接の持ち主がいない状態で残る、と。

この記事はNixを使えとか使うなという話ではありません。あなたが依存しているプロジェクトのリスクをどこで測るべきかについての話です。

バス係数は知識ではなく権限の数だ

バス係数は普通こう説明されます。「中核の人員が何人かバスにはねられたらプロジェクトが止まるか。」そしてたいてい知識の問題として解釈されます。文書が足りない、特定のモジュールを一人しか知らない、というふうに。

Nixpkgsの事例が見せているのは別の軸です。Nixpkgsは知識が集中したプロジェクトではありません。貢献者が数千人いてコミッターも増え続けています。コアチームが10か月のあいだにやったことのひとつが、まさにコミッター委任手続きを改革し新規コミッター19人をオンボーディングしたことでした。

それでもチームの二人が抜けると空白が生じました。なぜならその二人が持っていたのはコードの知識ではなく決定権限だったからです。発表文が引用する憲法上の委任事項は、Nixpkgsに関わる限りでのプロジェクトの方向性、意思決定、NixOS財団理事会との調整、チームの創設と管理です。

コードを書く人はたくさんいます。「この方向へ行く」と言う資格のある人は二人でした。この二つはまったく違う数であり、私たちは普通、前者の数しか数えません。

発表文が実際に言っていること

解釈を乗せる前に、原文の事実関係から正確に移します。

  • チームは10か月間活動しました。
  • 成果として、コミッター委任手続きの改革と新規コミッター19人のオンボーディング、マージボットの拡張によるメンテナ権限の強化、GitHubとの関係の再構築およびEnterprise Cloud後援の確保、セキュリティ勧告GHSA-67f2-674w-6g63のトリアージ支援、初期の自動化・AIポリシーの策定を挙げます。
  • 退く直接の理由は健康です。原文は、積極的な技術貢献と両立できる軽い役割だとは分からず、2週間前に退くことが自分たちの健康のために必要だという結論に至った、と書きます。
  • 新規人員の募集については「実際に応募した人は一人」であり、アウトリーチへの反応もまちまちだったと明かします。
  • 運営委員会については、憲法が想定した委任に対する本能が制度的に欠如している一方で、そのレベルの個別決定を自ら処理できるほど関与しても凝集してもいない、と診断します。その結果が下位チームへの不必要なマイクロマネジメントと慢性的な意思疎通の不足だというのです。
  • 最後に「この決定はどれかひとつの出来事のためではなく、長く続いたパターンの帰結だ」と明記します。

ここまでが原文です。Nixpkgs自体が止まるとか開発が中断するという話はどこにもありません。リポジトリはそのまま回っています。

委任が名前だけ残るとき何が崩れるか

発表文でもっとも一般化できる部分は、委任についての診断です。

ガバナンス構造を設計するとき、よくこう作ります。最上位に代議機構を置き、その下に領域別のチームを置き、憲法や規定に「この領域はあのチームに委任する」と書きます。文書上は完結します。

問題は、委任が行為だという点です。文書に書いたから委任されるのではなく、上位機構が実際に手を離してはじめて委任されます。発表文が並べる失敗の様相が、まさにその地点です。

  • 運営委員会の構成員が個人の意見を述べているのか共同の立場を代弁しているのか不明瞭
  • 事案が望まれる結論がすでに付いた状態で伝えられる
  • 委任領域に全面的に属する事案を、関連チーム抜きで委員会が直接処理する
  • 懸念の提起に対する応答が不十分で遅延する

最後の一文が決定的です。「自分たちの権限の範囲のなかで自律的に決定できると信頼されているのかについての、全般的な不確実性。」

権限のない責任はこうして生まれます。委任されたチームは結果への責任を負いますが、決定の確定性は持ちません。この状態は人を速く消耗させます。社内のプラットフォームチームやアーキテクチャレビューグループを運営したことがあるなら、見慣れない構造ではないはずです。

10か月間の成果一覧は、そのまま消えた機能の一覧だ

発表文の成果一覧を自慢として読むと半分しか読んでいません。別の読み方をすれば、それは今や持ち主がいなくなった機能の一覧です。

コミッターのオンボーディング、マージボットを通じたメンテナ権限の委任、GitHub組織所有権の改革、セキュリティ勧告のトリアージ、自動化・AIポリシー、エスカレーションされた紛争の調停。

このうち相当数は「普段は誰も必要を感じないが、必要になる瞬間には即座に必要になる」種類の仕事です。セキュリティ勧告のトリアージが特にそうです。コミッターのオンボーディングが止まれば数か月後に処理量として現れ、紛争の調停が止まれば対立がスレッドの長さとして現れます。即座に障害にならないので、リスクが静かに積み上がります。

発表文自体もこの点を認めています。コアチームに調停を求められるという事実そのものが緊張を和らげ、合意可能な結論へ導いた事例が多かったと書きます。その通路が今はありません。

利用者の立場でこれが意味すること

ではNixpkgsを使うチームは何をすべきでしょうか。誇張も縮小もなく整理するとこうです。

今すぐ変わるものはありません。パッケージは更新され続け、チャンネルも出続けます。

変わったのはエスカレーション経路です。以前はポリシーレベルの事案(たとえばLLMが生成した貢献をどう扱うか、組織の所有権を誰が持つか)について尋ねる場所がありました。今は発表文の表現どおり、運営委員会が「いつものとおり最終的なバックストップ」として残っているだけです。バックストップは通路ではありません。

そして発表文によれば、二人ともNixpkgsへの関与を減らす計画であり、運営委員会に立候補する意思はありません。つまりこの空白は、その席に別の人が入るまで維持されます。

実務的にはこう対応します。ポリシー変化に敏感な依存関係があるなら、チャンネルの固定と自前オーバーレイの比重を点検し直し、セキュリティ勧告を上流の調整だけに頼らず自前の脆弱性スキャン経路を確認し、移行コストを今計算して文書に残しておきます。今すぐ移れという意味ではなく、移らなければならないときのコストを知っておけという意味です。

依存関係のガバナンスを実際に測る方法

スター数は人気の指標であってリスクの指標ではありません。代わりに数えられるものがあります。以下のコマンドは実際に動作する形であり、GitHubの検索APIは認証なしで使うと毎分のリクエスト制限が低いので、トークンを付けるほうがよいです。

# 直近90日間にマージされたPR数 — 処理量
OWNER_REPO="NixOS/nixpkgs"
SINCE="2026-05-11"
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/search/issues?q=repo:${OWNER_REPO}+is:pr+is:merged+merged:>=${SINCE}&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"

# 直近100件のマージ済みPRを実際にマージした人の分布 — 権限の集中度
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}/pulls?state=closed&per_page=100" \
  | python3 -c "
import sys, json, collections
prs = json.load(sys.stdin)
c = collections.Counter(p['merged_by']['login'] for p in prs if p.get('merged_by'))
for who, n in c.most_common(15):
    print(f'{n:4d}  {who}')
print('distinct mergers:', len(c))
"

二つめのコマンドが核心です。貢献者は多いのにマージする人が少数に集中しているなら、その少数がすなわちバス係数です。逆にマージする人が広く分散していれば、個人の離脱に対する耐性が高いです。

数字で測れないものは文書で確認します。意思決定機構が文書化されているか、委任領域が明示されているか、紛争をどこへ上げるかが書かれているか、そして最近その経路が実際に機能した事例があるか。最後の項目がもっとも重要ですが自動化できません。イシュートラッカーとフォーラムを自分で読まなければなりません。

消耗は性格ではなくプロセスの産出物だ

最後に、発表文で個人的にもっとも印象深かった箇所を移します。

発表文はコミュニティにガバナンスへの全般的な不信があることを認め、その不信が対立的でゼロサム的な葛藤の仕方を助長したと書きます。そしてこう続けます。そういうやり方はリーダーシップの空白状態や無応答のガバナンスを相手にすれば効果があるかもしれないが、善意で参加しようとするリーダーシップチームを相手にすると消耗を生み出すというのです。

その結果「聞かない側」が報われ、ガバナンスに参加する時間と意志のある経験豊富な貢献者のプールがさらに減り、膠着と離脱による意思決定という歴史的現象が固着する危険があると診断します。

この診断はオープンソースに限りません。社内のアーキテクチャレビュー、コードオーナー制度、プラットフォームチームにもそのまま当てはまります。委任されたチームに決定権限が実際に無く、葛藤を解消する正式な経路が無ければ、葛藤はもっとも疲れた人が先に出ていく形で解消されます。そしてそうやって解消された葛藤は記録に残らないので、次もまた同じ形で解消されます。

バス係数を下げる仕事は、文書をもっと書くことだけでは達成できません。誰が何を確定できるのかを明確にし、その確定を実際に尊重することが半分です。

参考資料

マージ済みPR 4,468件は2026年8月9日にGitHubの検索APIで直接照会した値であり、検索APIの結果は時点によって変わります。

Discuss on Twitter • View on GitHub