現在、私の関わる開発の指標として「コードの変更行数」「使用トークン数（GitHub Copilot）」「マージ数」などを計測している。
そこから見えてきた事実がある。チーム内で比較すると、純粋に「トークン消費量が多い人ほど、変更行数が多い」のだ。
こうなってくると、大量のコードを書くことは「個人の実力」ではなく、単に「AIをいかに使えたか」という次元の話になってくる。
トークン効率＝生産性ではない
単なる「変更行数」の比較には意味がない。最近GitHub Copilotが従量課金になったこともあり、計測データを見る際、私は「消費したトークン数」と「変更行数」の比率を確認するようにしている。
例えば、同じ1万行の実装でも、あるメンバーは1万トークンで到達し、別のメンバーは5万トークンを消費していたとする。
この差を見たとき、「5万トークン消費した人は意図しない不具合や問題が発生して迷走したのでは？」と推測できる。ただ、これは単なる「作業効率」や「AIの効率」の話であって、「生産性」そのものではない。
プロジェクトに求められる「AIのハーネス作り」
全員がAIを使って「ある程度のコード」を爆速で書けるようになった今、重要になってくるのは個人の実力ではない。
プロジェクトの階層をどうするか、コードベースをどうするか、1ファイルの行数をどうするか。AIがいかに気持ちよく、間違いが少なくなる環境（ガードレールやハーネス）を定義できるか。それがプロジェクトをスムーズに進める鍵になってくると感じる。
AIが迷走してトークンを無駄撃ちする根本原因は、大抵の場合、コードベースの乱れや人間側の設計の甘さにあるからだ。
「生産性」という指標の形骸化
コスト削減やスケジュールの遅れ挽回など、生産性を測る理由はプロジェクトごとに存在する。しかし、AIによってコードの「量」が容易に担保できるようになった結果、指標としての行数やコミット数は形骸化してきたと感じる。
重要なのは、1ヶ月で何万行のコードを書いたかではなく、「利用者の手作業を何時間減らせたか」という実績値（アウトカム）だ。ただ、この実績値をどう定義し、どう設定するかが凄く難しい。
生産性はあくまで課題を解決するための「手段」であって、「目的」ではないと感じる。
レトロスペクティブの評価軸を変更した
ここ2ヶ月、従量課金に移行する前と後で、チームのレトロスペクティブ（振り返り）での評価軸を変更し始めた。
「なぜ今週は実装行数が少ないのか」という不毛な追求は廃止した。大量のトークンを消費しているのにコードが生成できていないなら、個人のスキル不足ではなく「AIが迷走するほど既存のコードベースが汚い」あるいは「そもそも事前の設計に誤りがあったんじゃないか？」と疑うようにしている。
そして何より振り返るべきは、「AIで浮いた時間を使って、チーム内でどれだけ実のある協議ができたか？」「利用者や関係者とどれだけ価値のある打ち合わせができたか？」という点だと思う。
量や数をこなすことで、初めて質（本質的な課題解決）に進めることができる。
評価の基準は、もはや「コードの量」ではなく「課題解決の質」へとシフトし始めている。
（※単なる「手打ちコーディング」の価値が崩壊した現実と、これから戦うべきレイヤーについては、こちらの記事でも詳しく触れている。）
コメント