チーム全員が 10 倍速に、生じる「速度病」の正体

AI導入でチームが「速度病」に陥る理由と、解決策はドキュメントにある

AI ツールの普及により個人の開発スピードが劇的に向上した今、組織全体では逆に混乱が生じているというパラドックスが存在します。Matt Dailey 氏はこれを「速度病（Velocity Sickness）」と呼び、単なる生産性向上の壁ではなく、開発プロセスの本質的な再構築を迫る課題として捉えています。

「速度病」が引き起こす4つの深刻な症状

AI エージェントの導入により、エンジニア一人ひとりが以前よりもはるかに速くコードを書けるようになりました。しかし、チーム全員がこのスピードで動き出すと、以下のような問題が発生します。

1. PR の過多によるマージ混乱

個人が「すごいスピードで納品している」という感覚に陥り、PR（プルリクエスト）が殺到します。結果としてマージ競合が頻発し、キューが崩壊して開発フロー自体が止まってしまうのです。

2. 方向性の不一致による分断

複数のエージェントが異なるタスクを並行して実行する中、人間側も「誰が何をしているか」を追跡できなくなります。組織レベルでは、エンジニアたちがバラバラの方向へダッシュし始め、チームとしての一体感や焦点が失われます。

3. エージェントの使い捨て（アーキテクチャの崩壊）

一日中12ものターミナルを開き、大量の作業をこなしたと満足して翌朝出社すると、前日のコードや設定が「見知らぬ他人のもの」のように感じられる状態です。エージェントを「使い捨て」として削除し、同じ問題を二度手間（トークン消費）で解決する非効率なループに陥ります。

4. コード所有権の喪失

最も深刻なのが、AI エージェントが重要な技術的決定を下してしまうケースです。エンジニアが判断を委ねてしまうと、コードに対するオーナーシップは AI に移り、製品への責任と所有権も失われます。組織全体でこれが起きれば、最終的に「自社が自社のプロダクトを所有していない」という事態に陥ります。

これらの症状は、出力量は増えたもののインパクトがないという「速度病」の典型です。まるで週に一度本を書くニュースレター作家が、読者が誰も読んでいないページを量産しているような状態です。私たちは「速く書くこと」ではなく、「誰かに届き、価値を生む言葉（コード）」を書くべきなのです。

実装から「決定層」へのシフトが必要

従来のソフトウェア開発は、IDE（統合開発環境）を中心に据えた「計画→実装→調整」というワークフローが主流でした。しかし、AI の登場でこの形は崩れました。現在は、人間がアイデアを練り、エージェントが実装を行い、最後に人間が品質を確認する形へと変化しています。

ここで重要なのは、エンジニアの創造的価値が「実装」から「決定層（Decision Layer）」へ移行しているという点です。

「エンジニアリングの創造的な価値は、複雑なシステムの輪郭を理解し、方向性を定め、エンジニアとしての『 taste 』を表現する計画段階にあります。」

AI が実装を担うようになった今、人間がすべきことは「何を作るか」「どうあるべきか」という意思決定です。これは個々のコードを書く作業とは異なるギアであり、チームで複雑なシステムを管理し、その未来を決定する役割へとシフトしています。

チャットではなく、ドキュメント主導へ

この新しいワークフローを支えるためには、ツールとアプローチの転換が必要です。これまでのチャットベースの対話は、「実装」や「タスク完了」のために作られたものであり、孤立しており、一時的で記憶に残りにくいという欠点があります。

決定層での作業には、ドキュメント中心のアプローチが不可欠です。

• 永続性と共有: チャットは消えてしまいますが、ドキュメントは意思決定を永続的に記録し、チーム全体で共有できます。
• 文脈の維持: エージェントとの対話で下された重要な判断や、なぜその選択をしたのかという背景（コンテキスト）を文書化することで、後から戻った際にも「見知らぬ他人」のコードになるのを防げます。

かつてチームが方向性を失った時、マネージャーはチャットや DM ではなくドキュメントで合意形成を図るよう指示したはずです。AI 時代においても、この原則は変わりません。重要な意思決定をドキュメントとして可視化し、チーム全体で合意形成を行うことが、速度病の解決策となります。

人間の意思決定権限を堅持する

最終的に、AI エージェントが実装を高速化する一方で、技術的な決断や方向性の決定は人間が行うべきです。これにより、製品への所有権と責任を維持できます。

人間が意思決定の主導権を持ち、チームで共有された計画を起点にすることで、AI を活用した持続可能な開発フローを構築できるのです。スピードだけを追求するのではなく、「誰のために」「何を作るか」という本質的な問いに立ち返り、ドキュメントを通じて合意形成を図ることで、組織全体が真の意味で 10 倍速になることができるでしょう。