サービス指向要求工学には2つの種類がある。第1のサービス指向要求工学は、WebサービスやSOAなどの技術を用いて構築される情報システムのための要求工学である。第一種のサービス指向要求工学は、既に存在するWebサービスを再利用するという意味でアーキテクチャ指向によるモジュール組み立て型要求工学であるといえる。
これに対して第2のサービス指向要求工学は、モノとしての製品に対するコトとしてのサービスを、情報システムを活用して構築するための要求工学である。第二種のサービス指向要求工学では、最初からモジュールが明確になっているわけではなく、ビジネスプロセスに参画するパートナー間でビジネスプロセスの構成要素をどのように分担するかを探索していく、すりあわせ型の要求工学である。第1種のサービス指向要求工学は解指向であるのに対して第2種のサービス指向要求工学は問題指向であるともいえよう。
また第2種のサービス指向要求工学は、第1種のサービス指向要求工学とこのように明確に対比して意義付けられることは、これまであまりなかったように思われる。しかし上述したように、両者を区別しておくことで上手に連携することもできるようになるはずである。
今回は、これら2つのサービス指向要求工学の概要と課題について述べる。
サービス指向アーキテクチャとは
サービス指向アーキテクチャは、サービス提供者とサービス利用者を分離して、サービスをレジストリに登録しておき、必要に応じてネットワーク上でサービスを検索して利用するという考え方に基づいている。このように共通的に利用できる分散サービスを分離・再結合するアーキテクチャをSOA(Service Oriented Architecture)という[1]。
システム構築方針の観点から次のようにSOAを定義することもある[1]。経営目標に対して迅速かつ柔軟にITシステムを実現するためのアーキテクチャをSOAという。この2つ目の定義では企業内で共通化されたサービスをESB(Enterprise Service Bus)を用いて再結合することが求められる。これによって、経営環境の変化に応じて迅速にサービスを組み替えることでシステム構築費用を削減するだけでなく構築期間を短縮することができる。
このような2つのSOAの定義に共通する考え方は、前回のアスペクト指向の解説でも述べたように、ソフトウェア工学の基本原理の一つでもある。つまりサービス定義は1箇所に限定しておき必要に応じてサービスを再利用するのである。
SOAの構成要素
以下では、サービス構成要素の例を文献[2]を参考にして述べる。
◆サービス
SOAの最も基本的な構成要素である。サービスを合成することでソフトウェアを開発することができる。
◆ワークフローテンプレート
複数のワービスから構成されるワークフローの実行シーケンスを定義する。ワークフローテンプレートによって迅速なSOAサービスを開発できる。
◆アプリケーションテンプレート
ワークフローやサービスから構成されるアプリケーション全体を定義する。アプリケーションテンプレートを再利用することでSOAアプリケーションを迅速に開発できる。
◆データ、スキーマ、データの出所
SOA実行中に作成されるメッセージなどのデータやスキーマを定義して検索できる。
◆ポリシー
SOAの実行をポリシーによって制御する。サービスが機能要求に対応するのに対して、ポリシーはサービスの性質を記述する非機能要求の一種である[2]。
◆テストスクリプト
サービス提供者、仲介者、利用者がテストスクリプトを定義しておき、第三者がサービスを確認するために利用できる。
◆インタフェース
GUI設計をインタフェースとして定義しておき再利用できる。また実行時にサービスにインタフェースをリンクしておくことで SOAアプリケーションのインタフェースを動的に変更できる。
図1に示すように、これらの構成要素をデータとプロセス、対象と性質の観点から分類することができる。
図1 SOAの流通対象
第1種のサービス指向要求工学プロセス
第1種のサービス指向要求工学のプロセスは、表1に示したように通常の要求工学プロセスと同じように、要求獲得(または要求抽出)、要求定義、要求確認、要求管理という4つの構成要素に分けられる。
プロセス | 説明 | 課題例 |
---|---|---|
サービス要求獲得 |
サービスの活用前提として要求を獲得 |
|
サービス要求定義 |
サービス機能を定義 サービスレベルなどの非機能要求を定義 |
|
サービス要求確認 |
サービスの完全性、無矛盾性、無曖昧性を検証 |
|
サービス要求管理 |
サービスの追跡管理 サービスの再利用・再構成 |
|
◆サービス要求獲得
サービスの活用を前提としてサービス要求を獲得する。このためには、再利用可能なサービスを登録するリポジトリ(レジストリ)が必要になる。またサービスの目的や用途、制約などをサービスと対応付けて管理することで、サービス検索を容易化できる。
このようにサービス要求獲得では、サービスプロセスとゴール、機能、制約の関係を分析することで、必要なサービスを検索・再利用する。
◆サービス要求定義
サービス要求定義では、機能を定義するだけでなくサービスレベルなどの非機能要求についても定義する必要がある。このため機能ならびに非機能要求の定義を標準化する必要がある。たとえば複数のモバイルや多種のデバイスを扱うようなサービスを連携するためのモデル化や標準化が必要になる。またサービスを類似サービスで代替するために、サービス間のインターオペラビリティが重要になる。
エンタープライズ・アーキテクチャ(EA)やオントロジーなどによる組織、業界横断的なサービスの記述についても考慮する必要がある。
◆サービス要求確認
要求確認では、定義したサービスの完全性、無矛盾性、無曖昧性を確認する。サービスの受容性の確認では、定義したサービスがサービスプロセスやゴールと整合性が取れることを検査する。
またサービスのモデル検証では、サービス要求に対して作成したモデルとモデルが満たすべき性質に対して、モデルを実行することにより、モデルが定められた性質を満足することを確認する。
◆サービス要求管理
サービスの追跡管理では、組織横断的なビジネスゴールに基づいて、業務プロセスの構成要素と連携サービスとの追跡性を保証することが求められる。またサービスの再利用と再構成を支援するためにサービスと要求とを対応付けて管理する必要がある。
サービス要求管理の課題には、ビジネス環境の変化に応じてサービス要求の進化を管理することや複合サービスとそのコンポーネントサービスの対応を追跡することだけでなく、サービスコンポーネントの非機能要求を定量的に評価する品質管理などがある。
第1種のサービス指向要求工学の特徴
第1種のサービス指向要求工学のライフサイクルは次のようになる。まずサービスに用いる必要な再利用資源を発見すると、それを組み立てて実行することでシミュレーション結果を確認できる。この過程で非機能要求としてのポリシーに問題がないことを評価・管理する。したがって、第1種のサービス指向要求工学には表2に示したように以下のような特徴がある[2]。
特徴 | サービス指向要求工学 | 一般の要求工学 |
---|---|---|
再利用指向 |
サービスに用いる必要な資源は新たに開発するのではなく、再利用できることを仮定している | 再利用を前提にしていない |
ドメイン指向 |
再利用資源からサービスを合成するという点で、再利用資源が想定するドメインの制約を受ける | ドメインを前提にしていない |
アーキテクチャ指向 |
SOAに基づくサービスを再利用を前提にしているので、アーキテクチャを最初から考慮する | アーキテクチャを前提にして要求を定義しない |
モデル指向 |
サービスだけでなくワークフロー、ポリシー、テストケースなどの再利用資源のモデルが提供される | モデル指向要求工学 |
評価指向 |
サービス事前評価、サービス合成、サービス実行管理によってサービスを評価できる | プロトタイピングやシミュレーションに基づく要求確認 |
ユーザ指向 |
Web2.0によりエンドユーザがサービスを能動的に組合わせて定義 | ユーザは要求抽出の対象として受動的に参画 |
ポリシー指向 |
合成サービス、要素サービスごとにサービスポリシー要求を段階的に対応付けて管理 | ゴール指向要求工学 非機能要求 |
◆再利用指向
一般的な要求工学では再利用を前提にしていない。これに対してサービス指向要求工学ではサービスに用いる必要な資源は新たに開発するのではなく、再利用できることを仮定している。
◆ドメイン指向
一般的な要求工学では再利用を前提にしていない。これに対してサービス指向要求工学では再利用資源からサービスを合成するという点で、再利用資源が想定するドメインの制約を受けることに留意する必要がある。したがって、明確にドメインの制約を定義できるようにサービスを登録する必要がある。
◆アーキテクチャ指向
一般的な要求工学では再利用を前提にしていない。これに対してサービス指向要求工学ではSOAに基づくサービスを再利用を前提にしているので、アーキテクチャを最初から考慮する。そうすることで効率的にサービス要求を定義できる。
◆モデル指向
モデル指向要求工学の概念をサービス指向ではさらに進めて、サービスだけでなくワークフロー、ポリシー、テストケースなどの再利用資源のモデルも提供される。
◆評価指向
これまでの要求工学でもプロトタイピングやシミュレーションに基づく要求確認の重要性が指摘されている。サービス指向要求工学ではサービス事前評価、サービス合成、サービス実行管理によってサービスを段階的に評価できる。
◆ユーザー指向
これまでの要求工学では、ユーザーは要求抽出の対象として受動的に参画するだけであった。これに対してサービス指向要求工学ではWeb2.0などの登場によりエンドユーザーがサービスを能動的に組合わせて定義できるようになった。
◆ポリシー指向
ポリシーは非機能要求の一種であり、その意味ではゴール指向要求工学もポリシー指向であるといえる。サービス指向要求工学では実行可能な再利用サービスを対象としているので、要素サービスだけでなく合成サービスについてもサービスポリシー要求を段階的に対応付けて管理したり評価できるという特徴がある。
第2種のサービス指向要求工学プロセス
第2種のサービス指向要求工学では、ビジネスプロセスを共有するパートナー間での意識のすり合わせに基づく価値の創造が必要になる。このため、図2に示すように、Henry Chesbrough[3]が「価値はビジネスモデルによって創造されるのであり、テクノロジー自体に価値はない」と述べたように、モノとしてのテクノロジーを使いこなすコトとしてのビジネスモデルによって顧客価値を創造する要求工学プロセスが必要になる。このときの留意点は、パートナーがWin-Win関係をどのようにすれば構築できるようになるのかということである。たとえば、従来の製品は、製造者が製品を消費者に販売するという一方向の関係であった。これに対して製品の保守やアフターサービスを製品に付加することで関係を双方向にすることができる。たとえば、製造者に対して消費者は、廃棄すべき製品を供給することになる。このとき製品廃棄サービスにどのようにして価値を定義できるだろうか?
図2 サービスの価値
ごみを捨てることを考えれば分かり易いかもしれない。環境に大きな影響を与える製品を捨てるのは簡単ではない。製品の所有権を消費者が持てば、廃棄の責任を消費者が持つことになるが、製品を利用するだけにすることで、消費者は製品の廃棄責任を持つ必要がなくなる。このように製品のライフサイクルを考慮してビジネスプロセスのどの部分を誰が責任を持つのかを探索していくことで新たな価値を創造するビジネスモデルを発見できる可能性がある。実際にパナソニック電工では「あかり安心サービス」というビジネスモデルを提供している。このビジネスモデルでは照明器具を売りきりではなくサービスとして提供する。照明器具が故障した場合、取り替えてくれるというサービスだ。故障した照明器具を利用者が廃棄する必要もない。廃棄された照明器具は再資源化されて、また製品になるので、「あかり安心サービス」は環境にも易しいのである。このように照明器具が電気や水道と同じように使えるのである。
この考え方を一般化して示したのが図3である。従来は生産者と利用者の間のビジネスモデルだけを考えていた。しかし製品の再生者という第3のアクタを、製品のライフサイクルを考えて導入することでより広い範囲でビジネスの全体像を捉えることができるようになり、付加サービスを提供することができるようになったのである。
図3 循環型ビジネスモデル:価値の協創例
したがって第2種のサービス要求工学プロセスというのは、次のようになると考えられる。
- サービス対象のライフサイクルをまず抽出する
- ライフステージごとのビジネスプロセスの構成要素とその責任を持つアクタを定義することにより、ビジネスプロセスにサービス要求を割り付ける
- ライフサイクルに対してサービス要求の妥当性を確認する
- この過程でサービス要求とサービス対象の一貫性や追跡性を管理する
まとめ
今回は2つのサービス指向要求工学について説明した。とくに第2種のサービス指向要求工学の考え方は、これから益々重要になっていくと思われる。この理由は、何を開発すればいいかが分からないケースが最近とくに増えていると思われるからである。従来の情報システム開発では、「要件を正しく定義できれば、それに基づいて開発を成功できる」という暗黙の大前提があった。しかし、どんな要件が正しいかはだれとどのようにどこまで連携するかによって変化する。したがって、これからはだれとどのように連携するかを分析することが求められる。このような場合には、必ずしも既に存在するサービスがないかもしれない。むしろ存在しないサービスを発見できるかどうかが、ビジネスモデルの価値を決めることになる可能性が高い。そして最初にそのようなビジネスモデルを構築し、サービスとして提供したプレーヤがその市場を独占する可能性も高くなるのだろう。このような意味で、サービスが生む価値をビジネスゴールと捉えれば、第2種のサービス指向要求工学とゴール指向要求工学との関係も深いものがあることに気づくだろう。
いずれにしろ第1種も含めてサービス指向要求工学はまだ研究の初期段階にあるだけでなく、未解明の部分が多いことも事実である。今後サービス指向要求工学に関する研究開発が進展することを期待したい。
■参考文献
- [1]青木利晴監修、Webサービスコンピューティング、電子情報通信学会、2005
- [2]W. T. Tsai, Z. Jin, P. Wang and B. Wu, Requirement Engineering in Service-Oriented System Engineering, Proceedings of the IEEE International Conference on e-Business Engineering, pp.661-668, 2007
- [3]Henry Chesbrough著、大前恵一朗訳、 Open Innovationハーバード流イノベーション戦略のすべて、産業能率大学出版部、2002
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要