速度と理解のあいだにある緊張

出典: The Tension Between Velocity and Comprehension

AIはソフトウェアの出荷を加速させた。次のボトルネックは「共通理解」かもしれない。

先週交わしたある会話が、どうしても頭から離れません。

話し相手は、大手航空会社向けのアプリケーションを手がけるソフトウェア企業のデベロッパーでした。彼らの組織は最近、AI駆動開発に「全面的に賭ける」ことを決めたのだそうです。

印象に残った例がひとつあります。問題の中身を理解していて、自分ならすぐ直せると分かっているときでさえ、まずAIに投げることを推奨されている、というのです。AIに修正を試みさせ、その提案を可能な限り受け入れるほうがいい——そういう考え方でした。

そこに、例外なく2週間ごとという厳しいリリースサイクルが重なります。彼らの日常がどんなものか、想像がついてきます。

会話の途中で、私はこう尋ねました。

「作っているものに対する当事者意識や理解は、どうやって保っているんですか」

少し間を置いて、彼らは言いました。「たぶん、気に入らない答えだと思いますよ」

その答えは、「もう気にしていない」というものではありませんでした。理解することが、トリアージの対象になってしまった、というのです。読めるものは読む。任せるしかないところではエージェントを信じる。そして前に進み続ける。なぜなら、周囲の仕組みが「動き続けること」に報いるようにできているからです。

あの会話のことを、それ以来ずっと考えています。

私が言いたいわけではないこと

ここは慎重に書きたいところです。この文章は、誤読されやすいと思うからです。

私はこのデベロッパーを悪者にしたいわけではありません。彼らの周囲にいるリーダーたちを責めたいわけでもない。ソフトウェア開発への期待が急速に変わりつつあるこの瞬間に、登場人物の全員が適応しようとしているだけです。このデベロッパーは、自分が受け入れているトレードオフについて正直に話してくれました。その種の正直さは貴重なものです。感謝しています。

AI支援開発そのものを敵視したいわけでもありません。私自身、AIをきっかけにソフトウェアを作る側に戻ってこられた人間です。エージェントのおかげで、研究対象としてのプロダクトと、実際にそれを作る行為との距離がぐっと縮まりました。数年前なら何週間分もの夜を必要としたアイデアの試作が、土曜の朝に形になる。これは私にとって大きな意味があります。

つまりこれは、速度に反対する文章でも、AIに反対する文章でもありません。私が最近気づいた、ひとつの緊張関係についての文章です。そしてそれは、研究の場でも、プロダクトチームの現場でも、注意を払うに値するものだと思っています。

その緊張とは

AI支援開発がワークフローに入ってきたことで、デベロッパーが生成・変更できるコードの量は以前とは比べものになりません。それがそのまま生産性の向上、プロダクトの質、顧客にとっての成果につながっているのかは、まだ議論の最中です。ただ、ソフトウェアが生み出される量とスピードが変わったことは確かです。

そして同時に、「理解」の側で何かが起きています。

ここで言う理解とは、一行ずつのコードを説明できるかどうかだけを指しているのではありません。その仕事の意図、システムの挙動、そこで選ばれたトレードオフ、そして自分たちが生み出していると信じている顧客価値。それらを説明できるかどうかということです。コードの理解はその一部ではあっても、全部ではありません。

エージェントが生成した成果物が机の上を流れていく速さが、読み、問い、考える速さを追い越したとき、レビューは判断というより「注意力の配給」に近いものになります。

これはソフトウェア開発にとって新しい課題ではありません。

Curtis、Krasner、Iscoeによる1988年の古典的なフィールド調査は、大規模ソフトウェアプロジェクトの失敗原因として最も多かったのは、質の悪いコードではないことを明らかにしました。それは共通理解の崩壊であり、とりわけ要件とアーキテクチャをめぐるものでした。何を、なぜ作っているのかという共通の絵を人々が見失ったときにプロジェクトが苦しむことを、私たちは40年近く前から知っているのです。

私自身も『The Customer-Driven Culture』で近いテーマを扱いました。チームの有効性がいかに共通言語と共通理解に依存しているか、という話です。

新しいのは、コード生成の加速のほうです。AIが共通理解の必要性を生み出したのではありません。すでにあった必要性に、さらに圧力をかけているのです。

認知的負債、意図の負債、そして共通理解

これらをまとめて技術的負債と呼びたくなります。しかしMargaret-Anne Storeyは、いま起きていることには新しい語彙が必要だと、説得力のある議論を展開しています。論文「From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI」で彼女が挙げているのは、次の2つの負債です。これから数年、この区別は非常に重要になると思います。

認知的負債（cognitive debt） は、チーム全体の共通理解が時間とともに侵食されていくこと。システムがどう動いているかについてのメンタルモデルが、不完全に、断片的になっていき、結果としてシステムを安全に理解し変更することが難しくなっていきます。

意図の負債（intent debt） は、システムの進化を導くはずのゴール、制約、仕様、根拠——それらが外在化されないまま失われていくこと。「何が」出荷され続ける一方で、「なぜ」が抜け落ちていきます。

ただし私は、レビューされなかったAIの提案がすべて自動的に新種の負債になる、という主張だとは読んでいません。それは単に悪い習慣かもしれないし、リスクのある近道かもしれないし、プレッシャーの下での理解可能な妥協かもしれない。

負債が積み上がるのは、その仕事についてチームが語れる説明が、時間とともに薄くなっていくときです。コードは変わるのに、その根拠が一緒に移動しない。システムは進化するのに、チームのメンタルモデルが置き去りになる。やがて、何が出荷されたかは指させるのに、なぜそれがそういう形をしているのかを説明できなくなります。

コードは依然として重要ですし、出荷されるのは結局コードです。変わりつつあるのは、人間の注意をどこに集中させるべきかのほうかもしれません。実装の多くをエージェントが生成するようになるなら、チームは差分をレビューするだけでなく、意図をレビューすることにもっと注意を向ける必要が出てくるでしょう。

私はその新しい実践を インテントレビュー（intent review） と呼ぶのがよいと思っています。「このコードは動くか」だけを問う前に、チームはこう問えるはずです。エージェントは何をするよう指示されたのか。これはどの顧客課題に応えるものなのか。プロンプトや計画、テスト、評価基準に、私たちはどんな前提を埋め込んだのか。エージェントはどんなトレードオフを選んだように見えるか。その結果は、私たちが大事だと信じているものと、いまも噛み合っているか。

インテントレビューがコードレビューに取って代わる、と言いたいのではありません。コードレビューだけではもう足りないかもしれない、と言いたいのです。

個人の理解から、組織のコヒーレンスへ

チームの誰か一人があるコードの理解を失ったなら、それは取り戻せます。誰かとペアを組む、ドキュメントを書く、ウォークスルーをする。私たちは何十年もそうやってきました。

しかし認知的負債がチーム全体に、さらにはチームとチームの境界をまたいで積み上がっているとしたら、そこで起きているのは組織的コヒーレンスの緩やかな崩壊です。

組織的コヒーレンスという言葉で、私は具体的なことを指しています。クロスファンクショナルなチームが、目的、ゴール、そして作っているものの形について揃っている状態。その性質のことです。

これは、よくあるデリバリー指標のダッシュボードには映りません。PRのスループットは、作業が起きていることを教えてくれます。イシューがクローズされ、プルリクエストがマージされ、変更が本番に届いたことも教えてくれます。けれどもそれは、チームがまだその仕事の形を理解しているかどうか、顧客価値をどう生むかを分かっているかどうかは教えてくれません。

兆候はもっと後に、もっと厄介な形で現れます。手戻りの増加、重複した作業、長引くオンボーディング、脆い意思決定、オーナーシップの混乱、そして顧客やステークホルダーにトレードオフを説明できなくなっていくこと。

AI支援開発は、ダッシュボードには見えない場所に、新しい調整コストを生み出しているのかもしれません。

テストと評価は重要だが、それで全部ではない

この緊張について話すと、もっともな反応が返ってくることがあります。「それこそ自動テストや評価（eval）がやるべき仕事では?」

そこには確かに本当のことが含まれていると思います。テストと評価は意味のある仕事をします。AI支援のワークフローにおいて、強い評価基準は責任ある開発の基礎インフラの一部になっていくかもしれません。

ただ、テストと評価はそれ自体ではメンタルモデルを回復させません。テストが通ったということは、そのテストが確認するよう設計されたことをシステムが満たした、ということです。評価が通ったということは、私たちが与えた基準をシステムが満たした、ということです。どちらも、チームがその仕事の意図を、基準の背後にある前提を、顧客価値とのつながりを、いまも説明できるかどうかは教えてくれません。

ここで、顧客起点の筋肉が効いてきます。評価が測るものだけに最適化していると、チームは計測器に対しては前進しながら、顧客価値からは漂流していくことがあり得ます。顧客と話すことは、評価だけでは答えられない問いを立てる助けになります。私たちはまだ、大事なものを測っているのか、と。

これから探っていきたいこと

私が関心を持っているのは、注意の置きどころが移りつつあることを踏まえたプロダクト体験です。

デベロッパーが一行ずつ書くことに費やす時間を減らし、エージェントの仕事を方向づけ、レビューし、意味づけることに時間を使うようになっているなら、周辺のツールもまた別の瞬間を支える必要が出てきます。コードを書くことは変わらず重要です。けれど、エージェントの推論を追うこと、差分の背後にある計画を理解すること、その仕事が意図や顧客価値やシステムの挙動とどうつながるかを見ること——これらも同じように重要になります。

チームの実践についても同じです。答えがソフトウェアの改善だけから来るとは思いません。生成のペースが上がるなかで共通理解を保つための実践から来る部分もあるはずです。

• インテントレビュー: エージェントが生成した仕事の目的、前提、顧客価値をチームで検討する
• エージェントの仕事のチームウォークスルー: とくに、一人では抱えきれないほど変更が大きいとき
• 顧客価値チェック: 生成された仕事が、顧客の解きたい問題にまだ対応しているかを問う
• 評価レビューと定性的な顧客データの組み合わせ: 自分たちの計測戦略がまだ顧客価値を向いているかを確かめる
• 定期的なコヒーレンスレビュー: 「各パーツがどう噛み合っているか、まだ説明できるか」を問う軽量な場を作る

これらを重い承認ゲートにしたいわけではありません。人間の判断を仕事のすぐそばに保つための、ひとつのやり方として考えています。

楽観する理由と、開かれた問い

希望のある調子で締めたいと思います。実際、私は希望を持っています。

AI支援開発は、ソフトウェアを作るという行為をより多くの人に開いています。私自身、研究対象であるプロダクトに近づくことができました。アイデアを試すコストが下がりました。ものを作ることが、また手の届くもの——そして楽しいもの——に感じられるようになりました。

それは守るに値します。

問いは、生成の速さをどうすれば持続可能なものにできるか、です。チームは速く動きながら、その仕事が責任を負う人々にとってまだ読み取れるものかを確かめる小さな瞬間を作ることができます。その意味で、最も価値のある問いはこれかもしれません。私たちはまだ、何を作っているのか、なぜ作っているのか、誰のために作っているのかを理解しているか。

だから、ほかの人の話を聞きたいと思っています。AI支援開発に大きく舵を切ったチームにいる人は、いま何を見ていますか。共通理解はどこで持ちこたえていて、どこで滑り落ちていますか。エージェントの恩恵を拒まずに、チームがループの内側に留まるために効いている実践は何ですか。そして、より多くの仕事がAIを通るようになるなかで、評価、テスト、顧客からのフィードバック、人間の判断のバランスをどう取っていますか。

私自身、まだ全体像をつかめてはいません。この緊張がまだ形になりつつある段階のうちに、注意を払っておきたいと思っています。皆さんの経験から学べたら嬉しいです。

---