協和発酵キリンが描くクラウド時代の情報システム

中山嘉之 - 2009年9月2日(水) 08:00

「適材適所」を可能にするアーキテクチャの全容

新たなコンピューティングスタイルとして、「クラウドコンピューティング」が脚光を浴びている。クラウドの実現形態の1つである「SaaS（ソフトウェア・アズ・ア・サービス）」によるＩＴインフラの維持管理コスト抑制など、ユーザー企業がクラウドに寄せる期待は大きい。半面、戦略なきクラウド化は業務処理の自動化を妨げるといった弊害を引き起こしかねない。企業はいかにしてSaaSを活用し、クラウドの利点を享受すべきか。協和発酵キリンの考え方を解説する。

社内におけるコンピューティングスタイルの歴史を振り返ると、大きく3つの時代に分けられる。1970年代〜80年代後半まで主流だったメインフレームによる集中処理、80年代中盤〜2000年頃までのミニコンからWindowsサーバーに至る分散処理、そして2000年〜今日に至るオープンシステムの集中処理だ。エミュレーションからクライアント/サーバー（C/S）、Webへと変化を遂げてきた（図1）。

図1　ネットワークコンピューティングの歴史（図をクリックで拡大）

こうしたスタイルの変化はネットワークの高速化がもたらしたと言っても過言ではない。この30年間でデータ通信速度は9600bpsから100Mbpsに、約1万倍に速まった。今も変化は留まるところを知らず、第4のコンピューティングスタイル、すなわち「クラウドコンピューティング」の時代がすぐそこまできている。

クラウドについて考える前に、情報処理の目的を今一度確認しておきたい。70年代、ユーザー企業は社内の業務処理を自動化するためにメインフレームを導入してきた。90年代になるとパソコンやWindowsが登場してオープン化が進み、ユーザーインタフェースこそ変化したが、「業務処理を自動化する」という目的は大きく変わっていない。

突き詰めて考えると、ユーザー企業にとって情報処理の最終的な目的は「業務を遂行すること」なのである。業務アプリケーションを実行する上で必要なインフラの維持管理ではない。まして、OSのバージョンアップやウイルスの駆除は、ユーザー企業に直接的な恩恵をもたらすものでなない。

ところが、である。現実にはオープン化によって複雑化したインフラを維持管理するためにTCO（Total Cost of Ownership）が嵩んでいる。分散したサーバーや各種パッケージ、データの増加に伴い大容量化するストレージの維持管理や可用性・信頼性を高める対策コストなどが膨らむからだ。

このような状況下でクラウドが登場し、脚光を浴びつつあるのは必然と言っても良いだろう。ハードウェアやミドルウェア、アプリケーションなどの資産をオフバランス（ベンダー資産）化して、業務に注力できるようにするためである。

アプリの独自性や業務特性などSaaS化の判断基準を設定

クラウドと一口にいっても、その提供・利用には複数の形態が存在する。中でも高いコスト効果を生むと期待されているのがSaaS（ソフトウェア・アズ・ア・サービス）だ。SaaSは最終的にBPO（Business Process Outsource＝業務のアウトソース）に発展させていける可能性を秘めている。

SaaS化のアプローチはいくつか考えられる。最初から市販のSaaSを導入するケースもあれば、現在利用しているパッケージのベンダーがSaaSの提供を始めるタイミングで切り替える手もある。

では、実際に複数存在する企業内システムのどこにSaaSを適用していったらよいのか。ユーザー企業は何らかの視点に基づいて、優先順位を判断していく必要がある。以下は、視点の一例だ。

(1)企業の独自性が少ないシステムか？
(2)コア業務ではなくノンコアな業務か？
(3)他システムとのインタフェースが多くないか？

(1)は「汎用性の高いシステムかどうか」といった視点。言い換えると、SaaSと自社システムとの間でセマンティクスギャップ（データの意味の微妙な喰い違い）の問題が生じないかということだ。現状の企業内システムにおいてもセマンティクスギャップは散見される。SaaSを適用していくようになると、この問題はさらに複雑化するのは容易に想像できる。しかし、独自性が少ないシステムであれば、この点は大きな問題になりにくい。

(2)は主にリスク管理の視点である。企業にとってのコア業務は、運用継続性や情報セキュリティなどの面から、やはり慎重に外出しする必要がある。

また、一般にコア業務の管理内容と項目はノンコアの業務に比べてきめ細かくて幅広い。そのため汎用的なSaaSのサービスを活用するとアドオンが多発する可能性が高まる。

(3)は、情報システム部門でなければ見落としがちな視点だ。業務目的に合致したSaaSを導入できたとしても、他システムとのインタフェースが多ければ、システム間の“つなぎ”が分断されて人手の連携作業が増えることにつながる（図2）。

図2　計画性のないSaaS利用の弊害（図をクリックで拡大）

もっとも、今では他システムと連携しないスタンドアロン型のシステムは極めて少なく、(3)の課題は避けて通れない。したがってSaaSを導入する際、「いかに効率良く他システムとインタフェースするか」を考えることは極めて重要なポイントになる。

ユーザー企業はこうした多面的な視点から続々登場するSaaSを見極め、独自性の高いシステムや企業のコア業務など一部を除き、自社運用している業務システムを順次外出ししていくことになるだろう。そのスピードは、SaaS市場が活性化してサービス料金がユーザー企業の期待に見合う水準に落ち着くかどうかにかかっている。

適材適所のシステムを支えるトランザクションHUB

ところで、効率良いインタフェースとは何か。この問いに漠然と答えるなら、「継ぎはぎだらけで何カ所にも散らばった非効率なインタフェース」に反して、「できるだけ1カ所に集中化して管理性を高めたインタフェース」となろう。この「複数のインタフェースの一極集中化」の具体像が、当社で現在構築中の「トランザクションHUB（TR-HUB）」である。

TR-HUBは、システムの保守性を格段に向上させるための仕組みだ。異なるトランザクションデータをできる限り汎化して、更新プロセスや参照プロセスの部品を共有できるようにする。

もともと当社は、「画一的なERPをビッグバン導入するのではなく、各業務に見合ったパッケージ製品（もしくは手組み）を適材適所に導入する」というアーキテクチャ・ポリシーを設けている。TR-HUBは、このポリシーを実現する1つの手段である。サプライチェーンマネジメント（SCM）や生産管理、販売管理といった複数の基幹系システムに異なるパッケージ製品を適用し、これを並行開発するためのシステムだ（図3）。

図3　システム全体アーキテクチャ（図をクリックで拡大）

TR-HUBの最大の特徴は、TR-HUB上のデータウェアハウス（TR-DWH）を介して必要なデータを蓄積・交換する疎結合インタフェースにある。データ発生源となるシステムは、あらかじめ決められたフォーマットでデータをTR-DWHに書き出す。そしてデータ再利用側のシステムは、必要なタイミングで必要な条件を指定してデータを取得する。

ポイントは、汎用的なデータを非同期で取得できるようにすること。データの再利用性を極限まで高めるために、TR-DWHに格納するレコードは可能な限り明細データとし、更新は基本的にインサートのみとすることも肝心である。

TR-HUBの活用によりSaaSへ“ゆるやか”に移行

各業務に見合ったパッケージを適材適所に導入する以外にも、TR-HUBの役割がある。それは、レガシーシステムからのゆるやかな移行だ。TR-HUBを使えば、システム移行が完了するまで何カ月でもレガシーシステムを運用していける。

この特徴は、前述したSaaS化に伴うシステム要件の「効率良いインタフェース」としても十分に威力を発揮すると見ている。あるシステムをSaaS化してインターネットの外に出したり、ネットワークを社内LANからインターネットVPNに切り替えたりしても、TR-HUBで接続すればシステム全体のアーキテクチャには何の影響も及ぼさないからである。

ここでTR-HUBのメリットを整理しておこう。第1に、TR-HUBに接続する各種業務サービスの取り換えが容易になる。SaaSを利用する場合、サービスベンダーと運命共同体になるリスクを回避できる。

第2に、TR-HUBで集中して複数のシステムを管理できる。管理対象は複数システムで共通のプロセスを実行する各種コンポーネントなどである。TR-HUBの堅牢性を高めれば、運用トラブルの防止などリスク管理面での効果も期待できる。

第3に、TR-HUBは個別の業務やシステムに依存しない。このためデータのコード体系やフォーマットなど、異なるシステム間で生じがちなシンタックスとセマンティックスのギャップを解消できる。

こうしたメリットがある一方で、TR-HUBにはデメリットも存在する。その1つとして、密結合を必要とするリアルタイム系システムには不向きという点が挙げられる。加えて、一極集中の仕組みになっているため、TR-HUBそのものの改修・変更が他システムに与える影響が必然的に大きくなる。

MDM基盤を整備しマスターの整合性を確保

企業内システムをSaaS化する際に忘れてはならないのが、SaaSとのマスターデータ連携だ。TR-HUBの品質を保証するためには、SaaSと企業内システムのマスターデータの整合性が取れていることが必須要件になる。

そのために当社で運用しているのが、複数のシステム間でマスターデータを連携させる「マスターHUB」である。今で言うMDM（Master Data Management）の基盤そのものだ。当社ではTR-HUBとマスターHUBを合わせて、「エンタープライズHUB」と呼んでいる。

マスターHUBでは組織や取引先、製品といった全社共通マスターのメンテナンスを集中させて、各周辺システムへレプリケーションする。現在約60のシステムにクリーンなマスターデータを送り込んでいる。

当社にとってマスターHUBは決して新しい仕組みではない。メインフレームからオープン系にプラットフォームを移行しつつあった1990年代後半に、ホスト上で管理していた各種マスターデータをオープン環境に持ち込むために第1版を構築した（図4）。言うなれば“枯れた”仕組みだが、今後SaaSが本格化した際にもマスターHUBはSaaSへのマスター送信元として機能し、マスターデータの整合性を取るための基盤になり得る。

図4　マスターHUB（MDM）環境（図をクリックで拡大）

システムの“要”
ハブのBCP対策が不可欠に

業務システムのSaaS化が進むと、いくつかの変化が起こる。その1つが社内インフラのあり方である。例えば、業務アプリケーション用サーバーがクラウドの向こう側（インターネット越え）に置かれることで、システムのユーザー（クライアント）は社内のバックボーンネットワークを利用する必要がなくなり、高速インターネット回線で直接接続することになる。

一方で、SaaSベンダーのシステムとエンタープライズHUBを接続するバックボーン回線は、より一層の大容量化と高速化が求められる（図5）。同時に、システムの“要”となるTR-HUBとマスターHUBについて、リスク管理を今以上に徹底する必要がある。具体的には、BCP（事業継続計画）の観点からサーバーのフォールトトラレント化や、ディザスタリカバリサイトへのデータの自動バックアップなどの対策を施すことが不可欠になる。

図5　SaaS化と社内インフラ（図をクリックで拡大）

SaaSの推進で変化するシステム部のミッション

もう1つの変化は、情報システム部門のミッションだ。SaaS化はアウトソースの領域を広げていくことにほかならない。そのためSaaS化を推進すれば、情報システム部門の仕事は自ずと様変わりする。

図6は基幹系システムのSaaS化のイメージである。当社は、これが企業内システムの最終形の1つだと考えている。このとき企業が自社で管理すべきは、エンタープライズHUBに格納された共通マスターとTR-DWHのデータ、そしてデータの内容を解釈するためのメタデータを格納した「リポジトリ」である。このことを前提に、これからの情報システム部門の仕事の変化をまとめると次のようになる。

図6　基幹系システムのSaaS化（図をクリックで拡大）

(1)ハード/OS/ミドルウェアといったインフラの企画、管理が縮小する。これにより人的資源配分はより業務アプリケーションに集中させることとなる。

(2)業務アプリケーションとしての要件だけがサービス選定の視点となる。SaaSの発展でサービスの選択肢が増加して調達業務の重要度が増し、“目利き”のウェートが重くなる。

(3)システム保守業務の対象はエンタープライズHUBが中心になり、保守の目的はシステム間インタフェースの整合性維持となる。

(4)メタデータ（データ自身の説明）の知識が今まで以上に必要になる。当然のことながら、業務の内容やプロセスを正しく理解する能力が欠かせない。

このようにSaaSの本格化によって、情報システム部門のミッションは総じて業務寄りにシフトする。複雑化したインフラの維持管理に費やしてきた労力が少なくなることを考えれば、これは喜ばしいことである。

しかし、一方で新たな課題が浮上してくることも事実だ。特に、サービスの目利きやメタデータの効果的な管理を実現する上で、業務を抽象化して分析・把握する能力などSEのスキルセットの見直しが急務と考えている。そこで当社は現在、モデリング言語「UML（Unified Modeling Language）」の教育を実施したり、部内ポータルにモデルを共有する「モデル図書館」と呼ぶコーナーを企画したりして、モデル中心の業務の実現に向けてSEのスキル向上を図っている。