せっかく構築したシステムは、できるだけ長く使い続けたい。同じ形で使うだけでなく、別のシステムの一部として使う、複数のシステムから呼び出す共通機能にするなど、姿かたちを自由に変えて利用したい――。こんなニーズにこたえる究極のシステム延命術がSOA（サービス指向アーキテクチャ）である。SOAへの一歩を踏み出したユーザー企業15社への取材を通じて、システム延命を目指す取り組みの実態を探る。
|
本記事は日経コンピュータ2004年8月23日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバーをご利用ください。1200万ステップ、300億円。国内最大級のマスター・トラスティ、日本トラスティ・サービス信託銀行が抱える基幹系システムの規模と、それらを全面再構築した場合のコスト試算である。1200万ステップの内訳は、勘定系がPL/Iで650万ステップ、情報系がCOBOLで550万ステップ。日本IBM製メインフレームで稼働する。
「基幹系の全面再構築？ 現時点ではあり得ない」。日本トラスティ・サービス信託銀行のシステム子会社、日本トラスティ情報システムの益田美貴システム企画部長は言い切る。「300億円もの開発費用はとても出せないし、時間もノウハウもない。それどころか、万一のリスクを考え、システムに手を加えることを極力避けている。基幹系システムはできるだけ長生きさせたい」。実際、同行では基幹系システムの勘定系を稼働させた1985年以来、情報系を98年に追加した以外に大きな変更は施していない。
では、基幹系に新機能を追加する必要が生じた場合はどうするのか。日本トラスティ・サービス信託銀行は基幹系そのものを修整するのではなく、フロント側に別システムを作るという基本方針を採る。「仮に、フロント側に追加したシステム構築に30億円かかったとしても、それで基幹系があと10年生き延びれば、追加開発費のモトは十分取れる」（益田部長）との考えからだ。同行は来年中の完了を目指し、フロント・システムを約3億円かけて再構築している最中である。
変化に耐えられる延命術が必要に
システムを新たに構築したら、ある一定期間、そのシステムを使い続けるのが普通だ。小規模なWebシステムなら数年かもしれないし、全社的な基幹システムなら短くても5年、日本トラスティ・サービス信託銀行のように15年を超えて使う場合もある。
そのシステムは、やがて“寿命”を迎える。想定した年数で寿命に達することもあれば、ビジネスモデルや利用環境の変更により、予定よりも早く寿命を迎えるケースもある。多くの場合、寿命を迎えたシステムは廃棄され、ユーザー企業は次のシステムを構築する。通常はこうした作業を繰り返していく。
どれだけシステムをうまく作ろうが、いつかは寿命が来る。問題は、その寿命が想定よりも早く訪れる傾向にあることだ。「システムに求められる状況は、いつどう変わるか全く読めない」。ソニー生命保険の後藤聖央情報システム2部IS企画2課主事は、ビジネスの変化が激しく、それに呼応してシステムへの要求が絶えず変わる現状を指摘する。
ユーザー企業は、変化にシステムが耐えられるようにさまざまな手を打っている。それでも、システムの再構築を強いられるケースは少なくない。
システムの寿命が尽きたからと言って、システムを毎回新たに構築するのはコストがかかりすぎる。同じシステムを長く使えるなら、それに越したことはない。システムの寿命を延ばし、かつビジネスの変化に耐えられるようにするうまい方法はないだろうか。
この難問を解く解決策が、ここに来て急浮上している。SOA（サービス指向アーキテクチャ）である。
機能の呼び出し方法を共通化
SOAとは何かを説明する前に、冒頭で紹介した日本トラスティ・サービス信託銀行のシステム再構築の様子をもう少し詳しく説明しよう。
 |
| 図1●日本トラスティ・サービス信託銀行が選択したメインフレームの延命策。アプリケーションをサービスとして利用可能にした |
この形でシステムを延命すると、システム連携が複雑になってしまう恐れがある。「フロント・アプリケーションAとメインフレームの基幹系アプリケーション」、「フロントBと基幹系」など、フロント側とメインフレーム側を連携させたり、管理するための手間が増えるからである。
しかし同行の場合は、いくらフロント・アプリケーションが増えても、システム連携の部分は複雑化しない。基幹系の持つ機能を呼び出すインタフェースを共通化しているからだ。どのフロント・アプリケーションも、メインフレームで動く基幹系の機能を同じ要領で呼び出すことができる。
インタフェースを共通化するために、同行が使っているのは、日本IBMの「Host Publisher」という接続ソフト。Host Publisherは、IBM製メインフレームの画面をWebブラウザで参照できるようにHTML形式に変換する。メインフレーム側は一切変更する必要がない。このソフトを使えば、UNIX側で動くアプリケーションは、Host Publisherの裏側でどのような処理が行われているかを意識しなくてすむ。
人間同士のやり取りに近い
Host Publisherが実行しているのは、メインフレーム側で動く基幹系システムの機能を「サービス」として利用可能にしたことにほかならない。
ここでいうサービスとは「システムが提供してくれること」を指す（図2[拡大表示]）。例えば、在庫の検索、販促メールの送信、売上高の算出といったものだ。同時にそれらを実現するソフトウエアの単位もサービスと呼ぶ。
 |
| 図2●システムをサービス化すると、呼び出す側は処理のやり方を意識しないですむ。人間同士のやり取りに似ている |
ポイントは、サービスを利用する側は「相手がどんなハードウエアやOS、開発言語を使っているか」、「プログラムはどのような処理を行っているか」といったシステムの技術要素を意識する必要がないことだ。「サービスが何をしてくれるか」だけを気にすればよい。人間が頼みごとをする際に、「頼まれた相手がどんな手段をとるかは関知しない。とにかくやってくれればよい」というのに似ている。システムをサービスとして扱えるようにすることを「サービス化」という。
サービスで唯一決めているのは、サービスをどんな形で呼び出し、結果をどのように受け取るかといった出入り口の仕様である。これをインタフェースと呼ぶ。人間で言えば、会話に日本語を使うのか英語を使うのか、使える単語は何か、といったことを決めておくことに相当する。先ほどの説明を言い換えると、サービスを呼び出す側はサービスがどのように実装されているかを気にする必要はなく、インタフェースさえ意識すればよい。
以上の概念は、オブジェクト指向に基づくソフト部品（コンポーネント）あるいは分散オブジェクト技術と同じである。SOAにおけるサービスは、コンポーネントと比べると「大きさ（粒度）を自由に設定できる」柔軟さを備える点が大きく違う。
コンポーネントも大きさを変えられるが、部品化の対象となるのは基本的に1種類のアプリケーションだ。これに対しサービスの場合は、アプリケーションの一部、アプリケーションすべて、さらに複数のアプリケーションの組み合わせのいずれも、まとめて一つのサービスとして扱うことができる。
しかも、一つのサービスを構成する複数のアプリケーションは必ずしも同じハードウエアで動く必要はない。異なるハードで動く複数のアプリケーションをまとめて、一つのサービスとして利用することも可能である。
WebサービスでSOAの理想に近づく
 |
| 図3●システムをサービスの集合ととらえる考え方をサービス指向アーキテクチャ（SOA）と呼ぶ |
SOAに基づくシステムでは、15年前に構築したメインフレームのアプリケーションも、構築したばかりのJavaアプリケーションも、同じ仕様に基づくインタフェースを持つサービスとして実現し、連携して利用できる。サービスを取捨選択したり、サービスの大きさを変えたりすることで、ビジネスの要請に応じてシステム全体の構成を柔軟に変えることも可能だ。
インターネットの標準技術を使ってシステムをサービス化する技術であるWebサービスの普及により、SOAはより現実味を帯びてきた。Webサービスを利用すると、通信プロトコル仕様のSOAPをはじめとする標準技術が使えるのでベンダーに依存しない、インターネットを使うのでシステム連携の幅が広がるといった利点がある（図4[拡大表示]）。日本トラスティ・サービス信託銀行が利用しているHost Publisherも、Webサービスの技術を採用している。
 |
| 図4●WebサービスはSOAを実現する本命技術である |
実際には、SOAの概念よりもWebサービスのほうが先に注目された。SOAが脚光を浴び始めたのは昨年からで、まだベンダー主導の色が濃い。これに対し、Webサービスは登場してから3、4年が経過している。Webサービスの登場時にぼんやりと描いていた青写真を体系化した結果がSOAであると言えるだろう。
ただし、全面的にシステムをSOAの考え方で作るのは容易でない。特にWebサービスで実現するとなると、セキュリティや処理性能など多くの問題を解決しなければならない。そもそも、すべてのシステムをSOAの形で実現する必要はない。ネットワークを介して他のシステムと連動させたり、ビジネスの変化にすぐシステムを対応させる必要がなければ、SOAを意識しなくても現時点で特に問題はない。
しかし近い将来、企業の規模を問わず大多数の企業が「システムの柔軟な延命術」の必要性を自覚するはずだ。しかも、SOAは決して遠い未来の話ではない。すでにWebサービスを導入したユーザー企業は、みずから感づいているかどうかはさておき、間違いなくSOA実現への第一歩を踏み出している。システムを効果的に延命させることで、システム資産を最大限に生かす有力な選択肢として、WebサービスおよびSOAに今から目を向けておいても決して損はしないはずだ。SOAを「ベンダーの単なる宣伝文句」と軽視してはならない。
続きは日経コンピュータ2004年8月23日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
