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