「それって主観ですよね？」を乗り越える――客観とは「主観の集まり」であるという話
クォーター末の評価面談や1on1で、メンバーの振り返りをサポートしているとき、こんなすれ違いに出くわしたことはないでしょうか。 マネージャー：「今期の新規機能リリース、やり切ったのは素晴らしいね。ただ、この振り返りシートを見ると『予定通り完遂して満足している』という記述にとどまっている。もう少し客観的な視点で自分の成果や影響範囲を振り返ってみてほしいんだ」 メンバー：「客観的、ですか？ でも期日は…
コードと数字に強いエンジニアが陥る「人間系」と「全体像」の罠
元シティバンクの金利トレーダーであるGary Stevenson氏のインタビュー動画の中で、非常に示唆に富む言葉がありました。 https://youtu.be/ht6Ae4roWIE?si=DO_vPcuwOJHHgIcs 「数字や数学にとても強い人の多くは、物事の人間的な側面や全体像を理解することが得意でない人が多い」 動画内では主にマクロ経済学や金融市場の文脈で語られた話ですが、これを聞いて…
属人化という麻薬――「自分にしかできない」という幻想が組織を蝕む理由
「この機能の改修、誰が拾う？」 「あ、そこは〇〇さんしか分からない領域だから、〇〇さんにお願いしよう」 スプリントプランニングや日々のスタンドアップで、誰もが一度は耳にしたことがある会話ではないでしょうか。 短期的には「一番詳しい人がやるのが最速」という判断は合理的に見えます。しかし、これを繰り返した果てにあるのは、特定エンジニアへの極端な負荷集中、心理的ボックスタワー、そしてチーム全体の開発速度…
AI時代に必要な能力：コードを書く前に「言語化」できていますか？
最近、GitHub Copilotや各種LLM、さらにはClaude CodeのようなAIコーディングエージェントを日常的な開発フローに組み込んでいて、ふと思うことはないでしょうか。「自分がコードをタイピングしている時間、以前に比べて圧倒的に減ってないか？」と。 プロンプトを作成し送信すると、自律的にファイルの変更や複雑なロジックのリファクタリングまで完遂してくれる。そんな時代において、皆さんは現…
なぜコード品質を上げられないのか？ スキルと方針の欠如が招く惨状
開発現場において「コード品質を向上させよう」という号令がかかることは珍しくありません。リファクタリングの時間を確保したり、テスト駆動開発（TDD）の勉強会を開いたり。しかし、実際にそれが定着し、息をするように高品質なコードが生産されるチームは驚くほど少ないのが現実ですよね。 誰もが「保守しやすく、変更に強いコード」を書きたいと願っているはずなのに、なぜコードの無秩序化は止まらないのでしょうか。 現…
AIコーディングエージェント時代の生存戦略：正社員とフリーランスの役割はどう変わるか
GitHub Copilotの登場から始まり、現在ではより自律的に動くAIコーディングエージェントが開発現場に浸透してきました。皆さんの現場でも、日々のコーディング風景は数年前と全く違うものになっているはずです。 今回のテーマの背景として、以下の現状認識があります。 最近は、IT人材不足というところで、フリーランスが高値で現場で求められることが多かったです。 しかしAIコーディングエージェントが出…
プロダクト開発を迷走させないための「WHY・WHAT・HOW」の境界線
プロダクト開発の現場で「WHY・WHAT・HOWを意識しよう」という言葉、よく耳にしますよね。 エンジニアとして経験を積み、ただ目の前のコードを書くだけのフェーズを抜けてくると、自然とこういったレイヤーの違いを意識する場面が増えてくるはずです。 しかし、実際のミーティングでは「この機能はReactで書き直すべきか？」というHOWの議論と、「そもそもユーザーはこの機能を求めているのか？」というWHY…
「開発速度 vs 品質」の誤解を解く。私たちが本当にトレードオフにかけているものは何か？
「早くリリースしたいから、今回はちょっと品質を目を瞑って進めよう」 開発現場で耳にタコができるほど繰り返されるこのセリフ。皆さんも一度は言ったり、言われたりした経験がありますよね。そして、そのたびに「開発スピードと品質はトレードオフだから仕方ない」と、妙に納得したような諦めを感じていないでしょうか。 でも、ちょっと待ってください。この議論、そもそも「品質」という言葉の定義がガバガバなせいで、不毛な…
他部署に期待するな：ビジネスサイド連携の防御的アプローチ
エンジニアリング組織を率いていると、自チーム内のマネジメントと同じくらい、セールスやPdMといった他部署（ビジネスサイド）とのコミュニケーションに時間を使うことになります。 ここでも、厄介なトラブルの温床になるのが「相手への無自覚な期待」です。 結論から言います。他部署とのやり取りにおいて、相手に何かしらの「配慮」や「察し」を期待することは明確な間違いです。 他部署は、自分たちとは全く異なる目的と…
受動的なチームをどう動かすか。モメンタムを生み出すための実践録
チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。 現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。 指示待ちの「レガシーシステム」と化したチーム 当時の定例ミーティ…
正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力
ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。 しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのよう…
セールスvs開発：100%の「ビッグバン」か、60%の「小出し」か。終わらない聖戦
IT業界やプロダクト開発の現場にいると、必ずと言っていいほど目撃する光景があります。それは、新機能や新サービスのリリース方針を巡る、セールスと開発（エンジニア）の冷戦です。 「中途半端なものを客に出せるか！ 100%完成させてから『一気に』華々しくリリースさせろ！」と叫ぶセールス。 「いやいや、いきなり全部出すなんて自殺行為ですよ。60〜70%でいいから細かく出して修正させてくれ」と嘆く開発。 こ…