shadow-work

シャドウワーク

始める前に

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

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

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

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

回答スタイル

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

基本方針：

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

---

このスキルの使い方

• チームがコミットメントを果たせない一方で、全員が忙しそうに見える -> 3種類すべてのシャドウワークを診断し、最大のキャパシティ消費要因を特定する
• 突発的なインシデントやサポート依頼でキャパシティが削られる -> タイプ1：見えない本番サポートから始める
• シニアエンジニアが、目立たない調整業務で燃え尽きている -> タイプ2：グルーワークから始める
• 記録に残らない依頼が、気づかないうちにスプリントを消費している -> タイプ3：シャドウバックログから始める
• リモートチームで、実際に誰が何を引き受けているかが見えにくい -> リモート環境による増幅問題も含める

---

回答の基本構成

ユーザーから助けを求められたら、概念の説明だけにとどめず、実践的な診断を提示してください。

1. 可能性の高いシャドウワークのタイプ - ユーザーのプロンプトにある確度と根拠を添えて、該当するタイプを挙げる
2. 2～6週間にわたって測定する項目 - 大掛かりなプロセス導入ではなく、負担の少ないシグナルを示す
3. 直ちに行う封じ込め策 - チームのキャパシティ流出を今週止めるための対応を示す
4. 構造的な対策 - 計画、オーナーシップ、ローテーション、評価、または PM／EM のワークフローで変更すべき点を示す
5. 関係者へのメッセージ - EM が PM、リーダーシップ、またはチームに伝える簡潔なスクリプトを示す

ユーザーの情報が十分でない場合は、最低限必要な情報を尋ねてください。作業の発生元、誰が引き受けているか、どのくらいの頻度で起きているか、現在どこかに記録されているかを確認します。

---

シャドウワークとは

シャドウワークとは、実際のキャパシティを消費しているにもかかわらず、計画に現れない、追跡されていない作業です。なぜなのか誰も理解できないまま、チームが継続的にコミットメントを果たせなくなる原因になります。シャドウワークには3つのタイプがあり、それぞれに異なる対応が必要です。

重要なマネジメント上の一手は、「もっと頑張る」ことでも「見積もりを改善する」ことでもありません。まず、その作業をチームがトレードオフを正直に判断できる程度に可視化することです。

---

診断の質問

対策を提案する前に、次の質問を活用してください。

• 発生元： 計画外の作業はどこから発生していますか。本番環境、他のチーム、PM からの依頼、マネージャー、エンジニア、顧客、またはコードベース自体ですか？
• 担当者： 通常、誰が対応していますか。均等に分散していますか。それとも、シニアなメンバー1～2人に集中していますか？
• 可視性： チケット、スプリントボード、インシデントログ、レビュー資料、または人事評価に記録されていますか？
• パターン： 繰り返し発生しますか。季節的ですか。特定のプロジェクトに限られますか。それともランダムですか？
• コスト： 主にカレンダー上の時間、集中できる時間、精神的エネルギー、ロードマップのキャパシティ、または昇進評価の実績のどれを消費していますか？
• トレードオフ： この作業が発生したとき、計画していたどの作業が、気づかれないまま後回しになっていますか？

---

タイプ 1：見えない本番サポート

アドホックなインシデントのトリアージ、アラートの調査、サポートチームからの依頼、手動での修正、そしてチケットシステムに記録されない顧客からのエスカレーションです。

追跡しなければ、パターンを見落とします。同じ15分の手動修正でも、年間で数百時間を費やすことになりかねない一方で、根本原因は修正されないままです。チームには余力があるように見えるのに、成果を出せない状態が続き、その理由を示すデータもありません。

対処法：

• 計画外のサポート作業用に、軽量なカテゴリを作成します。チケット管理システムのタグだけでも構いません
• 4～6週間追跡したら、頻度を分析します。繰り返し発生する問題、依頼元、対応を引き受けている人の上位項目を特定します
• 1人が恒常的な「人間のサーキットブレーカー」にならないよう、緊急修正の担当をローテーションします
• 繰り返し発生する手動修正を、先送りコストを明示したロードマップ項目に変えます

---

タイプ 2：グルーワーク

コードレビュー、メンタリング、オンボーディング、ドキュメント作成、調整、チーム間の橋渡し、そして「ちょっと手伝って、ブロックを解消してくれない？」といった仕事です。こうした仕事は、シニアエンジニアに偏って降りかかります。

グルーワークを管理しないと、2つの問題が生じます。担い手は評価されないまま燃え尽き、担わない人は組織の機能を支える仕事を学ばないまま昇進します。

対処法：

• 人事評価の面談や昇進資料で、グルーワークを明確に取り上げます
• ペア作業、ライブレビューセッション、オフィスアワー、担当のローテーションを通じて、スキルをより多くのメンバーに広げます
• シニアエンジニアが周囲の生産性を高める役割を担っているときは、集中して作業する時間を確保します
• グルーワークがチームで共有する能力ではなく、特定の人のデフォルトの役割になっていないかを追跡します

---

タイプ 3：シャドーバックログ

公式ロードマップ外の作業です。PMが非公式に修正を依頼すること、エンジニアが正しいと分かっている遠回りを選ぶこと、他チームと直接調整して予定外の連携を進めること、そして合計すると決して「小さくない」のに、個別には「ちょっとした依頼」に見える作業が含まれます。

こうした作業は、ビジネス部門とエンジニアリング部門の信頼を損なう一方で、実際のキャパシティの大部分をひそかに消費することがあります。リーダーには、キャパシティがどこに使われたのか見えないまま、計画を立てては達成できないチームに見えてしまいます。

対処法：

• 計画時に、「スコープに含めていないものの、依頼されそうな作業は何ですか？」と尋ねます
• 環境が不安定なときは、シャドーバックログ用のキャパシティを明示的に確保します。データがない場合は、まず10～20％から始めます
• 非公式なPMからの依頼は、依頼者を責めずに公式バックログへ移します
• ロードマップのトレードオフを検討する根拠として、シャドーバックログのデータを定期的に関係者へ提示します

---

リモート環境での増幅問題

リモートチームでは、シャドーワークは二重に見えにくくなります。マネージャーも、それを何気なく目にすることができないからです。そのため、チームメンバーの昇給や昇進を提案するときに、自然に示せる根拠がなく、キャパシティが消費されている状況も把握しにくくなります。

だからこそ、軽量な追跡習慣を身につけることは、余計な負担ではなくマネジメントの基盤です。チームが実際の仕事を評価してもらえるようにし、EMがキャパシティについて話し合うための根拠を提供します。

---

関係者との会話例

直接的で、相手を責めない言葉を使います。目的は、作業の依頼元を責めることではなく、トレードオフを明らかにすることです。

PMとの会話： 「これらの依頼は実際の作業なので、見える形にしたいと思っています。バックログ外で対応し続けると、計画したロードマップを達成できない状態が続き、どちらにも十分なデータが残りません。ボードに追加して、何を後回しにするか決めましょう。」

リーダーとの会話： 「チームがコミットメントを達成できないのは、見積もりがいい加減だからではありません。計画に反映されていない計画外の作業を引き受けているからです。今後数週間、これを追跡して、繰り返し発生する依頼元、コスト、選択肢をまとめて報告します。」

グルーワークを抱えすぎているシニアエンジニアとの会話： 「あなたが多くの調整やレビューを引き受けているのは分かっています。その一部は重要ですが、見えないままになったり、成長につながる仕事から遠ざけたりしたくはありません。評価すべきこと、ローテーションすること、やめることを一緒に決めましょう。」

---

詳しく知る

ユーザーがフレームワークの出典を尋ねたり、元の記事を読みたいと言ったり、このスキルのトピックについてさらに詳しい情報を求めたりした場合は、references/sources.mdを読んでください。

---

関連スキル

• roadmap-planning - シャドウワークは無視せず、キャパシティプランニングで明示的に予算化する必要があります
• working-with-pm - オフレコの依頼は、単なるキャパシティの問題ではなく、PMとEMの関係性の問題です
• retaining-developers - 評価されないまま目に見えないグルー作業を担うシニアエンジニアは、「評価されていない」定着状態にあります
• knowledge-sharing - グルー作業は、ドキュメントやオンボーディングの不備と重なることがよくあります