アーキテクトはコンポーネントをうまく使う：ITアーキテクトを探して 第2章（1）

IPA（独立行政法人 情報処理推進機構）のITアーキテクトコミュニティではアーキテクチャのメタモデルの作成をはじめとした基盤作りに力を注いでいる。このような“大枠の整備”と並行して、現場のエンジニアは、ITアーキテクトとして何をどうすれば現場の問題点解消に貢献できるかを懸命に考えている。このような状況の下、本連載「ITアーキテクトを探して」も、ITアーキテクトの定義付けというレベル（第1章）から、ITアーキテクトが必要とする実践的な知恵を模索する第2章へと内容を刷新する。

» 2006年09月01日 12時00分 公開
[岩崎史絵（トレッフェ），＠IT]

　今日、エンタープライズシステムには「変化対応」「全体最適」「再利用性」が求められている。ITアーキテクトは、これらの要求に応えるため、どのような考え方でシステム設計に臨めばいいのか。そのカギとなるのが「コンポーネントベース開発」だ。

　ITアーキテクトに求められるスキルとは何か。書籍や雑誌の内容を総合すると下記の表のような形になる。これらすべてを1人のITアーキテクトが担当するのではなく、おのおのの実績や知識、スキルに応じて範囲を選択するのが一般的なスタイルだ。

分野 内容
システム設計 アーキテクチャ設計
モデリング／デザイン
要件定義
技術 技術評価／選択／適用
技術支援
開発 プロジェクトマネジメント
開発方法論の評価／選択／適用
総合 ファシリテーション（対顧客や他ベンダとの調整も含む）
ネゴシエーション（対顧客や他ベンダとの折衝も含む）
表 ITアーキテクトに求められるスキル

　もちろん、各項目の知識やスキルは大本でつながっているので、例えばファシリテーションやネゴシエーション能力がなければプロジェクトはマネジメントできないし、最適な開発方法論を適用するには、当然技術知識が必要になる。足りない知識やスキルは実践で身に付けるか、または講習やセミナーを受けて勉強するなどして、ITアーキテクトとしてのスキルを磨いていくのだ。

　この表に挙げたもののうち、特に実績とノウハウが要求されるのが「システム設計」と「総合」分野だろう。「技術」や「開発」も当然ノウハウが必要だが、この分野に関していえば、SI企業の多くが事例をデータベース化し、ノウハウを共有できるようにしている。そういう意味からいえば、ファシリテーションやネゴシエーションは、個人の資質やアイデアとも関係する分野であり、なかなか汎用的な知識となりにくい。

　一方「システム設計」は、ある程度データベース化されているとはいえ、やはり最終的には個人のスキルや力量、コミュニケーション力に還元されることも少なくはない。ITアーキテクトのスキルを磨くカギは、「システム設計」と「総合」に懸かっているともいえる。

　以上から、本連載「ITアーキテクトを探して 第2章」では、特にこの2つの分野に注力して、優れたノウハウを追っていくことにしたい。

　第1回は、先日開催された「ITアーキテクト サミット2006 Summer」（主催：IDGジャパン）のセミナー内容を基に「SOAを実現するためのコンポーネントベースのモデリング」を見ていく。

コンポーネント開発指向でSOAアーキテクチャを考える

　現在のシステム開発、特にアプリケーション領域に求められる3要素を挙げるとすれば「変化対応（柔軟性）」「全体最適」「再利用性」となるだろう。もう少しインフラ部分まで深追いすれば、堅牢性や拡張性なども要件に挙がるが、アプリケーションレイヤに限定していえば、「既存資産を再利用して柔軟にビジネス環境に対応でき、業務を全体最適の観点から効率化できるアプリケーション」が求められている。

　こうしたニーズが浮かび上がると同時に登場したのが、SOA（Service Oriented Architecture）という考え方だ。数年前は、懐疑的な見方が多かったSOAだが、ユーザーニーズの台頭に伴い、「変化対応（柔軟性）・全体最適・再利用性」を満たすシステム開発の考え方として定着しつつある。問題は、「どのように設計したら、SOAの利点を生かしたアプリケーションが実現するか」ということだ。

　この問いに対し、日立製作所 ソフトウェア事業部 Java/XMLソリューションセンタ ソリューションビジネス推進部の部長である桐越信一氏は、「事例検証！ SOAを成功させるコンポーネントベースモデリングの極意」と題した講演の中で、「これまで手掛けた事例をベースに考えた結果、これまでオブジェクト指向の世界でいわれていたコンポーネントベースのアプローチから、システムを設計し直すことが有効と分かった」と語る。そもそもコンポーネント自体、当初から再利用性の高い汎用機能を切り出し、複数のアプリケーションで再利用することを目的としており、この考え方とSOAで目指すところは一致するからだ。

　では、どのようにコンポーネントを設計していくか。桐越氏は次の4つのポイントを挙げる。

（1）コンポーネントのレイヤ分け：アプリケーション機能を「汎用性の高いもの」「業務に固有のもの」「1つのまとまった業務処理」と粒度によってレイヤを分けることで、SOAの構造化の一助とする

（2）コンポーネントの各パターンを押さえる：コンポーネントの各パターンについて、どのような構成でどのような処理を行うべきか、それぞれ最適な方法を身に付ける

（3）モデルベースの設計手法を押さえる：ハードウェアやシステム環境に依存せず、最適なコンポーネントモデルを切り出すために、MDA（Model Driven Architecture）による開発アプローチを身に付ける

（4）効果的な開発体制の整備：これは設計とは直接関係ないが、コンポーネントベースの開発を効率的に進めるため、重複開発を防ぐ開発体制や工程の理解が必要となる

コンポーネント開発を成功させる4つのポイント

（1）コンポーネントのレイヤ分け

　コンポーネント開発というと、「粒度をどのように定めるか」が議論されていたが、これはSOAにおけるサービスの切り出し問題とほとんど同じといえる。桐越氏は、「例えばデータの登録や更新といった、どんなアプリケーションにも必要となるシステム機能コンポーネント、次に固有業務ごとに必要となる業務機能コンポーネント、そして最後に、まとまった処理を行うために業務機能を連携させたビジネスコンポーネント」の3つに分類し、SOAのサービスとマッピングさせていく。こうすると、業務機能コンポーネントがSOAでいう“サービス”の単位となる。そして共通部品であるシステム機能コンポーネントは、アプリケーションインフラ部分に切り出すことで、ビジネスコンポーネントが必要に応じて必要な機能をキックできるようになる。桐越氏の過去の実績から見ると、あるアプリケーションでは7割以上がシステム機能コンポーネントで構成されていたそうだ。

　そして「ESB（Enterprise Service Bus）などのミドルウェアを用いて、業務機能コンポーネントを連携させることで、1つの処理体系であるビジネスコンポーネントが生まれる」という。

（2）コンポーネントの各パターン

　桐越氏によると、コンポーネントを再利用するには、3つのパターンがあるという。1つは、コンポーネント内部のクラスも共有し、パラメータや呼び出しオペレーションを変えることで再利用するもの（完全共有型）で、これはまさにシステム機能コンポーネントが該当する。もう1つは、クラスは継承するものの、業務固有の処理を行うために新たにクラスを設けるもの（クラス継承による共有）で、これが業務機能コンポーネントとなる。最後に、共通部分がなく、別コンポーネントとして新しく開発すべき部分だ。コンポーネントをレイヤ分けしたら、次にクラス構成まで分解して構造を設計することで、より再利用性の高いコンポーネントを開発する方法だ。

（3）モデルベースの設計手法

　再利用性の高いコンポーネントを設計する方法、それがMDAとモデリング言語による設計だ。MDAの利点は、システム環境に依存せずにコンポーネントのモデル（Computation-Independent Model：CIM）を設計し、環境決定後にプラットフォームに依存したモデル（Platform-Specific Model：PIM）を構築できること。CIMの設計が優れていれば、それだけ再利用率は高まるし、仮に現在のJ2EEや.NETに変わる環境が登場したとしても、マッピングルールさえ決めておけば開発までの期間を短縮できる。

　そのため、マッピングルールを決定するとともに、UMLを使ってビジネスプロセスからクラス構成までを定義しておくことが必要になる。最近ではビジネスプロセス記述言語として、BPMNも登場しており、ビジネスプロセス実装期間を短縮するのであればBPMNを活用するという手段もある。いずれにせよ、プラットフォームに依存するのではなく、非依存の形でプロセスとモデル、そしてクラス構成までを記述しておくことが有効だ。

（4）開発体制

　モデルと実装の間にはギャップがある。その両者を結び付けるのがITアーキテクトの役割の1つといえるが、数少ないITアーキテクトにすべてその役目を押し付けるのは、実質不可能に近い。そこで、市販のモデル変換プラグインなどを利用し、CIMからPIM、そして実装モデルへと変換する際のルール付けをしておくことで、プロジェクトが円滑に進む。

　同時に、システム機能コンポーネントの設計から着手することで、各アプリケーション共通の処理を二重に開発するリスクを軽減しておくことが重要だ。まとめると、

  • CIM、PIM、実装モデルへの変換ルールを決め、モデル変換プラグインなどに登録しておく
  • 最初にシステム機能コンポーネントの切り出し・開発に着手し、汎用部品の二重開発を防ぐ

といった開発上の工夫が要求されるわけだ。

参考文献
IDGジャパン「ITアーキテクト Vol.1」（2005年1月発行）
日経SYSTEMS 2006年8月号

「ITアーキテクトを探して」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ