「質とスピード」の
トレードオフは
存在しない。

命題——「削られているのは教育である」

2020年2月、Developers Summitで和田卓人(t-wada)氏は『質とスピード』という講演を行った。当時のスライドは短く、結論は明快だった。品質を犠牲にしても、スピードは上がらない。マーティン・ファウラーの "Is High Quality Software Worth the Cost?"(2019)とDORA State of DevOpsの定量データを引きながら、内部品質への投資の損益分岐点はせいぜい数週間以内であることを示した。

しかし、その2020年版の末尾に、それまでのバージョンになかった一行が追加されていた。

スピードおよび質と
トレードオフされているのは、
教育・成長・多様性への投資である。

これがt-wada論のもうひとつの核心であり、本稿が深掘りするテーマである。命題はその後も再演や議論を通じて磨かれ、生成AI時代には「AIに作業を手伝わせることはできても、能力そのものは代わりに育ててもらえない」という形で読み替えられるようになった。

一見すると当たり前のことを言っているように聞こえる。しかし、この命題が強力なのは、「品質と速度のトレードオフ」という長年の通説に対する反証として機能しながら、同時にでは何が削られているのかという問いに答えていることにある。品質・費用・納期だけを見ていると見落とすが、実際には教育や成長の時間が削られている——というのが、この論の全体像である。

公開スライドから見える変遷

学術的裏付けは、思っているより強い

「質とスピードは両立する」という主張は、感覚論ではない。ここ20年で蓄積されてきた実証研究が、強く支持している。

DORA: 11年・約4万回答の累積データ

『State of DevOps Report』は2014年から継続的に実施され、累計で39,000人以上の回答を集めている。最大の発見は、高パフォーマンス組織と低パフォーマンス組織の間に、信じがたいほどの差があるということだ。しかも速度と安定性は同時に向上し得る——これが繰り返し示されている。

— DORA State of DevOps Report / Forsgren, Humble, Kim『Accelerate』(IT Revolution Press, 2018) をもとにt-wadaスライドで整理された数値。208×（デプロイ頻度）は最も広く引用される代表値。

『Accelerate』はShingo Publication Awardを受賞しており、高パフォーマンスなソフトウェアデリバリ能力と組織成果の相関も示している。速度と安定性は二律背反ではない——むしろ、両方達成しているチームこそが速い。

SPACE: ひとつの数字だけで測ると、行動が歪む

2021年、Forsgren・Storey・Maddila らは ACM Queue 誌に "The SPACE of Developer Productivity" を発表した。要点は容赦ない。開発者の生産性は、ひとつの数字では測れない。ひとつの数字だけで評価しようとすると、人はその数字だけをよく見せる方向に動き、開発者自身もチームも傷つく。 たとえばPR数だけを追えば、小さなPRを量産したくなる。チケット消化数だけを追えば、難しい改善や教育は後回しになる。SPACEは、満足度・成果・活動量・協働・効率のような複数の観点を、緊張関係のまま見ることを勧めている。活動量だけを追えば、学習時間は必ず削られる。

TDD: 短期コストと中長期回収の構造

Nagappan ら（Empirical Software Engineering誌, 2008）は、TDD適用と非適用のペア比較で次を観測している。

つまりTDDには短期コスト（開発時間+15〜35%）が確かに存在する。これは正直に認めるべきだ。t-wada論は「短期で速くなる」とは言っていない。数週間〜数ヶ月の地平線で初めて回収されると言っている。1日で出荷したい局面では、命題は成立しない。

心理的安全性: 教育の前提条件

Edmondson 1999（Administrative Science Quarterly、製造業51チーム調査）は、心理的安全性 → 学習行動 → チームパフォーマンスという媒介モデルを実証した。Google Project Aristotle（180+チーム調査、2015）も5因子のうち心理的安全性を最重要としている。「教育を削らない」は精神論ではなく、心理的安全性という具体的な土台がなければ起こらない——これが学術的合意だ。

AI生産性データの逆説——+55.8%と−19%は両方とも本当である

AIコーディング生産性の研究は、結果の振れ幅が大きい。一方は劇的な向上を、もう一方は停滞や悪化を報告している。

本人は速くなった気がする。でも全体では遅くなることがある

METR論文の発見は強烈だ。事前予測+24%短縮 / 事後自己評価-20%短縮 / 実測-19%遅延。つまり開発者は、自分がAIでどれくらい速くなったかを過大評価しやすい。Simon Willisonはこの結果について「AIから本当に生産性向上を得るには、ほとんどの人が思うよりはるかに急な学習曲線がある」と書いている。

AIは70%を素早く生むが、
残り30%（エッジケース・本番統合・
セキュリティ）は依然として時間がかかる。

— Addy Osmani "The 70% Problem"（2024）

ここに整合的な解釈がある。個人としては速くなった気がする。しかし、経験豊富な開発者では実測で遅くなる場合があり、チーム全体ではレビュー負荷が増え、安定性やコードの健全性が悪化することがある。 つまり、個人の体感とチーム全体の結果は、同じ方向に動くとは限らない。

なぜAIは「教育」を削るのか

t-wada論をAI時代に読み替えると、論点はこう整理できる。

AIは書くスピードを上げますが、
学習の時間とはぶつかりやすい。
教育の強度を維持し、学習に時間を
かけさせることへの覚悟が問われます。

従来の開発には、教育が自然に組み込まれていた——コードレビュー、ペアプログラミング、新人がエラーで詰まって先輩に聞く時間、書きながら考える時間。これらは生産性の「無駄」のように見えながら、実は能力という資本を蓄積していた。

教育が削られる3つの仕組み

これらは個別には小さく見える。しかし合算すると組織の中に能力がたまらない構造になる。作業はAIに手伝わせられるのに、判断力や設計力がチームの中に育たない経路ができてしまう。

個人的には、ここで守りたい「教育」は研修制度のことだけではない。レビューで一度立ち止まること、なぜその実装にしたのかを言語化すること、失敗した変更を自分の手で直すこと。そういう小さな摩擦の積み重ねが、エンジニアとしての判断力を作ってきた感覚がある。AIで労力を減らすのは歓迎したい。ただし、判断力が育つ摩擦まで全部消してしまうと、あとで自分たちが何を失ったのか分からなくなる。

教育を削らない5原則

個人と小規模チームの両方で、すぐ試せる形に落とした実践案。

最後の聖域

t-wada論の中核命題は、AI時代にもこう言える。

質とスピードを支えているのは能力であり、
教育に投資することは
将来の質とスピードを作ること。

この読み方は、Peng 2023の+55.8%とMETR 2025の-19%、DORA 2024の安定性 -7.2%、GitClearなどの重複・変更過多への警告——という矛盾して見えるデータ群を、「個人では速くなった気がする一方で、能力育成・コードの健全性・システム安定性は悪化し得る」という形で説明できる。

学術的な「質と速度の同時達成」（DORA・Accelerate・Nagappan・Edmondson）は依然として成立する。ただし条件は、「学ぶ機会・心理的安全性・小さな変更・自動テスト・継続的リファクタリング」が保たれる場合のみである。

そしてAIエージェントは、これらの条件を自動的には強化しない。むしろレビュー疲れ・PRサイズ肥大・コード重複増という形で、教育を削る方向に圧力をかける。

作業はAIに手伝わせられる。けれど、判断力や設計力まで代わりに育ててもらうことはできない。その境界線をどこに引くかが、これからの差別化要因になる。