「それって主観ですよね？」を乗り越える――客観とは「主観の集まり」であるという話
クォーター末の評価面談や1on1で、メンバーの振り返りをサポートしているとき、こんなすれ違いに出くわしたことはないでしょうか。 マネージャー：「今期の新規機能リリース、やり切ったのは素晴らしいね。ただ、この振り返りシートを見ると『予定通り完遂して満足している』という記述にとどまっている。もう少し客観的な視点で自分の成果や影響範囲を振り返ってみてほしいんだ」 メンバー：「客観的、ですか？ でも期日は…
コードと数字に強いエンジニアが陥る「人間系」と「全体像」の罠
元シティバンクの金利トレーダーであるGary Stevenson氏のインタビュー動画の中で、非常に示唆に富む言葉がありました。 https://youtu.be/ht6Ae4roWIE?si=DO_vPcuwOJHHgIcs 「数字や数学にとても強い人の多くは、物事の人間的な側面や全体像を理解することが得意でない人が多い」 動画内では主にマクロ経済学や金融市場の文脈で語られた話ですが、これを聞いて…
属人化という麻薬――「自分にしかできない」という幻想が組織を蝕む理由
「この機能の改修、誰が拾う？」 「あ、そこは〇〇さんしか分からない領域だから、〇〇さんにお願いしよう」 スプリントプランニングや日々のスタンドアップで、誰もが一度は耳にしたことがある会話ではないでしょうか。 短期的には「一番詳しい人がやるのが最速」という判断は合理的に見えます。しかし、これを繰り返した果てにあるのは、特定エンジニアへの極端な負荷集中、心理的ボックスタワー、そしてチーム全体の開発速度…
「言い訳」の卒業式：自律を完成させるための「補助輪を外す」マネジメント
「マネージャーの指示だから」という盾を用意して若手の背中を押す手法は、初期の立ち上がりにおいては極めて有効です。しかし、いつまでもこの「言い訳」というシールドを使い続けていると、若手はいつまでも責任の本当の重さを知らず、組織の中核を担う自律したビジネスパーソンへと脱皮することができません。 マネジメントの真のゴールは、部下に「言い訳」を提供し続けることではなく、最終的にその「言い訳」という名の補助…
マネジメントの本質は「正当な言い訳」の提供にある：若手の足を動かすための戦略的リスクヘッジ
「言い訳をするな」 多くのビジネス現場で美徳とされるこの言葉ですが、マネジメントの観点から見ると、実はこれほど若手の行動を縛り付ける呪縛はありません。むしろ、優秀なマネージャーほど、部下が動くための「質の高い言い訳」を先回りして用意しているものなんです。 PIVOTでよい動画が配信されていました。「若者が辞めない理由を分析」という動画です。 この動画で触れられていた「若手に行動の言い訳を作ってあげ…
他部署に期待するな：ビジネスサイド連携の防御的アプローチ
エンジニアリング組織を率いていると、自チーム内のマネジメントと同じくらい、セールスやPdMといった他部署（ビジネスサイド）とのコミュニケーションに時間を使うことになります。 ここでも、厄介なトラブルの温床になるのが「相手への無自覚な期待」です。 結論から言います。他部署とのやり取りにおいて、相手に何かしらの「配慮」や「察し」を期待することは明確な間違いです。 他部署は、自分たちとは全く異なる目的と…
成長にこそ期待をかけろ：マネジメントにおける「期待」の扱い方
マネージャーやチームリーダーとして組織を回していると、「メンバーへの期待値コントロール」という言葉によく遭遇しますよね。 ただ、この「期待」という言葉、取り扱いが非常に厄介です。リスクヘッジをせずに「たぶんこう動いてくれるだろう」と楽観視するのと同じくらい、マネジメントにおける無自覚な「期待」は、チームを崩壊させる致命的なリスクになり得ます。 結論から言うと、マネージャーが他者に対して明確に期待を…
チームの「過剰な推進力」が引き起こす組織の不整合と、そのデバッグ
チームの推進力、適切にコントロールできていますか。 推進力がないチームは物事が進まないので論外ですが、推進力がありすぎるのも、実は非常に厄介なバグを組織に埋め込む原因になります。推進力があると、関係者の足並みが揃うのを待たずにどんどんと物事を進めてしまうからです。 アンチパターン：当事者不在の「破壊的変更」 ここで最も警戒すべきアンチパターンは、関係部署があるにもかかわらず、その部署の当事者が不在…
受動的なチームをどう動かすか。モメンタムを生み出すための実践録
チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。 現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。 指示待ちの「レガシーシステム」と化したチーム 当時の定例ミーティ…
正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力
ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。 しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのよう…
エンジニアの成長を阻む「現状志向」の壁。その正体とハック方法
はじめに：なぜぼくらは「レガシー」から抜け出せないのか 「今年こそはRustを習得するぞ」とか「インフラをIaC化して効率化するぞ」なんて正月に誓ったのに、気づけば年末。結局、手慣れた既存コードの保守と、温かみのある手動デプロイを続けている……なんてこと、ありませんか？ ぼく自身もそうです。「このコード、可読性が悪いからリファクタリングしてきれいにしたい」と常々思っているのに、いざ日々のタスクに向…
エンジニアを縛る「過去の武器」。スキルのサンクコスト効果との付き合い方
AI時代に「かつての必勝パターン」を手放せないエンジニア エンジニアとしての成長を考えたとき、こんな葛藤を感じることはないでしょうか。 例えば、生成AIの台頭です。 かつては、時間をかけて複雑な正規表現を一から組み上げたり、ドキュメントの隅々まで読み込んで独自の最適解を導き出したりする「職人芸」こそが、エンジニアの強みであり、自信の源泉でした。「自分にしかできない仕事がある」ことが、経験の証だった…