Tidy First? ―個人で実践する経験主義的ソフトウェア設計

30章コンスタンチンの等価性

　

私が若いプログラマーだったころ、ソフトウェア開発コストの70%がメンテナンスに費やされているという悲惨な報告を聞いたことを覚えている。70%も！ モノを作って動かし続けるのにその2倍のコストがかかる仕事とは、なんとお粗末なのだろうか？

ソフトウェアは「モノ」であり、一度作られたら変更されず永久機関のように動き続けるものだというメンタルモデルは、ソフトウェアの実際の姿や、あるべき姿とは正反対であることがわかっている。未来のシステムの価値は昨日の憶測ではなく今日の現実のなかで明らかになるのだ。

結合がソフトウェア開発に影響すると理解したところで、結合の重要性を理解する準備が整った。結合と凝集に関する古典『Structured Design』（邦訳『ソフトウェアの構造化設計法』）で、エドワード・ヨードンとラリー・コンスタンチンはソフトウェアのゴールはソフトウェアのコストを最小化することだと仮定した（価値を最大化することでもあるが、それは後述する）。だが、コストとは何だろうか？

この70%という見積りでさえ、あまりにも低すぎることをこれからご覧いただこう。まず、創造性を発揮すれば、価値を生み出すソフトウェアを最終的な開発コストの数%でリリースできる。こうすることがみんなにとって最善なのだ。実際に使ってもらってフィードバックを早く受けられれば、価値の低い振る舞いの開発に費やす時間や予算、機会を減らすことができる。

私が「コンスタンチンの等価性」と名付けた法則の最初の項は、ソフトウェアのコストはそれを変更するコストとほぼ等しいということである。確かに、ソフトウェアを「変更している」と表現できる時期に入るまでには少しだけ時間がかかるが、それは全体から見ると誤差のようなもので、経済的には無視できる。つまり、次のようになる。 ...