1.13 メンタリングとコーチングと知識共有
概要と動機
システムを動かしている知識は、ウィキに届くずっと前から、人の頭の中にあります。決済のリトライ処理がなぜ奇妙に見えるのかを知っている人、二度と実行してはならないマイグレーションを覚えている人、部屋の向こうからでも悪いデータベースインデックスの匂いを嗅ぎ分けられる人。その人が去るとき、休暇を取るとき、あるいは単に忙しすぎて答えられなくなったとき、知識も一緒に去ります。メンタリング、コーチング、知識共有とは、その知識を個人の頭から取り出し、チームの共有された血流に移す意図的な仕事であり、組織が学んだことを忘れる代わりに、時間とともに賢くなるためのものです。
本章は、人を育て専門性を広める実践を扱います。シニアエンジニアがジュニアをどう育てるか、技芸を軸にしたコミュニティがどう形成されるか、教えることが後付けではなく日々の仕事にどう組み込まれるか。いくつかの隣接する章と近い位置にあります。1.3章は、これらの実践が人々の登攀を助けるキャリアラダーを定義し、1.8章は、育てるべき新しい同僚を連れてくる採用とオンボーディングを扱い、1.10章は、健全な知識の流れが守る有効性を測定し、1.11章は、この仕事に資金を出し報いるマネジメントの技芸を扱います。技術面では、2.5章のコードレビューと2.7章のドキュメントは、あなたが持つ最も強力な教えの手段の二つです。
大規模なチームでは、知識共有は気の利いた付け足しではなくなり、構造的なリスク管理になります。バスファクターが1、つまり一人しか理解していないシステムは、辞表を待っている潜在的な障害です。企業は、何百ものサービスと長寿命のプラットフォームにわたってこれを感じます。政府機関は、最も鋭くこれを感じます。数十年にわたってシステムを運用し、入れ替わる公務員と契約者が人員を担い、市民向けサービスが、作った人々が去ったずっと後も、理解可能で保守可能であり続ける義務があるからです。これらの設定では、同僚に教えることは寛大さではなく、組織の記憶と継続性の仕組みです。
主要原則
- メンタリング、コーチング、スポンサーシップを区別します。人はその三つすべてを必要とし、それらは同じ行為ではありません。
- 知識共有を、時間が実際に予算化された本物の仕事として扱い、人々が時間外にやることにしてはいけません。
- バスファクターのリスクに意図して対処します。重要なシステムを、一人しか理解していない状態にしてはいけません。
- 教えることを、寛大な人への見えない税ではなく、キャリアラダーにおける可視で報われる期待にします。
- ペアリングやレビューのように、仕事をすることの副産物として知識を伝える実践を好みます。
- シニアおよびスタッフ以上のエンジニアを、他者を引き上げることからてこを得る力の乗数として育てます。
- 知識共有を、非同期で書面で機能するよう設計し、距離とタイムゾーンを越えて生き延びるようにします。
推奨事項
メンタリング、コーチング、スポンサーシップを区別する
これら三つの言葉は互換的に使われ、その混同は人々のキャリアを犠牲にします。メンタリングは経験と助言を共有することです。より経験のある人が、メンティーがまだ獲得していない視点を提供して、技術とキャリアの疑問を乗り越える手助けをします。コーチングは違います。コーチは答えを渡さず、自分自身の答えを見つける助けになる質問をし、コーチなしで次の問題を解く能力を築きます。メンタリングは「その状況で私はこうした」と言います。コーチングは「どんな選択肢が見え、それぞれ試したらどうなるだろう」と言います。
スポンサーシップは人々が見過ごすもので、昇進にとって最も重要です。スポンサーは、あなたがその部屋にいないとき、あなたのために自分自身の信用を使います。ストレッチなプロジェクトにあなたを推薦する、昇進にあなたの名前を挙げる、キャリブレーションの会議であなたの仕事を擁護する。メンタリングとコーチングは人を育て、スポンサーシップは人を前進させます。キャリアの進展に関する研究は一貫して、人を上級の役割へ動かすのは助言よりスポンサーシップであり、スポンサーを最も必要とする人々(1.12章で議論される過少に代表される集団)が、既定ではそれを得る可能性が最も低いと見出しています。これら三つの行為をチームで明示的に名指しし、上級者が心地よい最初の二つだけでなく、三つすべてを行っていることを確かめてください。
構造化されたオンボーディングバディを築く
1.8章は新しいエンジニアを入口から通し、最初の数週間が、その人が栄えるかを決めます。すべての新参者にオンボーディングバディを割り当てます。マネージャーではなく同僚で、その明確な仕事は、「些細な」質問に答え、明文化されていない規範を説明し、安全な最初の連絡先になることです。希望的な後付けではなく、時間を確保した、名前のある本物の役割にしてください。バディは新参者に、何が埋まっているかを見せます。どのサービスが脆いか、どのチャンネルで尋ねるか、デプロイが、ドキュメントの書き方と実際にどう違うか。
良いバディの仕組みは二度報われます。新参者はより速く生産性に達し、より早く自分の居場所を感じ、これは彼らが留まるかの最大の予測因子です。バディは、多くは中堅のエンジニアで、他者を育てる低リスクの最初の経験を得て、それは自分自身のシニアへの成長の一段になります。同じ少数の寛大な人々がいつも担うことのないよう、役割をローテーションし、経験が誰に当たったかに完全には依存しないよう、軽いチェックリストをバディに与えます。
実践コミュニティとギルドを育てる
実践コミュニティとは、技芸を共有し、それを発展させるために集まる人々の集団です。すべてのチームにまたがるフロントエンドエンジニア、データベースを気にかける人々、アクセシビリティの推進者。これらをギルドやチャプターと呼ぶ組織もあります。それらは1.2章のチームの境界を横断し、組織図が縦にしか人をつながなくても、知識が横に流れるようにします。ギルドは共有の標準を設定し、難しい問題を一緒にレビューし、最良のパターンを選り抜き、専門家に身近なスクワッドを超えた職業上の居場所を与えます。
失敗のモードは、誰も出たくない定例会議になってしまう実践コミュニティです。本物の仕事と本物の権限を与えて生かしてください。テストのギルドにテストの標準を所有させ、フロントエンドのギルドにコンポーネントライブラリを選ばせます。ファシリテーションをローテーションして、一人の推進者に依存しないようにします。書面の憲章と検索可能な決定の記録を保ち、ギルドが、会議が終わると消える会話だけでなく、持続的な成果物を生み出すようにします。
社内の技術トーク、ブラウンバッグ、ライトニングトークを開く
定期的な社内トークのシリーズは、投資できる最も安く、見返りの高い知識への投資の一つです。ブラウンバッグセッションは、昼食をとりながら、誰かが学んだことを説明する形式ばらないトークです。ライトニングトークは厳密に時間を区切った5分のプレゼンテーションで、ハードルをとても低くするので、初めて話す人が志願します。これらの形式は特定の知識(新しいキャッシュ層がどう動くか)を広め、そしてもっと微妙なものも広めます。教えることを当たり前にし、隠れた専門家を表面化し、昇進が依存するプレゼンテーションのスキルを築く、リスクの低い舞台を人々に与えます。
シリーズを、英雄的ではなく持続可能なものにしてください。分散した同僚や将来の同僚が見られるようにトークを録画し、録画とスライドの索引付きライブラリを保ち、一人の熱心な人が燃え尽きても途絶えないよう、運営の役目をローテーションします。新しいアイデアを取り入れるために、ときどき社外の講演者を招きます。初めて話す人を大きく祝ってください。「ここでは誰もが教える」という文化的なシグナルは、どの単一のトークの内容よりも価値があるからです。
ドキュメントを教えることとして扱い、知識の継続性を守る
ドキュメントは書類整理の作業ではなく、その瞬間とその著者を超えてスケールする教えです。ランブック、アーキテクチャの概要、「なぜこう作ったか」のメモは、会うことのない人、三年後に存在する自分のチームの姿を含め、そうした人に教える手段です。2.7章はドキュメントの上手な書き方を扱い、ここでの要点は動機づけです。持続的な文章の一つひとつがバスファクターを下げます。良い文書に捉えられた知識は、どの一人の退職も持ち去れない知識だからです。
バスファクターのリスクに意図して対処してください。一人しか理解していないシステムを特定し、それぞれを解消すべきリスクとして扱います。その人に概要を書かせ、別の誰かにコードを通じてペアで付き添い、次の変更を誰が担当するかをローテーションします。一部のチームは、意図的に「休暇テスト」を実施します。システムの専門家が本当に連絡不能になり、チームは彼らなしで運用しなければならず、どの知識が危険なほど集中しているかを正確に表面化します。目標は、辞めるかもしれない、病気になるかもしれない、あるいは単に忘れるかもしれない一人の人間の記憶に、どの重要なシステムも依存しないことです。
ペアリングとモブを知識の伝達に使う
ペアプログラミング、つまり二人のエンジニアが一つのキーボードで一つの問題に取り組むことは、二人の間で知識を動かす最速の方法の一つです。伝達がリアルタイムで文脈の中で起こるからです。モブプログラミング(アンサンブルプログラミングとも)は、これを小さなグループ全体が一つのことに一緒に取り組むところまで広げます。どちらも、生み出されるコードだけのものではありません。静かな見返りは、専門性、慣習、判断が、仕事をすることの自然な副産物として、人から人へ広がり、誰も別の研修を予定しなくてよいことです。
これらを、常にすべての仕事に義務づけるのではなく、教える価値のために意図して使ってください。新参者を、最初の本物の変更でベテランとペアにします。扱いにくく、バスファクターの高いサブシステムでモブを行い、一人より多くの人が理解して去るようにします。新しい実践の種をまくために、チームの境界を越えてペアを組みます。ペアリングとモブは、2.5章のコードレビューも改善します。レビューの多くが実質的にすでにライブで行われているからです。また、同僚の前で声に出して考え、間違えることを当たり前にすることで、1.1章の心理的安全性を高めます。
スタッフ以上のエンジニアを力の乗数として育てる
シニアエンジニアの先で、1.3章のラダーは、スタッフ、プリンシパル、ディスティングイッシュトの役割へと続き、総称してスタッフ以上の層です。優れたスタッフ以上のエンジニアの決定的な特徴はてこです。そのインパクトは、自分で書くコードよりも、周囲の全員の有効性をどれだけ引き上げるかから来ます。技術的な方向性を定め、他のチームの障害を取り除き、次世代のシニアを指導し、一つの良いアイデアを組織全体が採用する実践に変えます。力の乗数とは、その存在によって、チームの総成果が個人の総和より大きくなる人です。
こうした人々は偶然には現れないので、意図して育ててください。最強のエンジニアに、英雄的行為ではなく影響力を必要とするスコープを与えます。組織横断のイニシアチブを所有する、ギルドを導く、複数のシニアを同時に指導する。乗数の行動を人事評価で明示的に報いなければ、個人の成果だけが数えられると最良の人々に誤って教えることになり、彼らは他者を育てる代わりに問題を抱え込みます。個人のコミットだけで測られるスタッフエンジニアは、あなたが意図して武装解除した力の乗数です。
ラダー、時間の予算、指標で明示する
善意だけに頼る知識共有は、次の締め切りに押しつぶされます。構造にしてください。メンタリング、教えること、知識共有を、レベルとともに成長する明示的な期待としてキャリアラダーに書き込み、シニアに到達するには他者を育てることが本当に求められ、この仕事をする人々が昇進時にそれを示せるようにします。本物の時間を予算化します。ギルド、トーク、ドキュメント、メンタリングのための週の一定の割合を、オンコールを守るのと同じように守ります。教えることが盗んだ時間にしか行われないなら、余った時間のある人しかやらず、それは公平でも持続可能でもありません。
流れの健全性を、慎重に測定します。重要なシステムごとのバスファクター、ドキュメントのカバレッジと鮮度、最初の意味のある貢献までのオンボーディング時間、トークやギルドへの参加の幅といった先行指標を追跡します。1.10章は人を単一の操作可能な数字に還元することを戒めており、その警告はここでも全面的に当てはまります。これらのシグナルは、知識がどこに危険なほど集中しているかについての会話の糸口であり、順位表ではありません。それらが引き起こすべき問いは、「唯一の専門家が去ったら、どのシステムが最も痛手になるか」であり、それから何をするかです。
リモートで分散した知識共有を設計する
チームがタイムゾーンにまたがるとき、1.9章がますますそうなると想定するように、知識がかつて受け渡されていた廊下の会話は、単に消えます。意図してそれを置き換えなければなりません。書くことと非同期の形式を既定にしてください。録画されたトーク、検索可能な決定の記録、手入れされたウィキは、あなたが起きているときに眠っている同僚に届きますが、同期的なホワイトボードのセッションはその人を排除するからです。書かれた知識は包摂的な知識であり、たまたまあなたと勤務時間やオフィスを共有する人を特権化しません。
見つけやすさに投資してください。誰も見つけられない知識は、持っていない知識だからです。ドキュメント、録画、決定に対する強力な検索は、もう一つの会議よりも価値があります。すべてのトークを録画し索引を付けます。画面共有でリモートでペアを組み、それを普通のこととして扱います。専門家が場所を越えて互いを見つけられるよう、実践コミュニティのための明示的な仮想空間を作ります。分散した知識共有をうまくやる組織は、オフィスを知識の本当の源として扱うのをやめ、書面の記録を信頼できる唯一の情報源にした組織です。
トレードオフ: 長所と短所
メンタリングと知識共有への投資は、機能に回せたはずの時間を費やし、その緊張は本物です。表は、主な選択を誠実に整理します。
| 実践 | 長所 | 短所 |
|---|---|---|
| ペアプログラミングとモブプログラミング | 速く文脈のある知識の伝達。欠陥が少ない | 一つのタスクに二人以上。短期的には遅く感じる |
| 実践コミュニティ / ギルド | 横方向の知識の流れ。共有された標準 | 会議に堕ちうる。生き残るには本物の権限が必要 |
| 社内トークとブラウンバッグ | 安い。専門家を表面化する。話し手を育てる | 運営が推進者を燃え尽きさせる。出席が落ちうる |
| 教えることとしてのドキュメント | 著者を超えてスケールする。バスファクターを下げる | 担当者がいなければ古くなる。書くのに本物の時間がかかる |
| 構造化されたオンボーディングバディ | 立ち上がりが速い。所属意識が強い。バディも成長する | バディ自身の仕事が遅れる。質は人によって異なる |
| 明示的なラダーと時間の予算 | 教えることを公正で報われるものにする | プロセスが増える。雑に測ればチェックボックス作業になりうる |
中心的なトレードオフは、短期的なスループットと、長期的なレジリエンスと能力との間にあります。二人のエンジニアを一つのタスクにペアで付けることは、今日は成果が半分に見えますが、システムを理解する二人目の人、少ない欠陥、そして将来の速い仕事を買います。知識共有に週の一日を予算化することはベロシティの損失に見えますが、忘れず、誰かが去っても止まらず、人を使い果たす代わりに育てる組織を買います。意図して解決してください。あらゆる所ですべての実践を義務づけるのではなく、バスファクターが最も高く、人が成長する準備のできている所に投資を使います。コストは常に目に見えて即時ですが、見返りは本物でも遅れて来るので、まさに明示的な保護が必要なのです。
チームで議論すべき問い
唯一の専門家が明日辞めたら、私たちの重要なシステムのうちどれが最も痛手になり、それについて私たちは何をしていますか。 ほとんどのチームは、これを誠実にマップしたことがなく、つまり答えは、実際の退職のさなか、最悪のタイミングで発見されます。重要なサービスのリストを持ち込み、それぞれについて、重要な変更を自信を持って加えられる人全員の名前を挙げてください。そのリストが一人、あるいはゼロなら、漠然とした心配ではなく、具体的で対処可能なリスクを見つけたことになります。その後の行動は具体的です。その専門家に概要を書かせ、次の変更を二人目とペアで通し、理解が広がるよう担当をローテーションします。単一の専門家のシステムに名前を付け、それぞれのリスクを下げる計画を示せるチームは、バスファクターを不安から、管理されたポートフォリオに変えたのです。
メンタリング、教えること、知識共有は、ここで実際に報われていますか。それとも称賛されるだけですか。 他者を育てることを大切にすると言う組織と、そのことで人を昇進させる組織の間には大きな隔たりがあり、最良のエンジニアは、その隔たりを正確に読み取ります。直近の昇進と人事評価のサイクルを持ち込み、評価のどれだけの割合が、個人の成果ではなく乗数の行動に向けられたかを問うてください。三人のジュニアを静かに指導し、皆が頼るドキュメントを書いた人が、派手な機能を一人で出荷した人よりも昇進が遅かったというのが正直な答えなら、あなたは人々に教えるのをやめるよう訓練しています。求める証拠は、本物の期待としてラダーに書き込まれた教えること、そのための予算化された時間、そして他者を育てたことが見出しの理由だった直近の昇進が少なくとも一つあることです。
このチームで知識は実際にどう動き、リモートの人、新しい人、静かな人に届いていますか。 どのチームにも本物の知識伝達の経路があり、それらはしばしば見えず排他的です。廊下で下された決定、一人の上級者のダイレクトメッセージの中にある文脈、適切な人と昼食をとらないと学べない規範。新参者が最近学ぶ必要があった些細でないことを持ち込み、実際にどう学んだかをたどってから、リモートの同僚や内気な同僚が同じように学べたかを問うてください。知識が主に、同期的で対面の、形式ばらないチャネルを通じて流れるなら、1.9章と1.12章が含めよと言うまさにその人々を、体系的に不利にしています。目標は、場所、勤続年数、どれだけ声高に尋ねるかにかかわらず、全員に届く、書面で検索可能で非同期の知識への移行です。
このチームで、メンターされるだけでなくスポンサーされているのは誰で、そのパターンは、すでにリーダーシップに似ている人を静かに追っていませんか。 スポンサーシップ、つまりその人がいない場で、その人を前進させるために自分の信用を使うことは、実際に人を上級職へ動かす行為であり、既存の上級者に似た人々に、既定で最も与えられがちなものです。大きなチームでは、これが年々狭まるリーダーシップのパイプラインとして積み重なる一方、誰もがプロセスは公正だと主張します。直近二サイクルのストレッチなプロジェクトの割り当て、昇進の推薦、キャリブレーションでの擁護を持ち込み、誰が誰のために擁護したかを名指ししてください。見てみれば、パターンは通常見えます。相反する考慮は、スポンサーが、素晴らしい仕事を見た人を選ぶことで、それは能力主義に感じられながら、見える仕事を最初に得た人を構造的に優遇することです。昇進の決定が公平性のレビューに耐えなければならず、公的機関では公衆への説明責任にも耐えなければならない企業や政府では、常に同じプロファイルに流れる文書化されていないスポンサーシップのパターンは、公正さの失敗であり、監査上のリスクでもあります。求める成果は、上級者が直感では選ばなかったであろう有能な人々への意図的なスポンサーシップであり、流れが広がっていることを示せるほど追跡されていることです。
次の厳しい締め切りが来たとき、最初に切るものは何で、守ると誓った知識共有の時間ですか。 教えること、ドキュメント、ギルド、ペアリングはすべて、今日目に見える時間を、後で来る見返りに対して費やすので、どんな追い込みでも反射的に最初の犠牲者になります。大きな組織では、すべてのチームが圧力のもとで知識共有への資金を静かに削れば、集計した効果は、最も負荷がかかったまさにその時に学ぶのをやめる組織です。直近二回のデリバリーの追い込みを持ち込み、その間にメンタリングの時間、トークのシリーズ、ドキュメントに何が起きたかを誠実にたどってください。相反する考慮は本物です。締め切りが本当に勝たなければならないこともあり、そうでないふりをすれば信用を損ないます。試しているのは、その時間がオンコールのように守られているか(既定で防御され、明示的で説明責任のある決定でのみ犠牲にされる)、それともスライドの中でだけ守られているかです。システムが何年も動く企業や政府の文脈では、四半期の日付を達成するために知識の継続性を削ることは、持続的な負債を短期の勝利と引き換えにすることであり、誰かが、それがなりゆきで起きるに任せるのではなく、その取引に自分の名前で署名すべきです。
私たちの実践コミュニティは実際に何かを所有していますか。それとも、技芸に投資している気分になるために開く会議ですか。 本物の権限(テストの標準を所有する、コンポーネントライブラリを選ぶ、承認済みパターンを選り抜く)を持つギルドは、組織図が決して結ばないチームをまたいで知識を横に広げ、権限のないギルドは、人々が辞退するカレンダーのイベントに堕ちます。大きなチームでは、これは、一度見つかった解決策が、十数回まずく再発明される代わりに全員に届く主な仕組みなので、その健全性は直接的な効率の問題です。各コミュニティの憲章、直近三つの決定、出席の傾向を持ち込み、明日会合をやめたら実際に何が壊れるかを問うてください。正直な答えが何もないなら、あなたはゾンビを抱えています。相反する考慮は、本物の権限は本物の説明責任と、より遅く、より争われる決定を意味し、一部のリーダーは、横断的なグループへそれを譲ることに抵抗することです。多くのチーム、ベンダー、長寿命のプラットフォームを抱える企業や政府では、検索可能な決定の記録を伴う、憲章のあるコミュニティは、組織と契約の境界を越えて標準を一貫して監査可能に保つ方法でもあり、場当たり的な調整にはそれができません。
セクター別の視点
スタートアップ。 少数のエンジニアと短いランウェイでは、リスクはプロセスではなく、事業を支えるシステムのバスファクターが1であることです。ギルドや正式なラダーは省き、代わりに創業エンジニアが重要なサブシステムに触れるときは常にペアを組むようにし、教えることがプログラムではなく安い習慣になるよう、昼食時に5分のライトニングトークを開きます。唯一の持続的な投資は、一人しか理解していないものについての、短いランブックとアーキテクチャのメモを、その人が休暇に入った後ではなく前に書くことです。
小規模事業者。 専任の学習・開発部門はなく予算も厳しいので、知識共有を、作るのではなく、買うか借りる軽い構造として扱ってください。人員配置のあるメンタリングプログラムではなく、単純なオンボーディングバディのチェックリスト、共有のウィキ、録画されたウォークスルーに頼り、新しいプラットフォームより、すでに持っているツールを好みます。ここでの作るか買うかの判断は、通常、検索可能なドキュメントツールを買い、乏しい時間をそれを最新に保つことに使うことです。古くなったウィキはないよりも悪いからです。
大企業。 多数のチームと長寿命のプラットフォームにわたって、問題は横方向の知識の流れとガバナンスです。標準に対して本物の権限を持つ実践コミュニティ、キャリアラダーに書き込まれたメンタリングと乗数のインパクト、オンコールのように予算化された守られた時間、管理されたリスクポートフォリオとして重要なシステムごとに追跡されるバスファクター。オンボーディングバディ、索引付きのトークライブラリ、成果物としてのドキュメントを標準化し、一つのチームが見つけた解決策が全チームに届くようにし、他の運用リスクを監査するのと同じように知識の健全性を監査します。
政府。 システムは入れ替わる公務員と契約者のもとで数十年動くため、知識の継続性は気の利いた付け足しではなく、法的で説明責任上の義務です。調達では、ドキュメント、決定の記録、ランブックを、コードと同等の重みを持つ契約上の成果物として扱い、移行では、アクセスが取り消される前に理解が伝わるよう、去る職員を入る職員とペアにします。実践コミュニティは部門とベンダーにわたって標準を一貫して保ち、検索可能な書面の記録は、市民向けサービスが、最初に作った人々が去ったずっと後も、理解可能で保守可能であり続けられるようにします。
事例
スタートアップ。 12人のスタートアップは、課金システムを理解しているエンジニアが一人だけで、その人が1か月の育児休暇を取ろうとしていることに気づきます。彼らはそれを避難訓練として扱います。彼女は2日かけてアーキテクチャの概要とランブックを書き、次の三つの課金の変更を通じて同僚とペアを組みます。誰でも学んだことに5分を使える毎週のライトニングトーク・ランチを始め、物静かなジュニアが、オブザーバビリティのスタックを深く理解していることがすぐに表面化します。四半期のうちに、バスファクターが1の重要なシステムはなくなり、互いに教え合う習慣は、誰かが徹底しなければならない方針ではなく、チームの働き方の一部になります。
大企業。 数千人のエンジニアを抱えるグローバル銀行は、バックエンド、フロントエンド、データ、セキュリティという主要な専門分野ごとに、正式な実践コミュニティを運営します。各ギルドは自分たちの標準を所有し、承認済みパターンを選り抜き、検索可能なナレッジベースを維持するので、一つのチームが見つけた解決策は、まずく再発明されるのではなく、全チームに広がります。スタッフとプリンシパルのエンジニアは乗数としてのインパクトで明示的に評価され、メンタリングはキャリアラダーのシニアレベルで名前の付いた期待となり、すべてのエンジニアが知識共有のための守られた時間を持ちます。社内の技術トークは録画され索引が付けられ、どのタイムゾーンのエンジニアも、別のタイムゾーンの専門家から学べます。結果として、専門性は巨大な組織を横方向に動き、どの一つのチームの離脱も、重要な能力を孤立させることはありません。
政府。 ある国の税務当局は、数十年にわたって稼働しなければならないシステムを保守し、年月を通じて入れ替わる公務員と契約者が人員を担っています。知識の継続性は法的で運用上の必要性なので、当局は、徹底したドキュメント、決定の記録、ランブックを、コードと同等の重みを持つ成果物として義務づけ、移行の間、入る職員を去る職員とペアにして、その人が去る前に理解が伝わるようにします。実践コミュニティは部門とベンダーにわたって標準を一貫して保ち、構造化されたメンタリングは、生え抜きの公務員が、組織の記憶を担う上級の技術職へ成長するのを助けます。契約が終わったり職員が退職したりしても、システムは理解可能で保守可能なままです。当局が、次の管理者に教えることを、そもそもシステムを作ることの一部として扱ったからです。
ビジネスケース: 動機、ROI、TCO
知識共有の見返りは、リスクの低減、より速い立ち上がり、人と専門性の定着として現れます。最も明確な線はバスファクターのリスクです。単一の専門家に依存するシステムは値付けされていない負債であり、その人が去るコスト(誰も直せない障害、誰も理解していないコードの書き直し、数か月の再発見)は、事前に知識を広めるささやかなコストをはるかに上回ります。より速いオンボーディングも直接測定できます。新規採用者の生産性到達までの時間から削る一週ごとに、混乱ではなく価値を生む一週分の給与が生まれ、それは採用するすべての人に掛け合わされます。
数字が大きくなるのは定着です。エンジニアの置き換えは、採用、オンボーディング、失われた生産性で、年収のかなりの割合のコストになり、人は成長しなくなった組織を去ります。メンタリング、コーチング、スポンサーシップは、人々に投資されていると感じさせ、目に見える前進の道筋を与えるので、持てる最も強い定着のてこの一つです。採用のコストは、おもに守られた時間と軽い構造です。予算化された時間、トークのシリーズ、ギルドの憲章、バディのチェックリスト。放置のコストは、知識が集中し、ドキュメントが腐り、最良の潜在的なメンターが、自分を育ててくれる組織へ去るにつれて、静かに複利で増えます。リーダーシップに論拠を示すには、知識共有を、すでに注視している指標に結びつけてください。オンボーディング時間、定着、専門家が不在のときのインシデントからの復旧、そして1.10章の有効性の尺度です。
アンチパターンと落とし穴
- 英雄文化: 窮地を救う孤高の専門家に報い、知識を広める代わりに抱え込むことを静かに動機づけること。
- 無給の残業としてのメンタリング: 教えることが盗んだ時間に行われることを期待し、余った時間のある人だけがやり、寛大な人が燃え尽きること。
- スポンサーシップのギャップ: 助言は惜しみなく与えるが、本物の信用は既存のリーダーシップに似た人にしか使わないこと。
- ゾンビギルド: 権限も成果物もなく、出席が減っていく、定例会議と化した実践コミュニティ。
- ドキュメントの芝居: チェックボックスのために一度ドキュメントを書き、役立つより誤解させるようになるまで腐らせること。
- 無視されるバスファクター1: システムに専門家が一人しかいないと知りながら、その人が実際に去るまで何もしないこと。
- 操作可能な数字で教えることを測る: メンタリングを指標の競争にし、本物の知識伝達のない活動を生み出すこと。
- オフィス中心の知識: 重要な文脈を廊下とダイレクトメッセージに置き、リモートの人、新しい人、静かな同僚を排除すること。
- 報われない乗数の仕事: 個人の成果だけで昇進させ、最強の人々に他者を育てることはキャリアの過ちだと教えること。
成熟度モデル
- レベル1、開始: 知識共有は偶発的で個人的です。重要なシステムはしばしばバスファクターが1で、オンボーディングは沈むか泳ぐか、メンタリングは個人の善意に完全に依存し、人が去るたびに専門性も建物から去ります。
- レベル2、発展: いくつかの実践はありますが、チームごとに一貫しません。あるスクワッドはオンボーディングバディを、別のスクワッドはときどき技術トークを運営し、ドキュメントの質は大きくばらつき、メンタリングは自ら求める人に届きますが、何も予算化も期待も測定もされておらず、すべては少数の推進者の努力で生き延びています。
- レベル3、標準化: 知識共有は文書化され、組織全体で徹底されています。メンタリングと教えることは、守られた時間を伴う明示的なラダーの期待で、実践コミュニティが標準を所有し、オンボーディングバディとトークのシリーズは局所ではなくあらゆる所で標準で、ドキュメントは維持される成果物で、すべてのチームが、独自のものを考案するのではなく同じ期待に従います。
- レベル4、管理: 知識の健全性は、ベースラインに対するデータで測定され、制御されます。重要なシステムごとのバスファクター、ドキュメントのカバレッジと鮮度、最初の意味のある貢献までのオンボーディング時間、トークやギルドへの参加の幅が時間とともに追跡され、単一の専門家のシステムは、リスクを下げる計画と期限を伴う管理されたリスクポートフォリオとして扱われ、スポンサーシップと乗数のインパクトは想定されるのではなく公平性についてレビューされ、知識共有の時間は、静かに削られるのではなく、明示的で説明責任のある決定によって、締め切りから守られます。指標は、知識がどこに危険なほど集中しているかについての会話を始めるもので、順位表ではありません。
- レベル5、オーケストレーション: 教えることは継続的に改善され、組織全体に統合され、状況が変わるにつれて適応します。ペアリング、モブ、スポンサーシップ、乗数の成長は普通のことで報われ、知識はチーム、ベンダー、タイムゾーンを越えて書面で自由に流れ、レベル4の尺度は、実践を作り直し、教えることの労力の向かう先を再均衡させ、もう機能しないものを退ける定期的な改善ループに入り、どの重要なシステムも、一人の記憶に依存しません。
議論のためのアイデア
- チームでバスファクターが1のシステムを一つ挙げてください。今月それを2にするための最小の具体的な一歩は何ですか。
- キャリアラダーは、シニアに到達するのに他者を育てることを実際に求めていますか。それとも、ついでに触れているだけですか。
- 直近の評価サイクルが認識も報酬もしなかった、見えない乗数の仕事をしているのは、チームの誰ですか。
- リモートの同僚や入社したばかりの同僚が、オフィスにいる在籍の長い人が自然に吸収する知識を最後に逃したのはいつですか。
- シニアエンジニアは人々のスポンサーになっていますか(本物の信用を使う)。それとも助言を与えるところで止まっていますか。
- 最高のメンターが明日去ったら、教える実践は生き残りますか。それとも、完全にその一人の中に生きていますか。
要点
- メンタリング、コーチング、スポンサーシップは三つの別個の行為です。人はその三つすべてを必要とし、スポンサーシップは、最も必要とする人々から最も差し控えられがちなものです。
- バスファクターのリスクに意図して対処します。単一の専門家のシステムに名前を付け、ドキュメント、ペアリング、ローテーションでそれぞれのリスクを下げます。
- ペアリング、モブ、コードレビュー、教えることとしてのドキュメントのように、仕事の副産物として知識を伝える実践を好みます。
- 教えることを構造にします。キャリアラダーに書き込み、本物の時間を予算化し、乗数の行動に報い、操作を許さずに知識の健全性を測定します。
- 知識共有を、書面で、非同期で、見つけやすく設計し、距離、タイムゾーン、誰か一人の退職を越えて生き延びるようにします。
参考文献とさらなる読み物
- Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity
- Will Larson, Staff Engineer: Leadership Beyond the Management Track
- Tanya Reilly, The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change
- Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
- Sylvia Ann Hewlett, Forget a Mentor, Find a Sponsor: The New Way to Fast-Track Your Career
- Andrew Hunt and David Thomas, The Pragmatic Programmer: Your Journey to Mastery
- Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process
- Woody Zuill and Kevin Meadows, Mob Programming: A Whole Team Approach