少人数チームのロールローテーション：知識の属人化を防いで属人化リスクを分散

「あの人がいないとこの機能は誰もわからない」——小規模チームではよく起きる問題だ。特定の人物に知識が集中している状態（属人化）は、その人の退職・休職・繁忙で即座にプロジェクトの危機につながる。

ロールローテーションはこの属人化リスクを分散するための最も効果的な手法だ。

バス係数で属人化リスクを数値化する

「バス係数（Bus Factor）」は、「何人がバスに轢かれて（= プロジェクトを離脱して）も、プロジェクトが継続できるか」を示す指標だ。

バス係数1 = 1人のキーパーソンが抜けた瞬間にプロジェクトが止まる危険状態

自分のチームのバス係数を確認する方法：

チームの各機能・システムについて確認する：
「このシステムを完全に理解しているメンバーは何人いるか？」
「この業務を他のメンバーに引き継げる人は何人いるか？」

1人しかいない項目の数がバス係数1の箇所だ。

ロールローテーションの設計

ローテーション対象の決め方

すべての業務を均等にローテーションする必要はない。特に重要なのは「バス係数1の領域」だ。

優先度高：

• コアシステムの開発・保守知識
• 顧客との主要接点（特定の担当者が1人の場合）
• デプロイ・インフラの操作

優先度低：

• 専門性が高く学習コストが非常に高い領域
• ローテーションより専門家を育てる方が効率的な領域

ローテーション頻度の設計

業務の種類	推奨ローテーション期間
主担当エンジニア	6〜12ヶ月
サブ担当（バックアップ）	3〜6ヶ月
オンコール当番	毎週〜毎月
コードレビュアー	毎スプリント

引き継ぎドキュメントの作り方

ローテーションを機能させるためには「引き継ぎドキュメント」の品質が鍵になる。

引き継ぎドキュメントの標準フォーマット：

# [担当業務名] 引き継ぎドキュメント

## 担当業務の概要
- 何をする業務か（1〜3行）
- 発生頻度（毎日・週次・月次・随時）
- 依存する外部システム・ツール

## 通常の手順
1. [手順1（スクリーンショット推奨）]
2. [手順2]
...

## よくある問題と対処法
- 問題A → 対処方法
- 問題B → 対処方法

## エスカレーション先
- 問題A：□□さん or Slack #channel名
- 技術的な問題：□□ドキュメント

## 関連ドキュメント・リンク
- [ドキュメント名](URL)

ローテーションを成功させるコツ

コツ1：「シャドーイング期間」を設ける いきなりロールを交代するのではなく、2週間〜1ヶ月のシャドーイング期間（現担当者の作業を横で見学・補助する期間）を設ける。シャドーイング後に段階的に主担当に移行する。

コツ2：「引き継がれた側」に書かせる 引き継ぎドキュメントは現担当者が書くのではなく、「引き継いだ人が理解した内容」を書くと品質が上がる。「引き継いだ人にとって分かりにくかった部分」が明らかになるからだ。

コツ3：ローテーション後も「前任に聞く」を許容する 「分からなくても前任に聞いてはいけない」というルールは、引き継ぎを機能不全にする。最初の3ヶ月は「前任への質問OK」として、実際の業務でわからない箇所を補うドキュメントを更新させる。

まとめ

少人数チームのバス係数を上げること（=属人化リスクを下げること）は、プロジェクトの持続可能性を高める投資だ。ローテーション自体よりも「引き継ぎドキュメントの整備」と「シャドーイング期間」の設計が成否を分ける。PMが率先してローテーション計画を作ることで、チームの誰も「自分にしかできない仕事で縛られる」状況を作らない文化が生まれる。