knowledge-sharing

ナレッジ共有

開始する前に

まず EM のコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳細なアドバイスをする前に、マネージャーの簡単なプロフィールを尋ねて保存してください。必要な情報は、役職、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項です。

特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスをする前に、その人物の簡単なプロフィールを尋ねて保存してください。必要な情報は、役職・職位、在籍期間、強み、現在の課題または成長領域です。

会話の中で、後になって長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な不満、未解決の解釈ではなく、安定した事実やパターンを保存してください。

回答スタイル

最初の回答は簡潔で役立つものにしてください。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨事項を最初に述べる
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大2～3個する
• 次に取るべき具体的な行動を示し、必要に応じてマネージャーが使える正確な言い回しを提示する
• 関連するフレームワークに簡単に触れるが、各要素をすべて説明しない
• 直接的な回答を示した後でのみ、より詳しい説明を提案する

---

このスキルの使い方

• チームが他のチームですでに作られたものを作っている／知識がチーム内にとどまっている → 水平方向の情報共有がない（ギルド）
• ドキュメントがない、古い、または参照されていない → ナレッジ共有が効果的でない（ADR）
• 新入社員の立ち上がりに時間がかかりすぎる → オンボーディングの不足
• チームが情報を抱え込んだり、協力する代わりに競争したりしている → 「自分たち対相手」という考え方
• チーム間の依頼が保留状態になっている → チーム間依頼の3つの進め方

---

デフォルトの回答形式

ナレッジ共有を支援する際は、ドキュメントの作成を提案する前に、情報の流れに関する問題を診断してください。

1. 主なサイロ化の原因： 水平方向の情報共有、ドキュメント、オンボーディング、または「自分たち対相手」の考え方。
2. 根拠： 知識が共有されていないことを示す行動。
3. 最小限で有用な仕組み： ギルド、ADR、オンボーディングバディ、ローテーション、オフィスアワー、または依頼経路。
4. 担当者と頻度： 誰がその仕組みを維持し、どのくらいの頻度で実施するか。
5. 失敗パターン： どのように形骸化した官僚的な仕組みになり得るか、またそれをどう防ぐか。

大規模なドキュメント作成よりも、行動を繰り返し生み出す軽量な仕組みを優先してください。

---

サイロが生まれる理由

多くの組織では、開発者の45％が、ナレッジサイロによって週に複数回、生産性が低下していると報告しています。別のチームがすでに作ったものを作ることに時間を費やしています。どこかに存在する情報を見つけられません。誰に尋ねればよいかも分かりません。

根本原因は4つあり、それぞれに異なる解決策があります。

---

1. 水平方向の情報共有がない

従来型の階層組織では、情報は上下には流れますが、横には流れません。知識はチーム内に閉じ込められています。

解決策：エンジニアリングギルド（チャプターとも呼ばれます）。フロントエンドギルド、MLギルド、プラットフォームギルドなど、特定の領域を中心に組織されたチーム横断のグループです。

ギルドが機能するか失敗するかを分ける要因：時間の割り当ても実際の成果もない非公式な集まりになると、ギルドは失敗します。エンジニアは不満を述べ、「何か対処すべきだ」と合意した後、それぞれのチームのバックログに戻ってしまいます。ギルドが機能するには、次の3つが必要です。

1. 戦略との整合性 — ギルドのプロジェクトは、エンジニアリング上の好みだけでなく、会社の目標に結び付いている必要があります
2. 正式な承認 — リーダーシップがギルドの存在を認め、メンバーに参加時間を与える必要があります
3. メンバーの自由 — エンジニアが自分の関心やキャリア目標に基づいて、取り組む内容を選べるようにします

ギルドの実施が難しい場合は、より手軽な方法として、技術領域ごとに専用のSlackチャンネルを設けます。そこで質問やチーム横断の問題解決、解決策の共有を促してください。

---

2. 効果的でないナレッジ共有

ドキュメントを作成する文化がなければ、ナレッジは人々の頭の中や Slack のスレッド、見つけられないメールの中に埋もれてしまいます。その人たちが退職したり、対応できなくなったりすると、ナレッジは失われます。

解決策：最小限の実用的なドキュメント＋ADR

ドキュメントがうまく機能しない理由は2つあります。

• すぐに古くなり、結局誰も読まなくなります
• 作成が面倒なので、誰も継続的に取り組みません

原則は、すべてをドキュメント化するのではなく、仕事をするうえで実際に必要なことをドキュメント化することです。次の点に重点を置きます。

• 重要な意思決定の背景にある理由（何をしたかだけでなく、なぜそうしたか）
• 基本的なアーキテクチャの原則とプロトコル
• 合意済みのパターンと承認済みのサードパーティ製パッケージ

**アーキテクチャ決定記録（ADR）**は、実用面で最も優れた実装方法です。共通のテンプレートを使ってコードベース内に保存し、決定事項、背景、検討した代替案、問い合わせ先を記録します。開発者は、どこを見ればよいか、なぜ今の形になっているのかをいつでも把握できます。

標準化されたテンプレートは、ドキュメントを実際に書いてもらうための鍵です。エンジニアは書式について考える必要がなく、空欄を埋めるだけで済みます。

---

3. 不十分なオンボーディング

オンボーディングは、新入社員が組織についての最初のナレッジマップを形成する機会です。このプロセスが混乱していると、初日からナレッジのサイロ化が進みます。

解決策：体系的なオンボーディングバディ

バディは、新しく加わったメンバーを次の内容について案内します。

• ペアプログラミング — コードベース、ワークフロー、暗黙のコンテキスト（過去の意思決定、技術的負債、テストの慣習）を学ぶ最も速い方法です
• プロダクトとアーキテクチャの概要 — チームが何を構築しているか、なぜ重要なのか、システムがどのように連携しているか
• ドメインの詳細な解説 — チーム固有のツールやプロセス

同じくらい重要なのが、チームの外部での紹介です。新入社員に他チームのプロダクト概要の説明会に参加してもらいます。社内のさまざまな人に紹介します。こうした取り組みによってチーム間のつながりが生まれ、後々ナレッジが自然に流れるようになります。

---

4. 「自分たち対相手チーム」という考え方

チームが孤立したり、リソースを奪い合ったりすると、ナレッジが権力の源になります。ナレッジを共有すると、弱点が露呈したり、競争上の優位性が損なわれたりするように感じられ、リスクを伴います。

解決策：徹底した透明性と、問題の共通認識

チーム同士が互いの制約やトレードオフを理解すれば、「自分たち対相手チーム」から「自分たち全員対問題」へと考え方が変わります。効果的な構造的アプローチは2つあります。

アーキテクチャレビューセッション — 設計上の意思決定を組織全体に公開します。学習や意見反映を目的として、誰でも参加できます。これにより可視性が確保され、技術的な方向性に対する共同所有意識が生まれます。

ミートアップとライトニングトーク — 公式・非公式を問わず、チームが専門知識を共有し、個人的なつながりを築く機会になります。発表者はコミュニケーションスキルを高め、参加者はより幅広いコンテキストを得られます。

重要な追加事項は、キャリアフレームワークでナレッジ共有を奨励することです。パフォーマンスの評価方法に組み込みます。自分の仕事を完了させるだけでなく、他の人の障害を取り除き、チーム間の連携に貢献する人を評価します。

---

チーム間の依頼に対する3つの対応方法

他のチームから機能の追加、連携、システムへのアクセスなどを依頼されたとき、実際の対応方法は3つあります。

1. 対応しない： 依頼を記録して優先度を下げ、そのまま対応しません。
2. 対応を先延ばしにする： 依頼を受け付けたものの、バックログに追加します。「次の四半期に対応します。」
3. 優先する： 実際の時間を割いて対応することを約束します。

直感に反する点は、対応を先延ばしにするほうが、対応しないより悪いことがよくあるということです。

「次の四半期に対応します」と伝えると、依頼したチームはその依頼が実現する前提で準備を進めます。その連携を想定してシステムを設計し、ステークホルダーにも約束します。「次の四半期」になっても何も起こらなければ、最初に「いいえ」と伝えて別の方法を探してもらった場合より、はるかに大きなコストがかかります。

チーム間の依頼への対応方法：

• すばやく判断します。「今四半期も次の四半期も対応できません」と伝えるだけでも、「検討します」より役に立ちます。
• 回答を保留する場合は、具体的な時期を伝え、実際のカレンダーにリマインダーを設定してフォローアップします。
• 断る場合は、はっきり伝え、その理由も理解してもらえるようにします。相手はその情報をもとに、よりよい判断ができます。

断るのを遅らせるほど、そのコストは積み重なります。対応できる範囲について率直に伝えるのが早いほど、蓄積する損失は小さくなります。

---

さらに詳しく

このフレームワークの出典を知りたい場合、元の記事を読みたい場合、またはこのスキルに関連するトピックについて詳しい情報を知りたい場合は、references/sources.md をお読みください。

---

関連スキル

• team-health — チーム集中デーは、チーム間の連携を支える仕組みです
• working-with-architects — アーキテクトは、アーキテクチャレビューセッションで中心的な役割を担うことがよくあります
• management-transitions — 新入社員は、早い段階で知識共有に投資することで最も大きな恩恵を受けます
• shadow-work — グルー業務（記録されていない調整やメンタリング）は、関連する見えにくいキャパシティの問題です