オフコン・汎用機からの移行先としてのIBM i（２）

前回はサーバー移行がどこで実施されており、今後はどこがポイントになりそうなのか、市場全体の動向を述べてまいりました。今回は移行先サーバーの選定基準を確認し、その観点から各サーバーはどのように見えるのかを検討してみます。

サーバー選定基準の実際 ～ 安全性、テクノロジー刷新と将来性

汎用機もオフコンもその主な役割は各企業の経済活動、すなわち基幹となる業務をサポートすることにありますので、安全・確実に移行作業を行えることが最も重要な要件ではないでしょうか。これは単に作業を完了できるに留まらず、その後も安定してシステムを稼動させることができる、という点まで広く構えておく必要があります。この点において一切の妥協は許されないはずです。そのためにはどうしたら良いでしょうか。最も堅実な手段は変更部分を極力抑えることです。旧来のアプリケーション・プログラムはできるだけそのまま使う、システム運用方法も可能な限り従来のものを踏襲することです。新旧のシステムの構造が似ているとなお良いでしょう。新規構築を行う部分があると、どうしてもそこにはバグが潜むリスクが生じてしまいます。バグを皆無にするよう頑張る、といった精神論だけでは通用しません。 次に考えたいのがテクノロジーの刷新です。大きな投資を行ってシステムを移行するのであれば、そこに新たな付加価値が生まれなくてはなりません。特に移行プロジェクトに対して経営層の承認を得る必要があるのであればなおさらです。旧来のレガシーなサーバーを置き換えるに際してオープン性が必要、というわけです。既存の汎用機ないしオフコンには基幹業務を受け持たせ、周囲に配置した別のオープン系サーバーに例えばWebサーバー機能を受け持たせる、といった機能分離は一つの典型であり、これまでも実装されていました。できることならば、わざわざサーバー台数を増やすのではなく、一台で基幹業務もWebサーバーも実現できる方が運用上便利ですし、効率も良くなります。 サーバーとしての将来性も必要です。サーバーを移行するのは極めて時間と労力を必要とする作業です。能動的・積極的な事情があるのでしたらまだしも、ベンダーのサポート打ち切りなどやむを得ない事情による移行はできる限り避けたいものです。メーカーのサーバーに対するコミットメント、言わば長期的な投資計画が明らかであることが望ましいです。さらに移行先サーバーも何年か経ったら刷新するべき時期が到来することも考慮しておくべきでしょう。その際に、どのような作業が必要になるのか、という長期的視点も必要になります。特に注意が必要になるのはアプリケーション・プログラムです。新規構築費用にXXXX万円、バージョン・アップグレードのためにやはり同額のXXXX万円、といったケースがあるのも残念ながら事実です。これではせっかくサーバー移行においてコスト・ダウンを実現したのに、そのメリットが相殺されてしまいます。 他にもいくつか考えられますが、次期サーバーを決定する上でおそらく最も重視されるのが、上記の安全性、テクノロジー刷新、将来性、の３点だと言えるでしょう。例えばパフォーマンスやセキュリティなどは、決定されたサーバー上でどのように実装・実現すれば良いのかを後から検討する、というやり方でも良さそうです。これを念頭に、今後のサーバー候補はどのように評価できるのかを検討してみましょう。

汎用機とオフコンの見え方

現行の汎用機・オフコンを提供しているメーカーにとっては、さしたる機能拡張や将来性がないとは言え、可能であるならば、より新しいマシンを提案するのが最良の選択肢かも知れません。同一メーカーのそしておそらく同一シリーズのマシンであれば、アプリケーションの移行は安全に行えそうです。また従来からのSEサポートもそのまま継続提供できるというメリットもあります。しかしながら、逆の側面としてテクノロジー刷新は期待できそうにありません。ユーザーにとっては、サーバー置き換えのための投資を行いながらも、実現できることは従来と同じ、というわけです。これでは投資案件として果たして経営層の承認を得られるでしょうか。あともう一点気をつけたいのは、本来であれば経営を支えるシステムとして、サーバーの置き換えを検討しなければならないのに、課題を先送りしているに過ぎないのかも知れないということです。最新テクノロジーを活かしながら、ビジネスを変革・推進する機会を逸しないようにしたいものです。

Windowsサーバーの見え方

対案として考えやすいのはいわゆるオープン系サーバー、具体的代表例はWindowsサーバーです。オープンを標榜するだけあって、その最大のメリットの一つはオープン化、すなわちテクノロジー刷新です。一方でサーバー置き換えと同時に、既存のアプリケーション・プログラムをどうするのかも検討しなければなりません。レガシーのイメージが根強いながらも、従来から長年にわたって利用されてきた、COBOL言語によって記述されたプログラムが多数存在するはずです。 サーバーがオープン系だから、言語もオープンなもの、例えばJavaに書き換えよう、という考え方もあります。ここで仮にツールによるCOBOLからの移行が可能だとしても、生成されたJavaプログラムを容易に改修できるのだろうかという懸念が残ります。COBOLは手続き型言語、Javaはオブジェクト指向型言語、とそのタイプは全く異なるため、限りなく手続き型のような、Javaプログラマーにとって変則的なコードが生成されたとしたら、人手による保守・改修は極めて困難になります。移行後のJavaプログラムを改修するために、結局元のCOBOLに立ち返らなければならないとしたら、移行の意義はありません。また最近は多少改善される傾向にはありますが、Javaはバージョン・アップグレード時において、互換性が保たれないという問題があります。当初は最新バージョンではあっても、古いバージョンのままアップグレードできず、いずれJavaとは言えレガシー化してしまうリスクがあります。 Windows上で稼動するCOBOL実行環境も存在しますが、業務アプリケーションはCOBOLが全てではないはずです。典型的にはJCL（Job Control Language）による、サーバーを運用するためのプログラムも数多く利用されているのではないでしょうか。Windowsにはこれに相当するテクノロジーは見当たりませんので、システム運用ツールなどを導入して新規に構築し直す必要があります。 汎用機にはスプール、すなわちプリンター出力時のファイルを一時的に溜めておく領域がありますが、実際には出力後もそのまま留まるので、これを利用したアプリケーション・プログラムも数多く利用されています。Windowsサーバーにおいては、スプール・ファイルは印刷後に消滅してしまうので、同様のプログラムを利用することはできません。全く新しく、帳票印刷のプログラムを開発する必要があります。 地味ではありますが、文字コード、すなわち文字を表現するために割り当てられている16進数値の違いにも注意が必要です。汎用機とWindowsとで文字コードが異なるということよりも、その表現方法が変わるために、文字列の長さが変わることが懸念事項になります。これはすなわちデータベースのフィールド長が変わり、画面における入力フィールドの長さが変わるということを意味しており、アプリケーションに手を入れなければならないのです。 上記全てがうまくいくとしても、Windowsサーバーではマシン台数が増える傾向があります。従来は一台のマシン上で数多くのアプリケーション・プログラムを統合的に稼動できていたのに、アプリケーション毎、機能毎にサーバーを分離するためです。さらに性能を維持するために、複数サーバーによる並行処理を行ったり、信頼性を担保するために、本番業務機に加えてバックアップ機を設置したりする必要に迫られるかもしれません。マシン台数が増えれば運用が複雑化し、それだけ人手をかける必要が生じます。

実はここには最適解は見あたらない

いくつか代表的な懸念事項を列記したに過ぎませんが、これらはシステムの構造すなわちアーキテクチャーにおいて、汎用機とWindowsとの間に隔たりがあることが原因です。テクノロジー刷新においては、どうしても新規に開発しなければならない割合が多くなり、安全性を危険にさらす可能性が高くなりがちです。 以上のとおり誰もが納得できるシンプルな結論には至りませんでした。だからと言って、このまま放置しては無責任なコラムになってしまいます。次回最終回では最適解、筆者一人の思い込みではなく、多くのユーザーが出した結論とそこに至る経緯を検討します。 ＜バックナンバー＞ 移行先サーバーとしてのIBM i（１）