読者です 読者をやめる 読者になる 読者になる

SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。

クソコードが生み出す余計な「将来的な費用」について、金額面で考えてみた

最近、クソコードを見るのが楽しくなっています。

クソコード、格好良く言い換えれば技術的負債とも言えますが、これがどういう余計な費用を生み出していくか、思ったことを書いてみます。

なぜ「利益」ではなく「費用」なのか

クソコードが費用となるなら、超美麗なコードは利益を生み出すのか?  

という疑問はあると思います。

これは先に説明が必要ですね。

まず、どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」です。
システムが利益(これは収益の増加、費用の削減両方を含む)を生み出すかどうかは、システムのコンセプトや営業活動、利用促進等に依るところが大きいです。
よって、システムが仕様通りに作られている限り、「プログラム内部がクソコードかどうか」は、一応関係ありません。

クソコードでもいいんじゃね?という状況

いきなり例外(笑)

絶対に自分しか使わないソース

好きなだけ汚してください(笑)
これは、別にきれいに書いてもいいんですが、誰にも迷惑かけないのであれば好きなように書いていいと思いますよ、という意味です。

この場合は、少々クソでも、自分がわかればいいので、特に問題ないと思います。

作ったら、二度とメンテしないシステム

いずれメンテするかもしれないじゃないかというのは、いったん置いといてください。
システム作成時点で、次版を作るつもりがないなら、クソでも問題ないです。

ただし…
仮に当初決定が覆り、機能拡張等が発生した場合、当初のソースは捨てましょう。
機能追加分と「将来の改訂予定」を加味して、再設計したほうが、将来的にコストが安くなります。

あとで書きますが、メンテを考慮していないプログラムを修正するぐらいなら、作り直したほうがいいです。

保守担当が一人(定期改訂あり)

まぁ、別にずっと同じ人がメンテするなら、少々ソースが汚くても…とは思います。
その人が辞めても、死んでも、働かせる気があるならですが。

『プログラミングの心理学』に、プロジェクトの支柱となっている人の例が載っているので、見てみるとよいでしょう。
結局、「その一人がいなくなったら終わり」という状況でうまく行くわけがない、とのことです。
以下、同書の引用。

大規模組織のとりわけ興味深い特徴の1つは、どのメンバーの在籍期間よりも長い期間にわたって存続できることである。
~(中略)~
ところが、多くのマネジャーは自分のプログラミングプロジェクトに同じ理屈をあてはめることができない。

クソコードが費用を発生させる状況

仕様変更

クソコードの特徴として、「書いた人以外が読めない」というものがあります。
(書いた人が読めないこともある!!!)

仕様変更があったとき、ソースが読めないと、変更できないですよねー。

担当者変更

「ギリギリ仕様通り動いているけど、ソースがクソ」の場合、後任は大変ですねー。
この場合は、ソースが綺麗でも、「引継ぎが不十分」とか「後任者の力量不足」の場合でも、大変です。

もしくは、開発委託先を変更した場合も含みます。

凍結予定のシステムの仕様変更

「まさか…次版を作るだと…?」

設計書が無い

どれほどクソコードでも、「何を達成しようとしたのか」記載してある設計書があれば、「何を作ろうとしていたのか」わかります。
しかし、それすらもなければ…どうなるやら。

クソすぎて既に炎上している

お金をドブに捨ててでも、火を消すしかない状況ですね。
「炎上しているプロジェクトのソースは、たいていクソ」と言われます。

クソコードが生み出す、絶賛炎上中のシステムは、当目は「火を消す」しかないです。
なので、「将来的な費用」の考慮対象外とします。

本題:なぜクソコードは「余計な費用」となるのか

管理会計の世界では、「意思決定」という分野が存在します。
これは、かなり単純化して言うと、

その投資を行った際の、「支出(キャッシュ・アウト・フロー)」と「収入(キャッシュ・イン・フロー)」から「純額(ネット・キャッシュ・フロー)」を算出し、それがより大きい投資案を採択する

ものです。(割引現在価値とか、いろいろありますが、説明の都合上無視します)

仮定0:すべてがうまくいった場合の金額

※1年で区切ります。また、1年目に当初開発が終了し、毎年改訂を行うものとします。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 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円

仮定1:クソコードのシステムを改訂する(人海戦術で期間通りに改訂できた)

先ほど書いた通り、

どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」

です。言い換えると

ソースの品質そのものは、収益に関係ない

ものとします。

そうなると、クソコードを改訂するために「余分にかかった費用」の分だけ、利益が減ります。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 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円

6年後からは損失ですね。南無。
なお、例だから、比例的に増やしましたが、クソコードがあると「加速度的に」費用は増えます。
(改訂内容によるとは思う)

仮定2:クソコードのせいで、予定していた改訂が行えず、収益が得られなかった

これは、単純に収益が減少したケースです。
費用が増えることを、とにかく嫌った場合とかですかね。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 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業界の変遷は早いので、改訂速度が遅いシステムなんて、あっという間に淘汰されます。
こんなのんびり、収入が減るなんてことは、現実には無いでしょう。

仮定3:クソコードのせいで、思ったほど利益が上げられなさそうなので、1年後に解消に走った(うまくいった)

誰もが得する(かもしれない)理想パターンです。
なお、「クソコードを修正し、再構築するのに、支出は仮定1の3倍かかる」ものとします。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 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円

雑な仮定ですが、「1年後に240万支出を増やすことで、将来の支出を280万抑える」結果となります。

仮定4:クソコードのせいで、思ったほど利益が上げられなさそうなので、3年後に解消に走った(うまくいった)

修正年以外の仮定は、「仮定3」と同じです。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 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円

直すのが手遅れ、な感じです。
直さないほうがましかもしれませんが、6年目以後を視野に入れるなら、クソコードを解消するしかないでしょう。

仮定を見て(総括)

今回は、仮定3が最も良い結果となるようにしました。
でも、エンジニアの方々なら、仮定1の「加速度的に費用が増える」や、仮定2の「のんびり収入が減ることはない」というのには、同意していただけるように思います。

クソコードと戦うには

発注者が、クソコードのメンテを依頼してきた場合、我々はどうしたらよいのでしょう?
最も大変なのは、「相手がソースなんて理解していない」場合だと思います。

このソースはクソだから、余計に費用がかかるんです!と言っても信じてもらえず、「前はこれだけなんだから、同じ金額で受けてもらわないと困る!」みたいに圧力かけられたりとか…(妄想です)

そういうときに、金額的な根拠も示せると、もしかしたら不合理と戦える交渉でも有利になれるかもしれない、と思います。(妄想ですが)

もし、費用面で相手が納得したら、今度はクソコードを解消できるだけの設計技術が必要となり…という感じですね。
SEの勉強は、こうしてまだまだ続きます…

といった感じでおしまい。