情報システムの経年劣化

http://itpro.nikkeibp.co.jp/article/COLUMN/20091021/339209/

物はたいてい経年劣化する。

例えば、錆びてくるとか、時間が立って歪んでくる。

これは、もののみでもなく、情報システムにも経年劣化はあるのだろうか？

私が思うには、もちろんあると思う。ソフトウェアも出来上がったときが一番「ドキュメント品質」が高く、徐々に経年劣化してきている。

サービス員当時はぴっかぴか。が、サービスイン後、数々の仕様変更があると、「システム」には手を加えられる。一方、「ドキュメント」には手を加えない。その状態で年月を重ね、いつの間にか「システム」と「ドキュメント」の乖離が起こる。と、なるとコードを見て、テストをしてみないと仕組みがわからず、「ドキュメント」ではこの仕組は何ができるのか。何が必要なのかが見えなくなってくる。

そのようなシステムの状態で、例えばサーバ変更やシステムの抜本的な見直し、再構築のような案件が入るとすでにてんやわんや。軽く、現行分析を業務視点で行い、現行論理モデルを作成し、新モデルを作成する・・・なんて、教科書通りには行かず、現行システム分析に取られる時間が多くなる。

こういう状況は、企業の大小・業種にかかわらず起こっているのだろう。書籍やセミナーでの事例ならびに私の経験でもそう感じる。

このような場合、以下にこうならないように予防するのか。

もしなってしまった場合、どうやって現状分析するのか。の二点が考えられる。

＜予防策＞

　１．変更時のプロセスを定義し、実践すること。（些細な変更でも）

　２．リバースエンジニアリングツールを最初から突っ込む。

　３．システム変更はさせない

１は仕組みを作り、回すのに教育が必要であるし、しっかり回っているかを調査するような取り組みが必要。手間暇かかって実践できるかがミソ。

２はお金で解決。すべてが良い物ではないかもしれないが、要求から基本設計の業務内容は判断できないかもしれないが、システム・データレベルでいつでも把握できるはず。

３は究極・・・WW。まあ、そうやっていたら市場の理論で淘汰されそうですが・・。　　

＜予防できなかった場合の現行システム分析＞

　１．リバースエンジニアリングツールを利用

　２．人海戦術で解析

　３．今の業務を捨て、新業務モデルでシステム構築

とまあ、極端な例を記載しましたが、結論としては、「作ったらハイおしまい」としないことと、「システムが自動的に保守・メンテされている」という変な期待を抱かないことである。

世間ではDEVOPSも流行っている？というか保守がテーマに上がっているくらい、システムの劣化に対する方策が求められていると思われる。

そりゃ、要件変更でプログラムだけ変えて、動きゃいいでしょ！！というのは楽なのだが、それは短期的なコストについてのみ。長期的にどのような開発プロセス、保守プロセスを抱くことで、ソフトウェアの品質の劣化を防止し、新たな品質レベルへステップアップできるか、多少なりとのお金はかかるが・・・業務とビジネスを硬直させないためにも対応が必要ではないかと思わる。