プラクティス名（別名）
トラックナンバー （トラック係数、バス係数、ハネムーンナンバー）
プラクティスの目的・狙い
- 属人化領域の可視化（リスク低減）
どんな時に使うか
- チームの弱点（ボトルネックや手薄な箇所）を知りたい時
- メンバー変更/離脱に伴いどこを補強する必要があるかを知りたい時
実施手順
- チームにとって必須のスキルや作業をリストアップする
- それを1人でできる人数をカウントして、書き入れる（この数字をトラックナンバーと呼ぶ）
- トラックナンバー＝1の領域は高リスクのため、何らかの属人化解消策を検討する
トラックナンバーという言葉は、仮にチームメンバーのうち何人がトラックに轢かれてしまうと開発継続ができなくなるか、というのが由来。不吉なのでハネムーンナンバー（＝長期離脱者）という呼び方もある。
アレンジ例
- チームで星取表（スキルマップ）を作成している場合は最下行に「1人でできる人数」を追記する
アンチパターン
- 「そんなにすぐに教えられるものじゃありません」 （→だからこそ、です）
- 「私が継続してやるから大丈夫です」 （→そのあなたがいなくなったら？という話です）
参考情報
アレンジ例に記載した星取表にトラックナンバーを併記するというやり方はこの書籍で知りました。他にもトラックナンバーの取り扱いについて詳しい解説が載っています。
こぼれ話（私的コメント）
そもそもスクラムチームにおいてはPOとSMは単一障害点です。これはスクラムの構造上どうしようもありません。SMはチームのことを熟知していないと務まらないのですぐに替えが効く存在ではありませんが、幸い開発作業を直接実施するわけではないので、まだ何とかなるかもしれません。
問題はPOです。マルチチームスクラムでPOがチーム化（複数のエリアプロダクトオーナーに分割）している場合でも影響は免れないでしょう。スクラムの原則には反しますが、普段からPPO（プロキシプロダクトオーナー：POを補佐し作業の一部を代行する人）を立てておけば、少しマシかもしれません。
DEVがPOのプロダクトビジョンを真に理解し、あのPOだったらこう判断しただろう、と思考をトレースできるほど意思疎通が図れている状態であれば、あるいは・・・。
そもそも交通事故に遭わない方法を考えた方がいいのかもしれません。