- 今はエンジニアリングマネージャーになったが、私がソフトウェアエンジニアとして働いていた頃、複雑な機能に何日も取り組んでPRを上げた
- フィードバックは断固としていて冷淡だった。「オーバーエンジニアリングだ。複雑すぎる。リファクタリングしなさい」という短い一文がすべてだった
- 一言の称賛もなく批判だけを受けた経験に怒りを覚えたが、そのマネージャーとの出来事はほんの始まりにすぎなかった
感情に配慮しないリーダースタイル
- このマネージャーは、それまで知っていたリーダーたちとは違っていた
- 手取り足取り教えることも、柔らかい言葉をかけることもなかった
- 次のような特徴があった
- 練り切れていないアイデアは即座に却下する
- 複雑さのための複雑さを嫌う
- きれいで保守しやすく効率的なコードだけを重視する
- 振り返りでも遠回しに言わず、問題を直接指摘した
- 最初は冷酷な性格だと思ったが、その裏には別の哲学があった
プライドを揺さぶったフィードバックの転機
- スプリントレビューで自信のある機能をデモしたが、マネージャーは途中で遮ってこう尋ねた
> 「これは脆い。高負荷時にはどうなる？ ロールバック計画は？」
- まともに答えられないと、マネージャーはこう言った
> 「今の君はコーダーのように考えている。エンジニアのように考えなければならない」
- 最初は腹が立ったが、結局、自分のコードスタイルが回復力よりも賢さに偏っていたことに気づくようになった
本当の教訓: そのマネージャーは私を個人的に攻撃していたわけではなかった
- 考え方に大きな変化が生まれた
- 「賢い」コードではなく、読みやすいコードを書く
- 障害を見越した設計に集中する
- 自分のためのコードではなく、後続の開発者のためのコードを書く
- その後、そのマネージャーのコードレビューは難なく通るようになった
- マネージャーが変わったのではなく、自分自身が成長したからだった
自分のリーダーシップスタイルに残した影響
- エンジニアリングマネージャーになってから、その経験を何度も思い返した
- 皆に嫌われるリーダーにはなりたくなかったが、ただ優しいだけのリーダーにもなりたくなかった
- 次のような形で自分のスタイルを固めた
- 背景説明を伴う率直なフィードバックをする
- システム思考を重視する
- 高い基準は保ちつつ、人間味のあるフィードバックを提供する
- エンジニアは挑戦されることを望むが、軽んじられていると感じるのは嫌う
断固としたマネージャーが必要なとき
- リーダーシップにはプライド、締め切り、プレッシャーが絡み合っていて混乱しやすい
- 断固としたマネージャーは、次のようにしてこの混乱を取り除く
- 機能ではなくスケーラビリティを考えさせる
- 賢いコードより保守可能なコードを書かせる
- 失敗や例外状況に前もって備えさせる
- 感情よりも、コードが長く生き残れるかどうかを重視する
断固としたマネージャーの下で生き残り、成長する方法
- 息苦しいリーダーの下にいるなら、次のように対処できる
- 個人的な攻撃として受け取らないこと: フィードバックはコードに対するもの
- フィードバックの後に「なぜ？」と尋ねること: たいていの断固としたリーダーは好奇心を尊重する
- 失敗ポイントを自分で先に考えてみること: マネージャーのように考え始める必要がある
- リーダーなら次を実践すべきだ
- 高い基準を示しつつ、その基準が重要な理由を説明すること
- 曖昧なフィードバックではなく、具体的に伝えること
- 成功より成長を祝うこと: 開発者がマネージャーより先に問題を見つけたなら称賛すること
却下されたPull Requestがくれた最高の贈り物
- 最初はプライドが傷ついたが、今振り返れば、その却下されたPRは人生最高の機会だった
- コーディングを個人プロジェクトではなく、システム構築として見るきっかけになった
- 断固としたマネージャーは気分を良くしてはくれないが、開発者として成長させてくれる
- 本当の成長はPRが通ったときではなく、却下されたときに始まる
22件のコメント
感情への配慮をしない率直なマネージャーと、ラポールを保ちながら親切なマネージャーがいるとして、どちらのタイプのマネージャーがフィードバックを通じてチームメンバーの成長を後押しできるのだろうか。前の記事を読みながら、こんな疑問が湧きました。
私は確率のゲームだと思います。極めて低い確率を突破して成長する人はどこにでもいます。マネージャーは、そういう人をいったん脇に置いて、全体の確率を高めることに努めるべきだと思います。自分なりに確率を高める姿勢だと信じて行動しているマネージャーは、尊重されるに値すると思います。ただ、だからといって、普段からやってきたやり方をそのまま続けるだけでよいわけではありません。
この種のフィードバックは、性格や文化圏、個人差によっては、受けたときに気分を害したり腹が立ったりすることもあると思います。ですが基本的には、「あの人がわざと自分を苦しめようとしているわけではない」と考えて向き合うほうが、メンタルの面でも成長の観点でも良い気がします。そういう状況になったとき、この文章を思い出しながら「もしかするとこのマネージャーも？」と考えてみることはできそうです。いい文章ですね。
kind and directはよく語られますが、実際には、kind であることよりも direct であることのほうがはるかに難しいものです。全体の文脈までは与えなくても、フォロワーが従うべき文脈を伝えられないリーダーには価値がありません
本人の能力が優れていることを他人に還元できる、優れたフォロワーが書いた文章のようですね
リーダーが文脈を伝えてくれないのであれば、そのリーダーは特に必要ありません
早急に交代させるべきです
耳に心地よい言葉が、必ずしも良い言葉とは限りません。私も、
Nasty Codeというたった2語だけのコードレビューが、人生で最も役に立ったと思っています。開発者といっても、みんな同じ開発者ではない。
「システム的思考」とは何かと考えてみたのですが、この文章の文脈では、何かアプリケーションの動作という観点からの思考のことのように感じられます。ですが、本当に重要な観点だと思います。
うまく丸く進めているうちにコードベースがめちゃくちゃになっていくのを見たので、かなり共感しますね。マネージャーの力量の重要性は本当に大きいです。
共感します
文章の含意としては、そのマネージャーが優れていたというより、むしろ本人がうまくやったように感じられますね。（著者はどんなフィードバックを受けても成長するタイプの人なのでは）
（文脈が不足した）否定的なフィードバックを受けたとき、行動が期待とは逆方向に変化する可能性が高いという研究を見た記憶があります。
成果物へのフィードバックは、個人攻撃ではないと理解する必要があります。
マネージャーがもっと良い人だったらなお良かったかもしれませんが、会社は学校ではないので……私たちはプロだからこそ……フィードバックについては自分で学ばなければなりません。
分からないことを分からないと言える勇気も必要です。
かなり私とは異なる視点をお持ちのようです。私のキャリアが浅いからかもしれませんが、明確でないフィードバックや、何を指しているのか曖昧なフィードバックは、かえって逆効果になる例ばかり多く見てきたので……
スペルが間違っています。
"非難ではないことを悟らなければなりません。" -> "非難ではないことを悟らなければなりません" と書くべきです。
個人的な非難ではないことはご存じだと思いますが、見た瞬間に私の指摘に腹が立ったのではないかと思います。人によっては朝三暮四だと言いますが、朝三暮四と暮三朝四を違って受け取るのが人間なのだと思ったりもします。
ps. 私もスペルミスに気づいていなかったのですが、例を探したくてスペルチェッカーに入れてからようやく間違って書かれていたことを見つけました。
スペルミスを直してくれたなら、ありがとうございます、知りませんでしたと言えば済む問題であって、怒る材料ではないように思います。自分が感じたとおりに他人も感じるだろうと考えるのは、危険な一般化だと思います。そして、
받아 드리는 게ではなく받아들이는 게です。ストレスを受ける仕事でも解決できるのがプロだと思います。
ストレスを与えることを正当化しようとしているわけではありません。プロとして仕事をしていると腹が立つこともあるでしょうが、それを賢く解決するのがプロだと思います。
私は正書法の専門家ではありません。コミュニティは会社でもありません。
コメントに本当に同意します。受け取る側の力量と心構えが優れていたのだと思います。あのマネージャーは哲学自体は明確でしたが、自分の哲学をチームに浸透させるための良いアプローチを取る方法は分かっていなかったのだと思います。
こういうのを、投げやりに言われても察してうまく受け取るってことなんだろうな…（笑）
本当に良い文章です。これはPRを上げる前も、上げた後も、ずっと見返すべきですね。
個人的な攻撃にならないようにするには、ラポール形成をしっかりしておく必要があるように思います。（特に韓国社会の文脈では）
私は個人的に主語の使い方に気をつけています。オーバーエンジニアリングなのは「このコード」であって、「相手」が間違っているわけではないからです。
専門家の頭の中ではいったい何が起きているのだろうかという記事を思い出しますね。"オーバーエンジニアリングだ。複雑すぎる。リファクタリングしなさい"、"これは脆弱だ。高負荷時にはどうなる？ ロールバック計画は？" といったレビューを受けたとき、なぜそう考えたのか、どんな問題を想定しているのか、どの方向での改善を考えているのかを聞いてみるのもよいでしょう。（筆者がそうしなかったというより、ああいう状況でどうすればもっと多くの学びを得られたのだろうか、と考えたので。）
本当に良い文章だ..