team-health

チームの健全性

始める前に

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

.agents/em-context.md が存在しない場合は、詳しい助言をする前に、まず最低限のマネージャープロフィールを尋ねて保存します。必要な情報は、役職・職位、チームの人数、チームのミッションまたは担当領域、現在の課題または優先事項です。

会話で特定の人物が中心となっており、.agents/reports/[name].md が存在しない場合は、詳しい助言をする前に、まずその人物の最低限のプロフィールを尋ねて保存します。必要な情報は、役職・レベル、在籍期間、強み、現在の課題または成長領域です。

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

回答のスタイル

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

基本方針：

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

---

このスキルの使い方

• 何から始めればよいかわからない／健全性の診断が必要 → 効果的なチームを支える 5 つの要素
• チームの進みが遅い、約束した目標に届かない、または燃え尽きている → チームの健全性の状態
• チームが持続不可能なペースで動いている → チームの強度を管理する
• 「チームは十分に努力していない」と誰かが言った → 「チームは十分に努力していない」
• チームに意欲がない、またはつながりが薄いように見える → エンゲージメントの積み重ね
• チームミーティングを計画していて、内容のアイデアが必要 → チームミーティング
• チームのオフサイトまたは集中日を計画している → チーム集中日
• 活動のアイデア集（成長／つながり／インパクト）が必要 → references/activities.md を読む
• レトロで毎回同じ問題が浮上する → レトロがマンネリ化したとき
• チームメンバー同士の信頼が足りないように見える → 信頼のバッテリー
• 問題が起き、ポストモーテムの実施が必要 → 非難のないポストモーテム
• 技術力は高いが、結束が弱く感じられる → 結束したチームとチームの結束を損なう行為
• チームにどこまで共有すべきかわからない → チームの健全性を示すシグナルとしての透明性
• 監視文化を生み出さずに柔軟な働き方を示したい → 積極的に休暇を取る

---

回答の基本構成

チームの健全性について支援する際は、活動を提案する前に診断します。

1. 健全性の評価： 士気、安全性、信頼性、明確さ、強度、信頼、またはエンゲージメント。
2. 根拠： ユーザーが観察したことと、そこから考えられる意味。
3. 当面の安定化策： 今週取り組むこと。
4. 構造的な介入： ミーティング、習慣、透明性の改善、回復計画、レトロの改善、または活動。
5. 注視するシグナル： チームが改善しているかを判断するためにモニタリングするもの。

チームが燃え尽きている、または高強度モードにある場合は、士気を高める活動を提案する前に、回復と優先事項に取り組んでください。

---

効果的なチームを支える5つの要素

Google の Project Aristotle では、何がチームの効果を実際に高めるのかを見つけるため、数百のチームを調査しました。重要度の高い順に、上位5つの要素を紹介します。

1. 心理的安全性 — チームメンバーは、不安や恥ずかしさを感じずにリスクを取れますか？
2. 信頼性 — チームメンバーは、互いが期限内に質の高い仕事をすると信頼できますか？
3. 構造と明確さ — 目標、役割、実行計画は明確ですか？
4. 仕事の意義 — その仕事は、各チームメンバーにとって個人的に重要ですか？
5. インパクト — チームは、自分たちの仕事が重要だと信じていますか？

順番が重要です。5つすべてが必要ですが、心理的安全性は土台となる要素です。これがなければ、ほかの要素は機能しません。人は、批判を恐れていると、懸念を口にしたり、アイデアを共有したり、問題を指摘したりしません。

実践的な活用方法として、各メンバーがそれぞれの要素を5段階で評価する、短いチーム演習を行います。評価が最も低い項目を確認しましょう。平均評価が最も低い要素が、最も優先して取り組むべき領域です。自分が最も緊急だと感じる領域ではありません。

---

同僚のチームも重要です

マネージャーに「あなたのチームは誰ですか？」と尋ねると、ほとんどの場合、直属の部下を挙げます。同僚は決して挙げません。

しかし、マネージャーの同僚グループもチームであり、同じ5つの要素が当てはまります。同僚との関係を単なる取引（あるいは競争）と捉えるエンジニアリングマネージャーは、サイロ化を招く状況を生み出します。知識が共有されず、チーム間の連携が遅れ、境界で問題が起きたときに責任の押し付け合いが発生します。

部下との関係づくりに注いでいる信頼、対立への向き合い方、説明責任、コミットメントを、同僚の EM との関係にも注ぎましょう。

---

チームの健全性の状態

An Elegant Puzzle（Will Larson）によると、チームは常に次の4つの状態のいずれかにあり、それぞれ EM に異なる対応が求められます。

状態	状況	対応
遅れが拡大している	スプリントごとにバックログが増え、チームは圧倒され、約束した作業が遅れます	キャパシティを増やします。採用が直接役立つのは、この状態だけです。短期的には、コミットする作業の範囲を縮小し、そのことをステークホルダーに率直に伝えます。
現状維持に追われている	チームはリリースを続けていますが、プロダクト開発のみで、技術的負債に対処したり改善に取り組んだりできていません	WIP を減らします。チームが取り組む対象を絞りましょう。新しい作業を始める前に既存の作業を終わらせ、余裕を作ります。
負債を返済している	チームは技術的負債の解消に積極的に取り組んでおり、ベロシティが遅く感じられます	この作業を守ります。負債を解消するまで、新たなプロダクト開発の要求からチームを守りましょう。この状態は一時的であり、必要なものです。緊急性を理由に中断させないでください。
イノベーションに取り組んでいる	技術的負債が少なく、安定してデリバリーできており、チームには実験に取り組む余裕があります	慎重に維持します。この状態は不安定です。チームの現在の働き方と両立できる作業だけを追加しましょう。不適切な人材採用やプロジェクトによって、すぐに「現状維持に追われている」状態へ逆戻りすることがあります。

最もよくある間違いは、すべての状態に同じ対応をすることです。「遅れが拡大している」チームに負債の返済も求めてもうまくいきません。現状維持に追われている状態でイノベーションを試みてもうまくいきません。まず現在の状態を診断し、それから適切な対応を取りましょう。

---

チームミーティング

多くのエンジニアリングマネージャーは、チームミーティングに十分な時間を割いていません。忙しすぎたり、時間を無駄にすることを恐れたりして、まったく開催しないか、議題を用意せずに実施しています。よくある言い訳は、「何かいいことを言えるときに議題を作ります」です。その結果、年に3回しかミーティングが開かれません。

チームミーティングは、1:1 では代替できない、共通認識、共通の記憶、そしてつながりを生み出します。

ミーティング内容のアイデア 7 選

1. 次のプロジェクトを確認する：ロードマップの中でどのような位置づけなのか、なぜ選ばれたのか、何を達成しようとしているのかを説明します。技術的なキックオフの代わりではなく、背景の共有と認識合わせを目的とします。

2. 最近のインシデントを振り返る：何が起きたのかを確認し、次の発生を防ぐ方法をチームでブレインストーミングします。

3. 開発者が担当したプロジェクトを紹介する：発表スキルを高めるとともに、チームの他のメンバーも新しいことを学べます。

4. 社内の他のチームの興味深いプロジェクト：クライアントとの新しい PoC や、他のチームが進めている技術的な取り組みを紹介します。

5. ビジネスの最新情報：チームが普段知らない情報を共有します。営業の最新情報、利用状況の指標、次回の資金調達ラウンドの計画などを伝えます。

6. ゲストを招く：

   • 営業担当者 — 大規模なプロジェクトを始める前に、顧客の背景やプロジェクトを受注した経緯を共有してもらいます
   • デザイナー — 仕事の進め方、大切にしていること、意思決定の指針について話してもらいます
   • プロダクト担当 VP — アジェンダ、ロードマップの見方、今後 6 か月の予定について話してもらいます
   • 自分のマネージャー — 特に先行きが不透明な時期に招きます
   • 他チームのリーダー、アーキテクト、サポート、カスタマーサクセス、またはその他の部門横断的な役割の人

7. 楽しむ：一緒にランチをしたり、短いゲームをしたりします。リモートチームなら、Drawize のようなものがおすすめです。

頻度

普遍的な正解はありません。週 1 回、30 分のミーティングでは、質を保つのが難しいでしょう。まずは 月 2 回、30 分 から始め、うまくいっているかを見て調整するのが妥当です。

最も大切なのは、始めて、キャンセルしないことです。思いとどまる前に、定例ミーティングを設定しましょう。

---

チームフォーカスデー

優れたチームと平均的なチームの違いは、多くの場合、次の 3 つの点に表れます。

1. チームのコミュニケーションのあり方 — 何を伝えるかだけでなく、どのように伝えるか
2. 対立への対処方法 — 向き合うのか、それとも放置してこじらせるのか
3. 単なる同僚ではなく、一人の人間として互いにつながりを感じられているか

チームフォーカスデーは、この 3 つすべてに取り組むための体系的な方法です。年に 2 回、丸一日チームでオフィスを離れ、仕事と交流を組み合わせて過ごします。

形式

• オフィスの外で行う。 場所が変わると雰囲気も変わります。別の場所で会議室を借りたり、コワーキングスペースに行ったり、オフサイト会場を見つけたりする方法があります。大切なのは、いつもの環境から離れることです。
• 6 か月ごとに行う。 意義を感じられる程度に定期的でありながら、特別感が薄れない頻度です。
• PM も参加する。 エンジニアだけの日ではありません。PM のパートナーがいる場合は、参加してもらいましょう。共通認識の形成と認識合わせは、対面で行うのが最適です。
• 仕事と交流を組み合わせる。 一日中会議室で過ごすのでも、活動だけで一日を過ごすのでもありません。どちらも大切です。

フォーカスデーの内容のアイデア 10 選

1. ロードマップの確認： 目指す方向とその理由を確認します。今後 6 か月に予定していることと、どのようなトレードオフがあったかを話し合います。
2. 技術的負債の洗い出し： チームの進行を妨げているものは何でしょうか。エンジニアが率直に挙げられる場にします。
3. 振り返り： この 6 か月でうまくいったことは何でしょうか。うまくいかなかったことは何でしょうか。
4. 「X をもっとやりたい」： 各自が一つずつ挙げます。批判はしません。その後、優先順位を決めます。
5. チーム間の関係： 他のチームとの間に摩擦はありますか。対面のほうが表面化しやすくなります。
6. プロセスの見直し： スタンドアップ、コードレビュー、デプロイなど、うまくいっていることや負担になっていることを確認します。
7. ペアでのキャリア相談： エンジニアが今後のキャリアについて話し合う時間を設けます。
8. ハッカソンまたはプロトタイプの時間： 実験的なものを作ります。リリースするプレッシャーはありません。
9. 互いに教え合う： 各自が、他の人が知らない自分の知識について 10 分間話します。
10. 一緒に食事やアクティビティを楽しむ： 最後は交流の時間で締めくくります。無理に楽しむのではなく、皆で選んだことをします。

---

チームの健全性を示す透明性

チームと何を共有し、何を共有しないかは、あなたや会社に対するチームの信頼を形作ります。

チームの盾になりすぎないでください。 チームをあらゆる厳しい現実から守ろうとするマネージャーは、メンバーを守っているつもりです。しかし実際には、悪い知らせにいつも不意を突かれ、備えたり対応したりする手段のないチームを作り出しています。本当に機密の情報もありますが、「悪い知らせ」の大半は共有するべきです。

失望の境界線。 チームがいずれ知ることになる情報、たとえばロードマップの変更、組織再編、財務上の圧力、戦略の転換などは共有しましょう。誰か別の人から聞いたり、事後に知ったりすれば、あなたの信頼性は損なわれます。たとえ不確かでも、早めに共有するほうがよいでしょう。

財務状況を共有しましょう。 事業の状況を理解している開発者は、より適切な判断を下せます。緊急性、スコープ、トレードオフを理解できるからです。スプレッドシートを見せる必要はありません。しかし、「好調な四半期で、投資を続けられる余裕があります」と伝えるか、「ここ数カ月は厳しく、効率的に進める必要があります」と伝えるかで、メンバーの仕事に対する考え方は変わります。

船にたとえて考えてみてください。船が沈みかけているかどうかは、乗船している全員が知っています。乗組員が状況を理解するのに、取締役会の開催は必要ありません。チームに、乗客ではなく乗組員として行動できるだけの背景情報を伝えましょう。

ロードマップの草案を共有しましょう。 優先順位を確定する前に、検討中の内容とその理由を共有してください。メンバーは草案を受け止められます。受け止められないのは、何も知らされないまま完成済みの計画を渡されることです。

---

チームの負荷を管理する

毎週同じように進める必要はありません。常に全力疾走しているチームは燃え尽きます。ペースを落とし続けるチームは鋭さを失います。大切なのは、今どのゾーンにいるかを把握し、意識的に選ぶことです。

持久力トレーニングを参考にした、シンプルな5ゾーンモデルです。

ゾーン	感覚	使用する場面
1 — ごく軽い	落ち着いていて、持続可能で、プレッシャーが低い	集中的な期間の後の回復、新メンバーのオンボーディング
2 — 軽い	安定したアウトプット、追い込みなし	年間の大半で基準とする健全なペース
3 — 中程度	集中しており、多少の緊急性がある	通常のスプリント期間、定期的なデリバリーサイクル
4 — ハード	エネルギーが高く、期限が厳しい	製品のローンチ、重要なマイルストーン
5 — 最大	全力投入、持続不可能	本当の危機に限る — 本番環境の停止、成否を分ける局面

多くの EM が犯す間違い： ゾーン4を通常の状態にしてしまうことです。ゾーン4は生産的に感じられます。熱意を持って取り組んでいるようにも見えます。しかし、そこには上限があります。チームはその状態を維持できず、回復に大きなコストがかかります。

活用方法：

• ゾーンを明示しましょう。「ローンチがあるため、今回のスプリントはゾーン4です」。ゾーンに名前と終了日があると、チームは高負荷を受け入れやすくなります。
• ゾーン4または5の期間の後は、ゾーン2で回復する計画を立てましょう。すぐ次のハードなスプリントに取りかからせないでください。
• 回復期間なしでチームが常にゾーン3〜4にいるなら、それはモチベーションの問題ではなく、仕事量の問題です。

---

「チームは十分に懸命に働いていない」

誰かからチームが十分に懸命に働いていないと言われたら、その意見を退けるのも、批判的に検討せず受け入れるのもやめましょう。根本原因は大きく3つあり、それぞれに異なる対応が必要です。

1. 「ハッスル」が足りない — 外部の人が、目に見える努力のサインを感じられない状態です。メンバーはリラックスしていて、急いでおらず、忙しそうに見えません。特にリモート環境では、パフォーマンスの差ではなく、認識のずれであることがよくあります。

2. 目に見える成果が足りない — コミュニケーションの不備、理不尽な期待、または優先順位付けの不備が原因です。チームは働いているものの、ステークホルダーには進捗が見えていません。これはコミュニケーションや透明性の問題です。

3. 情熱が足りない — チームのモチベーションが低い、または仕事から距離を置いているように見える状態です。これは士気やエンゲージメントの問題です。

どの場合も、フィードバックを退けないでください。あなたの目に映るものと、フィードバックをした人の目に映るものの隔たりを埋める方法を探しましょう。多くの場合、仕事をより見えやすくするだけで十分です（更新の頻度を上げる、進捗をより明確に伝えるなど）。

---

大きな声で退勤する — 許可を求めない

開発者から「これからは在宅で仕事を続けます」と言われたとき、「わかりました」と返すのはやめましょう。自分の事情を説明したり、許可を求めたりする必要があると思わせてしまいます。

代わりに、次のように伝えましょう。「自分の時間は自分で管理できると信頼しています。在宅で仕事を続けるときに、わざわざ伝える必要はありません。」

そして、自分でも実践しましょう。早めに退勤するとき、「子どもたちが寝たあとに仕事を続けます」と付け加える必要はありません。ただ退勤しましょう。理由を説明せずに伝えましょう。これは、監視されなくても各自が自分の時間を管理できると信頼していることを示します。柔軟な働き方における心理的安全性とは、まさにこういうものです。

---

レトロがマンネリ化しているとき

レトロで同じ問題ばかりが出てきて解決されない場合は、次の方法を試してみましょう。

• 質問を変える。 4Ls形式（気に入ったこと、学んだこと、足りなかったこと、望んでいたこと）にすると、話題に上がる内容が変わります。
• ツールを変える。 オンラインのレトロツール（EasyRetro、Parabolなど）を使うと、何度も形だけのレトロを繰り返してきた人たちの意欲を取り戻せる場合があります。
• メタレトロを行う。 過去6か月のレトロを要約します。どんなテーマが繰り返し現れていますか？ なぜ解決されていないのでしょうか？
• 「最後に公開」形式にする。 ほかの人の内容を見ずに、全員が項目を書きます。一斉に公開します。アンカリングを減らせます。

レトロで同じことが繰り返される根本的な原因は、たいてい、そこから生まれた内容が行動につながっていないことです。形式を変える前に、過去のレトロで出た内容が実際に取り上げられたことがあるか確認しましょう。

---

エンゲージメントの階層

個人のエンゲージメントには、4つの層がそろっている必要があります。それぞれ、1つ下の層に依存します。

1. 個人 — この人は、根本的に仕事から活力を得ていますか？
2. 役割 — 仕事で強みを生かし、成長できていますか？
3. チーム — 仲間とのつながりを感じ、尊重されていますか？
4. 会社 — 会社の方向性を信頼し、ここで働いていることを誇りに思っていますか？

誰かの意欲が低下しているときは、どの層に最初の問題が生じたのかを見極めましょう。会社のコミュニケーションを改善しても、役割が合っていない人には効果がありません。役割を改善しても、チーム内の関係が悪い人には効果がありません。

---

エンジニアの感情状態をパフォーマンスのシグナルとして捉える

スタンドアップの前に緊張する。スプリントのたびに疲れ果てる。意見を求められなかった決定に苛立つ。こうしたことは個人の問題ではなく、チームの健全性を示すシグナルです。

心身がストレス状態にあるとき、最高のパフォーマンスを発揮できる人はいません。1対1のミーティングで、セラピーの質問ではなく、状況を把握するための質問として、*「今週はどんな気持ちでしたか？」*と尋ねましょう。本音で答えられる余地をつくりましょう。

職場で誰かの神経系が常に脅威を感じている状態なら、それはパフォーマンスの問題であると同時に、環境の問題でもあります。

---

ジェル化したチームとチームサイド

Peopleware（DeMarco & Lister）によると、ジェル化したチームとは、まとまりのある一つの単位として結束したチームのことです。メンバーは互いを信頼し、息を合わせて行動し、個々のスキルレベルから予想される以上の成果をチームとして生み出します。ジェル化したチームは本当にまれであり、その価値は非常に大きいものです。

ジェル化に必要なこと：

• 共有の状況認識と信頼を築くために、十分な時間を一緒に働くこと
• 大切にする価値のある課題があること――単に割り当てられた仕事ではなく、チームが自分たちのものとして責任を持てる目標
• 流れを妨げ、経営陣がチームを信頼していないという印象を与える、官僚的な摩擦がないこと

チームサイド――結束を壊すパターン：

要因	その例
防衛的なマネジメント	マイクロマネジメント、判断への口出し、絶え間ない進捗確認――チームを信頼していないという印象を与えます
分断された作業環境	集中して作業するのが不可能なオープンオフィス、または非同期作業の共通ルールがないリモート環境
断片化された仕事	チームメンバーが無関係なプロジェクト間を頻繁に行き来し、誰も何も完了できません
スケジュール優先の品質低下	エンジニアが誤りだと分かっている近道を強制し、仕事への誇りを損ないます
見せかけの締め切り	人工的な緊急性があり、すべてのスプリントで「これは最重要です」と言い続けることで、エンジニアは緊急性など無意味だと学びます
派閥による支配	チームの一部を内輪として扱い、残りを実装担当者として扱うマネージャー

多くのことを正しく行っていても、こうした要因のどれか一つでジェル化したチームを壊してしまうことがあります。最もよくあるのは、関与し続けることを装った防衛的なマネジメントです。

---

信頼バッテリー

It Doesn't Have to Be Crazy at Work（Basecamp/Fried）によると、二人の間のあらゆる関係には暗黙の信頼バッテリーがあり、残量は約50％から始まります。

相手が言ったとおりに行動すると、バッテリーは充電されます。約束したとおりに返信し、引き受けたものをリリースし、約束したとおりに状況に対処する、といった行動です。そうしなければ、バッテリーは消耗します。

信頼は主に、温かく、友好的で、熱意のある態度によって築かれるわけではありません。約束を果たすことで築かれます。毎スプリント、静かに引き受けたことをリリースするエンジニアは、皆をとてもいい気分にさせながらも絶えず約束を果たせない人より、同僚との信頼バッテリーが充電されています。

実践での活用：

• チームの誰かが対人関係で苦労していて、同僚が冷たかったり、関心がなさそうだったりする場合は、性格の問題だと結論づける前に、その人の成果の実績を確認してください。バッテリーが消耗していると、関係性の問題に見えることがよくあります。
• 新入社員が孤立しているように見える場合、まだ信頼バッテリーを充電する時間がなかったのです。オンボーディング活動よりも、早い段階で小さくても目に見える成果を挙げられるようにするほうが、バッテリーを速く充電できます。
• マネージャーとして、チームとのあなた自身の信頼バッテリーが、あらゆることの土台になります。チームは、あなたが言ったことを実行するか、戦うと約束したもののために実際に戦うかを見ています。

---

非難のないポストモーテム

問題が発生したとき――本番環境でのインシデント、デプロイの失敗、重大なバグなど――従来の対応は、責任者を見つけて正すことです。業界標準となったEtsyのアプローチは異なります。その時点で得られた最善の情報とツールを使って、人々は行動したと考えます。目標は、誰が問題を引き起こしたかを見つけることではなく、システムがどのようにして問題の発生を許したのかを理解することです。

非難を優先するポストモーテムが逆効果になる理由：

• 人々は発言を控えるようになります。何が起きたかを隠したり、自分の責任を小さく見せたりします。
• 実際に何が起きたのか、その詳細な全体像を把握できなくなります。
• システムではなく人を正すことになり、次の人が同じ過ちを犯します。

非難のないポストモーテムの進め方：

1. 責任を問わずに、出来事のタイムラインを作成します。「誰が何を間違えたか」ではなく、何がどの順序で起きたかを記録します。
2. 各判断を下した時点で、人々は何を知っていたかを問いかけます。ほぼ間違いなく、得られた情報をもとに最善の判断をしていたはずです。
3. これが起きないようにするには、何が違っていればよかったかを問いかけます。通常、その答えに含まれるのはツール、プロセス、アラートの不足、あるいはコンテキストの不十分さであり、個人の過失ではありません。
4. 人々の行動だけでなく、システムを変えるアクションアイテムを記録します。

EMの役割： トーンの手本を示します。ポストモーテムを主導するあなたが犯人を探しているなら、チームは自分たちを守ろうとします。システムが何を許したのかを心から知りたいと思っているなら、チームは真実を話してくれるでしょう。

非難がないことは、責任を問わないことではありません。個人の過失が繰り返される場合や、意図的な違反があった場合は別の状況です。ただし、それらは例外であり、初めから想定すべき説明ではありません。

---

さらに詳しく

ユーザーがフレームワークの出典を尋ねたり、原文の記事を読みたいと言ったり、このスキルのトピックについて詳しい情報を求めたりした場合は、references/sources.mdを参照してください。ドライバー（成長／つながり／インパクト）別に整理されたチームアクティビティのアイデア集については、references/activities.mdを参照してください。

---

関連スキル

• 1on1s — 個人のコンディションに関する問題を把握し、対処するための主な場
• feedback — チーム内の具体的な行動上の懸念に対処するためのスキル
• engineer-motivation — 個人レベルでのモチベーションとエンゲージメントへの介入
• roadmap-planning — チームの健全性を考える際の入力となる、業務量とキャパシティ
• retaining-developers — 5状態の定着フレームワークは、チームの健全性を示すシグナルに直結します