PR

 「変化に強いシステム基盤の条件」と題し,4人のITアーキテクトがそれぞれの考えを語った。パネリストは,日立製作所 ソフトウェア事業部 ネットワークソフトウェア本部 第2ネットワークソフト設計部 チーフアーキテクト 桐越信一氏,日本IBMシステムズ・エンジニアリング アーキテクチャー・イノベイティブ・ソリューション ICP-エグゼクティブITA 大嶽隆児氏,NEC ニューソリューション開発本部 プラットフォームアーキテクチャ企画グループ グループマネージャー 小池和雄氏,富士通 インフラサービス事業本部 プロジェクト統括部長 兼 コーポレートIT推進部 主席部長(システム技術担当) シニアマネージングITアーキテクト(情報システム) 成瀬泰生氏の4人。

 後編では,NEC 小池氏,富士通 成瀬氏の主な発言をまとめた。

NEC 小池和雄氏の主な発言内容



 変化に強いシステム基盤の技術として仮想化機能を考えた場合,四つのポイントがあると思います。システムの構造を上位レイヤーと下位レイヤーに分けて話しますと,(1)一つの下位レイヤーで複数の上位レイヤーを実装できるので実装効率を向上させることができます,(2)複数の下位レイヤーをまとめて一つに見せることができるので,性能や可用性を向上させることができます,(3)上位と下位を自由に配置できるので,変更に対する柔軟性を高めることができます,(4)上位と下位を切り離すことができ,独立して実装できるので古いものと新しいものを混在できます。これは投資効率を向上させることになります。仮想化のこういったポイントが,変化への強さを生み出しているわけです。

 今は仮想化といえばマシン(主にサーバー機)の仮想化を中心に考えられていますが,仮想化はマシンだけでなく,ネットワークもストレージも仮想化できます。仮想化にはいろいろな観点がありますので,整理して全体としてどう考えるかが重要なポイントになります。全体として考えるなかで,技術を単純に適用するだけでなく,どうやって作るのか,どう運用していくのかといったことも考えます。さらに言えば,エンジニアは自分の作ることだけを考えがちですが,周りを巻き込んで,なぜシステム基盤の変革が必要なのかを説得するといったことも求められます。

 システムのアーキテクチャを確立するのはITアーキテクトです。ITシステムの要件を出す人は技術的なことを知らないことが多いので,本当に実現できるのかどうか分からず,たいていあいまいなことを言います。そうした要件をシステムとしてどう実現するか,つまり,どんなコンポーネント構造で実現するかを考え,ITで実現できるものにしていきます。システムとして,上位レイヤーから下位レイヤーまで考えて実現できるものにしていくこと。それがITアーキテクトの仕事です。

 仮想化したシステム基盤をどうやって運用していくかにおいて,考えるべきことがあります。従来は単体のサーバーを見ればシステムの状況を把握できましたが,仮想化されると内部コンポーネントが複雑になります。仮想化の目的の一つは変化に柔軟に対応できるようにすることで,柔軟にすれば,基盤構成はどんどんと変わっていくことになります。そうなれば,ますます運用管理は難しくなります。だから,統合的な運用管理の仕組みが欠かせません。マシンなどのコンポーネント単位で標準化を図り,同時に運用の標準化を図ることがポイントです。


富士通 成瀬泰生氏の主な発言



 変化をどう見るかですが,EA(エンタープライズ・アーキテクチャ)を手掛かりにしたいと思います。EAには,「BA(ビジネス・アーキテクチャ)」「DA(データ・アーキテクチャ)」「AA(アプリケーション・アーキテクチャ)」「TA(テクノロジ・アーキテクチャ)」の4層あります。ビジネス(BA)の変化でいうと企業の合併。データ(DA)の変化では,例えば「こんな新商品を売りたい」といったデータ種類の追加。アプリケーション(AA)の変化では,「今度はインターネットを介して販売したい」といったチャネルや売り方の変化。テクノロジ(TA)の変化では,Windows,Linuxといった技術の変化があります。こうした4層に分けて変化をとらえ,それぞれの層でシステムの柔軟性を考えなければなりません。具体的には,データの領域では「概念データモデル」や「マスター統合」。アプリケーション領域では「SOA」「SaaS」「Web2.0」といったものになります。

 システム基盤を考えるとき,利用者を意識することは重要です。Webシステムで不特定多数の利用者が使うなら,実際どれくらい使われるか分からないのでスケールアウトの構成が必要になります。それに対して社内でのみ使うなら,「このスペックのサーバーで大丈夫でしょう」といったことを判断できます。しかし,システムは生き物ですので,どうやって維持していくのかを考えなければなりません。そのためには標準を決め,システムを導入するところから標準を守ることが大事です。標準を守ればシステムの“スパゲッティ化”を防ぐことができます。それは,変化に対応しやすくなることを意味します。

 国内の大企業で基幹システムの再構築が進められていますが,そうした企業ではほとんどのケースでSOAを考えています。SOAという言葉を使うかどうかは別にして,「こんな大きなかたまりでシステムを再構築するのは大変である」と言っています。例えば当社の受発注システムも再構築を進めていますが,受発注システムの周りに70くらいのシステムがあり,インタフェース数は1300にも上ります。そうなっていると,どこか1カ所を修正すれば,どこでどんな影響があるか分からないのが実情です。そうしたケースでは一般論として,大きなかたまりでシステムを再構築せざるを得なくなってしまいます。

 サブシステムに分割しておいて,10年くらいかけてサブシステム単位で順番に新しくしていく,そのようなことができたら理想ではないかと思っています。そのためには,切り出しやすく,切り出したシステム単位で再構築しやすくなっていないといけません。そうしたことを考えているシステム再構築の現場では,SOA的な発想,つまり,バスを介してサービス単位でシステム間を連携するという考え方で設計を進めています。

 SOAでは内部に「バス」を作る構造にします。システム間のやりとりはバスを介して行うので,バスを見ておけばその企業のビジネスの活動が分かるわけです。これは内部統制の観点で重要で,バスから得られるビジネス活動の履歴を,「企業総活動記録」という名前をつけて取るというアイデアがあります。