禅みたいなタイトルだが。

cognitive surrender

cognitive surrender という言葉がある。無自覚なまま判断を AI に丸投げする、という意味合いだ。

Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender
papers.ssrn.com

自覚がないので抜け出すのが非常に難しい。物量に負けたとかやらない理由を探しているとかではなく、 AI によって「自分が判断した」と錯覚しているというけっこう衝撃的な内容が論文に書いてある。正答すると金銭的な報酬が増えるという状況下でも AI に判断を丸投げする行為自体は一定数見られた。人命がかかっているとか個人の名誉が毀損するなどであればもしかしたら違う結果になるかもしれないが、実験室で再現可能なインセンティブ程度ではそういった振る舞いは消えない、という解釈になる。

cognitive surrender と開発組織

ここからは自分の感覚として参照しやすい、開発組織を例にあげて考えてみる。個人を飛び越えていきなり組織のハナシをするのは、無自覚なので自分ひとりでは対処できない可能性が非常に高いこと、そもそも Need for Cognitionが高い人間ほど surrender しにくいが、これは育った環境に大きく左右され、成人後に高めるのが難しいとされているからだ。

やらないとスキルは伸びない。それはわかりきっているのだが、 cognitive surrender によって、コードを書くというスキルがまったく伸びない。これは AI が出てきた当初からエキスパートへのキャリアが途切れるとしてみな危機感を持っていたところ。

ソフトウェアエンジニアならわかると思うが、書いていくとそれをベースに改良点が見つかったり、前段タスクへのフィードバックとブラッシュアップが働いたりして、その時点の最適な形に落ち着いていく。こういったステップの経験がすなわちスキルの習得だ。

CS 比率を 0 に保つ

ここで、チーム内で cognitive surrender が常態化したメンバーの数と全メンバー数との比率を CS 比率と呼ぼう。現在かなりの組織で tech lead / エンジニアリングマネージャーとして、 CS 比率をいかに 0 に抑え込むかという点が重要になってきている。順に説明する。

組織練度の低下

cognitive surrender してしまうと deskilling 、つまりできていたことができなくなる、ということが加速する。 unlearning は意図的にスキルを組み替えることだが、こちらには意図しないパフォーマンス劣化のニュアンスが含まれている。スキルは使わなければ忘れられる。調査や要件定義、基礎設計、アーキテクチャーの決定など、 AI で代替できないスキルが deskilling されていないか？

結果として CS 比率上昇の原因となってしまう。より中長期的には組織存続の危機として立ち現れてくる。ひとが育てられないので、現在エキスパートのエンジニアに依存したまま高齢化、後継者がいないという状態になりうる。高齢化は極端としてもバス係数が上がらない、ということの危険性はわかるだろう。

判断コストの偏在

また、 cognitive surrender したメンバーがいると、その他の人間が判断コストを支払うことになる。これは OSS PR への AI slop として可視化されていて、メンテナーによっては PR を受け取らない方針にしたところもある。組織内ではもちろんそういった対応は取れないので、その他メンバーに判断コストの支払いを迫ることになる。

当然の帰結として、誰かが surrender するとそれによって負担が増えたメンバーも surrender したり、最悪チームを離れることになる。結果、 CS 比率が上がる。

cognitive surrender からの復帰

surrender からの復帰はかなり難しい。

復帰するにはまず cognitive surrender を自覚することが大前提だ。無意識に surrender しているので、他者からの介入がないと気づかない可能性が非常に高いし、そもそも他者だってそういう状況を直接見ていないと判明しづらい。代替指標として、レビュー時の指摘のうち判断に関するミスがどの程度あるのかや、判断ミスによる再作業率などだろうか。要件や設計、もしかしたら目標設定など前段の部分での測定でないと現実的には厳しい場面も出てくるかもしれない。

自覚できたとして surrender しないような仕組みを自分や組織で作っていくことがもうひとつ重要な点だ。先述した通り surrender しやすさは個人特性が大きく、成人後に変動する可能性が低いため、成長してもらうという方向の投資では難しい。

要件や設計のレビューを義務付ける、 AI を用いたペアやモブでのプログラミング機会を多くするなどの、人間によるチェックという点くらいしか今は思いつかない。幸い、これらはスキルトランスファーにも役立つので deskilling したスキルの再習得につながりやすい、というメリットはある。もちろんメンバーの負担が増えるのと、その分の時間を投資として割り切れるかという組織判断になるので難しい場合もある。

結局 AI 時代になってもチームの認知リソース総量は決まっているので、振り分け先として妥当かの見極めと、いかに効果的に割り振っていくか、個人と向き合って、マネジメントスキルと適切な投資を駆使する必要がある。

surrender から offloading へ

なお cognitive surrender と対比して、 cognitive offloading という概念も紹介されている。 offloading は適切に AI を道具として使えている、という状況だと理解すればよいだろう。

コードを理解するために AI に解説してもらうなどは現実的な時間で可能になったというのが最たる例で、これは意識的に判断を AI へ offloading している。もちろん AI のコード解釈を鵜呑みにしたら意味がないので、自分であっているかを確認する必要はあるが、全部自分でやるのと比較して、消費する認知リソースの量は明らかに少なくなる。

こういった、何が cognitive offloading か？というラインを見極める行為は非常に実践的になる。 tech lead / エンジニアリングマネージャーのもうひとつの役割がこれで、 AI 受容とはまさにこういった仕事になってくるのではないか？解像度高い議論を各組織でやっていくとよいだろう。もちろん、チーミングやマネジメントなどの人間的なアプローチも視野に入れて。

個人でも無意識に surrender していたかもしれない、と行動を振り返ることで offloading への道が拓ける可能性はある。意識していこう。