セールスvs開発：100%の「ビッグバン」か、60%の「小出し」か。終わらない聖戦
IT業界やプロダクト開発の現場にいると、必ずと言っていいほど目撃する光景があります。それは、新機能や新サービスのリリース方針を巡る、セールスと開発（エンジニア）の冷戦です。 「中途半端なものを客に出せるか！ 100%完成させてから『一気に』華々しくリリースさせろ！」と叫ぶセールス。 「いやいや、いきなり全部出すなんて自殺行為ですよ。60〜70%でいいから細かく出して修正させてくれ」と嘆く開発。 こ…
AI時代の「開発生産性」はどこで測るべきか？4keysの次に来るもの
アジャイル開発が浸透してからというもの、我々は「4keys（デプロイ頻度、変更のリードタイム、変更障害率、復旧時間）」を主要な指標として追いかけてきました。特に「変更障害率」は、AIが生成するコードの品質を担保する最後の砦として、今後も変わらず重要であり続けるでしょう。 しかし、それらの数字が健全でも、現場では少し違和感が出始めているのではないでしょうか。「数字上は生産性が上がっているはずなのに、…
Dockerの.env、置いただけじゃ動かない！？環境変数の読み込ませ方備忘録
完全にやらかしました。 Dockerを使っているとき、「.envファイルに環境変数情報書いたし、同じ階層に置いたからこれでコンテナ内でも読み込めるっしょ！」と余裕をぶっこいていたら、全然読み込まれていませんでした。 というわけで、初歩的すぎて逆にハマる「Docker Composeでの環境変数の扱い」について、自分用の備忘録として残しておきます。 そもそも何が起きていたのか 「.envファイルは、…
DockerでARM版イメージを使うときにハマらないための備忘録
最近、PCをSnapdragon搭載のWindows機に買い替えて個人開発をしていたんですが、普通に使っているつもりでも「あれ？なんか挙動がおかしいな」とか「起動しないな」と感じることがあり、今後もARMアーキテクチャのマシンで開発を行う機会も増えてくると思うので、書き残しておきます。 明示的に指定しないとうまく動かないことがある 結論から言うと、Dockerイメージを使用するときに、明確にArm…
Snapdragon搭載PCに変えたので、開発環境構築の備忘録
最近、PCをSnapdragon搭載のマシンに変更しました。 従来のインテルなどのCPU（x64）とは少し勝手が違うため、自分用の備忘録として、「ここだけは気をつけるべき」というポイントをまとめます。 Docker Desktop は「Arm版」が必須 Docker Desktopなんですが、いつもの感覚でMicrosoft Storeから取得したり、適当なインストーラーを使うと起動しません。 S…
GitHub Copilotが頑なに英語で返してくるので、日本語で喋らせるためのinstructionsを書いた話
GitHub Copilotを使っていると、こちらが日本語で質問しているのに、なぜか英語で返答してくることってありますよね。特にドキュメント生成や、コミットメッセージの提案なんかで発生しがちです。 毎回「日本語で書き直して」と頼むのも手間なので、.github/copilot-instructions.md を作成して、最初から日本語で出力させるように矯正してみました。 今回はその設定ファイルの中…
GitHub MCPを使って、PRの指摘対応＆返信を自動化するCopilotプロンプトを作ってみた
「PR作成」「PRレビュー」と自動化を進めてきましたが、今回はその続き。 レビューで指摘された内容を修正して、返信するところまでを自動化するプロンプトを作ってみました。 作成した背景 これを作った背景は、自分の開発スタイルの変化が大きいです。 個人開発でのAI駆動開発の推進 最近は「基本的な開発はAIに任せる」という方針でやってます。いわゆるAI駆動開発ってやつですね。 人間はディレクションに回っ…
エンジニアの成長を阻む「現状志向」の壁。その正体とハック方法
はじめに：なぜぼくらは「レガシー」から抜け出せないのか 「今年こそはRustを習得するぞ」とか「インフラをIaC化して効率化するぞ」なんて正月に誓ったのに、気づけば年末。結局、手慣れた既存コードの保守と、温かみのある手動デプロイを続けている……なんてこと、ありませんか？ ぼく自身もそうです。「このコード、可読性が悪いからリファクタリングしてきれいにしたい」と常々思っているのに、いざ日々のタスクに向…
GitHub MCPを使って、PRレビューを自動化するCopilotプロンプトを作ってみた
前回、GitHub MCPを使ってPR作成を自動化してみましたが、今回は「コードレビュー」を自動化するプロンプトを作ってみました。 作成した背景 PRを作るのが楽になっても、その後のレビューがボトルネックになることってありますよね。今回これを作った背景はこんな感じです。 業務でのレビュー工数を減らしたい 単純なバグや仕様との食い違いみたいな指摘はAIに任せて、人間はもっと設計思想とか深い部分のレビ…
エンジニアを縛る「過去の武器」。スキルのサンクコスト効果との付き合い方
AI時代に「かつての必勝パターン」を手放せないエンジニア エンジニアとしての成長を考えたとき、こんな葛藤を感じることはないでしょうか。 例えば、生成AIの台頭です。 かつては、時間をかけて複雑な正規表現を一から組み上げたり、ドキュメントの隅々まで読み込んで独自の最適解を導き出したりする「職人芸」こそが、エンジニアの強みであり、自信の源泉でした。「自分にしかできない仕事がある」ことが、経験の証だった…
GitHub MCPを使って、PR作成を半自動化するCopilotプロンプトを作ってみた
普段の開発で、コードを書くのは楽しいけど、その後のプルリクエスト（PR）作成って地味に面倒だったりしませんか？ 「やったこと」や「背景」を思い出して、フォーマットに合わせて埋めていく作業。あれ、意外と脳のリソースを持っていかれるんですよね。 そこで今回、GitHub MCP（Model Context Protocol） を活用して、現在のブランチの変更内容からいい感じにPRを作成（または更新）し…
エンジニアの「バグ」を増やすも減らすもラベル次第？心理効果でチームを変える
はじめに：ラベルという「呪い」と「祝福」 マネジメントにおいて、部下やメンバーに対する「言葉」がどれだけ重いか、考えたことはありますでしょうか。 実は、「ラベリング効果」という心理効果によって、上司が貼ったラベル（レッテル）一つで、メンバーのパフォーマンスが良くも悪くも激変してしまうんです。 使い方を間違えると、優秀なエンジニアを潰してしまうこともあれば、逆に伸び悩んでいる新人をエース級に育てるこ…