前回の連載はこちらから。
技術的負債を解消したい！ でも、工数も根拠も出せない
開発現場でよく観測されるのは、障害が頻発したり影響調査の範囲に時間がかかるほど、「技術的負債を計画的に返済したい」と懇願する場面が出てくることです。コードの複雑さで変更の影響が読めず、リリースをしても思いもよらない箇所で障害が発生。ポストモーテムを書くことに業務が圧迫され、再発防止の振り返りでも「ちゃんとコードレビューをしていれば大丈夫だったかもしれない」「STG環境でちゃんとテストができていれば防げたかも知れない」という言葉が並ぶものの、新規開発で工数は取られ、技術的負債を返却する工数は取れません。
一方、技術的負債というのは、どのぐらい負債があるのかの計測と返却したときの効果試算が難しい代物でもあります。
返済の工数と期間、必要な予算。そして本当に技術的負債を返却したら開発は早くなるのか。正しく技術的負債を返却できるスキルをもったチームなのか。この問いにエンジニアは答えられないといけません。
測れないのではなく、測り方と説明の言葉がそろっていない
技術的負債は測れないから説明できないというのは誤解です。
従来の単一的な測りやすい指標（Four Keysや静的解析）では説明しずらいですが、これから述べていく多角的な視点を組み合わせることで説明可能になります。
負債は「時間」として先に流出している
ここで1つの調査データを紹介します。Stripe / Harris Poll（2018）の"The Developer Coefficient"は、5カ国で開発者1,000名超とCxO 1,000名超を対象にした調査で、開発者の週平均労働時間41.1時間のうち、技術的負債への対応に13.5時間、バッドコード対応に3.8時間、合計17.3時間が費やされると報告しています。これらの時間を合わせると週の約42%にもなる時間です。新しい価値を作る前に、既存システムの維持と修復で時間が先に失われています。負債は帳簿に載らなくても、時間という形で毎週流出しています。
この数字は「自社も必ず同じ比率だ」と決めつけるためのものではなく、現場の体感を定量の問いに変える基準線として使えます。週次の時間を新規開発・保守修復・調査や待ち時間に分けるだけでも、どこで速度が失われているかを議論できるようになります。
内部品質を上げるほど、長期では安く高品質なソフトウェアが作れる
スピードを優先するなら品質を犠牲にするしかないという論調もありますが、連載第1回でも紹介したMartin Fowlerの"Is High Quality Software Worth the Cost?"では、内部品質についてはこのトレードオフの立て方そのものがずれているという旨を紹介しました。
ユーザーが評価できる外部品質と異なり、モジュール分割や命名といった内部品質は外から見えません。それでも開発者がこだわるのは、仕事の大半が既存コードの読み解きと変更だからです。理想の設計との差分（cruft）が増えるほど、変更の見当がつくまでの時間が伸びます。
「きちんと書くから時間がかかる」と説明すると、品質にはコストがかかると受け取られて議論で不利になりがちです。しかし実際には逆で、内部品質が高いほど将来の変更が安く済み、トータルコストは安くつきます。内部品質への投資はコストではなく、将来のコスト削減への投資です。
「測れない」の正体は認知的負債
もう1つ見落とせないのが、コードもシステムも動いているのに、なぜそう動くのか、なぜその設計になったのかを誰も説明できない状態です。これを認知的負債（Cognitive Debt）と呼びます。
技術的負債がコードや設計そのものに溜まるのに対し、認知的負債は人間側の理解の欠如にあります。テストもパスし、デプロイ回数も安定するので、開発速度の指標にはほとんど表れません。
AIエージェントを使った開発である「Loop Engineering」が進むほど、このずれは広がりやすくなるでしょう。
認知的負債についての2つのレポート
関連したレポートとしてRockoderの"Cognitive Debt: When Velocity Exceeds Comprehension（速度が理解力を上回るとき）"では、
AIエージェントを使った開発において出力の加速と理解の形成を切り離すと指摘しています。何がなぜ作られ、ほかとどう関係するかを本当に理解する作業は、人間の処理速度に縛られたままです。
この出力と理解のギャップそのものが認知的負債です。表面化するのは数カ月後、設計変更や障害対応で誰も説明できない場面に至ったときです。理解があれば10分で済む修正が、理解がなければ4時間の調査に化ける。出荷したなら理解しているはず、という前提が崩れたいま、理解を測れない以上は短期のスピードばかりが最適化されやすくなります。
あわせて、Addy Osmaniの"Loop Engineering"のレポートでも、エージェントが自律的に反復するほど、自分が理解していないコードが先に増えると述べており、テストが通りマージも進むのでPR数やマージ数だけを見れば活動は活発に見えます。一方で理解の負債だけは静かにたまります。ループが回るほど、もういいかと受け入れる誘惑も強まります。Osmaniはこれをcognitive surrenderと名付け、ループ設計が思考を避けるための言い訳にもなりうると述べています。それでもエンジニアであり続けるにはループの出力を読み、検証し、理解を意図的に確保する設計が必要です。同じループでも、理解を深める人と避ける人では結果は真逆になります。
この2つのレポートに共通するのは、認知的負債はコードの劣化ではなく、出力が理解を追い越したときに溜まる負債だという見立てです。従来の評価指標ではAIエージェントやループが速くなるほど、活動量の指標だけが良く見え、理解の不足は見えにくくなります。請求は遅れて届き、障害対応や設計変更の現場で、誰も説明できないまま時間だけが溶けていきます。本回の冒頭で述べた、返済を懇願しても工数も根拠も出せないという話にも直結します。それは、チーム自身が何を直し、返済すると何が戻るかを説明できなければ、返済の議論そのものが止まってしまうからです。
ここまでの負債が放置されやすいのは、今は動くから後でリファクタリングするという判断が短期的には合理的に見えるからです。けれどその後はなかなか来ません。新機能が優先され、負債は雪だるま式に増え、修正コストは後になるほど膨らみます。
リファクタリングに工数を割いても、短期のベロシティやリリース数にはすぐ出にくい。返済そのものは活動量の指標に載りにくく、負債の利息だけが障害や手戻りとしてあとから請求される。投資や活動は増えているのに、成果の数字に出ません。
開発生産性の誤解について、体系的に解説した書籍が発売中です！
