SOA適用開発プロセスの体系化 - たこはちの「へのかっぱ」日記

SOA適用開発のプロセスを自分なりに体系化してみた。BPMやSOAの適用開発では、市販本や各ベンダが公開している情報を眺めてみて、以下のように感じた。

　■実装技術や標準を語る部分がほとんどである
　■あまり開発プロセスを明確に提示したものはない
　■標準化が進化過程であり、どう収束するか把握できない
　■各ベンダや製品依存で語られるので用語も不統一
　■範囲も不統一(Webサービス限定か、XPDLなどを包含するかなど)

体系化のアプローチ

このような状況で、以下の方針で体系化を進めることにした。

　(1) 知識(基本事項)と活動(プロセス)の分離
　(2) 原理・原則をベースとした体系化
　(3) 抽象化と共通化

まず、プロセスの構成要素である活動を整理するために、各活動で共通する概念を前提として規定する。活動は目的ベースで抽出し、手段(手法・技法・ツール・ノウハウ)と分離して語る。市販本や各ベンダの公開情報は、手段が分離されていないために活動が分かりにくくなっているように感じる。また、洗練、見直し、最適化といったものが活動として挙げらていたりするが、これらはプロセスの設計上で反復やフィードバックとして考慮すればよいことだ。

SOA適用開発ではいくつかの基本となる原理・原則がある。その原理・原則にもとづいてプロセスが構成されないと非常に理解しにくくなる。戦略モデル、ビジネスモデリング、エンジニアリング、サービス特定手法の4つを取り上げてみた。ビジネスモデリングやサービス特定手法は、手段ともいえるが、SOA適用開発では欠くことのできない原理と言える。

また、体系化は技術やプロセスを抽象化することなので、全ての実装技術や標準を吸収できる枠組みを提供するけれども、個別の実装技術や標準については語らないようにすべきだ。用語も各ベンダや製品に依存しないように簡単な抽象化された用語で統一したい。またスコープもWebサービスに限定しないし、BPEL+XPDLを包含できるように体系化を目指す。

ではまず、ベースとなる原理・原則を考える。

原理原則１：戦略モデル

SOA適用開発は企業の全体最適化を目指すので、企業の戦略をITシステムにブレークダウンする必要がある。そこで、BSCに代表されるような一般的な経営戦略のモデルをベースとする。つまり、戦略は、目標、手段、指標で構成されるものとし、抽出された課題から目標を設定し、その目標に対して手段(施策)を講じる。そして施策には評価指標(KGIやKPI)を明示しておき、施策の実施時にはそれらの指標で目標達成度が評価できるようにしておく。

戦略には何段階かのレベルが必要である。戦略レベルに対する検証と妥当性確認が必要となる。SOA適用開発での戦略レベルには、少なくとも3つある。企業のビジネスゴールレベル、SOAプロジェクトのスコープに限定されるゴールレベル、対象フェーズでの分析スコープに限定されるゴールレベルである。

3番目のレベルは、SOA適用開発が一般に段階的なフェーズ開発となることを前提としている。企業におけるITの成熟度の向上、SOA基盤アーキテクチャの洗練／進化、サービス適用範囲の拡大は段階的に行わなければならない。

原理原則２：ビジネスモデリング

ビジネスモデリングはEAをベースとする。原則、AsIs(現状)、ToBe(理想)、Realize(次期)の3つのモデルを作成する。プロセス上では、ToBeモデル作成の前に戦略モデルの作成が必要であり、現状モデルに対する改善・変革ポイントを記述する。またRealizeモデル作成の前にはAsIsとToBeのギャップ分析があり、それがフィードバックされながらRealizeモデルが洗練される。

ビジネスモデルをどのような視点／側面で記述するかは諸説あるが、分析の過程でEAでのBRM、PRM、DRM、SRM、TRMに落とし込める必要がある。一般には、目標、組織、ネットワーク、プロセスといったビューの提唱が目立つ。各ビューの定義にもよるが少し足らない感じがする。ゴールモデル、サービス構造、情報構造、プロセス構造という4つの視点／分類を推奨したい。

原理原則３：エンジニアリング

サービス分析／設計の流れは、CMMIとSWEBOKのエンジニアリング領域に従うべきである。CMMIでは要件開発(RD)、技術解(TS)、成果物統合(PI)の順に進み、RDとTSの間は階層化される構成要素に応じて繰り返される。また各RD、TS、PIでは、検証(VER)と妥当性確認(VAL)を行う。

SOA適用開発で、サービス仕様さらにコンポーネント仕様が決まるまでは要求エンジニアリングの範疇と言える。CMMIでのRDとTSの繰り返しの一部である。SWEBOKベースで、要求抽出、分析、仕様化、妥当性確認の4つの活動で明示すべきである。

市販本や各ベンダの公開情報を見ると、分析作業の境界が明確でなく、また妥当性確認が明示的なものが余りないようだ。

原理原則４：サービス特定手法

サービスを抽出し、分析・仕様化する際の推奨される手法・技法のベースは、IBMが強調するトップダウン＋ボトムアップ＋ミドルアウトになる。またMicrosoftが強調するプロダクトライン／FODAでの共通性・可変性分析も考慮する必要がある。

またIBMが強調する識別(Identification)、仕様化(Specification)、実現(Realization)の流れは、前述のSWEBOKベースの抽出、分析、仕様化、妥当性確認の流れを2段階で回すことで、より厳密に表現できる。最初のサイクルが識別(Identification)でのサービス抽出と分析、仕様化(Specification)でのサービス仕様化と妥当性確認である。次のサイクルが実現(Realization)でのサービス内部設計(＝コンポーネント分析)に対応し、ここでも抽出、分析、仕様化、妥当性確認が必要となる。

SOA適用開発では、サービスの抽出と仕様化が強調されるあまり、分析と妥当性確認が軽視されているように見えるのだ。サービスを特定する手順もエンジニアリングベースで明確化すべきだろう。