エンジニアリングリーダーが直面する主要な課題の一つは、知識のサイロを見つけることです。これらのサイロが特定されず、対処されないまま放置されると、個々の人に依存する状況が生まれ、チームが（意図せず、場合によっては無意識に）後れを取ることになります。私のキャリアのある時点で、Apple Store での iOS アプリの設定に関する小さな詳細を変更する任務を与えられたことを覚えています。通常、私たちの素晴らしい創業 iOS エンジニアがその作業を行うのですが、今回は彼が育児休暇中だったため、その任務が私に回ってきました。
作業を始めたとき、私はすぐにそれを完了することができないと気づきました — 1 時間、1 日、1 週間では無理でした。なぜなら、責任のあるエンジニアが出発前にパスワード管理システムに資格情報をアップロードしていなかったからです。結局、彼は iOS に関するすべてを迅速かつ適切に行う専門家だったので、彼がいないときにわざわざやる必要はなかったのです。しかし、この場合、私たちは違法なことをしていたことに気づいたため（最近法務チームができたばかりです）、迅速に対応する必要がありましたが、できませんでした。
そこで何が起こったか見えますか？知識のサイロが私たちを困らせました！では、今の質問は：どうすればそのような知識のサイロやその後の一人依存を避けることができるのでしょうか？いくつかのアイデアがあります。
しかしまず、なぜ知識のサイロが最初に発生するのでしょうか？#
会社の初期段階では、特定のことを知っているのが一人だけであったり、正しい権限を持っているのが一人だけであることは普通です。理想的には、これらのシナリオは制限されており、ミッションクリティカルではありません。たとえば、アニメーションを「ちょうど良く」すばやく実行できる CSS の専門家が一人だけいるのは問題ありません。しかし、デプロイをロールバックする方法を知っているのが一人だけであるのは問題です。
同様に、特定のタスクに誰が取り組むかについての議論やプロセスがないチームの例もあります。むしろ、役割は暗黙的であり、「DevOps スペシャリスト」や「バックエンドの女の子」といった内部名で呼ばれます。また、エンジニアリングマネージャーやプロダクトパートナーが、何かを緊急に行う必要があるときに特定のエンジニアに直接行くケースもあります。このようにすることで、彼らはしばしばチームのプロセスや儀式をバイパスします。
このような事例が示すことが一つあります：放置すると、潜在的な知識のサイロが開かれるリスクがあります。
どうやって知識のサイロを特定できますか？#
ここでの鍵は、一人依存を探す、あるいは聞き取ることです。そのためには、次のようなフレーズに耳を傾けてください：
👉 「本当にシニアなエンジニア X が休暇中なので、そのタスクに取り組みたくありませんでした」
👉 「創業エンジニア Y にデプロイをお願いする必要があります。彼らが権限を持っているからです」
👉 「DevOps エキスパート Z からのレビューを待っているので、マージできません。彼らがインフラストラクチャとしてのコードの専門家だからです」
要するに、何かが期待通りに進まないとき、その個人が利用できなかったことが原因であることを示唆しています。
知識のサイロを避けるための 3 つの確実な方法#
知識のサイロが簡単に一人依存を生むことができ、徐々に厄介になることがわかったので、最初からそれを避けるための 3 つのアイデアを紹介します：
1. 知識のサイロを考慮してチームを設計する#
機能専門家だけのチームを避けてください。少なくともいくつかのフルスタックエンジニアや、チームが行う可能性のあるあらゆるタイプのタスクに取り組める複数の人を持つようにしましょう。これにより、すべてのチームメンバーがあらゆるタイプのタスクに挑戦することに自信を持てる文化を作ることができます。
そのためには、低レベルのチーム設計の際に次の質問を明示的に尋ねてください：このチームが行う各タイプの作業を処理できるのは一人以上ですか？
2. チームローテーションを組織する#
もう一つのベストプラクティスは、チームローテーションやチーム「サファリ」を組織することです。メンバーが他のチームに永続的（または一時的）に参加することで、チーム間の知識共有を促進し、以前に一緒に働いたことのない他の人から学ぶ機会を提供します。
プラス面として、チームローテーションは従業員が新しいことを学ぶだけでなく、他の人の働き方に対する共感を育むことを奨励します — 組織全体でお互いの仕事に対する尊敬の念を生み出します。特定のチームから 1 人または 2 人だけがこれらのサファリ中に他のチームと協力するため、各チームは通常通り機能し続けることができます。
3. すべての重要なタスクが 2 人によって完了されることを確認する#
最後に、ソフトウェアを本番環境に投入するために必要なすべての重要なタスクを少なくとも 2 人が実行できるようにしてください。たとえ 2 人のうち 1 人だけがその作業をうまく行えるとしても、2 人がそのタスクの詳細を知っていることで、知識が一人だけに制限されることを防げます。
並行して、これらの重要なタスクの「やり方」が、全員がアクセスできる文書によってサポートされていることを確認してください。これにより、全員が知識にアクセスできるようになり、一人への依存を減らすことができます。
知識共有の実践#
良いチームは知識を共有することを実践します。これはさまざまな方法で行うことができます：
文書化に投資する#
正しい方法で文書化するためのガイドラインを作成し、すべての文書をホストする場所や情報をパッケージ化するフォーマット（たとえば、短いスクリーン録画の説明ビデオやチェックリスト）を含めます。ただし、文書化には時間がかかることを忘れないでください。また、文書はすぐに古くなったり、繰り返しになったり、混乱を招いたりする可能性があります。
文書化のガイドラインを設定し、知識共有文書を作成するための時間を確保することが役立ちます。また、これらの文書を定期的に更新するための時間を確保することも重要です。そうしないと、行ったすべての作業がすぐに無駄になってしまいます。
知識カフェセッションを組織する#
これは、「ショーアンドテル」セッションで、チームメイトがどのように X を達成するかを共有します。これらの知識共有セッションに Q&A の時間を含めることで、組織内に生産的なピアラーニング環境を作ることができます。
これらのセッションの唯一の欠点は、時には内向的な人にとっては困難であり、手を動かして学ぶことが好きな人にとってはそれほど価値がないことです。これを克服するために、ショーアンドテルのプレゼンテーションを行う意欲のある人に声をかけてください。チームの内向的なメンバーには、公共の場でのスピーキングが鍛えたい筋肉かどうかを尋ね、そうすることで彼らをそのようなセッションを主催するように動機づけることができます。
グループで作業する#
これが私のお気に入りの知識共有方法です — グループで作業する（モブプログラミングやペアプログラミング）。このような知識共有セッションでは、すべての従業員が手を動かして学ぶ機会を得ます。これにより、学びの文化を創造し、知識の蓄積を防ぐ最も価値のある方法の一つとなります。
ただし、これに対する一般的な不満は？チームの進行が遅くなることです。場合によっては、確かにそうかもしれませんが、短期的な話です。たとえば、Java のロックスターがフロントエンドの初心者とペアを組む必要がある場合、JVM のガーベジコレクションに関するバックエンドのチケットの深掘りはおそらく遅くなります。
しかし、これは特定のタスクの最大速度が短期間低下するだけであり、翌週には同じフロントエンドの初心者がバックエンド専用のタスクに参加することになります — 彼らのために低価値の作業を発明する必要がなくなります。同様に、Java のロックスターが別の会社で働くために去るかもしれませんが、新しいロックスターを雇うまで、フロントエンドの初心者が製品を前進させ続けることになります。
要するに、わずかな遅れを受け入れることで、将来的に多くの時間を節約できるため、すべてが価値あるものになります。
最後の考え#
誰もが年中無休で働くわけではなく、非常に少数の人々が永遠にあなたの会社に留まりたいと思うでしょう。これにより、知識のサイロを防ぎ、一人依存から組織を守ることが重要になります。文書化に投資し、知識共有セッションを開催し、チームローテーションを組織することが必要です。最も重要なのは、知識共有を考慮してチームを設計することです。
もしまだ知識共有を優先しない状況にあるなら、あなたの最も大きな生産緊急事態や最も重要な顧客緊急機能リクエストの日に、あなたの MVP エンジニアが幸せに子供の誕生を祝ったり、結婚したりしていると仮定することをお勧めします。
そのような仮定を持つことで、知識のサイロを防ぐ道を歩むことができるでしょう。