「言い訳」の卒業式：自律を完成させるための「補助輪を外す」マネジメント
「マネージャーの指示だから」という盾を用意して若手の背中を押す手法は、初期の立ち上がりにおいては極めて有効です。しかし、いつまでもこの「言い訳」というシールドを使い続けていると、若手はいつまでも責任の本当の重さを知らず、組織の中核を担う自律したビジネスパーソンへと脱皮することができません。 マネジメントの真のゴールは、部下に「言い訳」を提供し続けることではなく、最終的にその「言い訳」という名の補助…
マネジメントの本質は「正当な言い訳」の提供にある：若手の足を動かすための戦略的リスクヘッジ
「言い訳をするな」 多くのビジネス現場で美徳とされるこの言葉ですが、マネジメントの観点から見ると、実はこれほど若手の行動を縛り付ける呪縛はありません。むしろ、優秀なマネージャーほど、部下が動くための「質の高い言い訳」を先回りして用意しているものなんです。 PIVOTでよい動画が配信されていました。「若者が辞めない理由を分析」という動画です。 この動画で触れられていた「若手に行動の言い訳を作ってあげ…
成長にこそ期待をかけろ：マネジメントにおける「期待」の扱い方
マネージャーやチームリーダーとして組織を回していると、「メンバーへの期待値コントロール」という言葉によく遭遇しますよね。 ただ、この「期待」という言葉、取り扱いが非常に厄介です。リスクヘッジをせずに「たぶんこう動いてくれるだろう」と楽観視するのと同じくらい、マネジメントにおける無自覚な「期待」は、チームを崩壊させる致命的なリスクになり得ます。 結論から言うと、マネージャーが他者に対して明確に期待を…
チームの「過剰な推進力」が引き起こす組織の不整合と、そのデバッグ
チームの推進力、適切にコントロールできていますか。 推進力がないチームは物事が進まないので論外ですが、推進力がありすぎるのも、実は非常に厄介なバグを組織に埋め込む原因になります。推進力があると、関係者の足並みが揃うのを待たずにどんどんと物事を進めてしまうからです。 アンチパターン：当事者不在の「破壊的変更」 ここで最も警戒すべきアンチパターンは、関係部署があるにもかかわらず、その部署の当事者が不在…
受動的なチームをどう動かすか。モメンタムを生み出すための実践録
チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。 現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。 指示待ちの「レガシーシステム」と化したチーム 当時の定例ミーティ…
正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力
ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。 しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのよう…
エンジニアの成長を阻む「現状志向」の壁。その正体とハック方法
はじめに：なぜぼくらは「レガシー」から抜け出せないのか 「今年こそはRustを習得するぞ」とか「インフラをIaC化して効率化するぞ」なんて正月に誓ったのに、気づけば年末。結局、手慣れた既存コードの保守と、温かみのある手動デプロイを続けている……なんてこと、ありませんか？ ぼく自身もそうです。「このコード、可読性が悪いからリファクタリングしてきれいにしたい」と常々思っているのに、いざ日々のタスクに向…
エンジニアを縛る「過去の武器」。スキルのサンクコスト効果との付き合い方
AI時代に「かつての必勝パターン」を手放せないエンジニア エンジニアとしての成長を考えたとき、こんな葛藤を感じることはないでしょうか。 例えば、生成AIの台頭です。 かつては、時間をかけて複雑な正規表現を一から組み上げたり、ドキュメントの隅々まで読み込んで独自の最適解を導き出したりする「職人芸」こそが、エンジニアの強みであり、自信の源泉でした。「自分にしかできない仕事がある」ことが、経験の証だった…
あの「深夜の障害対応」だけが評価される不思議。「利用可能性ヒューリスティック」でバグる人事評価の話
「俺はこんなに頑張った」vs「あいつ最近たるんでない？」 想像してみてください。あなたはバックエンドエンジニアです。 この半年、あなたの活動はまさに、神掛かっていました。複雑なスパゲッティコードをリファクタリングし、技術的負債を返済し、システムをかつてないほど堅牢にしました。誰にも文句は言わせない、完璧な仕事ぶりだったはずです。 しかし、評価面談の3日前、ごく些細なバグを1つ出してしまいます。即座…
評価制度は、エンジニアにとっての『仕様書』である
「これだけ技術力を磨いたのに、なんで評価されないんだ」 「あの上司は技術のことなんて分かってない」 そんなふうに感じているエンジニアは多いものです。 この記事は、会社にある程度しっかりとした「評価軸」や「評価制度」がある環境にいる人を対象にしています。 もし、あなたの会社に明確な評価軸がないなら、それはもう「上司の習慣」や「好み」で決まっているようなものです。成果主義やスキル評価といっても、基準が…
内省のススメ
なぜ「内省」が重要なのか？ マネジメントで実感する、その理由 マネジメントの仕事をしていると、日々「内省」することの重要性を痛感します。 これは、部下にだけ求めるものではなくて、マネジメントする側（つまり自分自身）にとっても、ものすごく重要なんです。 忙しいとつい後回しにしがちですが、これがないと、いろんな問題が起きてくるんですよね。 内省がないと陥りがちな「ワナ」 じゃあ、もし内省をサボってしま…
なぜ「環境」だけでは人は育たないのか？成長の公式とマネージャーの3つのアプローチ
『環境が人を育てる』 『環境さえ整えれば、人は育つ』 マネジメントの現場で、まるで真理のように語られるこの言葉。しかし、日々の業務でメンバーと向き合っていると、「思う通りにはいかない」と感じることはありませんか？ 『……本当にそうだろうか？』 挑戦的なプロジェクトを任せても、ある人は驚くほど成長し、ある人は全く変わらない。この違いはどこから来るのか？ この『環境だけでは越えられない壁』の正体を突き…