概要
前回はi*(iスター)フレームワークをプレゼンツールで描く簡単な方法を紹介した[1]。i*フレームワークはアクタ間の依存関係をソフトゴール、ゴール、タスク、資源という4種類の対象を用いて分析する手法だ[2][3]。このように構成要素は単純だが、実際に図を描いてみると分かると思うが、なれないと案外戸惑うことも多いものである。そこで、今回はi*フレームワークの図式を作成する上で、困惑したり間違え易いポイントについて整理しよう。
これらのポイントは、みなさんがi*フレームワークという車に乗ってゴール指向という路をドライブするときに、おそらく繰り返し出会うことになる危険な曲がり角の一部になるだろう。
i*フレームワークの誤り易いポイント
私のこれまでの経験から、i*フレームワークの誤り易いポイントを整理すると、次の5点になる(表1)。
- アクタの漏れ、重複
- 依存関係の記述ミス、ループ
- デペンダムの抜け、記述ミス、重複
- デペンダム名の記述ミス、曖昧さ
- デペンダム関係の記述ミス
以下ではこれらを順番に説明しよう。
アクタについての誤り
・アクタ境界に対するアクタが抜けている
具体例を図1(1)に示す。
この例では、点線で示したアクタ境界の上にアクタを示す円が抜けているので、追加する必要がある。
・どのアクタとも関係しないアクタがある
具体例を図1(2)に示す。
この例では、Cで示したアクタが他のアクタと依存関係を持たないので、このアクタCを削除するか、他のアクタとの依存関係をを追加する必要がある。

図1 アクタについての誤り
依存関係の誤り
・境界を持つアクタに依存関係を付けている
具体例を図2(1)に示す。
この例では、アクタ境界をもつマーケティングサービス会社を示すアクタに製造会社からの依存関係が接続しているので、ソフトゴール「顧客情報を収集したい」からの依存関係をアクタ境界の中にあるタスク「顧客情報を収集する」に接続するように変更する必要がある。
・ソフトゴールの依存関係がループしている
具体例を図2(2)に示す。
この例では、製造会社と販売会社という2つのアクタ間で同じソフトゴール「販売情報を収集したい」からの依存関係がループしているのでどちらかの依存関係を削除するか、ソフトゴールを2つに分割してループしないように変更する必要がある。

図2 依存関係の誤り
デペンダムの誤り
・アクタ内部のデペンダムが抜けている
具体例を図3(1)に示す。
この例では、アクタAからのソフトゴールXがアクタBのアクタ境界に接続しているので、アクタB内のデペンダムを追加して、それにソフトゴールXからの依存関係を接続するように変更する必要がある。
・デペンダムがアクタの内部にある
具体例を図3(2)に示す。
この例では、アクタBのアクタ境界の中にソフトゴールXが含まれてしまっているので、XをBのアクタ境界の外側に出すように変更する必要がある。

図3 デペンダムの誤り
・受益者のデペンダムと同じタスクを提供者が持っている
具体例を図4(1)に示す。
この例では、アクタAとアクタBが同じタスクTを持っているので、どちらかのタスク名を変更する必要がある。またソフトゴールもタスクと同じ名前を付け易いので注意する必要がある。タスクやソフトゴールがそれぞれのアクタに対してどのような意図や効果を持つのかをきちんと考察すべきである。そうしないとゴールやゴール間の依存関係を分析する意味がない。
・アクタ間のデペンダムが抜けている
具体例を図4(2)に示す。
この例では、アクタAとBのアクタ境界の中にあるタスク間が直接依存関係で接続されてしまっているので、SとTを関係付けるソフトゴールを追加すべきである。このような図を描いてしまう理由はアクタ間の意図や役割の分析が不十分だからである。

図4 デペンダムの誤り(続き)
デペンダムに対する命名誤り
・ソフトゴールにタスクの名前を付けている
具体例を図5(1)に示す。
この例では、「購入機能」という本来タスクに付けるべき名前をソフトゴール名としているので、ソフトゴールにふさわしい名前に変更すべきである。
・ゴールにソフトゴールの名前を付けている
具体例を図5(2)に示す。
この例では、「~したい」という本来ソフトゴールに付けるべき名前をゴール名としているので、ゴールにふさわしい名前に変更すべきである。
・名詞がゴール名になっている
具体例を図5(3)に示す。
この例では、「満足度」という名詞をソフトゴール名としているので、ソフトゴールにふさわしい名前、たとえば「満足度を向上したい」などに変更すべきである。
・資源名としてゴールやタスクの名前が付けられている
具体例を図5(4)に示す。
この例では、タスクを表現すると思われる「顧客サービス」を資源名としているので、資源にふさわしい名前に変更するか、資源ではなくタスクを表す図形に変更すべきである。

図5 デペンダムに対する命名の誤り
・デペンダム名が曖昧であると依存関係の方向が決まらない
具体例を図6に示す。
この例では、マーケティング情報という用語の持つ意味が曖昧なため、依存関係の方向付けも曖昧になっている。つまりマーケティングは市場開拓から販売に至る一連の活動であり、活動内容ごとにマーケティング情報の依存関係が反転する。たとえば顧客の嗜好情報である場合とコピーライティングやDMの場合では矢の向きが逆になるだろう。

図6 デペンダム名の曖昧さ
- 1:要求工学の概要
- 2:第12回要求工学国際会議 RE2004
- 3:要求仕様
- 4:要求工学プロセス
- 5:要求抽出
- 6:要求分析
- 7:要求確認
- 8:要求管理
- 9:要求追跡
- 10:要求工学の課題
- 11:ジャクソンの問題フレーム
- 12:シナリオ分析
- 13:要求工学国際会議RE2005
- 14:ゴール分析
- 15:iスター・フレームワーク
- 16:要求インタビュー
- 17:ゴール分析 応用編
- 18:ゴール分析 応用編つづき
- 19:ゴール分析の視点
- 20:ソフトシステム方法論 再考(その1)
- 21:ソフトシステム方法論 再考(その2)
- 22:ソフトシステム方法論 再考(その3)
- 23:非機能要求
- 24:信頼性要求
- 25:コミュニケーションの構造
- 26:組織とコミュニケーション
- 27:論理思考プロセスと現状分析ツリー
- 28:対立解消図と未来実現ツリー
- 29:前提条件ツリーと移行ツリー
- 30:特性要因図とゴール思考分析
- 31:i*フレームワークの書き方
- 32:i*フレームワークの危険な曲がり角
- 33:目的思考
- 34:要求工学の研究動向
- 35:アジャイル開発の要求工学
- 36:アジャイル開発の要求工学
- 37:要求レビュ
- 38:要求の曖昧さ
- 39:アクタ関係分析
- 40:要求工学の現状と課題
- 41:セキュリティ要求工学
- 42:ソフトウェア品質要求工学
- 43:イノベーションと要求工学
- 44:Wikiと要求工学
- 45:要求工学プロセスの改善
- 46:アクタ関係から見るユースケースと要求獲得
- 47:要求エンジニア
- 48:要求モデリングと誤り
- 49:要求を軸としたこれからのソフトウェア社会
- 50:ゴール指向とアスペクト指向要求工学
- 51:サービス指向要求工学
- 52:要求質問
- 53:試験工程での要求発見
- 54:要求とテスト
- 55:すりあわせの技術と価値星座
- 56:学生からの質問
- 57:SysMLの要求図
- 58:アシュアランスケースとGSN
- 59:組込み要求工学
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 10G-EPONの概要 その4-10G-EPONの課題と今後の動向-
【新ネットワーク】 - やっぱりおかしいよね?メモリの使い方
【通信ソフトウェア開発】 - 猿でもわかる”フレッツテレビ”その2
【猿でもわかるICT】 - 10G-EPONの概要 その3-10G-EPONの特徴2-
【新ネットワーク】 - 10G-EPONの概要 その2-10G-EPONの特徴1-
【新ネットワーク】 - 開発支援ツール
【通信ソフトウェア開発】 - 猿でもわかる“フレッツテレビ”その1
【猿でもわかるICT】


