はじめに
この記事はZOZOアドベントカレンダー2022#5 11日目の記事になります。
バス係数とは
バス係数という言葉をご存知でしょうか？(パスではなく、車の「バス」ですね)
自分が知ったのは「Googleのソフトウェアエンジニアリング」という書籍からでした。
書籍では情報の単一障害点という観点で紹介されており、端的に言えば「何人バスに轢かれたら破綻するか？」ということになります。
同じ意味で「トラックナンバー」、「ハネムーンナンバー」とも言うらしいとSNSで教えていただきました。ハネムーンナンバーは轢かれるという
表現があまりよろしくないので、何人ハネムーンにでかけたら破綻するか？ということですね。
当然ながらバス係数１の場合は１人しかその情報を知らない。２なら２人、３なら３人と、多ければ多いほど安全ということです。
危険なバス係数になる行為
そこで、危険なバス係数になるような行為を考えてみました。
- 一人で全部やる。共有がない。
- レビューしない、またはレビューが適当
- ドキュメントがない、またはドキュメントが不明瞭、ドキュメントの場所がわからない。
- 共有されても馴染みがないドメイン
- 共有されても難しい作業、運用（失敗できないなど）
などなど
作業する側も、共有される側も背景含め理解してもらう、理解する。さらに作業の内容をトレースできるぐらい共有できないとなかなか難しいことではあります。
また、作業が終わったあとに共有となると、さらに難しいのが、元の作業者が運用に追われる、他の仕事に追われる、ドキュメント書く余裕もないし、そのドキュメントに価値があるのかも不明となれば、なかなかバス係数は増えていかない危険な状況と言えます。
バス係数を増やすには？
バス係数を増やすにはどうすればいいか？
- 一人で作業しない、複数人でやる
- 作業完了後のメンテなども一人でやらない
- 作業後になってしまったら、ドメインの共有含め、バス係数が増えるまで頑張る
つまり、一人ではなくチームで作業するということだと思います。
アジャイルの観点から
これをアジャイルの観点で当てはめると、そもそも一人で作業するという観点がありません。単位はチームからになります。
細かい作業を個人が担当するかどうかなどはチームが決めることになりますが、きちんと物事に優先順を決め、優先度が高い順にチームとして取り組むことになります。
ペアプログラミングやモブプログラミングで取り組むことが多いのではないでしょうか。
個人が対応してもお互いに関心を持つ仕組みがあり、早い段階で共有され、相談され対応していくことになります。
個人ごとの「グループ」ではなく、「チーム」であることが大事になってきます。
あなたのチームは本当に「チーム」ですか？
バス係数１で悲惨な状況を作らないためにも振り返ってみてください。