モデリングの要件

サービスの設計は，要件定義を行い，要件を元に概要設計を行うステップで進んでいく．

要件定義は，顧客のビジネス目標を達成するために顧客を理解し要求を獲得する工程，顧 客の現状のビジネスとの差異から要求を明らかにする工程，更に，この要求を元にサービ ス設計に向けた要件を定義する工程から成る．概要設計では，定義された要件が，機能要 件，あるいは，非機能要件であるかを判別し，機能要件を達成するための機能群の定義と，

非機能要件を実現するための機能およびアーキテクチャの定義を行う．次に，これらの定 義と，プロバイダ側のシステム，ビジネス上の制約と擦り合わせを行い，設計解を導出す るステップが続く．以上のステップを通じて，サービスの上流設計を完成し，以降，サー ビスを実装するためのパラメータを決定する詳細設計，実装，検証，導入，評価とステッ プが進んでいく．

要求や要件は，顧客と言葉で交わされた内容を，自然言語で記述し，共通理解を図って きた．この書き方に曖昧さや，情報の不完全さが含まれやすく，開発の後工程で初めて気 づくこともある．そのため，開発の手戻りの大きな要因となってきた．

そこで，要件定義を形式的かつ客観的に記述するための試みがなされている．要求や要 件は，ダイアグラムのような標準的でかつ可視化できるモデルで表記しにくいため，項目 を定義する．IEEE 803では，ソフトウェアの要求定義を行っている［IEEE830］．要求を 階 層 構 造 で 表 現 し ， 仕 様 を 漏 れ な く 抽 出 す る 表 現 方 法 と し て ，USDM（Universal Specification Describing Manner）がある［清水2010］．この表現方法は，仕様は要求の 中の動詞にあるという考え方に基づき，要求を振舞いとして表現し，仕様はその振舞いが 及ぶ範囲の中で導き出す．要求と合わせて理由を記述することで，要求の意図や背景に関 する情報を併せ持つことができる．これは，国内のシステムインテグレーションの開発文 書形式として広く用いられているMicrosoft Excelの表形式の記述と親和性が高く，仕様と 設計要素間の関係を示すマトリクスと組み合わせて仕様と設計内容のトレーサビリティの 確保に応用できる．そのため，近年，現実解として，国内のシステムインテグレーション 事業でUSDMの採用が図られている．

この要求から仕様を定義する過程において，漠然とした希望や期待する効果などの要求 は，実現対象とするシステムの要件に置き換えがなされる．すなわち，希望や期待などの

「要求」は，システムで提供し得る「機能要件」と，システムの構成などで達成できる「非 機能要件」として具体化される．機能要件は，顧客の要求との対応が明快であるため，こ れまで，UML（Unified Modeling Language）［UML 2005］が採用されてきた．一方，非 機能要件は，機能と対応づけられるものと，物理的な機能に対応付けられず，アーキテク

34

チャで実現するものがある［IPA2011］．また，オペレータなど人手の操作や行動で実現す るものがある．これらを形式化するために，非機能要求グレード［IPA2010］では，標準的 な非機能要件をリストにして体系化している．特に，アーキテクチャに関わる部分では，

UMLを補完する形で，SysML（System Modeling Language）が定義され，次第に，導入 が図られている（図3-1）．これは，機能，振舞い，制約，および要求も含んでいる（図3-2）

［SysML2008］．

このUML および SysMLは，特定の観点でモデルを表記する方法を示しているが，各

モデルで技術される項目間の関連性について網羅的に規定していない．

図3-1 SysML と UML の関係［SysML 2011(改)］

図3-2 SysML ダイアグラム種類［SysML2011(改)］

Web サービスの設計や管理に関する従来の研究は，サービス指向アーキテクチャ

（Service-Oriented Architecture; SOA）に基づくアプローチである．SOAは，システムを 柔軟に変更可能にするため，また，再利用性を高めるため，アプリケーションを構成する ソフトウェアをコンポーネント化し，それらを組み合わせてシステムを作る設計手法であ る．これを体系付けるため，参照アーキテクチャが提案され，各レイヤでのモデル化対象 が定義されている（図3-3）．

35

図3-3 SOA 参照アーキテクチャ：ソリューションスタック［Arsanjani 2007(改)］

以上に示したように，ITサービスの研究は，これまで主にWeb サービスの実装方法論 としてサービス指向アーキテクチャ(Service Oriented Architecture: SOA)に焦点があり，

Web サービスの業務ロジックとその実装方法，及びシステムアーキテクチャについて議論 が中心になされてきた．近年は，より上位概念を含む業務モデル［IIBA2009］や，複数の サービス間の関係まで考慮したシステム構成方法［Zhang 2007］にも議論が拡げられてい る．しかし，設計～運用に跨ったプロセス全体を規定するに至っていない．また，マーケ ティング視点での設計方法［Shostack 1982］［Ramaswamy 1996］も，具体的な生産方法 まで詳細には言及されていない．

一方，サービス工学では，Service CAD［Arai 2004, 2005］［Hara 2006］［Kimita 2009］ により，サービスシステムの概念設計を計算機上で可能にしている．サービス工学では，

ビューモデル，フローモデル，スコープモデルの 3 つの主要なサブモデル概念を導入して いる．ビューモデルは，顧客に対する価値提案の内容を，機能・実体・属性の構造として 表現し，可視化したモデルある．フローモデルは，サービス提供に関わるパートナーのネ ットワーク関係を表現するモデルである．スコープモデルは，ビューモデルのセットによ り，特定の提供者・需給者間の関係を表現するモデルである．これらサブモデルは，サー ビスの提供時点の構造を，特定の視点に関する情報を含む形でモデル化することで，要求 から機能および非機能要件に，更にその仕様定義，実装，機能・非機能へのリソースの割 り当てまで，設計～運用プロセスを定式化することまで，現状扱われていない．また，サ ービス提供プロセスの表現に，サービスブループリントがある．これは顧客とのフロント エンドからバックエンドまでのサービスの機能提供の構成を表現するモデルである．サー ビス工学では，従来のブループリントを拡張し，人の活動と製品の挙動を統合的に記述可 能にしている［Hara2009］．しかし，サービスブループリントは提供時のプロセスに視点 があり，設計～提供に至る開発プロセスのモデル化と，プロセスを進行させるための手順

36 については十分にモデル化できない．

以上に示したように，既存のモデリング方法では，開発プロセスのある工程および提供 時点で必要となる視点・観点を形式的に表現できるようにしたものである．従って，開発 プロセスに沿って，連続性のあるモデリングと，モデルを跨ったデータ間の関連性につい ての考察が十分になされていない．