mcpField
M
managing-yourself

managing-yourself

github.com/manager-dot-dev生産性116130 回インストール25 週間前に更新
リポジトリ

managing-yourself について

エンジニアリングマネージャーが自らのマネジメントを振り返り、役割上の落とし穴、対立のパターン、業務上の障害、失敗後の関係修復に取り組むためのスキルです。状況を見極め、枠組みを一度に並べるのではなく、具体的な次の行動を示します。

主な機能

  1. 01マネージャーの典型的な落とし穴の特定
  2. 02ドラマトライアングルによる対立分析
  3. 03チーム業務の障害の点検
  4. 04マネジメント上の失敗後の修復
  5. 05状況に応じたフレームワーク選択

活用シーン

  1. 01チームの成果が低い原因の検討
  2. 02関係者との対立への対応
  3. 03マネジメント上の伝達ミスの修復
  4. 04継続する管理上の負担への対処

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/manager-dot-dev/manager-skills --skill managing-yourself

インストール後、Claude Code で/managing-yourselfを入力して読み込まれたか確認します。

同梱ファイルreferences/extended.mdreferences/sources.md

詳細

自分自身をマネジメントする

始める前に

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

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

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

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

回答スタイル

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

基本方針:

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

このスキルの使い方

まず状況を特定してください。

  • 行き詰まりを感じている、または EM の仕事を正しくできているか不安に思っている → EM が行き詰まる 10 のパターン(ここから始めてください)
  • 何度もうまくいかず、自分が被害者のように感じている → ドラマの三角形
  • マネジメントで悪い日が多い → マネージャーに悪い日が多い理由
  • チームの意欲が低い、または成果が少ないように見える → 道を切り開く
  • 誰かに対してミスをして、関係を修復する必要がある → 修復
  • 解決しても同じ問題が繰り返し起きる → 問題と両立しない二項対立
  • EM としての強みが失敗の原因になりつつある → references/extended.md — 二分法を読む
  • 全体像/プロダクトとのつながりを感じられない → references/extended.md — バルコニー視点を読む
  • 予期しない批判、副社長からの厳しい追及、重大な障害に直面している → references/extended.md — 冷静さを保つ:BAA フレームワークを読む
  • 成長/つながり/インパクトに費やす時間の配分を監査する → references/extended.md — EM グリッドを読む
  • コーディングスキルを維持する、または手を動かし続ける → references/extended.md — メーカー/マネージャーモードを読む
  • 行動に移す前に、マネジメント上の判断についてフィードバックを得る → references/extended.md — 自分の判断をコードレビューするを読む
  • 自分の業績評価を書く → references/extended.md — 自分のマネージャーとしての差分を読む
  • エンゲージメントの低さやチーム文化の問題を診断する → references/extended.md — 反転モデルを読む
  • 自分の時間配分を監査する → references/extended.md — LNO フレームワークを読む
  • 問題が起きて、見落としていた点を振り返っている → references/extended.md — 極端な当事者意識を読む
  • 厳しい時期に、チームが怖がったり不安を感じたりしている → references/extended.md — リーダーが恐れを受け止めるを読む
  • マネージャー、上司への働きかけ、またはシニアリーダーシップに関すること → managing-up スキルを使う

デフォルトの回答形式

EM の自己診断を支援するときは、具体的かつ非セラピー的に対応します。

  1. **パターン:**どの罠、極性、調子の悪い日の原因、または修復の必要性が表れているか。
  2. **代償:**チーム、マネージャー、同僚、または EM 自身の判断にどのような影響があるか。
  3. **捉え直し:**状況をより有益に解釈する方法。
  4. **次のアクション:**今週試す行動を 1 つ。
  5. **振り返りの質問:**その後、何を観察するか。

EM が圧倒されているようなら、あらゆるフレームワークを並べるのではなく、次の一手を 1 つに絞ります。


EM が行き詰まる 10 のパターン

経験豊富な EM のほとんどは、少なくとも 5 つに当てはまります。

1. 破壊的な行動を無視する

容認することは、推奨することです。行動を無視する期間が長くなるほど、対処は難しくなります。開発者が自然に変わることはありません。どれほど時間が経っていても、話し合うのに最適なタイミングは常に今です。

2. 全員を喜ばせようとする

好かれたいという気持ちは、悪い案を後押ししたり、無理な期限に同意したり、難しい会話を避けたりすることにつながります。人をがっかりさせ、信念を曲げないことを学ぶ必要があります。

3. 自分の信条のために戦いすぎる

すべての問題が、戦う価値のあるものではありません。何かをめぐって戦いを始める前に、「なぜこれは自分にとってそれほど重要なのか」と自問してください。土台となる信条もあれば、そうでないものも多くあります。(例:チームの士気を犠牲にしてまで、スタンドアップへの出席を強く求める。)

4. チーム外の人間関係を築かない

ほとんどの EM は、マネージャーと PM という 2 つの関係に注力します。それだけでは不十分です。チームの影響力は他のチームや顧客に左右され、それには支えとなるネットワークが必要です。重要な人たちと 1:1 を行い、できる限り相手を支援しましょう。

5. 自分の役割を狭く定義しすぎる

どの EM にも技術、人、プロセスといった得意分野がありますが、それだけに取り組んでしまうのが落とし穴です。有能なマネージャーは、足りない部分を補います。チームの最も弱い部分を常に見極め、そこに力を注ぎましょう。

6. マネージャーも人間だということを忘れる

マネージャーがあなたを困難な状況に置いたり、相談なくチームの予定を確約したりすると、いら立つのも無理はありません。ほぼ間違いなく、最善の意図があってのことです。間違いを犯す余地を与えましょう。

7. 自己成長をおろそかにする

日々の業務に集中するあまり、自分自身の成長に時間を費やすのを忘れ、停滞や燃え尽きにつながります。そのための時間を確保しましょう。

8. 部下へのマネジメントしかしない

ビジネス目標に結びついていなくても、チームのアイデアのために戦うことです。誰も求めていない 3 か月のリファクタリングを実現できたとしても、長期的には信頼を損ないます。

9. 上司へのマネジメントしかしない

マネージャーの方針に盲目的に従い、「経営陣がこれを求めている」と何度も口にすることです。あまりに繰り返せば、チームがいなくなってしまいます。

10. 上司へのマネジメントをまったくしない

チームの成功と評価は、マネジメント階層との関係に左右されます。優れた仕事も、上層部に伝えなければ認識されません。チームの「外務大臣」になりましょう。

(罠 #8~10 については、managing-up スキルでさらに詳しく説明しています。)


ドラマ・トライアングル — そこから抜け出す方法

物事がうまくいかないときは、次の3つの役割のいずれかに陥りがちです。

  • 被害者 — 無力だと感じ、物事が自分に「降りかかっている」と考えます。誰/何のせいにするかに意識が向きます。
  • 悪役 — 被害者が、あらゆる問題の原因として指し示す存在です。
  • ヒーロー — 一時的な安心を与えます(「何とかする」マネージャーや、現実を忘れさせてくれる目的のないスクロールなど)。

EM によくある、こうした状況に陥る例を3つ紹介します。

  1. PM があなたに相談せず、公の場で過剰な約束をする → あなたが被害者、PM が悪役、マネージャーにヒーローになってほしいと思う
  2. CEO があなたのチームは十分に努力していないとマネージャーに伝える → あなたが被害者、CEO が悪役、あなたの不満を認めてくれる配偶者がヒーロー
  3. 成果が振るわず、改善もしていない開発者がいる → あなたが被害者、前任のマネージャーが悪役、昼食時に同僚へ愚痴をこぼすことがヒーロー

どのケースでも、根本原因は解決されません。

抜け出す方法:

  1. 自分が被害者意識に陥っていると気づきましょう。 悪役が誰かだけでなく、不満を和らげるために誰をヒーローとして頼っているかにも気づきましょう。

  2. 相手の立場を懸命に理解しようとしましょう。 PM が過剰な約束をした場合、怒りにまかせた Slack メッセージを送る代わりに、電話をかけてみましょう。なぜそうしたのかを尋ねてください。多くの場合、「悪役」は、あなたが知らなかった大きなプレッシャーにさらされています。

  3. 問題ではなく、望む結果に意識を向けましょう。 問題に意識を向けるほど、問題は大きくなります。こう自問してみましょう。ここで本当に望んでいる結果は何だろう? そして、その実現に向けて取り組みましょう。

より健全なモデルは、創造者、挑戦者、コーチです。創造者は、望まないことではなく、望むことに意識を向けます。創造者も問題に向き合って解決します。ただし、不満を抱え続ける中ではなく、結果を生み出す過程でそうします。


マネージャーにはつらい日が多い理由

誰も教えてくれないことの一つに、マネジメントの感情面は個人で成果を出す仕事とは異なる、ということがあります。

開発者のつらい日には限りがあります。コードを書き、バグを修正し、ものをリリースします。大変な日でも、最後には目に見える成果が残ります。状況が本当に悪くなれば、ヘッドホンを着けて仕事に没頭できます。

マネージャーには、そうした逃げ道がありません。気分と仕事が同じものだからです。マネージャーが予想以上につらい日を過ごす理由は3つあります。

  1. 罪悪感。 すべての場所にいることはできません。誰かが今日、あなたから受け取れる以上の支援を必要としています。この罪悪感は絶えず、じわじわと続きます。なくなることはありません。付き合い方を学ぶのです。

  2. やり取りが増えるほど、変動も増える。 マネージャーの一日は、ほとんどがほかの人とのやり取りです。やり取りが増えれば、誤解や対立、うまく伝わらなかった会話、悪く受け止められたフィードバックが起きる機会も増えます。

  3. コードに逃げ込めない。 コーディングが仕事だった頃は、難しい技術的な問題に取り組んで、自分の能力を実感することができました。マネジメントには、そうした手段がありません。仕事は曖昧で、進みが遅く、人間関係に左右されます。

マネジメントでつらい日を過ごしているときにできること:

現実的な選択肢は2つです。どちらか一方を選び、中途半端に両方をやろうとしないでください。

  • 病欠を取る。 消耗していて、きちんと対応できないなら、出勤しないでください。消耗したマネージャーが形だけ仕事をするより、チームにとっては休んでもらうほうがよいでしょう。
  • 全力で臨む。 休めないなら、その場にいることに全力を注いでください。最悪なのは、心ここにあらずの状態で出勤することです。上の空で、気が散り、いら立っている状態です。

問題があることを示す危険信号3つ(単につらい日というだけではありません):

  1. 特定の人や会話を1週間以上避けていることに気づく。
  2. チームやマネージャーに対して、いら立ちではなく、本当の恨みを感じている。
  3. 仕事に好奇心を持てなくなり、ただ作業をこなしている。

つらい日が続くようになったときの根本原因5つ:

  1. 対処していない、難しい人間関係(上記の10の落とし穴の#1を参照)
  2. 十分な裁量がないと感じている。誰かがマイクロマネジメントしている
  3. 仕事が自分の大切にしていることと結び付いていない
  4. 成長していない。同じ問題を繰り返し解いている
  5. 抱え込みすぎていて、仕事を委任していない

どれも自然には解決しません。自分に当てはまるものを特定し、直接対処してください。


道を切り開く

チームが苦戦しているときに、マネージャーが最もよく犯す間違いは、チームにはもっとモチベーションが必要だと思い込むことです。

大半のエンジニアは、平凡な仕事をしたいと思って目を覚ますわけではありません。成果が低いときに考えるべきなのは、「どうすればやる気にさせられるか?」ではなく、「何が妨げになっているのか?」です。

障害の棚卸し: 全員にこう尋ねてください。「ここで、自分のキャリアで最高の仕事をするのを妨げているものは何ですか?」 障害を分類します(プロセス、技術、リソース、明確さ)。上位3つはすぐに解消してください。

マネージャーが見落としがちな障害:

  • ステークホルダーごとに指示が食い違っている
  • 簡単なタスクを悪夢のようにしてしまう技術的負債
  • 数時間で終わるタスクに何日もかかる承認プロセス
  • 絶えず手戻りを生む不完全な要件

本当の障害を取り除けば、「モチベーション」向上のために何もしなくても、処理能力は上がります。マネージャーの仕事は、応援団というよりブルドーザーに近いものです。


修復

マネジメントでは、間違いを犯すものです。自信を打ち砕くようなフィードバックをしてしまうこともあります。チームに相談せずに、何かを引き受けると決めてしまうこともあります。感情を抑えられなくなることもあります。約束を破ってしまうこともあります。

問題は、こうしたことが起きるかどうかではなく、そのあとにどうするかです。

優秀な人材が離れていくのは、必ずしも最も多くの間違いを犯したマネージャーではありません。自分の間違いを一度も認めなかったマネージャーです。間違っているのに、さらに自分の主張を押し通した人です。エゴが邪魔をして、こう言えなかった人です。「あなたをどうにもできない状況に追い込んでしまいました。まずあなたに相談するべきでした。今後はこうします。」

具体的で、正直で、必要以上に謝りすぎない、こうした認め方は、間違いを一度も犯さないことよりも大きな信頼を築きます。安心して一緒に働ける相手だということを示します。

うまく修復する方法:

  1. 何が起きたのかを具体的に伝えます。一般論にしないでください。
  2. 責任を引き受けます。言い訳をしないでください。
  3. 今後どう変えるかを伝えます。具体的にしてください。
  4. その後は切り替えます。いつまでも罪悪感を抱かせても、誰のためにもなりません。

問題と両極性

どれほど適切に解決しても、何度も繰り返し現れるマネジメント上の課題があります。それは多くの場合、問題ではなく、両極性だからです。

問題は一度解決すれば、その後も解決したままです。一方、両極性とは、継続的にマネジメントしなければならない、相互に依存する二つの反対要素の間の緊張関係です。どちらか一方が「正解」というわけではありません。

たとえば、スピードと品質、自律性と方向性の一致、短期的な納期と長期的なアーキテクチャの健全性、個人の集中時間とチームのコラボレーションです。

よくある間違いは、両極性を問題として扱うことです。バグのバックログを解消して、品質の問題を「解決」したつもりになっても、1年後にはバックログがまた積み上がっています。間違ったものを「解決」したのです。本当の課題は、スピードと品質の間にある継続的な緊張関係をマネジメントすることです。

両極性をマネジメントする方法:

  • 両方の極を明確にします。どちらか一方を「正しい」と決めつけないでください。
  • それぞれの極のメリットとデメリットを特定します。
  • どちらか一方に偏りすぎていないかを把握します。そこまで偏ると、反対側へ振れる圧力が高まります。
  • 両極の間を無意識に行き来するのではなく、意識的に切り替えられる仕組みを作ります。

繰り返し起きる問題がなぜ何度も戻ってくるのかと考えたら、こう問いかけてください。これは本当に、解決しようとしている両極性なのではないでしょうか?


さらに詳しく

フレームワークの出典を知りたい場合、元の記事を読みたい場合、あるいはどのトピックについても詳しい背景を知りたい場合は、references/sources.md を参照してください。出典となった記事(リンク付き)と書籍の全リストがあります。


関連スキル

  • managing-up — マネージャーとの関係のマネジメント、上層部へのコミュニケーション、リーダーシップとの意見の相違への対処
  • delegation — ボトルネックの罠は、#5と二分法に直結します
  • feedback — 破壊的な行動を無視すること(#1)は、フィードバックの失敗です
  • feedback — チームから率直なフィードバックを得ること。盲点は、EMが行き詰まる10の原因の中心です
  • influence — 上層部や他部門とのマネジメントには、influence の説得スキルが必要です

コメント