最近、AIを使ったソフトウェア開発の話をしていて、話が噛み合わないことが増えました。 「Claude Codeすごいですよね」「Cursor使ってます」みたいな表面的な話で終わる人もいます。一方で、「いまうちはCIに3つのエージェント並走させて、人間はラベル付けるだけにしてます」みたいな話が出てくる人もいます。同じツールを使っているはずなのに、見ている景色が全然違うわけです。 両者の差がどこから来ているのか、最近ずっと考えていました。 そのうちにだんだん見えてきたのは、AIを使いこなしている人とそうでない人の違いは、ツールの知識量でもプロンプトの上手さでもないということです。 差がついているのは、「評価して、改善ループを回す力」だと思っています。 AIは「作る能力」は持っています。AIの作る能力は年々急速に上手くなっています。ただ、「評価する能力」は持っていないか、持っていても極めて不完全

最近、プロダクト開発をしていて気づいたことがあります。 僕はもう、IDEやエディタをほとんど開いていません。 以前なら、開発といえば、まずVSCodeなどのエディタを立ち上げて、コードを書き始めるのが当たり前でした。 でも今は違います。AIに「こういう機能を作って」と指示を出して、生成されたコードを読んで、「ここを直して」とフィードバックする。この繰り返しでほとんどの開発が完結してしまいます。 プロダクト開発を行うメイン業務は「コードを書くこと」から「コードを読んでチェックすること」に変わりました。 この変化を経験して思ったのは、「書ける」能力より「読める」能力の方が重要になってきているということです。 これは何かに似ていると考えていまして、漢字です。 漢字の「読める」と「書ける」日本人なら誰でも経験があると思います。 「薔薇」を読むことはできます。でも、いざ手書きで書こうとすると書けませ

リモートワークは通勤時間もないし、集中した時間を確保できるので個人としてはとても良いと思っています。 ただし、マネージャーや同僚から「ちゃんと働いてるのかな？」と疑われる可能性は常にあるという話を書きます。 「疑われている」と書くと信用されていないのでは？ と思っていまいますが、受け入れるべき前提だと僕は思っています。 オフィスなら椅子に座ってるだけで「働いてる感」が伝わる。でもリモートでは、見えない。 だからこそ「見えること」を意識して作らないと信頼関係は簡単に崩れてしまいます。 リモートワークは、意図的に見える情報を作ることが重要なんです。 見えないことの不安Slackの返事が数時間ないだけで「作業中」から「サボってる？」に変わる。Pull Requestにコメントがついても翌日まで無反応だと「気づいてないのか、無視してるのか」と思われる。 人は見えないとき、悪い方のシナリオを想像しや

プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では

最近、Claude Codeを使っている人から「レビューが追いつかない」という相談をよく受ける。これは偶然ではなく、必然的に起きる現象だと考えています。 このnoteでは どうしてClaude Codeによる生産性向上の限界が訪れるのか どうすれば、全体の生産性が向上するのか Claude Codeを利用した場合にレビュープロセスでのボトルネックをどのように解消させていくか の3つを書いていきます。 プロダクト開発の典型的なワークフローまず、多くのチームで採用されている機能追加のワークフローを整理してみる。 ※あくまで一般例なので、チームにより変更があると考えています 機能追加のワークフローこの流れ自体は理にかなっていると思っています。 問題は各プロセスの処理速度のバランスです。 ボトルネック理論で考える開発プロセス生産管理の世界には「制約理論（TOC: Theory of Constra