バスナンバー ― 同僚たちに書くなと頼まれた GitHub プラグイン

バスファクターとは？

• バスファクターは、プロジェクトで何人のチームメンバーが突然いなくなるとプロジェクトが遅延するかを示す指標。
• 2015年、会社で唯一収益を生み出していたコードベースの貢献者が解雇されたとき、これを計算する GitHub プラグインを書こうと決意した。

プラグイン開発の過程

• トラックファクター研究論文を参考にしてプラグインの開発を始めた。
• 同僚たちは、このプラグインが管理者にとって誰を解雇しやすいかを計算する道具として使われかねないと懸念した。

結果の再現の試み

• 研究論文で提供されている GitHub リポジトリを使って結果を再現しようとした。
• データは JSON 形式で提供され、可視化は CSV を通じて可能。
• README の手順がうまく動かず、問題の解決に時間がかかった。

GNU Parallel の使用

• GNU Parallelを使って複数の GitHub リポジトリを同時にクローンした。
• 8 個のプロセスだけを使うように設定したが、すべてのコアが最大まで使われた。

Ruby Gems と NixOS

• Linguistプラグインのインストールに苦労した。
• NixOS で Ruby Gems をインストールする方法を探している。

結果の再計算

• 元のリポジトリをフォークし、Java ソースをコンパイルして結果を再計算した。
• Linux カーネルリポジトリの結果例: トラックファクター 12、カバレッジ 49.98%。

問題点と追加研究

• 計算過程でレビュー工程を考慮していない。
• Linux カーネルのトラックファクターが 10 年前と大きく異なる理由を調べる必要がある。
• よりよい計算方法を見つけるため、論文の引用文を見直す予定。

結論 - バスファクターの重要性

• 2015年の論文では Linux カーネルのトラックファクターを 90 と評価していたが、現在は 12 と計算される。
• これは改善を意味しない。
• 追加の可視化や詳細は mclare のブログで確認できる。

[GN⁺]

Hacker Newsのコメント

• CodeSceneの機能の1つは、コード変更が頻繁な領域のうち、知識の分散が低い部分を特定してリスクの高い領域を見つけること

  • 誰かが退職した場合、その人だけが把握しているコードを簡単に確認できるため、引き継ぎ計画を立てやすい
  • 悪用されるものだとは思わず、可視性を提供するツールである

• Amazonは、コードシステムに関するレポートを通じて、チームの活動やリスク要因を簡単に把握できる機能を提供している

  • 「バス係数」は、チームの特定メンバーが不在になったときにチームがどの程度影響を受けるかを示す指標である
  • 開発者は、特定システムに関する知識が雇用の安定を保証すると考えるかもしれないが、これは技術的リスクと見なせる

• GNU Parallelがすべてのコアを使うのは、各 git clone が複数の index-pack スレッドを生成するためである

  • pack.threads を 1 に設定すると役立つ可能性がある

• 「バス係数」は、チームの自律性と透明性を示しており、理想的にはすべてのチームメンバーがすべてを理解できるべきである

  • 0バス係数は、チームメンバーが互いの役割を代替できることを意味し、これはソフトウェアの単純さを反映している
  • メール、コミット、PR、コード行数などで人を評価するのは誤ったやり方である

• キャリアが上がるにつれて、開発者はコードを書くことよりレビューに集中すべきだという誤解がある

  • 優れた開発者を平凡なマネージャーに変えたいわけではない

• システムの著者は、ファイルに重要な貢献をしたユーザーとして定義されており、著者がファイル全体の 50% 未満しかカバーしていない場合、システムは深刻な遅延を経験する可能性がある

• スタートアップのレイオフ問題は、「誰を解雇するか」ではなく「次のバージョンを迅速に開発できるチームは誰か」という問いである

• 一部の企業向けソフトウェアには、メール送受信量を測定するダッシュボードが存在することがある

  • 同僚が反対することを趣味で進めるのは、良くない行動に見えるかもしれない

• CPANは長年バス係数を追跡しており、たとえば Moose のバス係数は 5 である

• 「宝くじ係数」という用語を使って、誰かが宝くじに当たって去ってもプロジェクトを継続できるかを表す