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

　前編では，日立製作所 桐越氏と日本IBMシステムズ・エンジニアリング 大嶽氏の主な発言をまとめた。

日立製作所 桐越信一氏の主な発言内容



　「変化に強い」システムを作成するために，業務アプリケーション部分では，変化することを見越してコンポーネント・ベースで設計を進めます。モデリングしてコンポーネントを抽出し，それを組み立てて業務システムを作っていくわけです。そのコンポーネントは4層に分かれており，下から順番に「SOA基盤」「システム共通コンポーネント」「業務共通コンポーネント」「業務固有ロジック」となります。

　要件定義から業務共通の機能部分を見付け出し，それを「業務共通コンポーネント」として抽出します。事業所によってルールが違うといったものは「業務固有ロジック」として，Javaで説明すると，同じコンポーネントになりますがクラス継承やメソッドを追加することで構成します。業務アプリケーションより下位のレイヤーは「システム共通コンポーネント」として実装し，そこには業務ロジックは含みません。つまり，業務共通コンポーネントは，複数のシステム共通コンポーネントを組み合わせ，さらに，業務ロジックを含んだものになります。

　業務ルールに変化があった場合は「業務共通コンポーネント」や「業務固有ロジック」のみを，業務アプリケーションより下位のレイヤーが変化した場合は「システム共通コンポーネント」のみを修正すればよいので，修正範囲を局所化でき，変化に対応しやすくなります。局所化できることがポイントです。

　システム間をつないでいく部分が「SOA基盤」です。ここで「SOA」という言葉を使っていますが，このレイヤーは新しく作ったものではなく，以前（SOAという言葉が出てくる前）からあるものです。少し話がそれますが，SOAは目新しいものではないと思っています。以前から，業務ロジックのなかにプロセス制御的なものは含まず，EAIとかワークフローとかを用いてつなぎ合わせる構造にしていました。そのつなぎ合わせる部分が「SOA基盤」で，コンセプトとしては以前のEAIやワークフローと基本的には同じものでしょう。

　ただ，違いはあります。以前はCORBAでガリガリとEAI的なものを手作りしていましたが，最近では敷居が低く容易に使えるようになりました。WebサービスやWSDLなどの標準がしっかりあり，製品に多くの（システムと直接つなげる）アダプタが備わっているので，例えばメッセージ・キューイングソフトなどとの連携も容易です。SOAのコンセプトは以前からあるものですが，標準化や道具立ての充実で実現が容易になった。それがSOAだと見ています。

日本IBMシステムズ・エンジニアリング　大嶽隆児氏の主な発言内容




　何が変化するのかを考えてみました。まず，企業買収，J-SOX法などの法制，企業自体の業務改革，新商品を出して新しい販売チャネルを開拓するといった，ビジネスの変化が大きいです。また，ビジネスはテクノロジに依存しており，テクノロジ自体が変わることもあります。変化はシステムへの要求になります。機能の要求や高い品質の要求，コスト要求になって表れてきます。これらの5W1H（What：何が，Why：なぜ，Who：誰が，When：いつ，Where：どこで，How：どの程度）を押さえることが，システムのアーキテクチャを考えるうえで大事になります。ITアーキテクトは，こうした変化をいかに想定内にするかが求められます。

　従来のITアーキテクチャでは，変化に伴って新しいシステムを作ると，既存システムのどこかにつなぐことになります。アダプタみたいなものでシステムをつないでも，数が多くなると複雑になってきます。システムをつなぎ合わせるとき，既存システムの技術に合わせることになりますので，組み合わせがいろいろで個別最適になりやすいです。古いものは塩漬けにされてしまうとか，どこかが変わるとほかに影響するといったことが起きていました。

　そうしたシステム構成においての大きな問題は，ビジネス・ルールはどこに埋め込まれているのか，エンティティはどこか，あの業務ロジックがどこにあるのか――などが簡単には分からないことです。変わる部分というのは例えば業務ロジックなどですが，それがどこにあるのか分からないから探すのに時間がかかり，簡単には変えられなくなってしまいます。それぞれのシステムはそれぞれの担当者が一生懸命サポートしていますが，それは暗黙知になってしまいがちで，全体で見ると自社の業務プロセスがどうなっているのか分からなくなってしまいます。

　そうした状況を改善するために行ってきたことは，アプリケーションとインフラストラクチャを切り離し，フレームワークを導入するといったことです。つまり，できるだけ依存関係を少なくするという考え方です。レイヤー分けを考えたり分散させたりすることで，例えばワークロードが増えたときは「この部分を強化するだけで対応可能」といったことをできるようにしてきました。また，最近出てきたのは，それぞれをサービスという単位で分けるという考え方です。機能を仮想化し，その機能がどこにあるのか分からなくても，公開されているサービスを利用するというものです。

　変化に強いアーキテクチャにするには，ITアーキテクトはシステムを一度分解し，今までと違う分類をすることが求められます。組み合わせを考え直して再統合し，変化に対応できるようにしていきます。分類するときに，共通化できるところ，専門化すべきところを見極めることが大切ですが，そのほか，できるだけ再利用することで早く対応すること，資源を共有して無駄をなくすことも大切です。