「UNIXサーバ vs. メインフレーム」で始まったこの議論は30年の歴史がある。この議論では基本的に、既存のレガシーハードウェアおよびソフトウェアの耐用年数と、米Intel、米AMD、英ARMプロセッサベースの低コストなCOTS（Commercial/Commodity Off-The-Shelf：市販／コモディティ型の既製品）サーバおよびストレージが持つ可能性が対比される（編注）。

編注：ここではCOTSサーバはオープンサーバ、レガシーサーバは旧来のメインフレーム、オフィスコンピュータなどを指す。

　党派的な議論の常として、この議論には技術的、経済的、政治的な問題が混在している。

　レガシー派は、「レガシーからの移行がいかに困難か」「移行した場合の障害発生のリスク」を考えるべきだとしている。COTS派は、「COTSではアジリティとパフォーマンス向上が約束されている」ことに目を向けるべきだという言い分だ。「レガシーシステムのハードウェアとソフトウェアは、減価償却が済んでからやっと更新されることが多い」としている。また、雇用の安定という問題も議論に複雑に絡んでくる。

レガシーシステムはきちんと役割を果たすか

　この質問にはトリックがある。「データセンターにおけるレガシーシステムの役割は静的なものである」という暗黙の前提がある。しかも、「アプリがビジネスプロセスを定義し、ビジネスプロセスがアプリを定義する。両者はいずれも最適な状態にある」という考え方が透けて見える。

　こうした前提や考え方は、よく考えればまず成り立たない。現在のビジネス環境は進化しており、ときには大転換を遂げている。どのようなビジネス分野でも、俊敏なプレーヤーが成功している。レガシーシステムはきちんと役割を果たすが、それはそもそも正しい問題設定だろうか。

ライバルに差をつけられるだけの速さでレガシーシステムに変更を加えられるか

　レガシーシステムは大抵の場合、ゆっくりと進化する。古いコード、貧弱なAPI、外の世界と通信できないことが進化のネックになるからだ。念のために補足すると、外の世界ではモバイル革命が進んでおり、企業は対応していかなければならない。

　Microsoft .NETをレガシーコードベースに組み込めば、問題が部分的に解決され、やや継ぎはぎのソリューションが得られる。レガシーアプリは、ターボディーゼルの世界における蒸気エンジンに相当する。

COTSサーバの出番

　COTSシステムへのエンジニアリング投資と、プロプライエタリ設計のシステムへの投資を比べてみよう。COTSシステムではCPUチップ、ハードウェア全般、ソフトウェアの投資効果が極めて大きい。

　COTSサーバのCPUはムーアの法則に沿って、18カ月ごとに性能が2倍に向上している。レガシープロプライエタリCPUの性能向上曲線ははるかに緩やかだ。新製品がリリースされるごとに大幅に性能が向上するが、リリース間隔は格段に長い。両CPUの性能の違いは大きいが、全体的に見ると、システムレベルの性能差はあまり目立たなかった。ストレージの性能が小幅な伸びにとどまっていたからだ。

　現在では、フラッシュドライブやSSD（ソリッドステートドライブ）のおかげで、高速で高性能のCPUが潜在力を発揮できるようになっている。これに伴い、コスト曲線でも性能曲線でも、COTSのアプローチの方がプロプライエタリシステムよりも断然優位に立っている。その差は実際のビジネスでも、「新しい機能やスケーラビリティを実現した企業がライバル企業を打ち負かす」という形で現れるようになっている。

　だが、COTSサーバへの移行には変化が伴うことから、移行のハードルが高くなっている。雇用の保護が変化の回避につながり、進化を妨げてしまうわけだ。すなわち、COTSサーバの運用管理では、大規模なデータセンターチームは不要になる。管理の負担が軽くなり、コーディングをする代わりに既製アプリや、さらにはクラウドベースのSaaS（Software as a Service）が使えるからだ。この2つでは、社内にコーディングノウハウはあまり必要ない。さらに、ほとんどのレガシーコードはCOBOLで書かれている（全世界でまだ4000億行のCOBOLコードが実行されている）が、新しいアプリはC++やJavaなどで作成されている。

　しかし、「レガシーハードウェアおよびソフトウェアはタダだ」とレガシー派は主張する。だが、これは間違いだ。例えば、メインフレームはCOTSと比べて大量の電力を消費する。また、多くのレガシーシステムを対象とした保守・サポート契約では、新しいCOTSシステムを一式買いそろえられるくらいの高額な料金が掛かるだろう。雇用の問題も、財務上の考慮事項に密接に関係する。コード作成やシステム管理に必要なスタッフ数が少なくなれば、人件費も減るからだ。

将来を見越したアプリ移行

　レガシーシステムに関して、COTSシステム導入のもう1つの大きな障害は、変化への不安だ。レガシーシステムからCOTSへの移行に当たって、レガシーシステム上のパッケージをエミュレートするアプリを作成するのは容易なことではない。しかもこの移行では、往々にして単なるエミュレートでは済まない。

　レガシーシステムではビジネスプロセスの変更ニーズが抑制されがちになるため、COTSへの移行を機に、これらのニーズへの対処が図られるからだ。こうして、新しいコードを作成する際に急速な機能進化が要求されることになる。

　そこで移行のプロセスが破綻してしまう。コードにむやみに変更が加えられ、安定性が損なわれるからだ。1つの選択肢として、COTSプラットフォームでコードをリコンパイルするという方法がある。そのための良いCOBOLツールもある。しかし、これはレガシーシステムのハードウェア上の問題を修正するにすぎない。

　最良の選択は、新しいアプリを購入することだ。アプリ開発をアプリの選択に変え、レンタルするか、購入するかも併せて決めることになる。何でも自前でまかなう自己完結した企業はほとんどない。大半の企業は業務やその処理方法の90％以上で、他社も使う何らかの既製のコードを利用している。コードの既製品がハードウェアのCOTSを補完するわけだ。

　新しいCOTSアプリに移行するには、ビジネスプロセスリエンジニアリングが必要になる。それにはコストが掛かるが、これはもともととっくの昔にやっておくべきだったことだろう。品質保証を目的としたISO 9000規格への取り組みや関連するプロセスドキュメンテーションアプローチを実行することが、重要な第1歩になる。

　クラウドの台頭を背景にIT部門の仕事では、外部との関わりがますます重要になっている。クラウドの経済性、拡張性、柔軟性は、レガシーシステムからの脱却を迫っている。IT部門の基本的な機能はサービスの提供となり、クラウド（パブリックまたはハイブリッド）は、サービス提供における最良の価値を提供するようになっている。各種の政府機関や米海軍も、硬直的で変化に無関心という評判を覆し、クラウドの導入に乗り出している。

　さまざまな問題をクリアし、レガシーシステムからCOTSへの移行を開始するには、シニアスタッフのコミットメントとITを統括する強力なリーダーが必要だ。