6月19日、Shift Magazineが「AI in Engineering Teams: ROI, Code Review, and Hiring」と題した記事を公開した。トロントで開催されたCTO Craftカンファレンス併催のラウンドテーブルで、シニアエンジニアリングリーダーたちが自社のAI活用の実態を率直に語り合った——その議論の内容を伝えるレポートだ。スライドもスポンサーピッチもない場だからこそ出てきた言葉が揃っている。
スポンサー不在のディナー形式で行われたこのラウンドテーブルは、開始5分で一つの結論に収束した。誰もまだAI活用を本当に解決できていない。
ROIの話をしようとすると詰まる
「AIに投資せよ」という号令が当たり前だった時代は終わった。今CFOが聞いているのは「何を得ているのか」という一点だ。
問題はROIの「I（投資）」がまったく管理できていないことにある。エンジニアリングキャパシティはかつてヘッドカウントで表せた。ファイナンス部門がモデル化できた。今はトークン数で語られる。個々のエンジニアが1日に何トークン消費するか、誰もコントロールしていない。
CFOは契約にサインした瞬間から、実際の投資額に対してもはや制御できない。投資額が分からなければ、想定リターンとは何を意味するのか。
ツールを買い、契約にサインして、その後の費用管理モデルが社内に存在しないと気づいた組織の話が複数出た。参加者の一人はこれを「FinOps以前のクラウド黎明期」と形容した。コストは依然として曖昧で、メトリクスはまだ存在しない。
※ FinOpsとは、クラウドコストを継続的に可視化・最適化するための組織的プラクティスを指す。FinOps Foundationが標準化を推進しており、AWSやAzureなどのクラウド費用管理手法として広く普及している。AIツールのトークンコスト管理にも同じ枠組みの適用が議論され始めている。
一方で「今ROIを厳しく問うと、間違ったものを測ることになる」という指摘もあった。先にベースラインを確立すべきだという立場だ。
いずれは「このトークン数でこれだけの機能価値が出る」と予測できる状態になると思う。ただ今はまだそこまで言えない。
採用で問われているものが変わった
ディナーで表面化したのは、「エンジニアとは何か」についての認識の分断だ。
ある参加者は、混同されがちな二つの役割を明確に区別した。AIを使ってプロダクトを出荷するエンジニアと、システム設計を担うエンジニアだ。言語はもはや問わない。PythonでもGoでもRustでもいい。しかしシステム設計は変わっていない。可用性、コスト、アーキテクチャの判断はAIには代替できない。
新しいソフトウェアエンジニアはプロダクトリーダーだ。「どう動くか」ではなく「何を作るか」を考える人間。ただし設計を考えられる技術者も依然として必要で、それは別の仕事だ。
採用面接については、コーディングテストよりもコードレビューを軸に変えたチームの話が最も示唆に富んでいた。
面接プロセスをコードレビュー中心に変えた。それが今実際にやっていることだから。実装はAIアシストが前提で、エージェントをどう使うかは各自の裁量だ。
AIによってコードの生成速度がレビュー速度を上回り始めている。ボトルネックはアウトプットではなく人間の判断だ。この視点はコードレビューを採用基準にする判断と一致している。
「認知的負債」という新しい問題
AIはコードを書くコストを下げた。しかしそれは出荷コストや保守コストが下がることとは別の話だ。参加者の一人が端的に表現した。「認知的負債（cognitive debt）はテクニカルデットの新形態だ」。
ここで言う認知的負債（cognitive debt）とは、コードベースが急速に膨らむことでチームがその全体像を把握しきれなくなる状態を指す。従来のテクニカルデットが「設計・実装上の負の遺産が将来の変更コストを押し上げる」問題であるのに対し、認知的負債は「誰が何を書いたか・なぜそう動くかを人間が理解できなくなる」という知識・文脈の欠落の問題だ。AIが生成速度を引き上げるほど、この種の負債は加速度的に蓄積しやすい。
2年前なら不可能だったペースで機能を追加しているチームが、今その保守負荷に直面している。誰かが3つのプロンプトで作った内部ツールが、気づけば永続的な資産として運用されている。
「ビルドかバイか」「長期保守に値するか」というプロセスは理由があって存在していた。午後一つで動くものが作れると、そこをスキップしやすい。問題は後から来る。
構造的な答えとして「テクニカルヘルスチーム」の概念が出た。機能を出荷するエンジニアと、削除・リファクタリングを専門とするエンジニアを同等に評価する体制だ。ただしベロシティを優先するビジネスサイドの理解を得ることが最大の壁だという。
PMがPRをマージすべきか
最も議論が白熱したのはこのテーマだ。AIで誰でもコードが書けるなら、プロダクトマネージャーが本番環境にデプロイすべきか。
反論はこう表現された。
エンジニアを事実上「PMが書いたコードのレビュー係」にして、出荷のクレジットはPMが取るなら、エンジニアのメンタルヘルスを確認した方がいい。
この指摘が示すのは、役割の境界が崩れることへの実務上の懸念だけではない。アウトカムの帰属と責任の所在が曖昧になるという組織構造上の問題だ。コードを書いた人間が本番リスクを負わないまま出荷の意思決定に関与する構造は、何か起きたときの対処を難しくする。
一方で現実的な意見もあった。小規模・低リスクのタスクへの非エンジニアの参加はフィードバックループを短縮する。デザイナーがコンポーネントを自力で実装できれば、エンジニアの待ち時間がなくなる。PMがコピーのバグを自分で直せれば、Jiraチケットが一枚減る。ただしガードレールが正しく機能している場合に限る。
議論の着地点として浮かんだのは「スコープと権限の明確化」だ。PMが触っていいのはどの範囲か、どのレビュープロセスを経るべきか——そのルールを先に定義しないまま「AIがあるからPMもデプロイできる」という運用を始めると、障害発生時に責任の所在が消える。技術的な可否よりも、ガバナンスの設計が先決という認識で参加者はほぼ一致していた。
ベンダーロックインという構造リスク
AnthropicやOpenAIが価格を上げたり、サービスが停止したらどうなるか。
ある参加者は自社の状況を率直に表現した。Anthropicがシングルポイントオブフェイラーになっていると。エンジニアは単一障害点の意味を理解している。マーケティングや財務でClaudeを使っている人たちは理解していない。
エンジニアリング以外のチームが大量に何かを作っていて、その下に何があるかを本当には分かっていないと思う。推論が取れなくなった途端、マーケティングから、財務から、全員エンジニアに電話してくる。
対策として具体的に挙がったのは、今すぐ汎用モデルAPIの上にUIラッパーを作ることだ。モデルそのものは差し替えられる。スキル、ツール、内部ワークフローの方がはるかに移行コストが高い。ラッパーを先に作っておけば、モデルを入れ替えてもインターフェースを作り直さなくて済む。
同じ文脈で「evalスイートに今すぐ投資せよ」という提言も出た。
※ evalスイートとは、AIモデルが期待通りの出力・挙動をするかを自動で検証するテストセットの総称だ。ユニットテストがコードの品質を担保するのと同様に、evalスイートはAIの出力品質・一貫性を継続的に担保するための仕組みで、モデルのバージョン変更やベンダー切り替えの際に回帰を検出する役割を果たす。
AIを使った機能のビルドコストは下がった。検証コストは依然として高い。ベンダーがモデルを更新しても、evalスイートが揃っていれば切り替えに耐えられる。
ビルドのコストはそこまで高くない。検証のコストは高い。パートナーのベンダーがモデルを変えたとき——彼らはよく変える——evalスイートを走らせれば済む。
このラウンドテーブルに参加したCTOたちの間でさえ答えは出ていない。「誰もまだ解決していない」という冒頭の結論は、記事を読み終えても変わらない。
詳細はAI in Engineering Teams: ROI, Code Review, and Hiringを参照していただきたい。
