なぜコード品質を上げられないのか？ スキルと方針の欠如が招く惨状
開発現場において「コード品質を向上させよう」という号令がかかることは珍しくありません。リファクタリングの時間を確保したり、テスト駆動開発（TDD）の勉強会を開いたり。しかし、実際にそれが定着し、息をするように高品質なコードが生産されるチームは驚くほど少ないのが現実ですよね。 誰もが「保守しやすく、変更に強いコード」を書きたいと願っているはずなのに、なぜコードの無秩序化は止まらないのでしょうか。 現…
AIコーディングエージェント時代の生存戦略：正社員とフリーランスの役割はどう変わるか
GitHub Copilotの登場から始まり、現在ではより自律的に動くAIコーディングエージェントが開発現場に浸透してきました。皆さんの現場でも、日々のコーディング風景は数年前と全く違うものになっているはずです。 今回のテーマの背景として、以下の現状認識があります。 最近は、IT人材不足というところで、フリーランスが高値で現場で求められることが多かったです。 しかしAIコーディングエージェントが出…
プロダクト開発を迷走させないための「WHY・WHAT・HOW」の境界線
プロダクト開発の現場で「WHY・WHAT・HOWを意識しよう」という言葉、よく耳にしますよね。 エンジニアとして経験を積み、ただ目の前のコードを書くだけのフェーズを抜けてくると、自然とこういったレイヤーの違いを意識する場面が増えてくるはずです。 しかし、実際のミーティングでは「この機能はReactで書き直すべきか？」というHOWの議論と、「そもそもユーザーはこの機能を求めているのか？」というWHY…
「開発速度 vs 品質」の誤解を解く。私たちが本当にトレードオフにかけているものは何か？
「早くリリースしたいから、今回はちょっと品質を目を瞑って進めよう」 開発現場で耳にタコができるほど繰り返されるこのセリフ。皆さんも一度は言ったり、言われたりした経験がありますよね。そして、そのたびに「開発スピードと品質はトレードオフだから仕方ない」と、妙に納得したような諦めを感じていないでしょうか。 でも、ちょっと待ってください。この議論、そもそも「品質」という言葉の定義がガバガバなせいで、不毛な…
「言い訳」の卒業式：自律を完成させるための「補助輪を外す」マネジメント
「マネージャーの指示だから」という盾を用意して若手の背中を押す手法は、初期の立ち上がりにおいては極めて有効です。しかし、いつまでもこの「言い訳」というシールドを使い続けていると、若手はいつまでも責任の本当の重さを知らず、組織の中核を担う自律したビジネスパーソンへと脱皮することができません。 マネジメントの真のゴールは、部下に「言い訳」を提供し続けることではなく、最終的にその「言い訳」という名の補助…
マネジメントの本質は「正当な言い訳」の提供にある：若手の足を動かすための戦略的リスクヘッジ
「言い訳をするな」 多くのビジネス現場で美徳とされるこの言葉ですが、マネジメントの観点から見ると、実はこれほど若手の行動を縛り付ける呪縛はありません。むしろ、優秀なマネージャーほど、部下が動くための「質の高い言い訳」を先回りして用意しているものなんです。 PIVOTでよい動画が配信されていました。「若者が辞めない理由を分析」という動画です。 この動画で触れられていた「若手に行動の言い訳を作ってあげ…
チームの「過剰な推進力」が引き起こす組織の不整合と、そのデバッグ
チームの推進力、適切にコントロールできていますか。 推進力がないチームは物事が進まないので論外ですが、推進力がありすぎるのも、実は非常に厄介なバグを組織に埋め込む原因になります。推進力があると、関係者の足並みが揃うのを待たずにどんどんと物事を進めてしまうからです。 アンチパターン：当事者不在の「破壊的変更」 ここで最も警戒すべきアンチパターンは、関係部署があるにもかかわらず、その部署の当事者が不在…
受動的なチームをどう動かすか。モメンタムを生み出すための実践録
チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。 現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。 指示待ちの「レガシーシステム」と化したチーム 当時の定例ミーティ…
正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力
ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。 しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのよう…
セールスvs開発：100%の「ビッグバン」か、60%の「小出し」か。終わらない聖戦
IT業界やプロダクト開発の現場にいると、必ずと言っていいほど目撃する光景があります。それは、新機能や新サービスのリリース方針を巡る、セールスと開発（エンジニア）の冷戦です。 「中途半端なものを客に出せるか！ 100%完成させてから『一気に』華々しくリリースさせろ！」と叫ぶセールス。 「いやいや、いきなり全部出すなんて自殺行為ですよ。60〜70%でいいから細かく出して修正させてくれ」と嘆く開発。 こ…
AI時代の「開発生産性」はどこで測るべきか？4keysの次に来るもの
アジャイル開発が浸透してからというもの、我々は「4keys（デプロイ頻度、変更のリードタイム、変更障害率、復旧時間）」を主要な指標として追いかけてきました。特に「変更障害率」は、AIが生成するコードの品質を担保する最後の砦として、今後も変わらず重要であり続けるでしょう。 しかし、それらの数字が健全でも、現場では少し違和感が出始めているのではないでしょうか。「数字上は生産性が上がっているはずなのに、…
Dockerの.env、置いただけじゃ動かない！？環境変数の読み込ませ方備忘録
完全にやらかしました。 Dockerを使っているとき、「.envファイルに環境変数情報書いたし、同じ階層に置いたからこれでコンテナ内でも読み込めるっしょ！」と余裕をぶっこいていたら、全然読み込まれていませんでした。 というわけで、初歩的すぎて逆にハマる「Docker Composeでの環境変数の扱い」について、自分用の備忘録として残しておきます。 そもそも何が起きていたのか 「.envファイルは、…