どんなシステムであれ、構築・リリースしてから徐々にシステムの老朽化は進んでいき、そうなる前にリプレイスされたり、その役目を終えて廃止もしくは別のシステムへと統合されていったりするわけですが、どう運用していっても最初は完璧だと思われていたそのシステムは、徐々に崩壊への道をたどっていきます。
最初は最新機能を兼ね備えたぴかぴかの家電製品でさえ、5年も経てば一気に色あせ、それはまだ動くにしろ時代とともに淘汰されていく運命にあったりします。
それは、システムとて同様のこと。
ただ、システムはその運用の中で著しく崩壊への時間が短縮されるイベントが多々あります。
つぎはぎだらけのシステム改修
華々しくリリースしたシステムでも、徐々に利用者からその機能やUIに不満というものが出てきます。
わがままな利用者の声に答えるべく対応した改修作業は、場合によってはそのシステムの寿命を縮めることにもなったりします。
機能拡張の仕様の中には、当初の設計上想定されていなかったものも含まれたりするため、半ば力技での対応になったり、上塗りするようにつぎはぎして拡張されていく場合もあります。
それは、設計思想が崩れたことであり、システム開発のルールが適用できなくなったことを意味したりもします。
一度生まれた例外は、また新たな例外を生む結果にもなったりするため、それまで綺麗に整理整頓されていた開発環境は一気に崩壊していきます。
最初は「こうすべき」と定義したルールが、「基本的にこのようにします」と変わり、最終的にはルールを遵守することへの疑問が深まっていく結果になったり。
また、何も利用者からの要望だけでなく、潜在的なバグが表面化したことによる改修も同様のことが言えるでしょう。
その対応もまた、つぎはぎを生む結果となるわけです。
想定外のイベント
当初の設計というのは、推測だらけで始まります。
利用者数やアクセス数、キャパシティへの見積もりなど過去のデータから類推したり、それまでの統計データからある程度の精度の予測を立てることはできますが、それはある想定に従った場合という条件付のものだったりします。
ある想定というのは、今の環境が変わらなければとか、類推したデータからの予測値を大きく外れるようなイベントが起きなければ、といったものだったりです。
しかし、当初の予測どおりにそのまま順調にシステムが利用されていくのはまれです。
もともと、このシステムだけでしか使わないと決めていた環境が、予算の都合とか政治的なやり取りの中で統合されたりもします。
想定していなかった利用者数によるリソースの使用率の増加や、システム統合や追加によるキャパシティの変化などはよく起きるイベントです。
それは、喜ばしいことでもあるのですが、そのシステムでは耐えられる期間を短くすることになり、同時に崩壊への時間を狭めます。
そうなってくると、まったく当初の予測から外れた結果になっていくことは明らかです。
5年持つと計算されていたのが、それらのイベントによりより速い時間で持たない状況に追い込まれることになるわけです。
運用ルールの変革による崩壊
開発ルールの崩壊と同様に、運用者たちが取り決めたルールによってもシステムは陳腐化していきます。
システムの運用ルールは、内部的な要因だけでなく法律やお客さんからの要望など外的要因で大きく変わっていくことがあります。
内部統制系の話によりシステムの利用ルールを厳密に決めることになったり、セキュリティを気にしたお客さんからシステムへのアクセス制限の強化や利用報告を求められるかもしれません。
変わった運用ルールに対応するために、システム/非システムいづれでも業務そのものの変革が起きてきます。
要はシステムだけでなく、そのシステムに関連する業務そのものがつぎはぎになるわけです。
しばらくは、変わったルールに対応するためになんとか頑張ろうとするかもしれません。
しかし、業務自体が非効率になっていく過程で、負担が大きくなりシステムに改修を入れる施策が持ち上がったり、もっと大きな業務改革のプロジェクトが立ち上がったりもします。
業務が変わっていくことでその道具であるシステムも同じ道を辿ることになるわけです。
時代遅れ
技術革新の流れについていく事が目的というわけではありませんが、システムが最新の（そして安定した）技術を利用しているに越したことはありません。
技術が最新であるかどうかは、技術者視点にとっての重要性でしかありません。
しかし、利用者からの要望の中には最新のWebサービスに感化されたためか、その最新の技術をで作られた機能の実装を求めてくる場合もあります。
数年前にリリースし、すでにその技術そのものがレガシー化した状態で、最もホットなサービスにあるような機能を付け加える事への対応が難しくなってきます。
もちろん、いくら技術の進歩が早いとは言え、数年前の技術が使い物にならないぐらいになっているかといえばそんなことはありません。
応用すれば、最新サービスが提供しているナウでヤングな機能も実装できるでしょう。
ただ、そのシステムがうまく対応できるかどうかは別の問題。
最新の環境であれば、数時間で対応できるようなことが数日かけて作る羽目になったり、対応そのものが力技になってたりもするわけです。
これは、システムの寿命そのものを直接的に縮めているわけではありませんが、一気にシステムが色あせて見えることになる結果をもたらすことにもなります。
まとめ
結局、そうならないためにも最初の設計凄く大事、って事に結びついたりもするんですが、同時に当初想定していたシステムのライフサイクルってほとんど当てにならないから、拡張性や柔軟性に優れた設計や開発手法を取り入れてた方がいいでしょう、と思ったりもします。
100年持つシステムというのはありえません。
システムそのものを100年動かすということであれば、達成できるかもしれませんがそれを利用するサービスや業務そのものが100年前と同じ事を続けているということはないでしょう。
その変化そのものを受け入れ、崩壊への道ではなく発展・進化の道を辿っていくような工夫が常に求められていくんだと感じます。