最近、クソコードを見るのが楽しくなっています。
クソコード、格好良く言い換えれば技術的負債とも言えますが、これがどういう余計な費用を生み出していくか、思ったことを書いてみます。
なぜ「利益」ではなく「費用」なのか
クソコードが費用となるなら、超美麗なコードは利益を生み出すのか？
という疑問はあると思います。
これは先に説明が必要ですね。
まず、どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」です。
システムが利益（これは収益の増加、費用の削減両方を含む）を生み出すかどうかは、システムのコンセプトや営業活動、利用促進等に依るところが大きいです。
よって、システムが仕様通りに作られている限り、「プログラム内部がクソコードかどうか」は、一応関係ありません。
クソコードでもいいんじゃね？という状況
いきなり例外（笑）
絶対に自分しか使わないソース
好きなだけ汚してください（笑）
これは、別にきれいに書いてもいいんですが、誰にも迷惑かけないのであれば好きなように書いていいと思いますよ、という意味です。
この場合は、少々クソでも、自分がわかればいいので、特に問題ないと思います。
作ったら、二度とメンテしないシステム
いずれメンテするかもしれないじゃないかというのは、いったん置いといてください。
システム作成時点で、次版を作るつもりがないなら、クソでも問題ないです。
ただし…
仮に当初決定が覆り、機能拡張等が発生した場合、当初のソースは捨てましょう。
機能追加分と「将来の改訂予定」を加味して、再設計したほうが、将来的にコストが安くなります。
あとで書きますが、メンテを考慮していないプログラムを修正するぐらいなら、作り直したほうがいいです。
保守担当が一人（定期改訂あり）
まぁ、別にずっと同じ人がメンテするなら、少々ソースが汚くても…とは思います。
その人が辞めても、死んでも、働かせる気があるならですが。
『プログラミングの心理学』に、プロジェクトの支柱となっている人の例が載っているので、見てみるとよいでしょう。
結局、「その一人がいなくなったら終わり」という状況でうまく行くわけがない、とのことです。
以下、同書の引用。
大規模組織のとりわけ興味深い特徴の１つは、どのメンバーの在籍期間よりも長い期間にわたって存続できることである。
～（中略）～
ところが、多くのマネジャーは自分のプログラミングプロジェクトに同じ理屈をあてはめることができない。
クソコードが費用を発生させる状況
仕様変更
クソコードの特徴として、「書いた人以外が読めない」というものがあります。
（書いた人が読めないこともある！！！）
仕様変更があったとき、ソースが読めないと、変更できないですよねー。
担当者変更
「ギリギリ仕様通り動いているけど、ソースがクソ」の場合、後任は大変ですねー。
この場合は、ソースが綺麗でも、「引継ぎが不十分」とか「後任者の力量不足」の場合でも、大変です。
もしくは、開発委託先を変更した場合も含みます。
凍結予定のシステムの仕様変更
「まさか…次版を作るだと…？」
設計書が無い
どれほどクソコードでも、「何を達成しようとしたのか」記載してある設計書があれば、「何を作ろうとしていたのか」わかります。
しかし、それすらもなければ…どうなるやら。
クソすぎて既に炎上している
お金をドブに捨ててでも、火を消すしかない状況ですね。
「炎上しているプロジェクトのソースは、たいていクソ」と言われます。
クソコードが生み出す、絶賛炎上中のシステムは、当目は「火を消す」しかないです。
なので、「将来的な費用」の考慮対象外とします。
本題：なぜクソコードは「余計な費用」となるのか
管理会計の世界では、「意思決定」という分野が存在します。
これは、かなり単純化して言うと、
その投資を行った際の、「支出（キャッシュ・アウト・フロー）」と「収入（キャッシュ・イン・フロー）」から「純額（ネット・キャッシュ・フロー）」を算出し、それがより大きい投資案を採択する
ものです。（割引現在価値とか、いろいろありますが、説明の都合上無視します）
仮定０：すべてがうまくいった場合の金額
※１年で区切ります。また、１年目に当初開発が終了し、毎年改訂を行うものとします。
| 費目 | 初年度 | １年後 | ２年後 | ３年後 | ４年後 | ５年後 |
|---|---|---|---|---|---|---|
| 収入 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 |
| 支出 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 |
| 利益 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 |
→合計：6,000,000円
仮定１：クソコードのシステムを改訂する（人海戦術で期間通りに改訂できた）
先ほど書いた通り、
どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」
です。言い換えると
ソースの品質そのものは、収益に関係ない
ものとします。
そうなると、クソコードを改訂するために「余分にかかった費用」の分だけ、利益が減ります。
| 費目 | 初年度 | １年後 | ２年後 | ３年後 | ４年後 | ５年後 |
|---|---|---|---|---|---|---|
| 収入 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 |
| 支出 | 1,000,000 | 1,200,000 | 1,400,000 | 1,600,000 | 1,800,000 | 2,000,000 |
| 利益 | 1,000,000 | 800,000 | 600,000 | 400,000 | 200,000 | 0 |
→合計：3,000,000円
６年後からは損失ですね。南無。
なお、例だから、比例的に増やしましたが、クソコードがあると「加速度的に」費用は増えます。
（改訂内容によるとは思う）
仮定２：クソコードのせいで、予定していた改訂が行えず、収益が得られなかった
これは、単純に収益が減少したケースです。
費用が増えることを、とにかく嫌った場合とかですかね。
| 費目 | 初年度 | １年後 | ２年後 | ３年後 | ４年後 | ５年後 |
|---|---|---|---|---|---|---|
| 収入 | 2,000,000 | 1,800,000 | 1,600,000 | 1,400,000 | 1,200,000 | 1,000,000 |
| 支出 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 |
| 利益 | 1,000,000 | 800,000 | 600,000 | 400,000 | 200,000 | 0 |
→合計：3,000,000円
なお、IT業界の変遷は早いので、改訂速度が遅いシステムなんて、あっという間に淘汰されます。
こんなのんびり、収入が減るなんてことは、現実には無いでしょう。
仮定３：クソコードのせいで、思ったほど利益が上げられなさそうなので、１年後に解消に走った（うまくいった）
誰もが得する（かもしれない）理想パターンです。
なお、「クソコードを修正し、再構築するのに、支出は仮定１の３倍かかる」ものとします。
| 費目 | 初年度 | １年後 | ２年後 | ３年後 | ４年後 | ５年後 |
|---|---|---|---|---|---|---|
| 収入 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 |
| 支出 | 1,000,000 | 3,600,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 |
| 利益 | 1,000,000 | -1,600,000 | 1,000,000 | 1,000,000 | 1,000,000 | 1,000,000 |
→合計：3,400,000円
雑な仮定ですが、「１年後に240万支出を増やすことで、将来の支出を280万抑える」結果となります。
仮定４：クソコードのせいで、思ったほど利益が上げられなさそうなので、３年後に解消に走った（うまくいった）
修正年以外の仮定は、「仮定３」と同じです。
| 費目 | 初年度 | １年後 | ２年後 | ３年後 | ４年後 | ５年後 |
|---|---|---|---|---|---|---|
| 収入 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 | 2,000,000 |
| 支出 | 1,000,000 | 1,200,000 | 1,400,000 | 4,800,000 | 1,000,000 | 1,000,000 |
| 利益 | 1,000,000 | 800,000 | 600,000 | -2,400,000 | 1,000,000 | 1,000,000 |
→合計：2,000,000円
直すのが手遅れ、な感じです。
直さないほうがましかもしれませんが、６年目以後を視野に入れるなら、クソコードを解消するしかないでしょう。
仮定を見て（総括）
今回は、仮定３が最も良い結果となるようにしました。
でも、エンジニアの方々なら、仮定１の「加速度的に費用が増える」や、仮定２の「のんびり収入が減ることはない」というのには、同意していただけるように思います。
クソコードと戦うには
発注者が、クソコードのメンテを依頼してきた場合、我々はどうしたらよいのでしょう？
最も大変なのは、「相手がソースなんて理解していない」場合だと思います。
このソースはクソだから、余計に費用がかかるんです！と言っても信じてもらえず、「前はこれだけなんだから、同じ金額で受けてもらわないと困る！」みたいに圧力かけられたりとか…（妄想です）
そういうときに、金額的な根拠も示せると、もしかしたら不合理と戦える交渉でも有利になれるかもしれない、と思います。（妄想ですが）
もし、費用面で相手が納得したら、今度はクソコードを解消できるだけの設計技術が必要となり…という感じですね。
ＳＥの勉強は、こうしてまだまだ続きます…
といった感じでおしまい。
