一貫性のあるAIポリシーを持とう

私が大学を卒業して最初に就いた仕事は、何百人ものパラリーガルを抱える法律事務所でした。彼らは差し押さえと破産案件を管理する社内ワークフローシステムを運用していました。住宅バブルが崩壊したとき、私は偶然にも好況の業界に飛び込みました。ピーク時には、年間10万件以上の案件を処理していました。仕事は細かくスライスされたタスクに分割されていました。パラリーガルは主に同じようなタスクのキューから作業しました。それは裁判所提出書類のための組み立てラインであり、テイラー主義が法律業務に持ち込まれたものでした。私が入社する前に、新しい役員が招かれました。彼女の仕事の一つはプロセスの合理化でした。彼女の計画は単純で、ストップウォッチを持って従業員の後ろに立ち、タスクの完了時間を計ることでした。その測定値に基づいてKPIが設定されました。これは予想通りうまくいきませんでした。役員が後ろに立ってストップウォッチを構えているとき、人は通常と同じようにタスクを実行しません。彼女はこれがどれほど無価値かをすぐに学びました。これはすべて、ソフトウェアエンジニアリングにおける最新のガベージKPIである「Tokenmaxxing」と、私がチームのために書いたAIポリシーへの導入です。Tokenmaxxingとは何か？Tokenmaxxingは、西暦2026年になっても、すべての指標が悪用されることを理解していない経営陣から生まれた最新の流行です。ストップウォッチを持ったあの役員は20年以上前に理解しておらず、今日でも明らかにそのメモを受け取っていないリーダーがいます。このアイデアは、最も多くのトークンを使用している人のリーダーボードを作成することで、AIツールの採用を促進するというものです。他のナイーブな指標と同様に、エンジニアはすぐにそれを悪用します。トークンを浪費するループを作成してリーダーボードのトップに躍り出るか、AIを「使用している」ことを示すのに十分なだけ浪費し、その使用法を説明しないようにします。これがリーダーシップとして通用しているようです。チームのために簡単に悪用できる指標を作成し、すぐに人々を実際に助けることから切り離します。結局のところ、私たちがここにいるのは人々を助けるためですよね？私は顧客が目標を達成するのを助けるためにここにいます。一定数のトークンを使用するためにここにいるのではありません。Tokenmaxxingはリーダーシップを装った虚栄の指標です。なぜAIポリシーが必要か？私はAIに非常に懐疑的なチームを管理していますが、それには理由があります。ここで倫理的懸念を列挙する必要はありません。それについてはすでに十分な論説があります。生産性の懸念についても列挙する必要はありません。風向きと木星の位置次第で、これらのツールがどれほど役立つかは異なります。持ち方によって0.1倍から10倍の生産性向上の信頼できる例を見つけることができます。しかし、私が確信しているのは、現在のLLMの世代が、私のほぼ20年のキャリアの中でソフトウェアエンジニアリングに最大の変革をもたらしているということです。チームのマネージャーとして、それについて何らかの立場を持つことは私の仕事の一部です。そこで、チームとの多くの議論の後、私はすぐにAI哲学を説明するガイドを作成しました。これをまとめた後、多くの開発者が職場にそのような文書を持っていないことに驚きました。命令は単に「できるだけAIを使い、うまくいくことを願う」ということです。要約：AIの義務化なし。AIが生成したコードが何をするか理解しなければならない。AIツールが消えても仕事ができなければならない。チームメイトと顧客を気にかける。詳細を見ていきましょう。AIツールをいつ使うか：AIツールの使用は義務ではありません。これらのツールをどれだけ使っているかで評価されることはありません。とはいえ、これらのツールは数十年で最大の変革です。日常的に使っていなくても、それらがどのように進化しているかを認識しておくことは有益です。この分野は非常に速く動いており、6ヶ月前の経験はおそらくもはや関連性がありません。スキルのこの大きな入れ替わりの副作用として、6ヶ月前に得た専門知識は今日ではおそらく無関係です。シニアエンジニアは、自分にとって最も効果的な方法でこれらのツールを使用することが推奨されます。それは日常のワークフローの不可欠な部分かもしれませんし、非本番コードの概念実証のための時々のツールかもしれません。AI推進派には矛盾があります。「今AIに乗り遅れると置いていかれる」「AIはあまりに速く動いており、今日知っていることはすべて6ヶ月後には無価値になる」この両方が同時に真であることはできません。なぜ6ヶ月待って、より良いモデルとテクニックを使えないのでしょうか？そのときには、現在のツールの未熟さを回避するためだけに存在するテクニックを学び直す必要はありません。私たちは賢い人材を雇い、仕事を任せています。彼らがどのOS、エディタ、LSP、AIツールを使うかは気にしません。プロトタイプに少し使っているのか、本格的に使っているのかも気にしません。重要なのは顧客に価値を提供しているかどうかです。しかし、ポリシーが言うように、変革は現実です。時々これらのツールを試すことは職業上の義務です。2025年6月に試したツールは、2026年1月に戻ってきたときよりもはるかに劣っていました。2026年6月に使っているツールはさらに良くなっていると期待しています。それはまだあなたのコードです：AIツールによって生成されたコードはあなたのコードです。PRのうちAIがどれだけ書いたかは関係なく、コードが何をするか理解することが期待されます。コードが既存のパターンに適合することも期待されます。AGENTS.mdファイルがこれを助けるはずですが、何も保証しません。レビューのために提出するコードが十分な品質であることを保証する責任はあなたにあります。レビュアーに過度の負担をかけてはいけません。時には問題のあるPRを提出することもありますが、それは言い訳になりません。最終的なアーキテクチャの決定は人間が行い、AIではありません。機械にとって簡単なコードと人間にとって簡単なコードのどちらかを選ぶ場合、私たちは人間を優先します。AIツールが常にコーディング標準に準拠しないコードを吐き出す場合、変更が必要なのはAIツールの方であり、おそらくAGENTS.mdファイルの改善です。AI最大化主義者はこのセクションを読んで嘲笑するでしょう。彼らはすでにすべてをバイブコーディングしており、生成されたコードがどのようなものかほとんど知りません。もし私たちがグリーンフィールドのスタートアップなら、私もこのアプローチを取るかもしれません。しかし、私たちはグリーンフィールドではありません。私たちには10年の歴史を持つコードベースがあり、異なるチームによってもたらされた矛盾するスタイルでいっぱいです。なぜそうなっているのかを理解するには、完全なコード考古学が必要なこともあります。AI最大化主義の賭けは、モデルが蓄積する技術負債を上回る速度で改善するというものです。これはスタートアップが何年も行ってきた賭けに似ています。初期のコードがどれほど悪くても問題ではなく、プロダクトマーケットフィットを見つけることに焦点を当て、持続可能性は後回しにします。しかし、私たちはすでにプロダクトマーケットフィットを達成しています。私たちはこのコードベースで今後10年間作業し続けられることを重視しています。顧客は現在の機能が動作し続けることを気にしています。もしあなたがAI最大化主義者なら、ボトルネックはどこに移っているのでしょうか？コードレビューでしょうか？顧客が何を望んでいるかを知ることでしょうか？顧客が吸収できる変化の速度でしょうか？理論的に10倍多くのコードを書けることは、顧客に10倍の価値を提供していることを意味しません。もし明日Claudeがダウンしたら、仕事を続けられますか？目の前のコードを理解できますか？もし来週OpenAIが倒産したら、コードベースの恐怖を目の当たりにして泣くでしょうか？私は10年間コンサルタントとして過ごし、本当にひどいコードベースに飛び込んだことがあります。あなたの選んだLLMがその日使えなくても、あなたが自分自身にもたらしたAIの粗悪品の中での5つの異なる日付フォーマット関数の使用法を三角測量しようとして震えるべきではありません。ジュニアエンジニアについてはどうか？あなたが自分の学習スタイルをどう思っていようと、私たちは皆、実践によって学びます。ソフトウェアでは、これはコードを書くことを意味します。真に学ぶためには、複数の理解レベルでコードの意味とニュアンスを考え抜かなければなりません。AIコーディングツールは、あなたから反復練習を奪うことでこの学習をショートサーキットします。このため、ジュニアエンジニアはこれらのツールを慎重に使用すべきです。AIツールにコードを書かせることに依存することは、長期的な成長を制限します。キャリアを進め、より大きなプロジェクトに取り組むために必要な深い理解を得ることができなくなります。これはツールを禁止するということではありません。しかし、もし明日AIツールが消えて、自分が貢献できなくなったとしたら、それは問題です。これは私が最も強く感じるポリシーの部分かもしれません。私たちの業界は急速にジュニアエンジニアのはしごを引き上げています。彼らが学ぶために必要な種類の仕事を取り上げています。AIが自動化に優れているような苦労の反復練習が必要です。現在のAIの世代は、ほとんどの人が学習がどのように機能するかを全く理解していないことをすぐに明らかにしました。学習スタイルは神話です。情報を消費する方法に好みがあるかもしれませんが、学習は実践によって行われます。学習は苦闘の中で起こります。概念と格闘し、時には混乱しなければなりません。それはオプションではありません。もしLLMにほとんどのコードを書かせ、自分で書く反復練習をしなければ、あなたは学びません。深い理解を得ることはできません。ジュニアエンジニアがこれらのツールをどの程度使うべきかは、あなたのチームにおけるジュニアの役割と、彼らのキャリアに対するあなたの責任に依存します。私はジュニアエンジニアに生産的であることを期待していません。彼らが生産的になる方法を学ぶことを期待しています。彼らが間違いを犯すことを期待しています。彼らがコードベースの学習方法を学ぶことを期待しています。彼らがドメインの学習方法を学ぶことを期待しています。そして、もし彼らがその大部分をLLMに外注しているなら、自分で考え抜く方法を学ぶことはありません。現在の形のAIは、これらの詳細が合理的に複雑なコードベースやドメインで常に表面化しないようにするには、あまりに漏れやすい抽象化です。それが変わるまでは、ジュニアは学ばなければならず、学習は実践によって行われます。あなたは、自分のチームにおけるジュニアの役割と、彼らの成長に対する責任を何らかの形で明確に述べることができるべきです。あなたの役割と目標は私のものと異なるかもしれません。それが、彼らがどの程度ツールを使うべきかについてのあなたの哲学を導くべきです。私たちは人を大切にします：最終的に、私たちは顧客が人々にリーチするのを助けるためにコードを提供します。私たちは顧客を大切にします。同時に、私たちはチームとして内部で働き、チームメイトを大切にします。これら二つのオーディエンスはしばしば緊張関係にあります。顧客が人々にリーチするのを助けるために、より多くの機能を提供するプレッシャーがあります。これは短いバーストでは良い理由で問題ありませんが、やりすぎると技術負債が蓄積され、チームメイトを傷つけます。これはAIの世界で関連します。顧客をより満足させるために、AI生成コードをできるだけ多く出荷する誘惑があります。しかし、これはコードベースのAI粗悪品を犠牲にしてはいけません。それは長期的な生産性とチームの幸福を傷つけます。エンジニアは一日中AI粗悪品のPRをレビューすることに費やしたくありません。Tokenmaxxingは人を大切にすることから切り離されています。私はトークンではなく、人を大切にします。トークンを使うことが人を助けるのに役立つなら、どうぞ使ってください。しかし、トークンは目的ではなく手段です。私のエディタは手段であり、私の選んだプログラミング言語も手段です。私のチームは「人」というカテゴリのサブセットです。私は人を大切にします。最終的に、私のチームが顧客に価値を提供し、同時に仕事を楽しみ、成長できることを望んでいます。それがこのポリシーを作った理由です。