先輩：ソフトウェア開発のゴールって何だと思う？

俺：うーん、機能をたくさん作ることですか…？

先輩：惜しい！最終的には“コストと時間を最小にすること”なんだ。

• 高速に開発ができること
• 変更がしやすいこと

俺：あー、後から直しにくいと時間かかりますもんね

先輩：そう、それを支えるのが設計ってわけ

先輩：ずばり、変更しやすくするためにあるよ

• 設計がうまくいってる = 労力をかけずに変更できる
• 設計が悪い = 触るたびに壊れる、直すのに時間がかかる

俺：じゃあ、変更が楽かどうかで設計の良し悪しが分かるんだ(変更容易性)

• 処理と処理が依存し合っていて一箇所直したら別のとこが壊れた
• どこを読めばいいかわからない
• 変更による影響範囲が予測しにくく、バグを埋め込みやすい
• 簡単な修正に数日かかる…

俺：あるある…前触ったコードが自分の敵に見えてくるやつ

先輩：まさにそれが技術的負債ってやつだ

• 変更・拡張が難しく壊れやすいコード

• 後で直さなきゃいけないツケ、将来的に修正や変更が必要な状態

📉 総務省のレポートによると、技術的負債による損失は年間12兆円（「2025年の崖」）

• 総務省のDXレポートでの発表
• https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf

俺：これ、放っておいたら大変なことになりそうですね…モチベーションも下がりそう

• 優れた・クリーンな・うまく設計されたコードの重要性を理解していない
  • 〆切まで時間がないので、とりあえず動くものを作ろうという気持ちになる
    • 「とりあえずモノを完成させて、後でコードを綺麗にするか」と言って、結局時間がなくやらない
  • 競合に追いつくためには機能を追加し続けなければならない
    • 今、この間にも競合はどんどん先を行っている
    • 後からコードを綺麗にする時間なんてない
• 崩壊したコードを書けば短期的には開発速度が上がると信じている
  • 最初はそれでいいかもしれないが…
  • どんどん変更が難しくなり、長期的には開発速度が下がる

先輩：最初はいいけど、どんどん沼になる

俺：あー、技術的負債のスパイラルだ

先輩：そうそう。いったん崩れ始めると、みんな「もうこのコードは手遅れだ」って思って、さらに雑に書くようになる。まさに負のスパイラルだね。