第４章 ライフサイクル知識の資産化と活用方法
4.3 ライフサイクル知識の資産化方法
サービス設計・運用プロセスの資産化方法は，第3章で述べたモデリング方法を用いて，
設計・運用プロセスの再利用に向けた資産化方法とする．
従来，個々の設計モデルあるいはソフトウェアコンポーネントの資産化に留まっていた のに対し，本手法は，ライフサイクル設計・運用プロセス自体を資産化の対象とする．
また，プロダクトラインエンジニアリングの考え方を応用し，カスタマイズインタフェ ースとモジュール最小構成を同定する．
4.3.1 開発～運用工程の知識の統合
4.3.1.1 カスタマイズポイントの導出
第3章で示した各モデルから構築したサービスモデルチェーンは，サービスの設計・運 用プロセス全体を網羅している．このサービスモデルチェーンをライフサイクル知識とし て保持することで，別の顧客に対して同じWebサービスを開発する際に再利用できる．サ ービスモデルチェーンには，開発に必要な設計情報が整列されるため，WBS（work
breakdown structure）4として開発全体の作業や成果物の雛形になるからである．しかし，
一般に，同じWebサービスの開発であっても，全ての要件が同じことは稀で，顧客毎にユ ーザインタフェースや部分的な機能要件の差異が生じる．そこで，このサービスモデルチ ェーンを有効に多くの案件に適用できるように，カスタマイズを前提とした，マス・カス タマイセーションを指向する．この実現には，多品種少量生産に適したプロダクトライン エンジニアリング［Clements2001］の考え方を応用し，次のように，ドメイン開発とカス タマイズの元になるパタンの開発を行う．
ライフサイクル知識の再利用性を最大化するため，次のようにコアと可変点を定義する．
ライフサイクルを指向したドメインとし，モデル中の必須属性をコア，選択・代替属性を 可変とする．モデル間のデータ連結に必須となるものは，必須（mandatory）とし，追加 属性の場合は，選択（optional）とする．また，代替となる属性aは代替（alternative）を 表す．
資産の再利用において，再利用性と適応性の間にトレードオフがある．再利用可能な資 産を最大化するために，パラメータの型は決定論的な方法で指定する．全てのモデルチェ ーンは主に必須（mandatory），追加データは選択（optional）属性であり，他者との依存 関係は，代替属性（alternative）である．これに基づき，次のように，各モデルのこれら の属性を定義づける．
サービス目標モデリング（Service Objectives）：financial, customer, innovation
4 WBSとは，プロジェクト管理を行うための計画手法で，プロジェクト全体を詳細な作業に細分化し，階
層構造などで管理する手法である．
76
perspectivesは必須，これらの関係性は選択（optional）．
ステークホルダ抽出モデリング（Value Chain）：stakeholders は，必須．一方，value chainの流れを構成する条件は代替（alternative）．
要 求 ・ 機 能 展 開 モ デ リ ン グ（Goal Prioritization）：operational processes,
requirements functions は，必須．要求から機能への転写は，設計者の選択である
ため，代替（alternative）．
サービスシステムモデリング（Service System Design）：functional components は，
必須．Functional component間の functional flowは，代替（alternative）．
品質・機能モデリング（Quality Function Insight）：quality とfunctionは必須．
non-functional requirementsは，性能と信頼性のように互いに影響するので，代替
（alternative）．
ユースケースモデリング（Application Use Case/Data Model/System Flow）：ソフ トウェア機能コンポーネントの実装の選択は多様であるため，ソフトウェアコンポ ーネントとデータストアは必須，代替（alternative），または選択（optional）．
リ ソ ー ス 割 り 当 て モ デ リ ン グ（Resource Combination Design）：Runtime
environments は必須．仮想マシンのパラメータは選択（optional）または代替
（alternative）
プロトタイピング（Application Prototyping）：ソフトウェアとリソースコンポーネ ントの間に制約関係がある場合，機能モジュール間の関係は，選択（optional）か つ代替（alternative），または，選択（optional）か代替（alternative）のいずれか．
非機能要件監視・評価（Application Execution：Execution stacks は必須．そのパ ラメータの一部に，互いに依存関係がある場合，代替（alternative）．
これらの任意の代替の属性が可変点と見做し，新しいサービスの開発のための設計のカ スタマイズ可能なインタフェースとして定義できる（表4-1）．
77
表4-1 カスタマイズポイント
工程(Phase) 必須(Mandatory) 選択(Optional) 代替(Alternative) 1 目的の構造
Service Objective
finance, customer, innovation
relationships
2 バリューチェーンのモデリング Value Chain
stakeholders conditions for a
flow of value chain
3 ゴールと機能の関係のモデリング Goal Prioritization
requirements, functions
transcription from
requirements to functions
4 システム構造のモデリング Service System Design
functional components
functional flows
5 機能と品質の関係のモデリング Quality Function Insight
quality and function
non-functional requirements 6 ユースケースのモデリング
Application Use Case
software components
software components
software components 7 機能のリソースへの割り当て
Resource Combination Design
runtime environments
parameters parameters
8 機能要件の検証
Application Prototyping
relationships between functional carriers
9 非機能要件の検証 Application Execution
execution stacks parameters
4.3.1.2 カスタマイズポイントを含むライフサイクルパタン構築
サービスドメインのインスタンスとして，ライフサイクルパタンを開発する．モデルチ ェーン全体が開発に必要になる場合と，部分的に必要になる場合がある．ドメイン特性を，
関心事と定義し，関心事に沿って，モデルチェーンの中から必須部分をパタンとして導出 する．
以上に示した手順を含め，設計・運用プロセスの構築と利用は次のステップで実践する
（図4-4）．
ステップ 1：サービスのドメイン開発（domain development）
対象サービスを分析し，対象サービスのライフサイクルを通じた関心事を 明確化する．例えば，実装指向，プロセス指向などの関心事から，サービ
78
スドメインを特定する．このドメイン特性に基づき，各モデルに含まれる 属性の特性を mandatory（必須），alternative（代替），optional（選択）
のいずれかに決定する．
ステップ 2：ライフサイクル知識のパタン構築設計
モデリングツールを利用して，サービスモデルチェーンを構築する．サー ビスモデルチェーンを構成するモデルについて，alternative，optional属 性に対して，カスタマイズインタフェースを指定する．
ステップ 3：ライフサイクル知識のパタン構築
上記のサービスモデルチェーンから秘密情報や特定のサービス固有情報を 除き，共通リポジトリに保持する．
ステップ 4：ライフサイクル知識のパタン利用
サービスを開発する際の初期データとして，保管されたサービスモデルチ ェーンを使用する．要件に合わせてカスタマイズインタフェースに対して カスタマイズを行い，サービス開発を進める．
ステップ3では，共通リポジトリにライフサイクルパタンを蓄積し，ステップ4では，
共通リポジトリに保管されたライフサイクルパタンを，案件毎に用意した開発用リポジト リにインポートし，カスタマイズ開発を行う．以上のステップを図4-4に示す．
図4-4 プロダクトライン型のサービス開発［Hosono 2012a(改)］
79