メディア

最低10年使える業務アプリケーション（前編）：28歳から挑戦するITアーキテクト（11）～実践編～

これまでの連載ではITアーキテクトとして日々考慮すべき内容について、特に実践編では具体的にどういった行動が必要であるかを考えてきた。では、それらを踏まえ、アプリケーションを構築して運用に乗せた場合、果たしてそのアプリケーションは何年間の寿命を持つことができるのだろうか？

» 2006年07月07日 12時00分公開

[岩崎浩文（株式会社豆蔵 BS事業部エンタープライズビジネスグループ），＠IT]

使い捨ての業務アプリケーション

　ここ10年、いわゆるオープン系開発が主流になってきたころからだろうか、コンピュータ関連の急激な技術革新（という名の新製品ラッシュ）により、その上で動くアプリケーションはひたすら翻弄（ほんろう）され続けている。

　例えば、たった10年間さかのぼっただけで、Windows 3.1の16ビットアプリケーション、およびWindows 95、Windows NT 3.51の初期型32ビットアプリケーションが混在する世界だ。その時代から多くのOS、言語が誕生し、忘れられ、淘汰（とうた）されている。

技術革新のスピードにアプリケーションが翻弄（ほんろう）されている

　あまり知られていない業務用ハードウェア・ソフトウェアの世界はさておき、読者の方にもなじみ深いWindows上で動作する業務アプリケーションであれば、（1）.NET登場以前のVisual Studioなどで作成したWin32アプリケーション、（2）PerlやPHPなどオープンソース系で作られたWebアプリケーション、（3）J2EE登場以前のJavaアプリケーション、（4）J2EE登場以後のアプリケーションサーバ上で動作するJavaアプリケーション、（5）.NET Framework上で動作するアプリケーション、などに大別できるだろう。これは筆者がそう感じているだけで、より細かい分別も可能だ。

　つまり、たった10年間にこれだけの技術が登場し入れ替わっている。これについての詳細は本連載第8回「基盤技術にロック・オンされていないか？」にて指摘したとおりだ。そして、アプリケーションは特定の環境上でしか動作しない。それは開発時に定められた「推奨環境」という名の縛りにて、運用側にその項目を厳密に守るように要求することとなる。仮にそのハードウェアが「改良」され、ソフトウェアが「バージョンアップ」された場合、推奨環境から簡単に外れる。そしてそのソフトウェアは動かなくなる「かもしれない」。

基盤のバージョンアップで簡単に動作しなくなるアプリケーション

　そんなばかな、と思われる方もいるかもしれない。だが、開発完了・連続稼働開始から数年経過したアプリケーションの現状とはこんなものだ。筆者は立場上、自ら作ったアプリケーションも含め、運用時のメンテナンスにおいて相談を受けることが多いのだが、その大半が「OSやアプリケーションサーバのバージョンアップを行いたいが、どうやっていいのか分からない」というものだ。

　困ったことに、OSやアプリケーションサーバ、プログラム実行環境（VM）、仕様ライブラリなどには、その組み合わせによって動作する・しないの制限がある。具体的にはAPIの変更があった場合や、挙動が変更されてしまった場合などだ。開発を行う側としてはそれほど気にしないが、よほどその内容に精通していない限り、動作する組み合わせを判断するのは非常に困難を極める作業だ。

　それも、利用しているライブラリが多くなればなるほど、ライブラリ間の複雑な依存関係やバッティング等も登場し、まるでパズルのように複雑怪奇なスパゲティー仕様となっていることが多々ある。

　それらに対してバージョンアップを行わなければならないのは、とてもではないがITアーキテクトなど専門家が判断しない限り難しい。

あるケース

　例えば2000年、J2EE 1.2が華々しく登場し、それに準拠したアプリケーションサーバで企業システムを構築した例だ。筆者はこの後3～4年してからこのシステムに初めて対面したのだが、企業の運用担当者は腹立ちと苦悩で顔がゆがんでいた。

　Javaが華々しく登場した当時は『Write Once, Run Anywhere』というマーケティング用語（J2EEの場合は『Write Once, Deploy Anywhere』）が結構本気で信じられていた。この担当者もその言葉を信じ、当時英断としてJavaを全面採用したのだが、OS刷新とともにバーチャルマシンおよびアプリケーションサーバのバージョンアップが必要となり、それに伴い数億掛けて構築されたアプリケーションが動作しなくなる現象が出ていた。

　このアプリケーションが企画された当時、J2EEが登場したばかりでJDKは1.2であったため、そのアプリケーションはこの上で動作する仕様として構築されていた。その後開発途中で1.3が登場したため、やむなく開発の手戻りを覚悟して乗り換え作業を行い、2001年に無事運用に乗せることができた。

　その後は、追加開発時にもこの仕様をかたくなに守っていたが、一部のハードウェア故障でサポート切れが発覚した。そのため新しいハードウェアを調達したのだが、JDKやアプリケーションサーバはすでにサポート対象外になっていた。

迫る「EOL」（End Of Life）

　運用側の本音としては、せっかく安定して動作しているサーバに対して手を入れることを極端に嫌ううえに、面倒なバージョンアップやセキュリティパッチなど当てたくもない。それにもかかわらず、上記のケースのようにOSやアプリケーションサーバ、実行環境などのサポート期限、つまりEOL（End Of Life）が迫ってくるため、渋々対処せざるを得ない。もちろん、日々発覚するセキュリティホールなども対処せざるを得ない原因の1つだ。

　先日も一般のニュースなどに取り上げられ話題になったが、一般利用のOSの更新期限があと2年ほどしかなく、その事実が消費者に認知されていない、という状況が現実として存在する。こうしたメーカー側の押し付けが横行する現状は誰にとっても好ましいことではないため、家電製品や自動車などと同様に法規制されるべきだと個人的には思っているのだが、一朝一夕で変わるものでもない。

　以前のオフコンではこうではなかったのだが、という愚痴もよく聞かされるが、そのころに実現できていた内容よりも、現代の業務アプリケーションはできることが多くなっているうえに安価で、汎用OSやハードウェアを使っていることも多いのが災いして、以前は10年程度持つと考えられていた寿命は、近年ではせいぜい数年だ。

死に体のアプリケーションを特殊延命措置

　このような状況を客観的に見れば、以下のようになる。

　仮に10年前に作ったアプリケーションを改修せずにそっくりそのまま使い続けるためには、開発した当時想定していたハードウェア・ソフトウェアをかたくなに保持し、ひたすら手を入れずに運用し続けるしかない。もちろん、挙動が変わってしまう可能性があるOSのセキュリティパッチやサービスパックなどの更新パッケージの適用などはご法度だ。適用したが最後、アプリケーションがウンともスンともいわなくなり、業務遂行が完全停止してしまう。そのような悲劇（と怒号）がこれまで何度繰り返されてきたことだろう。

　現実にそうやって特殊な延命措置が施された業務用アプリケーションは結構な数に上ると筆者はみている。現に、約20年前のNEC PC-9801シリーズの5インチフロッピーディスクモデルを後生大事に使い続け、ハードウェアが壊れたときのために数台の予備を持っている顧客も筆者の知るところに数件存在する。こうしたアプリケーションは特殊外部ポートや特殊増設RAM、厳密なハードウェアクロックタイミングに依存するソフトウェアが多いため、Windows上のエミュレータなどではまったく動作しない。

　これは極端な例だとしても、現代の状況はこれと大して変わっていない。特定のOSの特定のサービスパックでしか動作しない、特定のバージョンのVMやライブラリに大きく依存するアプリケーション。やはり、「推奨環境」をひたすら温存して使い続けるしかないわけだ。

　このようなアプリケーションは、単に開発当時のアプリケーションを動かし続けているだけであるため、その機能を改良したり、追加したりすることができないことが多い。当時のプログラマが廃業していたり、契約が切れていて音信不通であったり、開発時のハードウェアやコンパイラが入手できなかったり、ソフトウェア仕様書はおろかソースコードがなかったり、などだ。

　そしてその状況に追い打ちを掛けるように、OSなどのEOL（End Of Life）が迫ってくる。

「延命措置」が意味を成さない理由

　業務自体に変更が少ない場合、あるいは現状のアプリケーションの完成度が非常に高い場合を除き、世の中の移り変わりに伴い、ビジネスは変わってゆく。業務支援を旨とする業務アプリケーションの場合、大半は常に業務の変更に伴いアプリケーションも改良を続けていかなければならない。

　また、開発完了後、OSやライブラリ側で発覚するセキュリティホールや不具合への対処も悩ましい。社内ネットワークが外部のインターネットから遮断してあれば大丈夫、というのはよくある勘違いで、インターネットが一般に普及するはるか以前からフロッピーディスクなどを経由してコンピュータウイルス（という名の破壊プログラム）がまん延していた。プログラムのインストールをはじめ、外部から媒体を持ち込まれる可能性がある限り、セキュリティホールを突かれて破壊または情報が漏えいされる可能性は残る。

　このような場合、先のような改良できない自体に陥ったソフトウェアの末路はただ1つ。捨てられるだけだ。

　次回はこれら諸問題の原因を探り、現代の業務アプリケーションは延命できるのかを考えたい。

「28歳から挑戦するITアーキテクト」バックナンバー