金儲けだけが企業のなすべきことではないはずだ!!
しかし今は不況の時代でありコスト削減に取り組むべきということになるが、一コンピュータエンジニアとしてはIT関連のコスト削減について日々考えているわけである。フリーソフトウェアやOSSを活用すればITにかけるコストを下げられるということを、IT管理者さらには企業の経営者はまず思い出して欲しい。そして抑えるところはしっかり抑え、払うべきところにお金を払って頂きたい。つまり、ITコストは下げるだけ下げ、無闇に人員削減に走らないようにお願いしたいわけである。
高価なITシステムとして真っ先に思いつくのはメインフレームだろう。しかしこんなご時世にも係わらず、メインフレームの売れ行きが好調だというから驚きだ。今の時点でメインフレームは明らかに過去から引きずっている負の遺産であり、より安価なオープン系のシステムに置き換えるべきなのである。今日はフリーソフトウェアやOSSを利用する前段階として、メインフレームの置き換えについて考えてみよう。
メインフレームを使う理由はいくつかあるだろうが、最も大きいのはリスク低減という観点からだろう。そのリスクとは大きく分けて2つあると思うが、1.メインフレームはなかなか止まらない。もちろん停止することもあるだろうが、そうそう頻繁には起こらない。2.万が一停止したとしても、ベンダーから派遣されてきた管理者がすぐに直してくれる。マシンのリスクは全てメインフレーム側、つまりはベンダー側に押しつけられるのである。さらにメインフレームを利用している場合、システム構築から運用に至るまでを一括して委託している場合が多い。つまり、プログラムの不具合や運用中のトラブルまでのリスクや責任をもベンダー側に押しつけられるのである。
なんとメインフレームというものは素晴らしいじゃないか?!
自分は何も責任を負わずに安定したシステムを稼働できるなんて
まるで天国のよう?!
自分は何も責任を負わずに安定したシステムを稼働できるなんて
まるで天国のよう?!
と思うかも知れない。しかしこれには次のような罠がある。
- 当然のことであるが、このモデルは非常に高価である。ハードウェア自体も高価であるし、その保守料も高価である。
- ベンダーロックインから逃れられない。システムを全て丸投げするということは、自らそのシステムの詳細を知る由もない。つまりベンダーの言いなりである。
- ソフトウェアの開発コストが高い。メインフレームの開発言語はCOBOLであり、Javaなどの比較的新しい開発言語と比べると開発効率は遙かに劣る。
- 一般的には他のシステムとの互換性が低い。
- プログラムは常に特注(ワンオフ)なので再利用性が極めて低い。
- メインフレーマーは比較的シニアな人が多く、彼らが定年を迎えるとシステムのメンテナンスを出来なくなってしまう。
メインフレームなどいつまでも使い続けるわけにはいかない。
高いし柔軟性もないし最悪!!
高いし柔軟性もないし最悪!!
なのである。いつまでもベンダーにおんぶにだっこで高価なシステムに頼っていては良い未来などやってこない。最近のメインフレームでもLinuxが動作したりするが、Linuxを使うのなら別にメインフレームでなくても全然問題はない。ならばメインフレームを置き換えるしかない。いわゆるレガシーマイグレーションである。レガシーマイグレーションは今やらずしていつやるのか!!
メインフレームのような至れり尽くせりのシステムを利用してきた企業のIT部門にとって、オープン系のシステムは本当に大丈夫なのか?という不安もあるだろう。しかしオープン系のシステムは、ハードウェアの性能向上、ミドルウェアの拡充により十分な処理能力・高可用性を実現できるようになってきているので安心して欲しい。そして、オープン系システムでは上記で挙げたメインフレームの罠とは逆のことが言えるのだが、更に次のメリットがある。
- マシン単価が安いので負荷増加時にマシンを追加するスケールアウト構成がとりやすい。
- 各種FOSSを利用することができる。(リチャード・ストールマン万歳!)必要なソフトウェアが存在する場合が多い。
- 市販のパッケージソフトウェアが多く出回っている。そのようなソフトウェアを利用すれば、自前で実装するより遙かに安価にシステムを構築できる。
- ノウハウがインターネットで見つかる。
- x86/Linuxならベンダーを特に気にする必要がない。OSまでも!
- POSIX互換であればAPIレベルである程度互換性がある。(OSがしっかりPOSIXに準拠していれば!)
オープン系システムに移行すれば良いこと尽くしではないか!!
安いし柔軟性も高いし最高!!
安いし柔軟性も高いし最高!!
とはいえ、巨大なシステムの移行はとても大変である。マイグレーションの方法は様々であるが、要は化石化したハードウェアとプログラムをオープン系のプラットフォームでも動作するようにしてやることである。大まかには次のような方式がある。
- リエンジニアリング方式・・・業務の中身やプロセスを見直し、アプリケーションの仕様を一から再構築する。
- リライト方式・・・現在のビジネスロジックを元に、プログラムやデータベースなどをオープン系システム向けに書き直す。
- リホスト方式・・・COBOLで書かれたプログラムをそのまま他のオープン系システムで動作するようにする。
とはいえ、全てのメインフレームで動いているプログラムを置き換えるべきではないだろう。例えば銀行の勘定系システムなどはかなり慎重に置き換えないといけない。(とはいえ、新生銀行のように積極的にオープン系に移行している企業もあるが。)まずはビジネスの根幹とは関係のない人事、経理などのバックオフィス系システムを置き換えてはどうだろうか。そのようなシステムは多少のダウンタイムは許されるし、安価な市販のパッケージソフトウェアや、極端な例ではOrangeHRMのようなオープンソースソフトウェアもある。わざわざメインフレームで専用のソフトウェアを動かす価値はないのである。とても特殊な人事を行っている場合などは既存のパッケージソフトウェアの機能では置き換えられないということも考えられるが、その人事プロセスが会社によほどメリットをもたらしていることでなければプロセス自体を変更または廃止してしまうべきである。
リエンジニアリング方式やリライト方式の場合、Java、Python、Rubyなど生産性の高い言語を利用するといい。特に、ユーザーインターフェースをWeb GUIにする場合には各種フレームワークを利用することで開発効率が格段に高まることだろう。(特にRuby On Railsは素晴らしい!)メインフレーム向けにプログラムを構築した時とは格段に早くシステムが仕上がるはずだ。SIerに作業を依頼する場合には、既存のメインフレーム系の業者とはスッパリ縁を切った方が良い。(メインフレームに固執するだろうし、オープン系システムでの開発経験も少ないことが多いからだ。)そしてオープン系のシステムにおいて実績のある業者を選定するべきである。また、市販のERPパッケージなどを採用したり、セールスフォースのようなSaaSプラットフォームを利用することで安価に・素早くシステムを構築できる場合は、そのような対処も視野に入れるといいだろう。
レガシーマイグレーションを円滑に行えるかどうかは、如何にビジネスプロセス、アプリケーション仕様、QAテストケースなどのドキュメントが充実しているかということに掛かっている。そのようなドキュメントがない場合、ビジネスプロセスの洗い出しおよび見直しから入る必要がある。逆にいうと、普段からしっかりその辺を管理出来ているならば、レガシーマイグレーションは怖いものではない。しかししっかり管理出来ていないなら、まずはビジネスプロセスの見直しに関してコンサルティングサービスを受けるといいだろう。コンサルティングサービスは副次的なメリットもある。もし、現時点で書類に依存したプロセス(書類にハンコという無意味かつ無駄な)になっているのであれば、ついでにペーパーレス化を進めてコスト削減効果を高めることもできるだろう。同様に、潜在的にコストが掛かっているプロセスを見直すには、今は良い時期なのかも知れない。
また、レガシーマイグレーションを考えているなら、これ以上メインフレーム用のプログラムをゼッタイに増やさないことである。新しいプログラムをオープン系システム上で構築して、メインフレームへの依存度を減らしていき、どこかのタイミングでマイグレーションしてしまうというシナリオである。その過程において、オープン系システムに強いSIerを見極めるといいだろう。
日本男児たるもの責任は自分で負うものである!!
オープン系のシステムに乗り換えることでIT部門が管理しないといけないリスクは多少増えるだろう。しかしリスクのない仕事なんてこの世には存在しないし、この不況下においてリスク負わない人員を抱えておけるほど企業は裕福ではないはずだ。至れり尽くせりのメインフレームは捨て去るのは今しかない!!今は江戸時代とは違って失敗したら切腹!!とはならないので安心してリスクに立ち向かえる時代なのである。オトコなら自分の信じた技術で勝負しようではないか。
2 コメント:
VAX/Alpha(DEC)には下記のようなマイグレーション方法があります。ご参考になれば幸いです。
http://sribean.co.jp/vaxmigration/migration_panfu.pdf
http://sribean.co.jp/vaxmigration/vaxmigration.html
yokohamasogoさん、
参考情報ありがとうございます。これはいわゆるリホスト方式ですね。レガシーは何もメインフレームだけではないということですね。
過去に作成したプログラム資産は遺産と化してしまいますが、そういった遺産と戦うのはITに携わる者の使命かも知れません。
コメントを投稿