第３章 ライフサイクル工程のモデリング方法
3.6 モデリング方法の評価と考察
3.6.1 モデリング方法のクラウドサービスへの適用
4つの提案方法は，リポジトリを中心に，一連の1つのフレームワークとして機能するこ とが可能である．この機構は，設計工程と運用工程の情報共有や共同作業の基礎となり，
設計と運用がより一体化するDevOps3の考え方を実践・実装するための機構になり得る．
この機構をクラウドサービスへ適用した具体例を図 3-24 に示す．ここでは，ある Web サービス開発を想定し，リポジトリを開発環境内に配備し，システム構築関係者間で共有 する．このリポジトリを，クラウド環境の仮想サーバ内に配置する．リポジトリは，Web サービス案件毎に用意することで，案件間で各案件の秘匿情報を隔離し，Web サービス案 件情報の安全性を担保した開発・実行フレームワークをクラウド環境に構築できる．
このような仕組みを備えることで，クラウドサービスプロバイダは，設計～運用までが 一貫した，Webサービス設計・運用フレームワークをWebサービス化して，高機能かつ高 付加価値のクラウドサービスを提供できる．
図3-24 モデリング方法のクラウドサービスへの適用
3.6.2 ステークホルダの共通言語となるサービスモデルチェーン
ハードウェア製品の製造は，その開始時点で仕様が確定し，生産の各工程での作業や期 間が明確化されている．一方，サービスの開発工程には多くの協働作業が含まれ，各工程 での作業や期間は，人に依存し易い．分析～企画・設計に至る過程では，顧客と企画者の 間で仕様の合意形成が図られ，実装～提供の過程では，設計担当と運用担当の間で設計情 報の共有が必要となる．
本章で述べたサービスモデルチェーンは，標準的な記法で，かつ客観的な情報となるた め，これらの異なる役割を持った担当者間で情報交換や合意形成する際の共通言語になる．
3 DevOpsとは，開発者(developer)と運用者(operator)が連携し開発・運用を行うプラクティスである．
62
3.6.3 サービスモデルチェーンの考察
サービスモデルチェーンを，Webサービスの開発に用いることで，次の効果が得られた．
機能・非機能への展開設計では，機能カタログから機能候補を提示した．カタログデー タからWebサービスの実装・運用過程で生じ得るリソース制約を，予め設計過程で考慮す ることが可能になり，下流工程での設計の見直し機会を抑えられた．
サービスシステム境界の設計では，アプリケーションを構成する機能モジュールと要件 定義との対応を確認しながら設計した．これにより，先に要件定義と突き合わせを行うこ とで要件定義の対応漏れを検出できた．
機能モジュールおよび実行リソースへの割り当て設計では，機能独立性の評価を行いな がら，アプリケーションの仮想マシンへの配置構成を設計した．ツールは，この設計情報 を元にクラウド上に検証済みミドルウェアを含む仮想マシンを自動で構築した．
リソースの分離・結合による機能検証では，前工程で設計された機能モジュールを流用 して，Webサービスのロジックの雛型を生成し，実装を効率化した．
また，リソースの分離・結合による機能・非機能検証では，Web サービスを実行するミ ドルウェアのパラメータは，要件定義過程で蓄積したレベル値を再利用して自動設定を可 能とし，運用設計を容易にした．
このように，サービスモデルチェーンによって，設計作業を効率化し，設計内容を高品 質化できた．以上により，ITILで示された，戦略，設計，構築，移行，運用，改善を網羅 したモデル群（図3-25）となる．
図3-25 モデリングツール群［Hosono 2012b(改)］
63
これによりサービスシステムのサービスライフサイクルを通じ，パラメータを循環させ ることができる（図3-26）．
図3-26 工程間のパラメータの関係
以上に示した通り，リソースと前後の工程のモデリングにおいて，機能とリソースの分 離と統合が可能となり，機能と非機能の検証を容易にした．
また，各モデルで規定される属性間の関係を明確化し，工程間のデータ連携を間断なく 実現．これにより，顧客と設計者間，および設計者と運用者間にそれぞれにおいて，正確 な情報の伝達を可能にした．
64