開発チームのバス係数を下げる既存改善の進め方
「決済まわりは〇〇さんしか触れない」「あの人が有給を取ると、その週はデプロイを止める」——複数人の開発チームがいるのに、機能ごとに触れる人が1人しかいない状態を、私たちは支援先でよく目にします。1人体制の属人化リスクは分かりやすいですが、チーム化した後も機能単位で属人化が再生産されることは意外と見落とされがちです。
この状態を測る指標が「バス係数(bus factor)」です。この記事では、バス係数とは何かを噛み砕いたうえで、自社の状態を可視化する方法、下げるための具体的な手段、そしていきなり全部に手をつけない優先順位のつけ方を整理します。
バス係数とは何か
バス係数は「そのプロダクトについて、何人が同時に離脱(バスに轢かれる、は比喩)すると開発が止まるか」を表す数字です。バス係数が1なら、1人抜けただけで詰みます。
重要なのは、これがチーム全体の人数ではなく、機能・領域ごとの人数で決まる点です。5人の開発チームがいても、決済機能を触れるのが1人だけなら、決済まわりのバス係数は1です。チームの規模とバス係数は別物として扱う必要があります。
バス係数が低い状態で実際に起きる被害は、離脱そのものより離脱後の遅延です。有給・体調不良・突然の退職のたびに、その領域の改修だけが数週間止まる。障害対応でも「原因箇所は分かるが直せるのはあの人だけ」で復旧が長引く。採用面接で「この機能の設計思想を説明できる人がいない」と気づいて評価が止まる、といった形で表面化します。
まず可視化する: 誰しか触れない領域の洗い出し
対策の前に、現状を数字と事実で把握します。感覚では「うちは大丈夫」という思い込みが起きやすい領域です。
Gitのコミット履歴から機能ごとの偏りを見る。
git log --format='%an' -- app/models/payment/ のようにディレクトリ単位でコミット者を集計すると、特定領域が実質1人で書かれている状態が数字で出ます。直近1年に絞ると、「昔は複数人で触っていたが今は1人」というパターンも見えます。
PRのレビュー履歴を見る。
コミットは1人でも、レビューで他のメンバーが目を通していれば知識は多少分散します。逆に「レビュアーが常に同じ1人」「セルフマージが多い」領域は、レビューという第二の目すら通っていない = バス係数がより深刻です。
「本番で障害が起きたら誰に連絡するか」をチームに聞く。
機能ごとに名前が1つしか挙がらない領域をリストアップします。これはコミット履歴より実感に近く、ドキュメント化されていない暗黙知(インフラの設定・外部APIの癖・「なぜこの実装にしたか」)の偏りを拾えます。
デプロイ・インフラ操作の実行者を確認する。
コードは複数人が触れても、本番デプロイや管理コンソールの操作権限が1人に集中しているケースがあります。これはコードのバス係数とは別に、運用のバス係数として独立してチェックが要ります。
この4つを掛け合わせると、「コードは書けるが本番は触れない」「レビューはするが1人では書けない」といった役割別の偏りまで見えてきます。単に「詳しい人」を1人挙げて終わらせないことが可視化の精度を上げます。
バス係数を下げる手段と、それぞれの向き不向き
洗い出しが終わったら、領域ごとの状況に応じて手段を選びます。全部を同時にやる必要はありません。
ペアプログラミング・モブプログラミングは、即効性が高いが工数コストも高い。
属人化が深刻な領域(その人が抜けると即詰む機能)には最も効きますが、2人分の工数を一時的に食うため、対象を絞らないとチーム全体の生産性が落ちます。「このスプリントはこの機能だけペアで進める」と範囲を区切るのが現実的です。
コードレビューの担当ローテーションは、低コストで継続的に効く。
レビュアーを固定せず、機能ごとに毎回別の人が見る運用に変えるだけで、時間をかけて知識が広がります。即効性はありませんが、追加コストがほぼゼロなので恒常的な仕組みとして定着させやすい手段です。
設計判断のドキュメント化は、「なぜこうしたか」の消失を防ぐ。
コード自体は読めば分かっても、「なぜこの実装を選んだか」「検討して見送った代替案は何か」は、書いた本人が離脱すると復元不可能になります。ADR(Architecture Decision Record)のような軽量な記録形式で、大きな設計判断のたびに数行残すだけでも効果があります。網羅的なドキュメント整備より優先度が高い投資です。
知識の意図的な分散(担当替え・タスクのシャッフル)は、中長期でのみ効く。
「いつもこの人がこの機能を担当する」という暗黙のアサインを崩し、定期的に担当を入れ替えます。効果が出るまで数ヶ月かかるため、緊急度の高い領域には向きませんが、再発防止として最も根本的です。
これらは互いに排他的ではなく、深刻な領域にはペア作業、それ以外は低コストの仕組み(レビューローテーション・ドキュメント化)を敷く、という組み合わせが現実的です。
外部の「第二の目」を入れる価値
社内の分散だけでは解決しない属人化もあります。チーム全員が同じ思い込みを共有している場合です。「この実装は仕方ない」「この設計は変えられない」という前提そのものが属人化していると、社内のペアやレビューでは気づけません。
外部パートナーによる技術診断は、この種の属人化に対して別の役割を果たします。既存コードを外部の目で読み解く過程で、以下が自然に生まれます。
- 社内では「暗黙の了解」だった設計判断が、外部への説明を通じて言語化・文書化される
- 「なぜこの実装なのか説明できない箇所」が診断の過程で洗い出され、リスクリストとして残る
- 特定の1人に依存せず開発を進められることを、実際に外部チームが機能追加や改修を行うことで実証できる
これは属人化した領域を丸ごと外部に置き換えるという意味ではありません。社内の知識を奪う存在ではなく、社内の暗黙知を形式知に変える触媒として使うのが実務上の使い方です。診断結果をもとに、社内でドキュメント化・ペア作業の対象を絞り込む材料にもなります。
いきなり全部やらない: 優先順位のつけ方
バス係数の低い領域をすべて同時に手当てしようとすると、通常業務が止まります。次の軸で優先順位をつけます。
- 影響範囲 × 発生確率で領域をマッピングする。 決済・認証・本番インフラのように「止まると事業が止まる」領域を最優先にする。管理画面の一部機能のように「止まっても数日は待てる」領域は後回しでよい
- 離脱の兆候がある領域を先に手当てする。 転職活動中・体調不安・契約更新が近い、といった具体的な兆候がある場合は、抽象的なリスク評価より先にそこから着手する
- 新規開発を止めてまで一気に解消しようとしない。 バス係数の改善は「その機能を触るタスクが発生したときに、必ず2人以上を関わらせる」形で日常業務に織り込むほうが持続する。特別プロジェクト化すると、プロジェクトが終わった瞬間に元に戻りやすい
優先順位づけの実務では、「誰が抜けたら本当に困るか」を経営層・PM・エンジニアの3者で一致させることが最初の一歩です。エンジニアだけが把握していて経営層が知らない、というギャップ自体もよくある属人化の一形態です。
バス係数の問題は、多くの場合すでにチームがある状態でも起きます。チームの人数を増やすことと、バス係数を上げることは別の取り組みだという認識が、対策の出発点になります。1人開発の体制がそもそも抱えるリスクについては、ひとりエンジニア体制の属人化を減らす進め方で詳しく解説しています。また、既存プロダクトの改善に外部チームとして着手する際の一般的な観点は、既存プロダクトの改善、外部チームが最初に見る観点にまとめています。
まとめ
- バス係数はチームの人数ではなく機能・領域単位で決まる。コミット履歴・レビュー履歴・「障害時に誰に連絡するか」の3方向から可視化しないと、思い込みで「うちは大丈夫」と判断してしまう
- 下げる手段はペア作業(即効性・高コスト)、レビューローテーション(低コスト・継続的)、設計判断のドキュメント化、担当の意図的な分散(中長期)があり、深刻度に応じて組み合わせる
- 全領域を同時に手当てせず、影響範囲×発生確率でマッピングし、離脱の兆候がある領域から着手する。社内の思い込みごと属人化している場合は、外部の第二の目を診断として入れることが有効な選択肢になる
「特定のメンバーに依存した開発体制になっている」「その人が抜けたときのリスクを具体的に把握したい」という段階でも、torcheees はご相談を受け付けています。まずは1〜4週間の「要件整理・開発診断」で、コードとチーム体制の現状を確認し、バス係数改善の優先順位をご提示します。継続的な改善は継続的な改善支援としてもご相談いただけます。コンサルティングのサービス詳細をご覧のうえ、まずはお問い合わせフォームからご連絡ください。