はじめに
直近で，こんな記事を書きました．すごく丁寧に書いたので，読んでもらえたら嬉しいです．生成 AI がどんどん賢くなっていくけれど，それでも人間がコードベースを理解する営みは，決して手放しちゃだめだと熱弁しています．
… 熱弁したんですが，これを書いてから少し時間を置いて考えるうちに，私の話に共感してもらえそうな現場と，逆にあまり刺さらないかもなって現場があることに気づきました．しかも，こういう認識の差異って，生成 AI を使いこなす能力の問題でも，エンジニアの技術力の問題でも，はたまた個人の意識の問題でもなく，もっと身も蓋もない話なのかもしれません．
責任とコストの流れ
抱えているエンジニアの技術力はそう変わらないはずなのに，完成したプロダクトの品質がまるで違うということがあるかなと思います．丁寧に作り込まれて長く保守されるものがある一方で，リリースした瞬間からおかしくなって誰も手を付けたがらないものもあるでしょう．こういった差を「優秀なエンジニアがいるから」とか「工数に余裕があったから」とか「AI ツールを使いこなせているから」とかで片付けるのは簡単なのですが，それだけではないよなと思っています．
おそらく品質自体は結果でしかなくて，ここで効いているのは「ツケが誰に返ってくるか」という構造のほうなんじゃないかと自分は考えています．壊れたものの責任を誰が取るのか，そのツケを誰が払うのか，そしてその人が品質を左右する力を持っているのか，ここが揃っているかどうかが重要で，品質保証に投資するモチベーションが割と機械的に決まってしまう気がします．
例えば，ある企業が SaaS 事業をやっていたとしましょう．
まずは，事業会社が初期コストを渋って，技術力を持ったエンジニアを抱えないまま，ビジネスチームが生成 AI でとりあえず動くものを作ったとします．自分たちで運用するのは大変なので，運用は別の会社に投げます．最初から投げることもあれば，作ってみたけれど AI だけでは回らなくて後から外注することもあるでしょう．もし問題が起きたら「お前らがちゃんと運用しないからだぞ！何とかしろ！」と運用会社に苦情を入れるかもしれません．最初に作ったのは自分たちでも，その責任は運用側に押し流そうとするわけです．
開発自体を丸ごと外注する場合も同じです．開発会社が開発のみを任されれば「納品後は離れる」ことが前提なので，生成 AI で手早く作って引き渡したら，あとは手を引いてしまいます．それで運用はまた別の安く済みそうな会社に投げて，もし問題が起きたらその責任を事業会社と開発会社と運用会社の間で押し付け合う，大乱闘スマッシュブラザーズが繰り広げられることでしょう．
こういった構造では，プロダクトに対する責任とコストが分散していって，最初に品質保証をサボったツケが作った人の元に帰ってくるとは限りません．作っている側は運用の大変さを知らないし，そもそも知る必要もない建て付けです．だから誰も最初から，メンテナンスしやすく壊れにくく作ろうとはしません．そうする動機がどこにもないのだから．
逆に自社で開発して運用も自分たちでやっていくか，事業会社から受託した企業が開発から運用まで一貫して引き受けるパターンを考えてみましょう．作った企業がそのまま自分で運用するということは，雑に書いたコードの改修コストも障害対応の手間も，最終的には自分の財布に返ってきます．だから最初から壊れにくく作ろうとするし，あとで自分が読めるように理解を残しておく価値も出てくるわけです．いわゆる “You build it, you run it” ってことで，責任とコストが一点に戻ってくる構造ですね．
このように組織の構造が異なれば，たとえ同じように AI を渡されても，プロダクトの品質への向き合い方は真逆になります．前者における品質保証は不要不急なコストですが，後者では後から自分たちを助けてくれる投資です．抱える人材の善し悪しというよりは，誰の財布を見ているかの違いでしょう．
ここまで会社単位で見てきましたが，同じことは組織内の個人にも起き得ます．例えば，業務委託や SES の短期案件で「人月いくらで入って終わったら次…」という立場だと，別に作ったものの運用も保守も自分には返ってきません．評価されるのは期間内にどれだけ成果物を出したかなので，わざわざ中身を作り込むよりも生成 AI でそれっぽく動くものを手早く仕上げてしまうほうが，個人にとっては理に適っています．
もちろん，実際にはそういう環境でも丁寧に作ろうとする人はいるでしょう．ただ，これは腕や良心の問題ではなくて，ツケが自分に返ってこない立場に置かれたらそうなるという話です．評価される場所と後で困る場所が違いますから．
資本主義における経済の歪み
これって別にソフトウェア固有の話ではなくて，(私は経済学の専門家ではありませんが) いわゆる外部性とか，プリンシパルエージェント問題とか，モラルハザードとか呼ばれてきたものなんじゃないかなと思います．自分の決定に掛かるコストを外側に押し出せる立場にいれば，人間はどうしてもその対象に投資しなくなるし，品質保証をサボったツケが別の財布に流れるなら，そもそも品質にお金を掛ける経営判断は合理的だと見做されにくいわけです．
ソフトウェアの開発でこれが顕著なのは，組織の形がシステムの形に写し取られるという，いわゆるコンウェイの法則の延長で捉えられるかなと思います．本来は組織の構造がアーキテクチャの構造に表れるという話ですが，同じように責任の分かれ目が品質の分かれ目にもなって，作る人と運用する人と責任を取る人がバラバラに分かれていれば，それらの継ぎ目に品質の穴が空いてしまうわけです．
さらに厄介なのは，最終的な責任の所在と品質のコントロール権が分かれることです．事業会社は顧客に対する最終的な責任を負っていても品質を動かせず，開発会社や運用会社は動かす手を持っていても自分の責任だとは認めません．
というか，そもそも責任の所在すら素直には決まりません．いざ障害が起きれば，開発の瑕疵なのか，運用のミスなのか，事業会社の出した仕様が悪いのかと，関係者間での押し付け合いが始まります．こうなると，肝心の品質問題は揉めるだけ揉めて誰も直さず，本来そこへ向けるべき労力が犯人探しに吸われていくわけです．
これを生成 AI がもっと歪ませる
こういう歪みって生成 AI が出てきたから起こる話ではなくて，作り捨ての開発も責任の押し付け合いも大昔からあった問題でしょう．じゃあ，生成 AI が何を変えたかというと，作るための初期コストです．それも，ものすごーーーく下げました．そうやって，試しに作ってみるのがタダ同然になると「作って捨てる」とか「中身を理解せずに量産する」とか，そういった振る舞いが，経済的には割に合うような気がしてきます．
作り始めるのに手間もお金も掛かった時代は，これは本当に必要かとか，ちゃんと作らないと後で困るとか考えさせられたかなと思います．もちろん昔から作り捨ての開発はありましたが，少なくともコストの高さは立ち止まるインセンティブとして働いていたのでしょう．生成 AI がそのコストを取り払うと，そういった考える必然性も一緒に消えて，安くて動くものがすぐ出てくるなら深く考えずに作って出してしまえるということです．
そうやって，生成 AI は元々あった「誰も責任を取らない」構造の歪みを，作るコストを取り払うことで一気に膨らませて，目に見えるところまで引っ張り出してきたのではないかと考えています．責任もコストも自分に返ってこない現場では，コードの理解や品質保証に時間を掛けること自体が評価されにくく，生成 AI を使って手早く成果物を出すほうが合理的だと見做されやすいでしょう．そうなると，技術的な正論はそもそも土俵にすら上がれません．そういうわけで，これは技術の話だけでは閉じない事業の構造の話なんだろうなと思います．
思ったよりヤバいのが出てきたな (どうすんだこれ)
構造の話をしてくると「じゃあ現場で何ができるんだ」という気持ちになってきます．それでも，これは唯一の要因というわけではありません．こういった修羅の道でも踏ん張って品質を守ろうとする人はいるし，逆に自社で開発から運用まで一貫していても，目先のスピードを追った結果として崩れることはあるわけです．
とはいえ，構造の影響は無視できません．責任とコストを外に出せる立場では，品質への投資だけでなく，そうした構造そのものを変える投資も後回しになりがちです．逆に，品質問題のツケを自分で払う立場にいる人ほど，責任とコストの流れを揃えることに動機が生まれます．だから比較的変化が起きやすいのも後者です．開発と運用を同じチームで担うとか，受託でも運用まで含めて引き受けるとか，あるいは SRE を内製して長期的な運用能力を組織に蓄積するとか．やろうと思えば色々ありますが，共通しているのは，品質問題のツケが返ってくる場所と，品質を改善できる人を近付けることだと思います．
前回の記事では「コードの理解を手放すな」と書きました．しかしながら，今回考えていて気付いたのは，コードを理解することの価値ですら，責任とコストの流れによって変わってしまうということです．自分たちが運用し続けるシステムなら，コードの理解は将来の自分たちを助ける投資になります．ところが，品質問題のツケが別の誰かに流れる構造では，理解そのものがコストに見えてしまいます．だから前回の記事の話は，理解を残す動機が存在する現場で初めて成立するのでしょう．
この数年で，これまでの仕事が AI に奪われるとか，AI を使いこなせないと生き残れないとか，これからはビジネスやマネジメントに全振りなんだとか，そういう脅し文句があちこちで語られるようになりました．でも，こう考えてみると，それらは本質的な危うさを突いていないように思えてきます．結局のところ，それらは「品質問題のツケを他人に押し付けられる構造」の中にいる人間のポジショントークに過ぎません．品質を支えているのは，結局のところ誰が責任を引き受けるのか，誰がコストを払うのか，そしてその人が品質を改善できる立場にいるのかという構造のほうです．生成 AI がこの歪みを生み出したわけではなく，初期コストを大幅に下げたことで，コストを誰かに押し流して済んでしまう歪みを増幅し，露骨に表へ引っぱり出しただけなのでしょう．淘汰や生存戦略の話に見えるのは，その錯覚なんじゃないかと私は考えています．
だからこそ，もしもあなたが品質を維持しようとする力場の中にいるのであれば，生成 AI を巡る派手な言説に振り回される必要はありません．自分たちの事業を理解し，コードベースを理解し，ナレッジを蓄積し，そして組織を整えていくといった，一見すると地味な営みの価値は，おそらく今も AI 時代も変わらないことなのだと思います．