ナレッジ共有と属人化解消

属人化とそのリスク

属人化とは、特定のモジュールや業務知識が 特定の担当者にしか把握されておらず、その人がいないと変更や障害対応が滞ってしまう状態を指します。 このリスクを表す指標としてバス係数(Bus Factor)という考え方があります。

ドキュメント文化の作り方

知識を個人の頭の中だけに留めず、必要なタイミングで誰でも参照できる形で残します。

• README: セットアップ手順や全体構成など、新規参加者が最初に読むべき情報
• ADR(Architecture Decision Record): なぜその設計を選んだのかという意思決定の背景
• Runbook(運用手順書): 障害対応やよくある運用作業の具体的な手順

# Runbookの例: 決済バッチが異常終了した場合の対応手順

1. 監視ダッシュボードでバッチの失敗ログを確認する
2. エラーメッセージから、以下のどのパターンかを切り分ける
   - 外部決済APIのタイムアウト → リトライキューの状態を確認し再実行する
   - データ不整合エラー → 対象レコードを一覧化し、担当チームへエスカレーションする
3. 対応後、影響を受けた注文の件数と対応状況をSlackの #payments-ops に報告する

ペアプロ・モブプロ・コードレビューでの共有

ドキュメントだけでなく、日々の開発プロセスの中に知識共有を組み込むことも重要です。

• ペアプログラミング: 2人で1つの実装に取り組み、リアルタイムで知識を伝える
• モブプログラミング: チーム全員で1つの画面を見ながら実装し、知識を全体に広げる
• コードレビュー: 実装の背景や設計判断をコメントとして残し、レビュアー以外も後から参照できるようにする

オンボーディングとローテーション

新しいメンバーが特定のモジュールに早期に触れられるよう、オンボーディングのプロセスを整備します。 さらに、担当領域を固定しすぎず、定期的にローテーション(担当替え)を行うことで、複数人が同じ領域に詳しくなり、属人化が自然と解消されていきます。 オンコール当番を輪番制にすることも、運用知識を特定の人に偏らせないための有効な手段です。

ポイント

• 属人化のリスクはバス係数という考え方で表され、係数を高めることが目標になる
• README・ADR・Runbookなど、知識を個人ではなくドキュメントに残す
• ドキュメントは書いて終わりにせず、変更のたびに更新する運用を定着させる
• ペアプロ・モブプロ・コードレビューやローテーションを通じて、日々の開発の中で知識を広げる