DeNAの南場智子氏が「AIオールイン」から1年後に語った話は、しばしば「削減が思ったより小さかった」と覚えられています。実際は違います。タスクは大きく速くなりました。減りにくかったのは人数であり、空いた時間の行き先でした。
この記事では、南場氏が語った1年の中身を追ったうえで、それがエンジニア現場でどう起きているかを整理します。結論は単純です。AIは「できること」を増やしますが、「なぜやるのか」は決めてくれません。
まず、DeNAの1年で何が起きたのか
要点：効率化は大きく進みました。進まなかったのは、新規事業への人材シフトです。
DeNAが「AIオールイン」を宣言したのは2025年2月でした。その1年後の進捗が語られたのが、2026年3月6日に開かれた「DeNA × AI Day 2026 | Proof.」のクロージングです。当時の南場氏の肩書きは代表取締役会長。以下の発言と数字は、DeNAが公開しているスピーチ全文書き起こしから引いています。
当初の目標は、コスト削減そのものではありません。現業を薄くすることと、新規を厚くすることを同時にやろうとしていました。
| 項目 | 内容 |
|---|---|
| 宣言 | 2025年2月、「AIオールイン」 |
| 振り返り | 2026年3月6日、DeNA × AI Day 2026 |
| 当時の現業規模 | およそ3,000人 |
| 狙い | 半分の人員で現業を維持するだけでなく発展させる |
| 余力の使い道 | 出てきた人員を新規事業へ回す。一つではなく、たくさん |
1年後に出た数字を見ると、効率化が小さかったとは言えません。
| 領域 | 南場氏が示した数字 | 意味 |
|---|---|---|
| 開発（一部プロジェクト） | 人が5%、AIが95% | 南場氏はこれを「20倍の生産性」と表現 |
| リーガルチェック | 90%の効率改善 | AI前提で業務フロー自体を組み替えた成果 |
| QA | 半分の工数で同じことができる | 品質管理の工数半減 |
| Pococha配信審査 | 60%削減 | 特定業務のコスト削減 |
つまり、「AIは効かなかった」ではありません。効きました。かなり効きました。問題は、その先です。
南場氏の説明はこうです。同じタスクをするのに工数が少なくて済むようになると、新たにできた時間で「やりたくてもできなかったこと」を自分でどんどん詰め込んでいく。新規事業への人材シフトは、思ったほどまだできていない。現場からは「AIすごいよ。今までやりたかったけどできていなかったことが、できるようになった」という声が上がります。しかし南場氏の目から見ると、それは曲がりなりにも、やらないでなんとか成立していた仕事でした。だから「人が浮いてきました」と自ら言ってくる人は誰もいない。仕事を取りに行ってしまうからです。結論として、先に「バサッと」人を動かす仕組みと、トップの多少乱暴なリーダーシップが必要だ、という話になります。
覚え方と実態のズレは、表にするとこうなります。
| よくある覚え方 | 実際 |
|---|---|
| 1年やって削減は少しだけ | タスク効率は大きい（5%/95%、90%、半減、60%） |
| その分を新規事業へ回せると思っていた | 人員シフトは想定より進まなかった |
| AIで新しいことができるようになった | 正確には、以前からやりたかったが後回しにしていたことを、空いた時間でやっている |
| AIが失敗した | 効率化は成功し、余白の配分が失敗した |
「削減が少し」ではありません。余白が新規事業に転化しなかったのがポイントです。
なぜエンジニアあるあるに見えるのか
要点：後回しにしてきた品質投資が、AIによって初めて「やれる規模」になりました。
この話がエンジニアに刺さるのは、ソフトウェア開発では「やらなかったこと」が最初から欠陥として見えるわけではないからです。プロダクトは動きます。リリースもできます。ただ、現場の頭の中には未消化のリストがあります。
| 後回しにされやすいもの | やらなくても成立するか | AI後に起きること |
|---|---|---|
| もう一段細かい実装 | 成立しやすい | やりきれるのでやり始める |
| テストコード | 主経路だけでも出荷できる | テストを厚くしたくなる |
| 例外・リトライ・観測 | 平時は困らない | 堅牢化に時間を使う |
| 設計の整理、境界、命名 | 動いていれば後回しにできる | リファクタが正当化される |
| いわゆる技術負債 | 多くは「今はやらない」だった | 消化可能な量になる |
これまでそれは、能力不足というより納期と優先順位の問題でした。AIで実装コストが下がると、未消化リストが一気に実行可能になります。すると見た目の生産性は上がっているのに、人は減りません。余った時間は、既存事業の完成度を上げる方向に吸われます。
南場氏の「やらなくても成立していた」をエンジニアの言葉にすると、こうなります。
必須ではなかった品質投資が、AIによって初めて「やれる規模」になった。
技術負債という言葉は便利ですが、中身は一枚岩ではありません。放置されたバグもあれば、本来やりたかった設計もあります。AI時代に露わになったのは、後者の比率が想像以上に大きかった、ということです。これまで「負債」に見えていたものの一部は、実は意図的に切り捨てていた品質でした。
「無駄」の感覚が人によって違う
要点：AIで揃うのは生成速度であって、何を十分とするかの判断ではありません。
ここが現場を一番難しくします。甘いコードで先に出す人と、いつまでも堅牢なコードを書く人では、最適化している変数が違います。
| タイプ | 最適化しているもの | AI後にやりがちなこと | 他者から見た印象 |
|---|---|---|---|
| 早く出す人 | 速度と学習 | 動くものを量産する | 甘い、雑 |
| 壊れにくくする人 | 障害確率と保守 | 例外とテストを厚くする | 堅い、遅い |
| 美しくする人 | 設計と将来の拡張 | リファクタと命名に入る | 過剰、理想主義 |
AI以前は、この差が個人の作業時間で自然に制約されていました。いくら堅牢に書きたくても、手が足りなければ切り捨てざるを得ません。AI以後は、その制約が緩みます。すると「品質の上限」が個人の美意識に引っ張られ、同じチケットでも成果物の厚みがばらつきます。
だから「AIを使えば品質が揃う」は成り立ちません。揃うのは生成速度であって、何を十分とするかの判断ではありません。判断が揃わないまま生成だけ速くなると、レビュー観点が人依存になり、見積もりが再び崩れます。
南場氏の会社で起きた「空いた時間に以前やりたかったことを詰める」は、組織全体で見るとこの現象です。余力が戦略に流れず、各人の未完了リストに流れています。
揃えるべきなのは、完了条件からではない
要点：いちばん上に置くのは、テスト方針でもDefinition of Doneでもなく「なぜやるのか」です。
制御が必要なのは間違いありません。ただし揃える層のいちばん上に置くべきなのは、テスト方針でも Definition of Done でもありません。なぜやるのか です。
完了条件から入ると、品質は厚くなる方向に最適化されやすくなります。テストを書くのも設計を整えるのも正しい。ただ、正しいことが今の向きかは別問題です。南場氏の話で余力が新規事業に流れなかったのも、空いた時間の使い道を決めるベクトルが現場になかったからです。現場は誠実に、手元の未完了リストへ進みます。
揃える層は、こう置きます。
| 層 | 問うこと | 決まらないと起きること |
|---|---|---|
| 0. なぜやるのか（ベクトル） | この仕事で増やしたいものは何か。増やさないものは何か | AIが「できること」を全部やり始める |
| 1. 何をやるか（範囲） | 細かい実装、テスト、堅牢化、設計整理のどれを採用し、どれを見送るか | 範囲が個人の美意識になる |
| 2. どうやるか（手順） | リポジトリの流儀、禁止事項、失敗時の直し方 | 進め方が人によって変わる |
| 3. どこまでで止めるか（完了） | このベクトルに対する十分条件は何か | いつまでも厚くなる |
| 4. 誰の基準か（所属） | 個人のローカル設定か、企業・プロジェクトの共通物か | 品質も見積もりもばらつく |
0が無いと、1以降は全部、品質を増やす装置になります。エンジニアあるあるではそれが正義に見えやすい。だから先に向きを固定します。
実務では、ベクトルをチケットへ一文で置けば足ります。
| 今回のベクトル | やってよいこと | やらないこと |
|---|---|---|
| 仮説検証 | 主経路を動かす。壊れてよい | 全例外の堅牢化、広いリファクタ |
| 本番投入 | 例外、観測、リトライ | 美しさのための設計変更 |
| 負債返済 | 挙動を変えずに整理する | 新機能のついで実装 |
これがあると、甘い人も堅牢な人も同じ方向に止まれます。AIで品質が揃うのではありません。揃えるべき方向を先に固定するから品質が揃う。 見積もりが楽になるのも同じ理由で、工数の振幅は「どこまでやる人か」ではなく「このベクトルで十分か」に落ちます。
ワークフロー、Agent Skills、ハーネスは何のためか
要点：向きと完了条件を、個人の良心から仕事の仕組みへ移すための道具です。
AIを使うだけで品質は均一になりません。均一になるのは、向きと完了条件を、個人の良心から仕事の仕組みへ移したときです。
ここで言うハーネスは、AIを囲む約束事の束です。ワークフローが「いつ、何を決めるか」を持ち、Agent Skills が「その決め方を毎回どう実行するか」を持ち、プロジェクトや会社がそれを共通資産として配ります。個人のClaude設定やローカルルールに品質を預けません。フィールフロウがAI仕様駆動開発を開発標準にしたのも、目的・制約・完了条件を着手前に固定する場所を、個人ではなく仕組みの側に置くためです。
南場氏が見たズレも、構造は同じです。
| 層 | 会社側 | 現場側 |
|---|---|---|
| なぜ | 現業を半分で回し、余力を新規へ | 後回しにしていた品質を回収する |
| 何を | 人員シフト | やりたかった実装・テスト・設計 |
| 結果 | 業容を広げたい | 既存事業がより丁寧になる |
両方とも正しい。向きが違うだけです。正しいものが二つあるとき、個人の誠実さに任せるほど、余白は手元の未完了リストへ流れます。
まとめ
要点：先に決めるべきなのは、どれだけ速く書けるかではなく、この仕事は何のためにやるのか、です。
制御しないと、AIは余力を生む装置ではなく、未完了リストを無限に消化する装置になります。DeNAの1年が示したのは、AIの効果の小ささではなく、空いた時間に向きを与える仕組みの不在でした。
自社で確かめる方法は簡単です。直近のチケットを10枚開き、「この仕事で増やしたいものは何か」が一文で書いてあるかを見てください。書いてなければ、AIが速くした分は、すでに誰かの未完了リストへ流れています。
参考資料・データソース
確認範囲：南場氏の発言と数字は、DeNAが公開するスピーチ全文書き起こしで原文を確認しました。本文中の要約は、原文の趣旨を変えない範囲で整えています。
- DeNA南場智子「先に動かし、事業を広げる」 スピーチ全文書き起こし（フルスイング by DeNA） — 2026年3月6日「DeNA × AI Day 2026 | Proof.」クロージング。3,000人の現業、5%/95%と20倍、リーガルチェック90%、QA半減、Pococha配信審査60%、「やりたくてもできなかったこと」を詰め込む、「人が浮いてきました」と誰も言わない、多少乱暴なリーダーシップ、の各発言を2026年9月7日に確認。
- DeNA 南場智子会長が「AIオールインからの1年」語る（日本ネット経済新聞） — 同講演の報道。数字と当時の肩書きの照合に使用。確認日：2026年9月7日。