最も優秀なエンジニアが辞めてしまいました。さて、どうしますか？

すべての開発チームには、デプロイパイプラインがなぜそのような仕組みで動いているのか、なぜデータベースのスキーマに奇妙な命名規則があるのか、2023年の障害時に何が起きて現在の監視体制になったのか、そしてレガシーコードベースのどの部分が絶対に触ってはいけない「耐力壁」であるのかを、熟知している人が一人はいます。

その人物が去るとき（そして、いつかは必ず去ります）、それらの文脈（コンテキスト）はすべてその人と共に失われます。チームはその後数週間から数ヶ月にわたって、苦痛を伴うインシデントが発生するたびに、その知識のギャップを思い知らされることになります。ドキュメント化されていない手動のステップを誰も知らなかったためにデプロイが壊れたり、今では誰も思い出せない理由で存在していた回避策を、リファクタリングによって誤って削除してしまったり、退職したエンジニアなら20分で説明できたシステムを理解するために、新入社員が3週間も費やしたりするのです。

これは「バス係数（Bus Factor）」問題と呼ばれるもので、「プロジェクトを継続できなくなるまでに、何人のチームメンバーがバスに轢かれる必要があるか？」という不吉な問いに由来しています。ほとんどの開発チームは、システムの重要な部分においてバス係数が1または2であり、これは1人か2人が退職するだけで、数週間から数ヶ月に及ぶ混乱が生じる可能性があることを意味します。

実際に失われるもの

知識豊富なエンジニアが去っても、コードは残ります。プルリクエスト（PR）も残ります。Slackのメッセージも、少なくとも保存期間が切れて消えるまでは残ります。失われるのは「解釈のレイヤー」です。なぜ物事がそのようになっているのかという理解、どの決定が意図的なトレードオフで、どれが偶然の産物だったのか、どこに問題が潜んでいるのか、そして間違った場所に触れると何が壊れるのか、といった知識です。

これは最も凝縮された形の暗黙知（属人化された知識）であり、最も引き継ぎが難しい類の知識です。なぜなら、それを持っている本人すら、自分がどれほどの知識を持っているかを自覚していないことが多いからです。彼らはシステムと密接に関わりながら数ヶ月、数年をかけてそれを蓄積してきたため、その多くは完全に自動化されており、たとえ試みたとしても、包括的なドキュメントとして書き出すことはできません。

退職時の面談や引き継ぎセッションは役に立ちますが、退職する人が知っていることのほんの一部しか捉えることができません。2週間の引き継ぎ期間で、2年分の蓄積されたコンテキストを移転することは不可能なのです。

「継続的な記録」という選択肢

バス係数問題への対策は、退職の間際に慌てて知識を絞り出そうとするのではなく、日常的に知識を継続して記録することです。

自己執筆型ドキュメント（Self-writing documentation）は、すでに日々行われている開発アクティビティを、発生したその場で構造化され検索可能なドキュメントに変換することでこれを実現します。エンジニアがSlackのスレッドで設計上の決定を説明すると、その説明が記録され、システムのドキュメントに統合されます。PRに特定の設計アプローチを選んだ理由の説明が含まれていれば、その理由がコードとともに保存されます。ミーティングで移行計画のトレードオフについて議論された場合、その議論はドキュメント化され、関連するシステムにリンクされます。

知識は、特別なセッションでエンジニアから「抽出」されるのではありません。彼らがすでに行っている業務の副産物として記録されるため、システムが進化するにつれて自然と継続的に蓄積され、常に最新の状態に保たれます。

そのエンジニアが最終的に退職するとき、在籍中に生成されたドキュメントはそのまま残ります。次にデプロイパイプラインの仕組みを理解する必要がある人は、試行錯誤して答えを探るのではなく、ドキュメントを検索すれば済むようになります。

対策を講じない場合のコスト

適切なドキュメントがないまま主要なメンバーが退職するコストを、正確に測定するのは困難ですが、痛感するのは簡単です。重要な知識の保有者を失った後、チームの開発速度が2ヶ月から6ヶ月にわたって低下するという報告は一般的です。これは、その人物がシステムのどれだけを理解していたか、そしてその知識がどれだけドキュメント化されていたかによって異なります。

シニアエンジニアの年収が18万〜22万ドルであると仮定すると、チーム全体で生産性が大幅に低下する期間がわずか2ヶ月だとしても、失われるアウトプットは数万ドル分に相当します。退職したエンジニアが唯一の知識保有者であったようなクリティカルなシステムの場合、コストはさらに高くなります。本番環境のインシデント対応に時間がかかり、安全に修正できるほどシステムを理解している人がいないために機能追加が見送られ、新しく入った人が読むべき資料がないためにオンボーディングに数週間ではなく数ヶ月もかかってしまう、といった事態が発生します。

バス係数問題は、その解決策（知識を継続的に記録するドキュメンテーション）のほうが、それが防ぐ問題よりも安価で済む、数少ないエンジニアリング上のリスクの一つです。

よくある質問

引き継ぎセッションを行うだけではダメですか？ 行うことは可能であり、行うべきですが、そこで捉えられるのは退職するエンジニアが「言及しようと思いついたこと」だけであり、彼らの知識のほんの一部に過ぎません。最も価値のある知識の多くは文脈（コンテキスト）に依存するものであり、引き継ぎセッション中には発生しないような特定の状況に直面したときに初めて表面化します。

バス係数を下げるには、どの程度のドキュメントが必要ですか？ 実装の詳細（コード自体が実装レベルでそれ自体をドキュメント化しています）よりも、意思決定とその理由に焦点を当ててください。新しく入ったエンジニアがドキュメントを読んで「なぜシステムがこのような構造になっているのか」を理解できれば、バス係数のリスクは大幅に減少します。

これは小規模なチームにも当てはまりますか？ 小規模なチームのほうが、一人ひとりが全体の知識に対して占める割合が大きいため、実際にはより脆弱です。5人のチームから1人のエンジニアが抜けると、チームの共同知の20%が失われます。50人のチームから1人のエンジニアが抜けた場合は2%の損失です。

関連資料：暗黙知（属人化）の隠れたコスト、ドキュメンテーションの技術負債、コードはドキュメント化されていても、決定は文書化されていない。関連ページ：自己執筆型ドキュメント、ナレッジの維持・継承、開発チーム向け。