他部署に期待するな：ビジネスサイド連携の防御的アプローチ
エンジニアリング組織を率いていると、自チーム内のマネジメントと同じくらい、セールスやPdMといった他部署（ビジネスサイド）とのコミュニケーションに時間を使うことになります。 ここでも、厄介なトラブルの温床になるのが「相手への無自覚な期待」です。 結論から言います。他部署とのやり取りにおいて、相手に何かしらの「配慮」や「察し」を期待することは明確な間違いです。 他部署は、自分たちとは全く異なる目的と…
受動的なチームをどう動かすか。モメンタムを生み出すための実践録
チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。 現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。 指示待ちの「レガシーシステム」と化したチーム 当時の定例ミーティ…
正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力
ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。 しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのよう…
セールスvs開発：100%の「ビッグバン」か、60%の「小出し」か。終わらない聖戦
IT業界やプロダクト開発の現場にいると、必ずと言っていいほど目撃する光景があります。それは、新機能や新サービスのリリース方針を巡る、セールスと開発（エンジニア）の冷戦です。 「中途半端なものを客に出せるか！ 100%完成させてから『一気に』華々しくリリースさせろ！」と叫ぶセールス。 「いやいや、いきなり全部出すなんて自殺行為ですよ。60〜70%でいいから細かく出して修正させてくれ」と嘆く開発。 こ…
AI時代の「開発生産性」はどこで測るべきか？4keysの次に来るもの
アジャイル開発が浸透してからというもの、我々は「4keys（デプロイ頻度、変更のリードタイム、変更障害率、復旧時間）」を主要な指標として追いかけてきました。特に「変更障害率」は、AIが生成するコードの品質を担保する最後の砦として、今後も変わらず重要であり続けるでしょう。 しかし、それらの数字が健全でも、現場では少し違和感が出始めているのではないでしょうか。「数字上は生産性が上がっているはずなのに、…
Snapdragon搭載PCに変えたので、開発環境構築の備忘録
最近、PCをSnapdragon搭載のマシンに変更しました。 従来のインテルなどのCPU（x64）とは少し勝手が違うため、自分用の備忘録として、「ここだけは気をつけるべき」というポイントをまとめます。 Docker Desktop は「Arm版」が必須 Docker Desktopなんですが、いつもの感覚でMicrosoft Storeから取得したり、適当なインストーラーを使うと起動しません。 S…
エンジニアの成長を阻む「現状志向」の壁。その正体とハック方法
はじめに：なぜぼくらは「レガシー」から抜け出せないのか 「今年こそはRustを習得するぞ」とか「インフラをIaC化して効率化するぞ」なんて正月に誓ったのに、気づけば年末。結局、手慣れた既存コードの保守と、温かみのある手動デプロイを続けている……なんてこと、ありませんか？ ぼく自身もそうです。「このコード、可読性が悪いからリファクタリングしてきれいにしたい」と常々思っているのに、いざ日々のタスクに向…
エンジニアを縛る「過去の武器」。スキルのサンクコスト効果との付き合い方
AI時代に「かつての必勝パターン」を手放せないエンジニア エンジニアとしての成長を考えたとき、こんな葛藤を感じることはないでしょうか。 例えば、生成AIの台頭です。 かつては、時間をかけて複雑な正規表現を一から組み上げたり、ドキュメントの隅々まで読み込んで独自の最適解を導き出したりする「職人芸」こそが、エンジニアの強みであり、自信の源泉でした。「自分にしかできない仕事がある」ことが、経験の証だった…
エンジニアの「バグ」を増やすも減らすもラベル次第？心理効果でチームを変える
はじめに：ラベルという「呪い」と「祝福」 マネジメントにおいて、部下やメンバーに対する「言葉」がどれだけ重いか、考えたことはありますでしょうか。 実は、「ラベリング効果」という心理効果によって、上司が貼ったラベル（レッテル）一つで、メンバーのパフォーマンスが良くも悪くも激変してしまうんです。 使い方を間違えると、優秀なエンジニアを潰してしまうこともあれば、逆に伸び悩んでいる新人をエース級に育てるこ…
「捨てる選択」に向き合えないエンジニア。その「認知的不協和」を吹き飛ばせ
エンジニアなら一度は見る「あの光景」 開発現場にいると、こんな場面に遭遇すること、ありませんか？ あるベテランエンジニアが、数年前に開発した独自の社内ライブラリ。 当時は画期的だったかもしれませんが、今となってはメンテナンスも属人化しているし、世の中にはもっと便利で高機能なOSS（オープンソース）が溢れています。 チームの誰もが「OSSに移行したほうが、バグも減るし工数も下がる」と思っています。 …
あの「深夜の障害対応」だけが評価される不思議。「利用可能性ヒューリスティック」でバグる人事評価の話
「俺はこんなに頑張った」vs「あいつ最近たるんでない？」 想像してみてください。あなたはバックエンドエンジニアです。 この半年、あなたの活動はまさに、神掛かっていました。複雑なスパゲッティコードをリファクタリングし、技術的負債を返済し、システムをかつてないほど堅牢にしました。誰にも文句は言わせない、完璧な仕事ぶりだったはずです。 しかし、評価面談の3日前、ごく些細なバグを1つ出してしまいます。即座…
エンジニアの「普通わかるでしょ」はなぜ通じない？フォールス・コンセンサス効果とマネジメント
「え、この規模の機能追加でPR（プルリクエスト）ひとつにまとめる？ 普通はレビューしやすいように分割して出すでしょ？」 コードレビューや設計の打ち合わせで、こんな風に思ったことありませんか？ 「インデントはスペース4つが常識」「変数名はスネークケース以外ありえない」「この規模ならAWS一択だよね」などなど。 自分にとっては「息をするのと同じくらい当たり前」なことが、相手には全く通じていなかったり、…