バス係数

バス係数は、チームメンバー間で情報や能力が共有されていないことに起因するリスクの尺度であり、「バスにひかれた場合」というフレーズに由来しています。バス問題、トラック係数、^[1] バス/トラック数^{[要出典]、}またはサーカス係数としても知られています。^[2]

この概念は、キーパーソンリスクというかなり古い考え方に似ていますが、財務または経営幹部（理論上は保険費用で代替可能）ではなく、主要な技術専門家を失った場合の影響を考慮しています。バス要因に貢献するには、人員がキーパーソンかつ代替不可能である必要があります。代替可能な人員またはキーパーソンでない場合は、バス要因の影響は発生しません。

この用語は、最初にソフトウェア開発に適用されました。ソフトウェア開発では、チームメンバーが、パフォーマンスは良好だが他のチームメンバーが利用できないコードを作成することで重要なコンポーネントを作成する場合があります。たとえば、文書化されていない、共有されていない、暗号化されていない、難読化されていない、または公開されていない作業などです。したがって、重要なコンポーネントは、そのチームメンバーの不在の直接的な結果として事実上失われ、メンバーが重要な存在になります。このコンポーネントがプロジェクトの進行の鍵となる場合、プロジェクトは行き詰まるでしょう。

意味

「バス係数」とは、知識や能力のある人員の不足によりプロジェクトが行き詰まる前に、突然プロジェクトから消えなければならないチームメンバーの最小数です。

「バスに轢かれる」という表現は、人が死ぬか、もっと一般的にはプロジェクトから突然姿を消すことを表します。これは、仮想的な将来の失踪をブラックユーモアの形で表現するために使用されます。チームメンバーが文字通り「バスに轢かれる」必要はなく、「バス要因」が適用されます。チームメンバーが突然、実質的にプロジェクトで作業できなくなるようなイベントはいくつでも発生する可能性があります。これには、新しい仕事に就く、育児休暇を取る、ライフスタイルや生活状況を変えるなどが含まれます。

たとえば、30 人のチームが、材料を混ぜる、生地をこねる、焼くという 3 つの必須ステップでパンを生産しているとします。10 人が材料を混ぜる方法を知っており、30 人全員が生地をこねる方法を知っており、5 人がパンを焼く方法を知っています。パンを焼く方法を知っている 5 人全員がいなくなった場合、チームはパンを生産できないため、チームのバス係数は 5 になります。バス係数 1 は、単一障害点です。

歴史

この種の疑問の初期の例としては、1994年にマイケル・マクレイが「もしグイド・ヴァン・ロッサムがバスにひかれたらPython言語はどうなるのか」と公に質問したことがある。 ^[3]

「トラック番号」は、2004年に出版されたOrganizational Patternsの本ですでに繰り返し登場する概念であり、 ^[4]それ自体は、1995年に出版されたPattern Languages of Program Designシリーズの最初の本^{[5]で出版された成果の発展形であり、1994年8月に開催された最初の}Pattern Languages of Programsカンファレンスの出版記録であり、 Solo Virtuosoなどのパターンで参照されています。^[6]この用語は、 1998年に精神衛生の分野で使用されました^{[説明が必要] 。}^{[7] 2003年までにエンジニアリングの分野で使用され、}^[8] 2005年にはDebianプロジェクトで使用されました。 ^[9]

2015年と2016年に実施された調査では、133の人気のあるGitHubプロジェクトのバス/トラック係数を計算しました。結果によると、ほとんどのシステムのバス係数は小さく（65％のシステムはバス係数≤2）、値が10を超えるシステムは10％未満でした。^[10]^[11]

この用語は主にビジネス管理、特にソフトウェア開発の分野で使用されます。^[要出典]

バスファクターの改善

多くのソフトウェア開発プロジェクトでは、情報を共有してバスファクター（チーム全体の規模にまで及ぶ可能性がある）を向上させることが目標の1つです。バスファクターが優れているということは、多くの個人が十分な知識を持っていて、非常に不利な状況でもプロジェクトが成功できる可能性があることを意味します。^[12]

バス係数を改善するいくつかの方法が提案されています。

複雑さを軽減する、^[13]
すべてのプロセスを文書化し、その文書を最新の状態に保つ。^[13]
クロストレーニングを奨励する。^[13]

参照

参考文献

^ Bowler, Michael (2005年5月15日). 「Truck Factor」. Agile Advice. 2021年4月29日時点のオリジナルよりアーカイブ。 2014年4月9日閲覧。
^ Bernard, Mercedes. 「RubyConf 2021 - サーカス要素を最小限に抑える: 回復力のあるチームの構築 (Mercedes Bernard 著)」. devconf.net . 2024 年10 月 8 日閲覧。
^ McLay, Michael (1994 年 6 月 29 日)。「もし Guido がバスにひかれたら?」 (メーリングリスト)。
^ Coplien, James; Harrison, Neil (2004 年 7 月 26 日)。アジャイルソフトウェア開発の組織パターン。Wiley。
^ Coplien, James; Schmidt, Douglas (1995 年 5 月 12 日)。「第 13 章、生成 的開発プロセスパターン言語」。プログラム設計のパターン言語。Addison Wesley。Bibcode :1995plpd.book.....V。
^ Coplien, James (1994 年 8 月 4 日)、「A Generative Development-Process Pattern Language」、PLoP 1994 の内部議事録、イリノイ州 Allerton Park: 未発表。2014 年 9 月 12 日時点のオリジナルからアーカイブ。2014 年9 月 12 日取得。
^ サイモン、ロバート（1998年5月17日）。メンタルヘルス専門家と法律：包括的ハンドブック。ハーバード大学出版局。69ページ。ISBN 0-674-69721-9。
^ Redmond, Matthew C.; Newton, Paul (2003). 「エンジニアリング、計画、設計プロセスへのGISの統合」(PDF)。2012年3月12日時点のオリジナル(PDF)からのアーカイブ。
^ ペッター、ラインホルツェン (2005 年 11 月 11 日)。「Re:辞任とアップロード」（メーリングリスト）。
^ アヴェリーノ、ギリェルメ;ヴァレンテ、マルコ・トゥリオ。ホラ、アンドレ（2015年9月10日）。「人気のある GitHub アプリケーションのトラックファクターは何ですか? 最初の評価」。PeerJ プレプリント。ドイ: 10.7287/peerj.preprints.1233v3。 2015 年 12 月 8 日のオリジナルからアーカイブ。2015 年12 月 4 日に取得。
^ アヴェリーノ、ギリェルメ;パソス、レオナルド。ホラ、アンドレ。ヴァレンテ、マルコ・トゥーリオ (2016)。「トラック要因を推定するための新しいアプローチ」。2016 IEEE 24 回プログラム理解に関する国際会議 (ICPC)。 1 ～ 10 ページ。arXiv : 1604.06766v1。Bibcode :2016arXiv160406766A。土井：10.1109/ICPC.2016.7503718。ISBN 978-1-5090-1428-6.S2CID 19238548 。
^ James Coplien、Pair Programming Illuminated。引用: 「プロジェクトが機能しなくなるには、何人または何人ぐらいがトラックに轢かれるか (または辞めるか) する必要があるでしょうか?」
^ abc 「チームのバス係数を高める」 2008年9月3日。2016年4月16日時点のオリジナルよりアーカイブ。2015年12月4日閲覧。

さらに読む

Michele Marchesi、Giancarlo Succi、Don Wells、James Donovan Wells、Laurie Williams (2003)。エクストリームプログラミングの視点。ボストン大学：Addison-Wesley。ISBN 0-201-77005-9。{{cite book}}: CS1 maint: 複数の名前: 著者リスト (リンク)
ローリー・ウィリアムズ、ロバート・ケスラー (2002)。『ペアプログラミング入門』。ボストン大学出版局: Addison-Wesley。ISBN 0-201-74576-3。
Kent Beck (2000)。エクストリームプログラミング。Das Manifest (ドイツ語)。sl: Addison- Wesley。ISBN 3-8273-2139-5。

外部リンク

有毒な人々、バスファクターとその増加方法についての議論（他のトピックも含む）を含む講演
「もしリーナス・トーバルズがバスに轢かれたらどうなるか？」 - 実証的研究、ユーモア作品

[1] Bowler, Michael (2005年5月15日). 「Truck Factor」. Agile Advice. 2021年4月29日時点のオリジナルよりアーカイブ。 2014年4月9日閲覧。

[2] Bernard, Mercedes. 「RubyConf 2021 - サーカス要素を最小限に抑える: 回復力のあるチームの構築 (Mercedes Bernard 著)」. devconf.net . 2024 年10 月 8 日閲覧。

[3] McLay, Michael (1994 年 6 月 29 日)。「もし Guido がバスにひかれたら?」 (メーリングリスト)。

[4] Coplien, James; Harrison, Neil (2004 年 7 月 26 日)。アジャイルソフトウェア開発の組織パターン。Wiley。

[5] ^ Coplien, James; Schmidt, Douglas (1995 年 5 月 12 日)。「第 13 章、生成 的開発プロセスパターン言語」。プログラム設計のパターン言語。Addison Wesley。Bibcode :1995plpd.book.....V。

[6] Coplien, James (1994 年 8 月 4 日)、「A Generative Development-Process Pattern Language」、PLoP 1994 の内部議事録、イリノイ州 Allerton Park: 未発表。2014 年 9 月 12 日時点のオリジナルからアーカイブ。2014 年9 月 12 日取得。

[7] サイモン、ロバート（1998年5月17日）。メンタルヘルス専門家と法律：包括的ハンドブック。ハーバード大学出版局。69ページ。ISBN 0-674-69721-9。

[8] Redmond, Matthew C.; Newton, Paul (2003). 「エンジニアリング、計画、設計プロセスへのGISの統合」(PDF)。2012年3月12日時点のオリジナル(PDF)からのアーカイブ。

[9] ペッター、ラインホルツェン (2005 年 11 月 11 日)。「Re:辞任とアップロード」（メーリングリスト）。

[10] アヴェリーノ、ギリェルメ;ヴァレンテ、マルコ・トゥリオ。ホラ、アンドレ（2015年9月10日）。「人気のある GitHub アプリケーションのトラックファクターは何ですか? 最初の評価」。PeerJ プレプリント。ドイ: 10.7287/peerj.preprints.1233v3。 2015 年 12 月 8 日のオリジナルからアーカイブ。2015 年12 月 4 日に取得。

[11] アヴェリーノ、ギリェルメ;パソス、レオナルド。ホラ、アンドレ。ヴァレンテ、マルコ・トゥーリオ (2016)。「トラック要因を推定するための新しいアプローチ」。2016 IEEE 24 回プログラム理解に関する国際会議 (ICPC)。 1 ～ 10 ページ。arXiv : 1604.06766v1。Bibcode :2016arXiv160406766A。土井：10.1109/ICPC.2016.7503718。ISBN 978-1-5090-1428-6.S2CID 19238548 。

[12] James Coplien、Pair Programming Illuminated。引用: 「プロジェクトが機能しなくなるには、何人または何人ぐらいがトラックに轢かれるか (または辞めるか) する必要があるでしょうか?」

[eight2late-13] 「チームのバス係数を高める」 2008年9月3日。2016年4月16日時点のオリジナルよりアーカイブ。2015年12月4日閲覧。