属人化（暗黙知）に潜む隠れたコスト

暗黙知（部族の知識）とは、物事がどのように機能しているかについての、文書化されていない非公式な理解のことであり、それを習得するのに十分な期間在籍している人々の頭の中にのみ存在します。なぜ請求システムが現在のような方法で返金を処理しているのか。レガシーAPIについて誰に相談すべきか。現在の監視アラート設定のきっかけとなった3月の障害で何が起きたのか。どの設定値がシステムの支えになっており、どの設定値なら安全に変更できるのか。

小規模なチームでは、暗黙知は効率的です。全員が全員を知っており、距離の近さや日々の会話を通じて文脈（コンテキスト）が共有され、正式なドキュメントを作成するオーバーヘッドは、役に立つどころか実際には開発速度を低下させてしまいます。チーム（部族）が十分に小さいため、知識は自然に循環します。

問題は、暗黙知はスケールしないということであり、それがスケールしなくなるタイミングは、通常、チームが気づく前にやってきます。

スケーリングの限界

この限界は、通常10人から20人のエンジニアの間で発生します。10人未満であれば、ほとんどのエンジニアがシステム全体の妥当なメンタルモデルを持っており、特定のコンポーネントについて誰に尋ねればよいかを知っています。20人を超えると、システムは個人の理解を超えて成長し、歴史的な背景を持たない最近加入したメンバーがチームに含まれるようになり、暗黙知を保持しているエンジニアは、自身の業務と、増え続ける質問への回答という負担の間で、ますます手一杯になっていきます。

その兆候は顕著です。意思決定ではなく、主に文脈を共有するために存在するミーティング。実際の質問に対処する前に、議論の半分が背景の再構築に費やされるSlackのスレッド。新メンバーがドキュメントを読むのではなく、浸透圧のように周囲から文脈を吸収しなければならないため、何ヶ月もかかるオンボーディング。同じ質問が6ヶ月前に議論され解決されたことを誰も覚えていない（あるいは現在のチームが誰も知らない）ために、蒸し返される決定事項。

これらの兆候にはそれぞれコストがかかっており、個々の事例は些細なことに見えるため、そのコストはほとんどのチームが認識しているよりもはるかに大きなものになります。

なぜ非同期ワークを阻害するのか

暗黙知は、根本的に非同期ワークと相容れません。意思決定に必要な文脈が誰かの頭の中にある場合、その意思決定はその人が対応できる時にしか行えません。これにより、ミーティング、リアルタイムのSlackでの会話、直接の呼びかけなど、すべてが同期的なチャネルへと強制されます。

分散型チームやハイブリッドチームでは、この不適合はさらに深刻になります。決済システムに関する文脈を必要としている別のタイムゾーンのエンジニアは、その文脈を持つエンジニアがオンラインになるまで待たなければなりません。ドキュメントから非同期で行えたはずの意思決定が、カレンダーの空き時間枠によってブロックされてしまいます。

暗黙知を検索可能なドキュメントに変換することで、知識の保持者がその場にいなくても、いつでも誰でも文脈を利用できるようになるため、非同期の意思決定が可能になります。決済システムがなぜそのような構造になっているのかの意思決定ログを読めるエンジニアは、それを調べるためにミーティングをスケジュールする必要はありません。

変換における問題

暗黙知をドキュメントに変換する際、最も困難なのは、その知識を持っているのが通常、チームで最も多忙な人々（時間価値が最も高く、スケジュールが最も埋まっているシニアエンジニアや初期メンバー）であるという点です。彼らに席に座って知っていることをすべて書き出すよう求めるのは、既存の業務に加えて、ゴールのない膨大なタスクを引き受けるよう求めることになります。

自己執筆型ドキュメント（Self-writing documentation）は、すでに知識が共有されているチャネルから暗黙知をキャプチャすることで、この課題に対処します。シニアエンジニアが設計上の意思決定をSlackで説明すると、その説明がキャプチャされ、構造化されます。ミーティングでシステムの現在のアーキテクチャの背景にある歴史が取り上げられると、その議論はドキュメントの一部になります。PR（プルリクエスト）の説明で特定のアプローチが選ばれた理由が説明されると、その推敲プロセスがコードとともに保存されます。

シニアエンジニアはドキュメントを「書く」必要はありません。通常通りの業務を行うだけで、そこからドキュメントが自然に生成されます。

よくある質問

暗黙知をどのように特定すればよいですか？ 何度も繰り返し質問され、特定の人しか答えられないような質問を探してください。実際の質問に入る前に、最初の数件のメッセージが文脈の構築に費やされているSlackスレッドを探してください。意思決定ではなく、情報共有のために存在するミーティングを探してください。これらはすべて、ドキュメント化されるべきであるにもかかわらず、されていない知識の兆候です。

最初にキャプチャすべき最も価値のある暗黙知は何ですか？ システムアーキテクチャの意思決定（なぜそのような方法で構築されているのか）、障害履歴（何が問題で、その結果何が変更されたのか）、および統合の境界（異なるサービスがどのように通信し、なぜそうしているのか）です。これらは、文脈が欠落している場合に最もコストのかかるミスを引き起こす領域です。

暗黙知を完全に排除することはできますか？ いいえ、その必要もありません。一部の知識は本質的に状況依存型であり、ドキュメントでは完全には捉えきれない経験を通じて培われます。目標は、人々の頭の中にしか存在しない重要な運用の知識の割合を減らすことであり、非公式な知識の伝達を完全に排除することではありません。

関連の読み物：バス係数、ドキュメンテーション負債、エンジニアリングドキュメントが重要な理由。 関連ページ：自己執筆型ドキュメント、知識の保持、エンジニアリングチーム向け。