すべての管理職は失敗するが、良い管理職はそれを認めて修正する
(terriblesoftware.org)- 管理職になると、失敗を避けることはできないことを強調
- 重要なマネジメントスキルとして、失敗後の「修復（repair）」を重視
- 失敗を否定したり隠したりする悪いマネジメントスタイルは、チームの信頼とエンゲージメントを損なう
- 誤りを具体的に認め、心から行動を変えることが信頼を築く鍵
- 完璧さではなく、成長と関係の回復こそが真の管理職の役割
はじめに: 管理職なら必ず失敗を経験する
- 管理職に昇進すると、大きな失敗も小さな失敗も何度も経験する
- 誤ったフィードバックでチームメンバーの自信をくじいたり、論理的に見えて実は的外れな判断を下したりすることがある
- 約束をうっかり忘れたり、会議中に感情を抑えきれないこともある
本当に重要なのは失敗の「後」の姿勢
- 重要なのは失敗そのものではなく、その後にどう対処するか
- Dr. Becky Kennedyの子育て本 "Good Inside" では、親として**完璧さではなく「修復（repair）」**こそが最も重要なスキルだと強調している
- 失敗の後に立ち返り、責任を認め、相手と再びつながるプロセスが重要
マネジメントにおける「修復（Repair）」の重要性
- 優れた管理職は失敗を認め、修復する姿勢を示す
- 最悪の管理職体験を振り返ると、失敗の頻度よりも決して認めない態度のほうがはるかに有害
- 失敗を隠したり、誤りを繰り返したり、自分のプライドのために認めなかったりする
失敗が組織に与える影響と信頼の問題
- いくつかの典型的なパターンとして、管理職が十分な議論なしに外部へ無理な約束（機能・納期・サポートなど）をしてしまう
- チームは深夜残業までして何とかやり切るが、その代償として技術的負債、疲労、不満が蓄積する
- その後、管理職がチームの犠牲を顧みず、申し訳なさを示さなければ、最も優秀な人材を失うことになる
- 逆に「十分に相談せず、厳しい状況に追い込んでしまった。次は違うやり方にする」と率直に認める管理職は、むしろ信頼を得る
両側の経験と信頼の差
- 筆者自身もエンジニア時代に、管理職の誤りを容赦なく見て経験してきた
- 管理職が失敗を透明性を持って認める場合とそうでない場合では、チーム全体の雰囲気と信頼が劇的に変わる
- 責任を具体的に負い、詳細に説明し、次の行動で変化を約束すると、チームの信頼はむしろ高まる
効果的な「修復（Repair）」の方法
- 具体的に何を間違えたのかを明らかにする
- 抽象的な「失敗がありました」ではなく、「さっきの会議で3回も話を遮って意見を無視してしまった」と明確に述べる
- 相手への配慮を優先する
- 自己防衛や釈明（ストレス、背景説明）ではなく、相手が受けた影響を認識する
- 実質的な行動変化を伴う
- 謝罪だけを繰り返して同じ失敗を繰り返せば、それは言い訳になる
- 具体的な変化がなければ誠実さは薄れる
- 信頼回復には時間が必要
- 一度の会話で信頼が完全に回復するわけではない
- 継続的な行動の変化によって積み上げる必要がある
「修復（Repair）」の利点と管理職の成長
- 修復が自然にできるようになると、管理職として意思決定、対話、リスクテイクのすべてに自信が生まれる
- 完璧主義から離れ、失敗を成長と関係強化の機会として捉えられるようになる
注意点
- 無責任さや繰り返される失敗、あるいは「修復」を言い訳として悪用してはならない
- 管理職にとって重要なのは完璧さではなく、実質的な価値を提供し、チームとともに成長し、最適な業務環境を整える役割を果たすこと
結論
- ときには失敗やミスが避けられないことを認める必要がある
- ミスを透明性を持って認め、教訓を得て改善しながら前に進み続ける姿勢こそが、良い管理職の核心である
1件のコメント
Hacker Newsの意見
数年前にHacker Newsで「Mochary Method」という名前のGoogleドキュメント一式が共有されたことがあったが、この種のマネジメントスキルをとても人間的な視点で扱っていて、非マネージャーの自分にも本当に刺さった。ブックマークしてよく見返している
ミスへの対処法の文書がある
Mattがもう少し詳しく説明する動画もある
その記事と似たアプローチだが、必要なら「rewind and redo」を積極的に勧めている
カリキュラム全体へのリンクも共有しておく
もしそれらのGoogleドキュメント全部のリンクを持っていたら共有してもらえると嬉しい。内容の大半は常識かもしれないが、文章として整理されたものを見るだけでも立ち止まって考えるきっかけになり、より良くなれると思う
私の経験では、IC（Individual Contributor）とマネージャーの最大の違いは「責任感」だ
謝るのは簡単だが、本当に良いマネージャーになるために自分が最も意識しているのは、自分自身に対して責任を持つことだ
具体的には、1) 何の問題が起きたのかを正確に把握し（特に自分が原因のとき）、2) 再発防止の仕組みを整えることだ
従業員は、マネージャーに責任感が足りないと本当にはっきり感じ取る。特に中堅以上、上位のマネジメントは、仕事の生産性と人生の質の両方を本当に改善したいなら、口先で悪かったと言って終わりにせず、自分のリソースを投じて同じ問題が再発しないよう仕組みを改善すべきだ
たいていこれは、無理に仕事を増やすことではなく、優先順位をうまく調整したり、必要ならもっと上手に「ノー」と言ったりすることだ
2番には概ね同意するが、仕組みを入れすぎるとかえって何もできなくなることもあるので、何よりバランスが重要だ
あなたの言うことに加えて、悪いマネージャーの最悪の形は、ミスを正すふりをしながら自分を守ろうとするタイプだ。こういうマネージャーは神経質すぎて対立に耐えられず、個々のミスや問題ごとに場当たり的な仕組みを作って回避しようとする
ミスを認めるマネージャーが、その分だけ昇進もしやすいのか、それとも適度に隠したほうが昇進には有利なのか気になる
良いシステム思考と、継続的に成長したいという動機やインセンティブが組み合わさると、本当に良いマネジメントが生まれると思う
誰かを信頼できる理由は、自分自身と自分の行動には責任を持ちつつ、他人や他人の行動まで引き受けようとはしない、その境界がはっきりしていることだ。マネージャーにも直属の部下にも同僚にも、それだけを望みたい
これはエンジニアにもまったく同じように当てはまると思う
私がsenior developerに最も求める核となるスキルは「謙虚さ」だ。経歴の問題ではなく態度の問題だ
ミスを認めない独善的なシニアはチームを毒する。一方で、ジュニアの意見にも耳を傾け、フィードバックを受け入れるシニアは、皆から信頼されついていかれると思う
私たちは皆人間だ。LLMでさえミスをする
面接で私がいちばん注意深く見るのは、候補者が「わかりません」と言う瞬間だ
本当にその通りで、多くの人は良いマネジメントスキルと優れたシニアエンジニアのスキルがかなり重なっていることをあまり理解していない
ここまで「これは教師にも当てはまる！」「親にも当てはまる！」「エンジニアにも当てはまる！」という意見が出てきたが、結局のところ人間であれば誰にでも当てはまる話だ
LLMもかなりミスをする。今も別のタブでLLMが私のサイトのCSSを直そうとして延々と同じ作業を繰り返している
LLMはあからさまに自信満々ででたらめを言うことが多いので注意が必要だ
元教師でコーチでもあった立場から言うと、子どもたちと信頼関係を築くときには必ずこのやり方を使っていた
チームメンバー（Implementer）は赤ん坊ではなく、マネージャーは親ではない
本当に重要なマネジメント能力は、マネージャーが自分はチームの一部だと認識し、謝り方よりもチームの目標達成に集中することだ
記事が言うように、「本当に動くソフトウェアをデプロイし、チームの成長を助け、誰もがベストを尽くせる環境を作ること」が本当のマネージャーの役割だ
マネージャーが自分の人間味を強調して感情的に謝るかどうかは、同じミスを何度も繰り返して私の仕事の邪魔をしない限り、実のところそれほど重要ではない
引用された本も間違ってはいないが、少し視野が狭い。関係において本当に重要なのはrupture（亀裂）ではなくrepair（修復）だ
「管理者が自分のミスをドラマチックに謝るかどうかはどうでもよく、繰り返さないようにしてくれればいい」というあなたの見方には同意しないかもしれないが、管理者が自分の基準だけをそのまま当てはめると、かえって問題になる
私にとって最高のマネージャーは、経営陣からチームを守る能力が最も優れていた
私が認めたり修正したりするのが最も難しいミスは、採用ミスだ
「この人はきっとうまくやれる」という信念で長く粘ってみたが、チームが大きくなるにつれて、文化的に合わない人が一人いるだけでコストが大きすぎるとわかった
以前は十分に機会を与えてから最終的にPIP（Performance Improvement Plan）へ移していたが、引き延ばしすぎるとチーム全体がもっと苦しくなると気づき、最近はより早く手続きを進めている
社員の能力不足より、技術的なミスを認めるほうがずっと簡単だ。特にその人が良い人であればあるほどつらい
相手が難しいタイプなら少しはやりやすいが、それでも従業員の問題はいつも難しい宿題だ
私もかつては、誰でもコーチングすればパフォーマンスを引き上げられると信じていた
この助言は本当に良いと思う
内省があり、正直にもっと良くなりたいと思っているマネージャーには大きな助けになるはずだ
ただ、そういうマネージャーはごくまれだ
大半は自分の偏見や弱点を自覚しておらず、本当の意味での業績レビューや生産性評価もなく、実際にはマネージャーの役割が株主権限の代理人としてしか定義されていない場合がほとんどだ
チームのために本当にうまくやりたいと努力しているエンジニアリングマネージャーがいるなら、心から拍手を送りたい。なかなか見つからない
ただしIC（個別実務担当者）の立場では、悪いマネージャーの下から抜け出す方法は職場かチームを移ることしかない
同意するが、それすら簡単な選択ではない
良いマネージャーと「その場に居続ける」マネージャーは別物だというのが問題だと思う
インセンティブは前者ではなく後者により強く合っている
昔あるマネージャーが、自分で採用した全員を解雇したことがある。私は残った一人だったが、同僚をかばったせいで私も解雇され、隣の人は降格された
「great flattening」の話はよく聞くが、ことレイオフに関してはマネジメント層だけ妙に耐性が高いように見える
この50年間のアメリカ文化で最大の変化は、「失敗すること」より悪いものはない、という空気だ