「機能的にはもう足すものがない。だから、何もしなくていい」— 保守の現場で、何度も聞いてきた考え方です。完成したシステムは、触らなければ壊れない。動いているものに触るな。もっともらしいのですが、そんなことはないですよね。ソフトウェアは、何もしなくても腐ります。
コードは変わらない。世界が動く
腐ると言っても、コードは 1bit も変わりません。変わるのは周りです。依存 library に脆弱性が見つかる。TLS の古い version が捨てられる。実行基盤 (クラウドの managed service や OS) が強制的に世代交代する。browser が仕様を落とす。放置されたソフトウェアは、静止しているのではなく、動き続ける世界に置き去りにされていく。
以前、計測は今日のデータの静止画であって保証書ではない、と書きました。同じ構造です。「動いている」は今日の世界での静止画であって、今後も動く保証書ではないのです。
腐敗には、見た目がない
建物は錆びます。車は軋みます。目に見えて劣化するから、車検という点検の制度が生まれ、誰もその予算を疑いません。ソフトウェアは、どれだけ腐っても昨日と同じように起動します。摩耗の見た目がないものに、人は点検予算を払いたがらない — 「なぜ動いているものに金をかけるのか」と。「ソフトウェアは腐りやすい」という認知がいつまでも広まらないのは、この見た目の問題が大きいのだと思っています。セキュリティと同じです。
もう一つ怖いのは、放置の行く末です。腐敗が進むこと自体より、どれだけ腐ったか測れなくなることの方が深刻です。build の再現性が失われ、いま動いているものがどの version の組み合わせなのか、誰も特定できなくなる。こうなると、点検しようと思い立った日に、点検の足場から作り直しになります。
4〜5年かけて上げ続けた話
前のプロジェクトの Ruby on Rails システムは、私が join した頃、framework の version がだいぶ古いままでした。古すぎると、脆弱性検査をかけても「その前に上げるものがあるでしょう」という結果しか出ません。検査が意味を持つ位置に、そもそも立てていないわけです。
幸い、技術負債の返済に理解のある PM の下だったので、機能開発の合間に、少しずつ少しずつ上げていきました。4〜5年がかりです。派手さは何もありません。ただ、上げ続けている限り、脆弱性検査が意味を持つ位置に到達できます。”防腐” というのは一度の大掃除ではなくて、この地味な継続の方でした。
ソフトウェアは納品して終わりではない、という考え方は、SonicGarden の倉貫義人社長が「納品のない受託開発」という事業の形にまでしています。事業構造から変えないと守れないくらい、「完成したら終わり」という認知の力は強い、ということでもあります。
AI時代は、言い訳が一つ減った
version 上げは、後回しにされ続けてきた仕事です。前述の通り見た目の成果がない上に、実際は重い。機械的な作業ではありません。影響範囲の見極めがあり、芋づる式に上がっていく依存の連鎖があり、破壊的変更の前で諦める判断すらあります。ただ、その重さのうち「量」の部分 — 依存の更新、非互換の洗い出し、テストの通し直し — は、typo の駆逐と同じ梯子で、AI で安くなった側です。見極めと判断は人の仕事として残ります。それでも、「人手が足りないから」という、いちばん通りの良かった言い訳は、効力を失い始めていると思います。
見えないものを見る力
腐敗も、セキュリティも、目に見えません。そして人間は、目に見えないものに予算を払わないし、見えない仕事を評価もしません。けれども、経験とか学習とかいうものは、つまるところ目に見えないものを見えるようにする力のことだと思うのです。物理法則だってそうでした。見えないものを見えるようにすることで、人類はここまで来た。「動いているのに、なぜ触るのか」と聞かれたら、答えは結局これです — 見えているからです。
(下書きはうちのAIが書き、文責は私にあります)