最低10年使える業務アプリケーション（前編）
http://www.atmarkit.co.jp/im/carc/serial/2805/2805.html
Javaが華々しく登場した当時は『Write Once, Run Anywhere』というマーケティング用語（J2EEの場合は『Write Once, Deploy Anywhere』）が結構本気で信じられていた。
結構というか，実際にかなり高いレベルで実現されている．
この担当者もその言葉を信じ、当時英断としてJavaを全面採用したのだが、OS刷新とともにバーチャルマシンおよびアプリケーションサーバのバージョンアップが必要となり、それに伴い数億掛けて構築されたアプリケーションが動作しなくなる現象が出ていた。
VMやアプリケーションサーバの実装依存部分に依存するような記述をしていたからとか？典型的なものとしては，マルチスレッドのはずなのに，ある一定順序で実行されないとバグが表面化するというものがある．マルチスレッドの実行順序は基本的にランダムであるので，いかなる順序で実行されても正常に動作することが求められる．そういう実装になっていなければ，それはバグです．
この他にdouble-checkd-lockingイディオムのように，当初は有効と思われていたものの，後にJavaのメモリモデル上では使えないと判明した例もある．
このアプリケーションが企画された当時、J2EEが登場したばかりでJDKは1.2であったため、そのアプリケーションはこの上で動作する仕様として構築されていた。その後開発途中で1.3が登場したため、やむなく開発の手戻りを覚悟して乗り換え作業を行い、2001年に無事運用に乗せることができた。
一体どの程度手戻りが生じたか書かれていない．
「手戻りを覚悟した．」が，「実際にはほとんど全くと言っていいほど生じなくて，拍子抜けした．」だけではないのか．*1
業務自体に変更が少ない場合、あるいは現状のアプリケーションの完成度が非常に高い場合を除き、世の中の移り変わりに伴い、ビジネスは変わってゆく。業務支援を旨とする業務アプリケーションの場合、大半は常に業務の変更に伴いアプリケーションも改良を続けていかなければならない。
これがOOPを使う理由の一つだ．OOPを適切に使えば改変時のコストが1/100にも1/1000にもなる．
しかし適切に評価できる仕組みが組織にないと，これは機能しない．
- 営業は案件をとってくるのだけが仕事．取ってきた案件で赤字がでれば開発部門の責任．
- 開発は案件をつくるのだけが仕事．作ったシステムの保守／変更で赤字がでれば保守部門の責任．
- 保守部門は『完成した』システムの保守が仕事．機能追加や変更のコストは開発部門が作ったソースコードの品質次第．品質が良ければ２〜３日で済む仕事が，悪ければ一から作り直しで費用も期間も文字通りに桁違いになる．
こういう組織になっていれば，営業は赤字案件をとってくる．開発は赤字案件の赤字を少しでも減らすために，突貫工事で急ごしらえの，将来の変更など到底不可能なクズプログラムを作る．保守はそういうクズプログラムをできるだけ手を加えないように，小手先の修整だけを加える．大規模な変更を加えようとしても，やぶ蛇になるだけ．
