Vol. 48No. 8情報処理学会論文誌Aug. 2007
ロールに着目したビジネス領域における要求獲得手法RODAN の提案
中 谷多 哉 子†,†† 藤野晃延†††
ビジネスとは，複数の人々が関与し，各々の人々が各自に与えられた責務を，自分たちの意思によって達成し，同時に，組織としての目的を達成する営みである．したがって，ビジネスシステムの要求分析では，システムの利用者だけでなく，正負の影響を受ける複数の人々の責務と，それへの影響を分析しなければならない．ビジネス領域を分析する目的は，システムへの要求の背景を明らかにして，要求が発せられた根拠を示すことにある．我々はビジネスシステムの要求を獲得するための手法として，RODAN を開発している．RODAN を適用する分析者は，ステークホルダが担うロールに着目し，個人へのインタビューから得られた要求の背景を明らかにすることができるようになる．本稿では，最初に RODAN を適用して得られる成果物のメタモデルを示し，金庫という身近な事例に適用した結果を用いて手法を評価する．この手法を適用した結果，要求の背景を明らかにすることによって，未定義の要求を発見できること，さらにミスユースケースを得るためのネガティブアクタを抽出できることを示すことができた．最後に，手法の実用性についても考察を行う．
RODAN: A Requirements Elicitation Method for a Business Domainby Focusing on Roles
Takako Nakatani†,†† and Terunobu Fujino†††
One of the purposes of analyzing a business domain is to reveal the background of cus-tomers’ requirements.The resulting artifact provides us the reason why the requirementsarise and what the customers’ problems are. We are developing RODAN as a requirementselicitation method for customer’s business domain. When RODAN is applied to the businessdomain, analysts focuse on a personal view of their customers. The view is determined as arole that the stakeholder plays. This paper presents a metamodel of RODAN with a productperspective. It is build as a model of a common structure of “business domain” with stake-holders and their roles. RODAN is evaluated by applying an example. As a result of theapplication, undeﬁned requirements can be extracted as well as anti-actors for misuse caseswith the background of the requirements. We also discuss on the practical aspect of RODANapplications.
1.は じ め に
1.1研究の背景と目的
ビジネスとは，複数の人々が関与し，各々の人々が
各自に与えられた責務を，自分たちの意思によって達
成し，同時に，組織としての目的を達成する営みであ
る．このようなビジネスの領域において利用される
システムは，ユーザと呼ばれる人々の業務を支援する
だけでなく，ときには他の人々の責務遂行に負の影響
† 筑波大学大学院ビジネス科学研究科Graduate School of Business Sciences, University ofTsukuba†† 有限会社エス・ラグーンS-Lagoon, Co., Ltd.††† 有限会社インアルカディアInarcadia, Ltd.
を与えることもある．したがって，システムの要求分
析では，このような正負の影響を受ける人々のビジネ
スを分析する必要がある．そして，その分析結果を妥
当なものであるとして，関係者が了解しなければなら
また，要求の “where” や “who”，“when” を追求
することができれば，より品質の高い要求を獲得でき
るであろう36)．我々は，これらの視点から要求の背景
をモデルとして示すことができれば，関係者が要求の
妥当性をより良く了解できるようになると考える29)．
たとえば，ゴール指向分析は，要求である “what” に
対する “why” を追求する手法である2)．“what” に対
する “why” を得ることによって，より安定した要求
を獲得することが可能であると考えられている．
ビジネス領域を分析する目的は，システムへの要求
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2535
を，その背景から要求の根拠を明らかにすることであ
り，それによって，ビジネスの関係者の了解を得るこ
とにある．本研究で開発している RODAN と名づけた
手法は，特に，要求の背景として，現在のビジネスの
状況，解決すべき課題，それらの課題をかかえる人々，
目指すべき状況を可視化することを目指して開発され
RODAN の分析プロセスは，• ステークホルダ分析，• 課題分析，
という 3 種類のタスクから構成される．これらのタ
スクは，要求プロセス25) のうち，要求獲得のプロセ
スに属する．ただし，本稿ではステークホルダという
用語を狭義に使う．すなわち，ステークホルダとは，
ビジネス領域の関係者（たとえば，プロジェクトスポ
ンサ，システムの操作者，システムの購入者，対象ビ
ジネスの関与者）を主に指し，開発者，開発プロジェ
クト管理者を含まない．また，本稿で，単に関係者と
いった場合は，ビジネス領域の関係者を指す．慣習，
法律，企業理念などは，それらを代表する物理的な人
を求め，ステークホルダとして取り扱う．我々がこの
ように「物理的な人」を強調するのは，まず，それが
現実世界に根ざしていること，そして，実際にその人
に対するインタビューが可能だからである．
RODAN の開発当初，我々はビジネス関与者，個人
へのインタビューによって一般性のあるビジネスモデ
ルが定義可能であると考えていた．しかし，個人が定
義するモデルには，個人の認識の差による多様性があ
ることが明らかとなった．同じ業務を担当していても，
業務のルールが異なることもある．担当する業務が変
われば，課題が多様になるだけでなく，その優先順位
も多様となる．要求の多様性に起因する要求の欠落や
予期せぬ変更へ対処するための 1 つの解として，本研
究では，個人に依存した多様性をモデルとして明示し，
そこから組織で共有すべきビジネスモデルを構築する
ための手法として RODAN を位置づけることにした．
1.2ビジネスモデルとビジネス領域のモデル
ビジネス領域のモデルは，ビジネスルール，ビジネ
スリソース，ビジネスゴール，ビジネスプロセスとい
う 4 つのモデルから構成される11)．いわゆるビジネ
スモデル11) と，我々が本稿で取り扱うビジネス領域
のモデルとは，それを構成するモデルの種類は同様で
あるが，モデルの生成過程と意味が異なる．
前者のビジネスモデルは，企業のあるべき姿を設計
する過程で生成され，生成されたモデルは組織内で一
般性を持つモデルである．したがって，このモデルは
組織に属する人が従うべきモデルとなる．
これに対する後者のビジネス領域のモデルは，企業
で働く個人へインタビューすることによって得られる
モデルである．このモデルには，個人が認識するビジ
ネス上の課題だけでなく，その解決策の妥当性を理解
する背景が示される．したがって，ビジネス領域のモ
デルは，インタビュイである個人が従っている，ある
いは従いたいと望んでいるモデルということができる．
このモデルには，インタビュイの主観的な思い込みも
紛れ込むが，その一方で，業務の担当者しか知りえな
い重大な問題が明らかにされる可能性もある．それゆ
えに，ビジネス領域のモデルを示すことに価値がある
本稿の構成は以下のとおりである．次の章では，
RODAN の分析プロセスを示し，3 章では，RODAN
を適用して得られる成果物の構造をメタモデルとして
表す．分析手法では，手法を適用して作られる成果物
をモデルと呼ぶため，手法自体の成果物を表現したモ
デルは，メタモデルと呼ばれる7)．4 章では，金庫と
いう身近なシステムを例として取り上げ，RODAN を
適用する．適用した結果では，問題文には提示されて
いなかった要求が，個人の視点を導入することによっ
て発見できることを示す．5 章では，RODAN を適用
する効果と，実システム開発への適用方法と課題につ
いて考察する．また，6 章では，RODAN の関連研究
を紹介し，最後にまとめる．
2.ロールに着目した RODAN の分析プロセス
この章では，ロールに着目した RODAN の分析プ
ロセスを 3 種類のタスクに沿って解説する．
2.1ステークホルダ分析
溝口らのオントロジによると，ロールは，基本概念，
ロールホルダ，ロールの 3 層構造の一部を占める概念
である22)．RODAN の最初のタスクであるステーク
ホルダ分析では，基本概念である「人」が，どのような
ロールホルダを持ち，そのロールホルダにどのような
ロールが保持されているかを明らかにする．他のロー
ルホルダが保持するロールとの依存関係は，ビジネス
関係者の業務の背景を表す．
たとえば，ある人 “鈴木一郎” が，発注を行う業務を
担当するビジネスについて考えてみる．この例を図 1
に RODAN のロール依存モデルを用いて表した．ロー
ル依存モデルは，遂行ロールとしての Actor，受益者
ロールとしての Customer，そして，指示ロールとし
2536情報処理学会論文誌Aug. 2007
図 1ロールホルダ，ロール，リソースの関係を表す例（ロール依存モデルによる）Fig. 1An example of role holders, roles and resourceswith Role Dependency model.
ての Owner の 3 種類の依存関係を，ロールホルダとと
もに示すモデルである．このモデルでは，四角形を用
いてビジネスリソースを，楕円によってビジネスゴー
ルを，六角形を用いてビジネスプロセスを表し，人型
でロールホルダを表す．C，A，O のラベルが付けら
れた四角形は，それぞれ Customer，Actor，Owner
の各ロールを表す．ロールと，ビジネスリソース，ビ
ジネスゴール，ビジネスプロセスは，依存線によって
結ばれ，各ロールをどのロールホルダが保持し，ロー
ルホルダ間にどのような依存関係が存在するかが示さ
鈴木一郎は基本概念「人」に相当する実体である．
図 1 で，彼のロールホルダは，発注業務を担当し，そ
の業務に責任を持つという意味において，“注文” リ
ソースの提供者である Actor ロールと，持ち主を表
す Owner ロールを担っている．また，発注された “商
品” に着目すれば，彼は商品を受け取る受益者である
Customer ロールを保持すると考えることができる．“注文” リソースの Customer は受注者が担うロール
であり，“商品” の Owner は商品の持ち主のロールで
あり，Actor は商品の生産者のロールである．しかし，“鈴木一郎” の立場からは，これらのロールが受注者
によって担われているように見えている．したがって，
これらのロールは，受注者のロールホルダに保持され
ているものとして可視化されている．2.2課 題 分 析
次の課題分析は，ロールを担うことによって実体が
かかえる課題を抽出するタスクである．通常，ビジ
ネス領域で業務を行っている実体は，その業務で担う
ロールに依存した複数の価値観を持っていると考えら
れる．課題分析では，各ロールに着目し，個人の意見
を，各ロールの意見として表す．たとえば，「× × の観
点から見ると，○ ○ である必要がある」などには，発
言者の業務上の責務に基づいた価値観が現れている．
続いて，「しかし，同時に，△ △ も無視できない」と
いった対立する意見が，同じ発言者から発せられるこ
ともある．これは，ある実体に対応するロールホルダ
が複数のロールを持っている例であり，それらのロー
ルの間で，意見が対立していることを表していると考
えることができる．ここで，関係者が了解しなければ
ならない事柄とは，個人の意見は，個人が担っている
個々のロールに由来しているという状況である．2.3折衝
最後の折衝では，2 つのことを行う．第 1 にロール
ごとに課題の解決策を求め，次に，ロールごとに定義
された課題の解決策の中から，ビジネス組織として選
択すべきシステム要求を選別し，ロール間での矛盾を
解消したり，優先順位付けを行ったりする．このとき，
課題や解決策をステークホルダが了解するために，ビ
ジネスプロセス，ビジネスリソース，ビジネスルール
が参照される．これらを表すモデルは，関係者である
個人が，ビジネス領域で観察している現象15) を可視
化するために作成されたモデルである．
2.4プロセスの概観3 つのタスクによって，関係者達は，個人が認識し
ているビジネス領域のモデルを参照できるようになる．
たとえば，ロール依存モデルは，個人の立場を伝える
情報として読み解かれる．モデルから得られる情報は，
個々の関係者が認識する課題と解決策の妥当性を表す
根拠を示すものである．RODAN は，関係者に，他の
関係者の課題や解決策の妥当性を了解するためのモデ
ルを提供する．ここで「了解」とは，理解したと納得
するという意味であり，理解する対象が良い，悪いと
いう判断を含んではいない．RODAN は，このような
ビジネス領域のモデルを表すために，複数の手法を組
み合わせて構成されている．
3.RODAN の開発
我々は，RODAN を構成する手法を検討するため
に，RODAN を適用して得られる成果物のメタモデ
ルを開発した．この章では，RODAN のメタモデルが
満たす条件を示し，次にメタモデルの解説を行う．ま
た，既存手法を拡張し，適用した例を示す．
3.1メタモデルの条件
ビジネス領域のモデルが要求の背景や妥当性の根拠
を表すために，そのメタモデルは，以下の条件を満足
しなければならない．
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2537
図 2成果物視点における RODAN のメタモデルFig. 2Metamodel of RODAN in a product perspective.
• ステークホルダを取り巻くビジネスの環境を，ス
テークホルダが担うロールホルダとロールによっ
て表すこと．• ビジネス領域におけるロールの存在理由を，ロー
ル間の依存関係により表現できること．
• 個人が認識している課題を，ロールホルダと，そ
れに保持されるロールとの間の関連属性として表
すこと．なぜならば，課題とは，ある人が特定の
ロールを担うことによって認識されると考えるか
らである．• 課題と，それを解決するための策を，課題を解決
するために設定されたゴールと達成手段との関係
によって表せること．この関係によって，「× × と
いう課題を解決して，△ △ を達成すべきである」
という個人の動機と，提案された解決策の合理性
がモデルとして表現できるようになる．• 個人が達成すべきであると考えるゴールと，個人
の現在のビジネスの状況，すなわち，プロセス，
リソース，ルールとが関連づけられること．
3.2成果物視点に基づく RODAN のメタモデル
我々は，これまで RODAN のメタモデルを検討し
てきた23),24) が，ロールとロールホルダ，個人という
3 層構造の検討が不明確であり，その結果，個人が認
識する課題と，課題の背景を明確には峻別できてはい
なかった．そこで，RODAN の成果物視点に基づくメ
タモデルに溝口らのオントロジを導入し，ロール，お
よびロールホルダという概念を用いて再構成した．こ
れを図 2 に示す．
図中，溝口らのロールに対応する概念は，コンテキ
スト依存ロールとして表されている．ロールが依存
するコンテキストは，ロールコンテキストである．こ
れには，タスク遂行，リソース共有，ゴール達成の依
存関係がある33)．コンテキストに依存するロールに
は，遂行ロールとしての Actor，受益者ロールとして
の Customer，そして，指示ロールとしての Owner の
3 種類を設けた9)．
図中左下部のビジネスコンテキストとは，個人が認
識している課題の背景を構成するビジネスを表す．こ
のモデルには，時系列で複数のモデルが対応すること
もありうる．たとえば，課題を含む現在の状況と，課
題が解決されている将来の状況などである．ビジネス
コンテキストは，ビジネスルール，ビジネスプロセス，
ビジネスリソースから構成される．ビジネスコンテキ
ストは，個人が課題を認識したり，理想とするビジネ
スを表しているものであって，関係者で了解されるべ
き対象となる．
次の項では，既存の手法を拡張して，RODAN の部
分的な手法として適用することを検討する．
3.3既存手法の適用の試みRODAN のメタモデルは成果物視点に基づいてい
る．この成果物は，既存の手法を適用して得られる
部分もある．そこで我々は，まったく新しい手法とし
2538情報処理学会論文誌Aug. 2007
て RODAN を開発するのではなく，既存の手法を手
法断片として適用し，手法の接続部分を補完しながら
RODAN を開発することを目指した7)．
図 2 では，適用する手法断片を点線で囲んだ．既存
の手法は，その手法が，RODAN のメタモデルの一部
を網羅しているのであれば，手法断片として RODAN
に適用可能である．
ここでは，i*の戦略依存モデル33) とゴール指向分
析を例として取り上げて適用例を紹介する．3.3.1i*の 適 用
i*における戦略依存モデル33)，あるいはアクタ依存
モデル35) のメタモデルは，ロールコンテキストを表
す部分のメタモデルに対応する．戦略依存モデルでは，
アクタ間の依存関係はゴール，ソフトゴール，リソー
ス，タスクの 4 種に分類される．RODAN では，ゴー
ルに対して，現実世界の「人」が，どのようなロール
を保持しているのかが分析の対象である．そのため，
ゴールをハードゴールとソフトゴールとに分類するこ
とに注力せず，両者を同じゴールとして取り扱う．ま
た，アクタに対して 3 種類のコンテキスト依存ロール，
すなわち，Owner，Customer，および Actor を追加
して i*を RODAN の手法断片とする．
RODAN のロール依存モデル（図 1）は，戦略依存
モデルを拡張して開発したモデルの事例である23)．i*
の戦略依存モデルでは，それぞれの依存関係がアクタ
間の二項関係として定義されるが，ロール依存モデル
におけるロール間の依存関係は，3 種類のコンテキス
ト依存ロールによる多項関連として定義される．i*では，戦略依存モデルに基づいてシステム化境界
を定め，戦略合理モデルを作成する．これによってシ
ステムを組織の中に取り込み，システムとアクタとの
依存関係を明らかにすることが可能となる．ただし，
ビジネス領域では，ビジネスプロセスの変革や，リ
ソース構造の見直しを含めたビジネス改革が必要とな
ることも少なくない．したがって，個人が担っている
ロールに基づいて，解決すべき課題とそれに対する解
の合理性を明示しなければ，システムへの要求を定義
することはできない．
すなわち，要求獲得の第 1 段階としてすべきこと
は，各人のゴールやゴール達成のために定義された要
求の合理的な背景を，ロールコンテキスト，コンテキ
スト依存ロール，問題意識，課題というオブジェクト
を可視化することである．次に，これらの背景に基づ
いて，各人の問題意識と課題を関係者が了解し，組織
が目指すべきゴールや解決策としてのシステムへの要
求を定義する．我々は，これらのプロセスを経ること
で，開発後に担当者が変更になったり，組織の力関係
が代わったりすることによる要求変更を避ける道が拓
けると考えている．3.3.2RODAN の適用例：提案書作成支援シス
ここでは，提案書作成支援システムの要求獲得を例
として取りあげ，RODAN の適用方法を紹介する．提
案書を作成して，それを再利用するというビジネス領
域の場合，コンテキスト依存ロールは，以下のように
• コンテキスト：タスク遂行「提案書作成」– 指示ロール（Owner）：提案書作成指示者
– 遂行ロール（Actor）：提案書作成者– 受益者ロール（Customer）：提案書の読者，
• コンテキスト：ゴール達成「先進的な技術を活用
し，顧客に提案する」
– 指示ロール（Owner）：ゴール設定者，ゴー
ル達成評価者– 遂行ロール（Actor）：技術活用者，計画者
– 受益者ロール（Customer）：技術成果享受者
（＝顧客），技術参照者
• コンテキスト：リソース共有「先進的技術の共有」– 指示ロール（Owner）：技術共有の指示者– 遂行ロール（Actor）：共有技術の管理（登録，
削除，更新）者，利用者，研究開発者– 受益者ロール（Customer）：技術の利用者
図 3 に提案書作成に関するロール依存モデルを示
した．このモデルでは，，課題や問題意識のコンテキ
ストがロールの依存関係によって表されている．ロー
ル依存モデルに表されたロールの依存関係から，以下
のことが読み解ける．
• 提案書作成の生産性が低い原因は，シーズを役立
てる責務を持つ営業担当者にシーズ自体が理解さ
れていないことにありそうである．なぜならば，
モデルに以下の状況が示されているからである．( 1 )B 氏は，「提案書」というビジネスリソー
スを生成する Actor としての責務は自分に
あると考えており，
( 2 )このリソースに対する Owner としての権
限も自己が保持していると考えている．一
( 3 ) 「シーズを役立てる」Actor は営業担当者
☆ この事例は，株式会社 NTT データの寺越貞行氏にご提供いただきました．この場を借りて謝意を表します．
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2539
図 3提案書作成ビジネス領域のためのロール依存モデル（ある提案書提出者の視点による）Fig. 3A Role Dependency Model for a proposal reuse business domain (from a proposer’s view).
であるにもかかわらず，( 4 ) 「提案書作成」というビジネスプロセスの
Actor は，研究開発部門の R 氏であり，( 5 )営業担当者の B 氏は，提案書作成の指示者
である Owner，受取人としての Customer
というロールしか持っていない．( 6 )営業担当者 B 氏には，「顧客のニーズに対
して，自社のシーズがどのように使えるの
かが分からない」ことが原因で，「自分で
提案書は書けない」という問題意識がある．( 7 )シーズは研究開発部門の研究成果として事
業部長 E 氏に保持されており，営業担当者
の B 氏には参照できない．
この課題を解決するための方策を考案する前に，
ここでは，営業担当者 B 氏の問題意識の状況を
モデルから読み解いた．このビジネス領域の課題
はほかにもある．• 市場のニーズが，営業担当者，事業部長，および
研究開発部門で共有されていない．
( 8 )業務発注者が保持し，発する「要望＝ニー
ズ」は営業担当者の B 氏は把握している
が，その他の人々には共有されていない．• シーズとニーズの関連づけが営業担当者には把握
されていない．
( 9 )本来，提案書とは，ニーズに対するシーズ
を関連づけて売り込むための書類である．
したがって，提案書作成とは，ニーズとシー
ズとを関連づける作業ということになるが，
この作業は，研究開発部門の R 氏が行って
おり，営業担当者の B 氏は行っていない．
このような状況では，営業支援部隊が提案書のデー
タベースという器を提供しても，B 氏がかかえる問題
は解決されないであろう．ロール依存モデルで得られ
た問題の原因をより詳細に理解するために，B 氏のビ
ジネスコンテキストを分析してみることにした．
ビジネスプロセスのモデルでは，B 氏が業務発注者
を訪れて対話を行い，電話メモを含めた営業記録を残
す活動を行い，後に，これらの情報を研究開発部門のR 氏に渡して提案書の作成を依頼していることが分
かった．しかし，図 3 の研究開発部門 R 氏の吹き出
しには，「研究成果がニーズと結びつかないことが問
題」であると書かれている．このことから，研究開発
部門の人にも，ニーズがうまく伝わっていない現状が
理解できる．現状のシーズとニーズの構造がどのよう
に B 氏には理解されているのかを明らかにするため，
シーズとニーズというオブジェクトの構造を，ビジネ
スリソースの構造として構成してみることにした．
図 4 にシーズとニーズ，および，それらを取り巻
く人々，情報の「a. 現状を表すビジネスリソースモデ
ル」と，議論の結果導かれた「b. あるべきビジネスリ
ソースモデル」を示す．図 4 (a) によると，業務発注
者は，ニーズを認識しており，そのニーズが技術要素
を参照していることが示されている．また，研究開発
部担当者は，研究開発者として先端技術を参照してい
る．さらに，先端技術は，様々な技術要素をシーズと
して参照していることが示されている．このリソース
2540情報処理学会論文誌Aug. 2007
図 4現状，およびあるべきビジネスリソースモデル（ある提案書提出者の視点による）Fig. 4Business resource model for the proposal reusebusiness domain (from a proposer’s view).
モデルは，営業担当者 B 氏へのインタビューによっ
て，業務発注者からのニーズの提示の仕方と，研究開
発部担当者 R 氏からの自社のシーズに関する説明を
受けた状況に基づいて定義したものである．したがっ
て，このモデルは，B 氏が認識している B 氏のビジ
ネスコンテキストを表しているモデルである．
図 4 (a) では，同じ「技術要素」という言葉が，業
務発注者と研究開発部担当者から参照されている．そ
こで B 氏に問いかけたところ，業務発注者が使って
いる技術要素と，研究開発担当者が使う技術要素とで
は，用語は同じであるが，詳細度，専門性という観点
から，対応づけることが困難な意味を持つことが明ら
かとなった．これが，B 氏が図 3 で「自分で提案書を
書けない」と発言した原因であろう．
そこで，この問題を解決するためのモデルを作成す
るにあたり，提案書の意味を変えることにした．すな
わち，従来から提案書が持っていた意味「提案活動に
よる営業記録の一種である」に加えて，業務発注者側
の “技術要素” と，研究開発部担当者の “技術要素” を
各々“ニーズ要素”，“シーズ要素” と名づけ，「両者を
関連づけるオブジェクトである」という意味を付加し
て提案書をとらえ直したのである．こうして定義され
たリソースモデルが，図 4 に示した (b) のモデルで
(b) のモデルには，まだ，再利用のためのリソース
のアクセス権限を表す構造が考慮されていない．提案
書の生産性向上というゴールの Owner は，図 3 には
現れていない営業部の責任者である．営業部の責任者
へインタビューを行うことによって，提案書を営業部
内でどのように流通させるべきと考えているのかを明
らかにできるだろう．
ここで示したように，現状の課題を解決するにあたっ
て，リソースモデルに対する意味的な解釈を変更する
必要が生ずるような範疇の問題は，i* 33) や KAOS 8)
のようなゴール指向分析だけでは解くことができない．
3.3.3ゴール指向分析の適用
この項では，一般的な目的–手段展開を行うゴール
指向分析を RODAN に適用することを検討する．
RODAN では，ゴールモデルにロールの視点を導入
する．これによって，現状のゴール指向分析がかかえ
る以下の問題を解決することが可能となる．( 1 )トップゴールの抽出が煩雑である．
ゴールに所有者という，課題を解決する責任者が
担うロールを導入して，トップゴールを定める．( 2 )分析範囲を明確化することが困難である．
ビジネス領域では，権限の委譲や業務の指示が
日常的に行われている．これは「ゴール達成の
委譲」であると考えられる．現実世界のゴール
の委譲という事象をゴール指向分析へ取り込む
ために，「トップゴールから開始されたゴール
分析は，他者へサブゴールを委譲したところで
止める」というルールを設ける．このルールに
従うと，システムが達成すべきゴールが得られ
たところで，システムへゴール達成を委譲でき
る．これによって，不適切にゴールを展開する
ことによって，権限外のゴールの達成手段が定
義されるのを避けることも可能となる．
上記の ( 2 ) にあげた課題は，KAOS でもゴールモ
デルの枝刈り方法の基準として，以下のルールが定義
されている8)．
「求めたゴールや手段に対して，アクタを割り
当てた時点で，ゴールの詳細化を停止させる．」
我々が提案する RODAN と KAOS の差異を明確に
するために，RODAN のゴールの分析を停止させる
ルールを，KAOS の用語で説明すると，以下のように
「アクタが自分で認識する自分のゴールを詳
細化する過程で，他のアクタに委譲したゴー
ルや手段を発見できたときには，そこで，自
分のゴール分析を停止させる．」
RODAN でゴール分析を行うのは，ゴール達成を責
務としている当事者である．そのため，アクタは最初
から割り当てられているのである．このようなゴール
分析の停止は，分析者であるアクタの思い違いである
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2541
図 5誤解を生じているゴールモデルの例Fig. 5An example of a misunderstanding about the goalmodel.
可能性はある．しかし，他者が提示するゴールモデル
のトップゴールと，当人が委譲したゴールとが一致す
れば，少なくとも仕事の指示は伝達されていることが
確認できる．一致するトップゴールが見つからなけれ
ば，関係者の間で業務の誤解があることになる．
ゴールの達成を委譲するアクタは，ビジネスリソー
スやビジネスプロセスを再編する工程で決定され，同
時に他の組織との調整が行われる．ビジネスゴールは，
委譲する側と委譲される側とで矛盾なくゴールが遂行
されなければならない．KAOS のルールでは，このよ
うなビジネス特有の制約が考慮されていない．
したがって，ビジネスゴールのモデルでは，ゴール
の所有者（すなわち，ゴールの達成責任者）を識別す
るための表記が必要となる．ここで紹介する例では，
その表記として，ゴールモデルに UML のアクティビ
ティ図で用いられているパーティションを導入する．
パーティションの中には，ロールとゴールモデルの組
が表される．RODAN では，ゴールの所有者の視点
を導入したゴールモデルを所有者別ゴールモデルと呼
たとえば，図 5 のような所有者別ゴールモデルが
定義されたと仮定しよう．このモデルによると，A 氏
は，自分が導出した複数のサブゴールや手段の達成を
他者に委譲したと思っている．ここで B 氏のゴール
モデルを参照すると，A 氏から委譲された権限と責務
が認識されているか否かを観察できる．ここでは，A
氏が委譲していないゴール X を B 氏が委譲されたと
理解している一方で，A 氏が委譲したゴール Y は，B
氏も達成する責務があると認識していることが読み取
れる．また，A 氏が他者へ委譲した手段 Z は，誰が実
現するかが不明であることも分かる．
現実世界では，当事者間で様々な誤解が発生してい
ることがある．このような誤解をモデルによって可視
化できれば，ビジネスの遂行を今よりも円滑化できる
図 6ロール依存モデルの例Fig. 6An example of a role dependency model.
3.3.4手 法 統 合RODAN のメタモデルに示したように，個人がロー
ルを担うことによって，個人は現状の課題を認識し，
そこからゴールを導出する．ここまでで示したロール
依存分析と所有者別ゴール分析を連携させるためには，
ロール依存モデルから，ロールのトップゴールを得る
ための手段を方法論として提供しなければならない．
同時に，個人的な思い込みによって発せられたゴール
は一種の夾雑物でしかないため，ゴール分析を適用す
る前に排除する必要がある．
たとえば，個人的なゴールとは，「残業が減ってい
る状況」，「給料が増えている状況」といった状況を求
めるゴールである．残業を減らすことは，人の願いで
あるかもしれないが，組織として解決すべき優先的な
課題であるとは限らない．個人的な願いや希望は，個
人のトップゴールとして定義されたとしても，他者か
らは委譲されないゴールである．ゴールは，関係者か
ら了解されるような組織的なゴールでない限り，分析
対象からは外すべきである．
以下では，2 つの分析手法を統合するための方策の
機構を概観する．
( 1 )コンテキスト依存ロールからロールホルダを介
したロールの因果関係を推移的にたどり，( 2 )個人的ゴールと組織的に与えられたゴールとを
識別する．( 3 )組織的に与えられたゴールは，個人が達成する
責務を与えるゴールとする．したがって，この
ゴールは，所有者別ゴールモデルのパーティショ
ン内のトップゴールとなる．
図 6 に示したロール依存モデルを例として用い，
ビジネスプロセスとビジネスゴールの依存関係から，
Actor，Owner，Customer を端に持つ多項関連を解
釈するプロセスを以下に解説する．( 1 )あるビジネスプロセスを実行する責務を持つの
は，Actor ロールを持つロールホルダ X である．( 2 )このとき，このプロセスの実行を Actor に指示
する責務はプロセスの Owner ロールを保持す
るロールホルダ Y が持つ．したがって，
2542情報処理学会論文誌Aug. 2007
( 3 )このプロセスを実行することによって達成すべ
きゴールは，プロセスの Owner であるロール
ホルダ Y に所有されていると考えなければな
らない．Actor のロールホルダ X 氏は，Y 氏
からプロセス実行を委譲されていると考える．
( 4 )このとき，このビジネスプロセスの Customer
は，プロセスの Owner であるロールホルダ Y
が知っているはずである．なぜならば，( 5 )ロールホルダ Y がこのプロセスの実行を X 氏に
指示した理由は，図に示されたビジネスゴール
の Owner ロールのロールホルダ Z 氏からゴー
ル達成を指示されたからである．
( 6 )これは，ビジネスプロセスの Customer が，Y
氏にゴール達成を委譲した Z 氏となっているこ
とから理解できる．
依存関係のたどり方を，現実世界の言葉でいうなら
ば，「Y が X に業務を指示した理由は，Y が Z のため
にゴールを達成しなければならないからである」とい
うことになろう．実際には，ゴールを達成するための
プロセスは，ゴールモデルに表されるように多岐にわ
たる．したがって，ここで示した例のように単純な推
移関係にはならないかもしれない．しかし，ビジネス
が指示命令系統に沿って円滑に遂行されるためには，
ここで例示したロールの依存関係の連鎖が存在するは
この例では，ロールホルダ Y を所有者とするゴー
ルモデルには，Z から委譲されたゴールがトップゴー
ルとして定義され，X へは，このトップゴールのサブ
ゴールとして定義される実現手段がトップゴールとし
て委譲される．3.4実用に向けた検討
我々は，要求を獲得する際には，その前に，できる
だけ現実世界に根差した情報を収集し，そこから抽象
化の手続きを経て，要求の根拠をモデル内に明示し，
そのモデルを介して，関係者が要求の妥当性を了解す
る必要があると考えている．これは，度重なる要求変
更の原因の中には，獲得された要求の中に，個人的な
思い込みや勘違いが含まれていることも多いと考える
からである．個人の視点で要求の背景をモデル化する
ことによって，関係者の了解できない要求は排除され，
かつ，個人の発する問題が共有可能となる．このよう
なプロセスを経ると，これまでの要求獲得に比べて時
間がかかることになるであろう．しかし，品質の高い
要求仕様14) を得て，組織として妥当な要求を得るた
めに，その時間は必要である．
根拠のない要求に基づいたシステム開発が成功する
可能性は低い．現実世界の要求者は複数の業務をかか
えており，個人の中で複数の価値観が競合している．
RODAN の要求獲得のプロセスでは，このような複雑
に絡み合った個人の意図や思いを，ロールという概念
によって関心の分離を行うことができる．
次の章では，ロールに着目することによって，脱落
している要求を発見する過程を具体的に示すことにす
る．次章で，あえて我々が，金庫という非常に小さい
問題を取りあげるのは，システム開発者にとって，提
示された要求をそのまま信じること自体が，要求の脱
落を招く危険がある事例を示すためでもある．分析の
結果，業務担当者が抱える課題を明らかにでき，そこ
から脱落要求を獲得することができた．
4.例題への適用
RODAN は要求獲得プロセスで適用される手法で
ある．しかし，RODAN の成果物は，そのメタモデル
で示したように，ステークホルダの識別，ロールホル
ダの識別，依存関係の同定，課題の抽出，ゴールの導
出，ゴールおよび課題の背景を明示するためのビジネ
スモデリングという複数の分析プロセスの成果物から
構成される．しかし，あらゆるビジネス領域の分析に
おいて，これらのプロセスが必要であるわけではない．
課題に対応して分析するプロセスや分析の範囲は異な
る．この章で取り扱う例題は，小さな問題である．し
かし，それでも，より高い品質の要求を得るためには，
ビジネス領域の分析を行って要求の根拠や背景を明ら
かにする必要がある．4.1金庫の要求文32)
図 7 に示すようなホテルの宿泊室に設置する小型
の金庫を想定した要求文を以下に示す．• ご利用に際して
あなたの金庫番号は 125 です．いま扉は閉まって
いて施錠してあります（施錠灯が点いています）．
金庫番号の書かれた物置の扉にはパネルがあり，
そこに，施錠灯，0 から 9 までの押しボタン，C，L の押しボタン，十進数字 4 桁の液晶表示窓，90
図 7金庫のイメージFig. 7The image of the safety-deposit box.
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2543
度回転する取っ手が付いています．扉の開けかた( 1 )数字ボタンを 1234（施錠鍵といいます）と
左から順に押してください．( 2 )押した数字を表示窓で確認してください．( 3 )それが 1234 であれば施錠灯が消えます
（開錠）．( 4 )そこで扉の取手を時計回りに 90 度回して
手前に引けば扉が開きます．( 5 )数字ボタンを押し間違えたときは，C ボ
タンを押して，初めからやり直してくださ
い（C ボタンを押すと表示窓の数字が消え
• 扉の閉めかたと施錠( 1 )扉を閉め取手を逆時計回りに 90 度回しま
す（機械的な施錠）．
( 2 )L ボタンを押します（電子的な施錠）．( 3 )ここで施錠灯が点きます（直前に扉を開け
たときの，あるいは，次項によって変更し
た鍵による施錠）．( 4 )その後は開錠手続きをしない限り，取手を
回して引いても扉は開かないはずです．• 鍵の変えかた
施錠灯が消えているときに，次のようにして好み
の鍵にすることができます．( 1 )数字ボタンを 4 回押す．この 4 数字が新し
い施錠鍵になりますので必ず表示窓で確認
のうえご記憶ください．
( 2 )ついで L ボタンを押します．そこで鍵が登
録され，表示窓の数字が消えます．
以上4.2分析プロセス
金庫は，ビジネスプロセスを変更するための手段で
はなく，また，ビジネスリソースの構造に変化をもた
らすことが意図されるものではない．そこで，金庫
の要求文には示されていない要求を抽出するために，
ロール依存分析と所有者別ゴール分析を適用して金庫
の課題を分析する．このシステムのステークホルダと
彼らの意図は以下のとおりである．
支配人 GM 氏宿泊客自身が貴重品を保管できるよ
うに，各部屋への金庫設置を検討したい．
保守的ホテル従業員 SA 氏宿泊客の貴重品を宿泊客
責任で管理させれば，紛失というリスクを負わず
に済むだろう．
献身的ホテル従業員 SB 氏宿泊客の貴重品をフロン
トで保管することがサービスである．
泥棒の D 某，または悪意のある従業員 U 氏 宿泊部
図 8金庫に関わるロール依存モデルFig. 8Role Dependency Model for the safety-deposit box.
屋内の金庫から貴重品を盗みたい．
理想的な宿泊客 A 氏指示に従って金庫を使いたい．
物忘れがちな宿泊客 B 氏鍵を紛失しても，何とか
貴重品を回収したい．
不注意な宿泊客 C 氏金庫に貴重品を預けたまま
チェックアウトしたとしても貴重品は回収したい．
短気な宿泊客 D 氏好きなときに自分の貴重品を取
り出したい．
個人の意見を求めると，このように，何を是とし，
何を否とするのかという価値観が異なることは多い．
上記の意図をもとに，ロールホルダ間のロール依存関
係を分析した結果を図 8 に示す．ロール依存モデルや
所有者別ゴールモデルを用いることによって，自分が
設定しているゴールやプロセスが，自分自身の思い込
みによって設定されたものであることに気づくことが
たとえば，GM 氏は，「宿泊客自身が貴重品を保管
するために，各部屋に金庫を提供すること」が，「顧
客の満足度を高める」責務を持つ支配人として，行う
べき仕事であると考えている．おそらく，支配人の立
場では，信頼がおける従業員ばかりではないこと，あ
るいは突発的な健康上の問題や事故から，つねに従業
員に対して完全な職務遂行を期待すること自体が現実
的ではないというリスクへの対処も考える必要があろ
う．しかし，献身的ホテル従業員 SB 氏は，「宿泊客の
満足度を高める」ためには，「宿泊客の貴重品が安全
に保管されている」というゴールを達成するために自
分自身が働かなければならないと考えている．また，
支配人が各部屋に金庫を設置するということは，貴重
2544情報処理学会論文誌Aug. 2007
図 9金庫のゴールモデルFig. 9A goal model of the safety-deposit box example.
品を管理するという業務に対して，従業員の Actor の
ロールを解消することにほかならない．したがって，
金庫を導入することは，たとえば献身的なホテル従業
員にとっては賛成できないことかもしれないが，支配
人が金庫を設置する意図を理解すれば，金庫導入を了
解することは可能であろう．
図 8 の各依存関係に定義されているロールをたど
り，金庫の設置に関するロールの依存関係から導出し
た，所有者別ゴールモデルを図 9 に示す．
図 8 と図 9 に振った関連する番号に沿って，ロー
ル依存モデルから，所有者別ゴールモデルを得る過程
を解説する．( 1 )支配人 GM 氏は，自身が Owner となっている
ゴール「宿泊客の満足度を高める」を持ち，さ
らに，このゴールの Actor となっている．
( 2 )GM 氏の「宿泊客自身が貴重品を保管．．．」は，
ゴールの実現手段であることがインタビューに
よって明らかとなろう．このようなゴールと手
段の関係を構成した結果，GM 氏のゴールモデ
ルが作られる．GM 氏のゴールモデルでは，こ
れ以降，金庫設置に関する手段展開が分析され，
定義される．
( 3 )また，SA 氏は，「宿泊客の満足度を高める」のActor である．これは GM 氏より委譲された
ゴールである．献身的な従業員 SB 氏も同様で
ただし，顧客満足度を向上させるというゴールはホ
テル業務全般に対するゴールであり，金庫に特化した
ゴールではない．したがって，SA 氏と SB 氏のゴー
ル分析は，GM 氏から委譲される別のゴールに分析の
焦点を当てるべきである．以上から，両者が設定して
いる Actor としてのゴールやプロセスは，個人的な思
い込みによる個人ゴールとして分析対象から外すこと
( 4 )保身的な従業員 SA 氏は，ゴール「宿泊客の貴
重品が安全に宿泊客によって保管されている」
の Owner であるが，上記の理由により，この
ゴールは GM 氏から委譲されていないため排
( 5 )献身的な従業員 SB 氏は，宿泊客を Owner とす
る依存関係を Actor として持つ．これらは，最
初に GM 氏より委譲されたゴール「宿泊客の満
足度を高める」の実現手段であるが，GM 氏が
部屋に金庫を設置した時点で，SB 氏の Actor
としての意味は消滅する．したがって，このゴー
ルは分析対象からは外れる．( 6 )宿泊客は，これらのホテルの従業員とは独立で
あるため，従業員からのゴールの委譲は生じな
い．したがって，宿泊客のトップゴールは，「宿
泊客の貴重品はいつでも自由に出し入れ可能で，
安全に保管されている」となる．
( 7 )最後に泥棒や悪意のある従業員のトップゴール
は，貴重品というリソースを受け取るというCustomer としてのゴール「宿泊客の貴重品を
取得する」が定義されている．これは，顧客や従
業員とは独立した営みであるため，トップゴー
ルとなる．( 8 )宿泊客には様々な人々がいる．「いつでも自由
に出し入れする」や「安全」という意味を考え
ると，個々の人々の習性を列挙する必要がある．
ゴールモデルには，特異な宿泊客のみを取り出
し，それらへの配慮が必要であることを示せば
よいであろう．
「宿泊客の貴重品がホテルによって安全に保管され
ている」というゴールは，支配人から指示された「顧
客の満足度を高める」を実現させるために従業員が定
義したゴールである．このゴールは，前者のゴールのActor ロールを根拠として導出されたものであり，「顧
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2545
客の満足度．．．」の Owner である支配人が，その手段
として金庫の設置を決定したために，意味を持たなく
なった．以上から分かるように，Actor というロール
から導出されるゴールは不安定であり，分析対象とす
る有意性は低いと見なせる．RODAN では，ロール
の依存関係をたどって，ビジネス領域の根源的なゴー
ルの Owner からゴール指向分析を行う．この例では，
ロール依存モデルから所有者別ゴールモデルに受け渡
されるゴールは，支配人，宿泊客，泥棒のゴールのみ
金庫の可用性として，緊急時には施錠者以外の信頼
できるアクタによっても解錠できるという制約を満足
しなければ，宿泊客が求める「誤った使い方をしても，
金庫の貴重品が安全に手元に戻る」というゴールを達
成できない．図 9 では，このような状況が，負の貢
献として表されている．図中，影を付けたゴールは，Owner が他者へ委譲すると決断したゴールを表す．ま
た，※ を付与した委譲ゴールは金庫システムへの要求
を表している．したがって，委譲されるゴールの上位
ゴールは，システム要求の根拠を表す．金庫の要求文
に基づいて，実際にトップゴールの所有者別にゴール
指向分析を行うと，機能要求は現れない．システムに
対して金庫の開扉，閉扉，施錠，解錠，鍵の登録，鍵
の消去といった機能要求を出すためには，図に現れて
いる人々から金庫に委譲されたゴールを，金庫のトッ
プゴールとした金庫のゴールモデルを定義する必要が
ある．金庫への機能要求は，これらのトップゴールか
ら導出される．
暗証番号を金庫を施錠/解錠する鍵として使うこと，
そして，それが 4 桁の数字であるという機能要求は，
金庫が達成すべきゴールに対して，Chung らの非機
能要求10) のフレームワークを適用することで得るこ
とができる．4.3機能要求の再検討
システムの機能要求が獲得できた後，それらをユー
スケース図として表記することが一般的になってきた．
ユースケース図を表すことで，ミスユースケースを発
見することができる1)．また，ミスユースケースを緩
和させるための手段として，新たな機能も得ることが
できる．図 10 に，前節で述べた開扉，閉扉をはじめ
とした金庫の 6 つの機能に対して，ステークホルダ分
析で抽出した関係者をネガティブアクタとして設定し，
ミスユースケースを検討した．ただし，これらのネガ
ティブアクタがシステムに対してどのような働きかけ
をするかは，ゴールモデルにすでに表されている．所
有者別ゴールモデルに基づいて，システムの機能に対
図 10金庫のミスユースケースとユースケースFig. 10Use Case Diagram for the safety-deposit box withmisuse cases.
して脅威を与える行動を定義すれば，それをミスユー
スケースとすることもできる．このようなミスユース
ケース発見手順は完全ではないかもしれないが，思い
つきによってネガティブアクタを表す16) よりは，妥当
性が高く，また効果的であると考えられる．ミスユー
スケースを検討した結果，要求文に記述されている要
求のほかに，非常時に特別な権限を持つ人だけには，
解錠が許可される機能，そして，その権限を悪用され
ないために，権限を利用した解錠が記録される機能が
必要であることが示された．4.4その他の要求の獲得に向けて
ここまでで，金庫問題に対して，ロール依存モデル
と所有者別ゴールモデルを適用して要求を抽出する過
程を解説した．また，ミスユースケースと照合して，RODAN によるアクタ抽出の方が妥当性が高いこと
を示した．さらに，1 人の宿泊客に着目して，ホテル
へチェックインした後，様々なホテルの施設を利用し，
チェックアウトするまでのプロセスを分析したり，1 つ
の部屋に着目して，複数の宿泊客が部屋の金庫を利用
するプロセスに着目した分析を行うことも，RODAN
の要求獲得プロセスには含まれる．これらの視点で
ビジネスを分析することによって，金庫に対する制約
（ビジネスルール）として，以下の事項を定義できる
ようになる．• 保管依頼者に，確実に保管物を返却しなければな
そのためには，保管物を返却するときに，取り出
し要請者が元の依頼者であることを認証する必要
がある．暗証番号は認証のための手段である．暗
証番号を設けるとすると，
• 貴重品を保管する依頼者を記憶すべき期間を定め
る必要が生ずる．
2546情報処理学会論文誌Aug. 2007
たとえば，登録済み鍵が有効である期間はいつか
らいつまでが妥当であろうか．ただし，保管依頼
者が変わるという現象は，金庫というマシンには
共有されない37)．したがって，1 度目の依頼者と2 度目の依頼者を識別することは金庫にはできな
い．そのため，• 保管物を返却するたびに，金庫は保管依頼者を忘
れなければならない．
5.RODAN の評価
5.1例題による評価結果
金庫問題の分析でロールを導入することによって得
られた効果を以下にまとめる．• ビジネス領域における個人のロールと，ロールの
コンテキストとなっている他のロールとの依存関
係を参照することによって，個人的な思い込みに
よって定義されたゴールをゴール分析対象から外
すことができた．• ゴールの所有者という概念を導入することによっ
て，ゴール指向分析を適用する開始地点を明確に
示した．• 所有者別ゴールモデルの分析範囲を，ゴールの所
有者のトップゴールから，所有者がゴールを他者
へ委譲するまでの範囲とした．これによって，ビ
ジネスの組織内で，ゴールの委譲が妥当に行われ
ていることをステークホルダ達が確認することが
できるようになった．
さらに，金庫に関わる人々のロールに基づいてビジ
ネスを分析すると，システムが対応すべき以下の 4 つ
の要求項目を得ることができることを示した．• 秘密鍵の登録，初期化，更新機能• 秘密鍵を用いた解錠者の認証機能
• 秘密鍵を用いた解錠履歴の登録，解錠履歴の参照，
• 上記の機能の参照者の認証機能
また，ロールに基づいてネガティブアクタを導出し，
ミスユースケースに適用した例では，金庫に対する非
機能要求として，以下の 2 点の事項も明らかにできる
ことを示した．
• 泥棒が持ち出せない程度の重さがあること• 泥棒が壊せ程度に頑強であること
さらに，ミスユースケースでも発見されにくい，
• 保管依頼者の暗証番号を，保管物の返却のつど，
金庫は忘れなければならない
ことを明らかにした．Jackson は，システムの利用者
をできるだけ多く，開発に先駆けて洗い出すことがで
きれば，システムの信頼性を向上させることができる
と述べている16)．あらかじめ，能う限り広範な利用者
に対して，システムがどのように対処すべきかを定義
できれば，開発中や開発後の要求変更を少なくするこ
とができるという意味であろう．彼は，これらの利用
者を列挙することは，経験によるところが大きいとも
述べている．暗にこのような分析を行うのは，分析者
であるといっているように思えるが，たとえば金庫の
例では，支配人だけでなく，フロント，ポータ，ルー
ムサービスといったホテル従業員から，日々の業務経
験に基づいて，多様な金庫の利用者を列挙してもらう
ことは可能であろう．個人が担うロールに着目したモ
デルを構築するということは，このような業務遂行者
の知見からのみ得られる情報をモデルに取り込むこと
にほかならない．
インタビューに際して，システムへの期待や要望だ
けを聞くだけでなく，導入されたシステムに対してど
のような人々がどのような関わり方をするのかを問う
てみる必要もあろう．ロール依存モデルは，この情報
を表すモデルである．システムの要求分析というより
は，自分自身の業務として，多様な宿泊客に対して，
実際にどのようなサービスを提供しているのかを説明
するのは，困難なことではない．5.2RODAN の有用性についてRODAN の新規性は，実体としての個人が担って
いるロールを，要求の背景を表す概念として導入した
点にある．これによって，ビジネス領域で個人が担っ
ている役割ごとにモデル構築を検討することが可能と
なった．ここで作られるモデルは，同じロールを担う
人々によってレビューすることができる．ユースケー
スの定義が，現実世界のシナリオの取得から始まるの
と同じように，また，クラスの定義がオブジェクトの
抽出から始まるように，ビジネス領域のモデルも現実
世界の具体的な事例，すなわち，個人が担うロールに
立脚したモデル化から始めるというプロセスには合理
性があろう．個人にしか知りえない “現象”15) に立脚
してモデルの構築を行っているとも換言できる．
各モデルには，モデルの情報を提供した個人の価値
観が明示される．たとえば，所有者別ゴールモデル上
の，あるパーティションに示されたトップゴールには，
そのゴールを達成すべきであるというトップゴールの
所有者の価値観が表れている．
また，ロール依存モデルでは，他のロールとの依存
関係によってロールの存在理由が明示される．このよ
うな情報は，ステークホルダ間の折衝時に，他者の意
図を読み解くうえで重要な情報となる．
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2547
一般的な要求獲得とは，インタビューを行って情報
を得ることが主流であるが，我々は，そこから得られ
た情報を，一度，個人の主観に基づいたモデルとして
表し，そのモデルの妥当性を関係者の間で了解するプ
ロセスを RODAN のプロセスに導入した．このプロ
セスは，インタビューを行った対象者の個人的な思い
込みや勘違い，誤解を含め，まずあるがままにとらえ
ることを可能としている．そして，あるがままにとら
えることが可能となれば，誤解に気づくことも可能と
なろう．これは，創造的な発想や問題改善のためのア
イディアの妥当性を関係者が吟味するための契機とも
つながる．要求が定義される前に，その根拠となる課
題の妥当性を関係者が了解するプロセスがあるという
意味において，関連研究で紹介する他の様々な手法よ
りも妥当な要求を得られる可能性が高い．
RODAN が対象としているステークホルダ分析，お
よび課題分析という，要求獲得の初期の段階では，要
求の正しさを問うても意味はない．現実世界に立脚し
て，要求の妥当性や信憑性こそが追求されるべきであ
る．そして，関係者が要求の背景について了解する必
要がある．このようなプロセスによって，妥当な解を
得ることができるという考えは，構造構成主義を哲学
的根拠としている29)．
今後は，事例への適用とともに，要求変更とビジネ
ス領域の変化との関係について調査し，要求獲得プロ
セスの新しい提案を進めていく予定である．
6.関 連 研 究
役割，あるいはロールという概念は様々な分野で研
究が行われてきた．オブジェクト指向のモデル化や
エージェント指向，アスペクト指向で議論されている
ロールは，現実世界の物理的なオブジェクトによって
担われている役割が，サービスを提供する状況ごとに
分類されたものである12),13),26),27),30),31)．また，ロー
ルは関心事を分離するための “perspectives” として
取り扱われているものもある19)．Loucopoulos と Kavakli らによる EKD アプロー
チ18),21) には，組織のロールとリソースへのアクセス
権限や業務の承認権限が，組織間の依存関係として分
析される．彼らのロールの依存関係は，個人ではなく
組織に着目しているという点を除いては，RODAN の
ロール依存モデルで導入したコンテキスト依存ロール
と構造的に対応する部分もある．i*の戦略依存モデルにおいては，エージェントの依
存関係の中に依存する/依存されるというロールが示さ
れる33)．Yu はシステムとの関わりに対してある種の
意図を持ち，ビジネスに対する知識を持つ「もの」を
エージェントと定義し，要求工学に導入した34)．我々
は物理的な個人に着目して，ある価値観を表すものと
してロールを位置づけ，ビジネス領域を表すメタモデ
ルの中に取り込んだ．
ゴール指向分析を適用した折衝手法には，AGORA
（Attributed Goal-Oriented Requirements Analy-
sis）がある17)．また，Theory-W は，開発者を含め
たステークホルダ間の折衝を行うための戦略手法であ
る6)．RODAN では，折衝プロセスはいまだスコープ
外となっており，今後の課題である．Rolland らは，シナリオとゴールのカード RC を
使って，ゴールの詳細化，サブゴール導出の手法を提
案している28)．この手法は，概念レベル，機能レベ
ル，物理レベルの 3 層を持っており，ゴール分析から
システム要求およびシステムへの物理要求を導出でき
る手法である．RODAN は，ビジネスゴールとシステ
ムゴールの間に委譲関係を定義することで，概念レベ
ルと機能レベルの連結を行っている．RODAN は個人に着目するという特徴を持つが，個
人の視点を重視する要求獲得手法として，花子メソッ
ドが提案されている3)．花子メソッドは，不特定多数の
利用者が見込まれるシステムの要求を獲得するために，
利用者の代表的なモデルを想定し，その要求を定義す
るという手法である．本稿で提案している RODAN
は，ビジネス領域に導入されるシステムを対象として
いる．そのため，代表的な利用者というよりは，個別
の利用者の個人的な要求を仕様に取り込む努力が必要
なだけでなく，関係者の間での了解に基づいた仕様の
取捨選択が必要である．その点で，要求の根拠は，す
べて物理的に存在する人々の意見となる．この点に，
花子メソッドを適用できるシステムと RODAN を適
用できるシステムとの差があり，それにともなって個
人の取り扱い方にも差異が生じている．
B-SCP は，i*と問題フレームを統合した手法であ
る4),5)．この手法では，段階的にビジネスのビジョン
から，ソフトゴール，ハードゴールを導き，各々に対
してミッション，戦略，戦術を対応づけてシステムへ
の要求を導出する手法である．これらの項目と静的
構造は，i*のゴールやタスクに対応させることができ
る．また，問題フレームを導入することで，ゴールの
詳細化の過程で関与するドメインの組織，人，役割の
依存関係が概念図として示される．B-SCP は手法を
統合しているという点では RODAN と同様であるが，
RODAN では直接問題フレームを導入してはいない．B-SCP と RODAN の最も大きな違いは，B-SCP
2548情報処理学会論文誌Aug. 2007
がシステムの要求に対して，ビジネスの根拠を与え
ようとしたモデルとなっているのに対して，RODAN
は，ビジネスの現状から要求を導出しようとしている
点にある．RODAN を導入する時点では，システムの
要求，その適用範囲，システム化境界が未定義でもよ
い．たとえば，仮にそれが定義されていたとしても，
その妥当性を再検討し，関係者が了解する機会を提供
できる．すなわち，要求獲得では，要求を定義する前
に，ビジネスの関係者の意図や問題意識を抽出し，そ
の背景を含めた深い理解を関係者の間に醸成すること
がもっと重要視されるべきであると我々は考える．
ここで抽出された問題意識から導出されるビジネス
の問題点や改善点は，システムへの要求と直結するも
のもあるが，直結しないものも多い．そのため，抽出
された問題点と問題解決手段に対して，関係者が優先
順位と依存関係，競合関係を了解するというプロセス
が必要なのである．このような関係者の了解を取り付
けるという RODAN で重視するプロセスは，B-SCP
の視野外である．
ソフトシステムズ方法論における CATWOE（Cus-
tomer, Actor, Transformation process, World view,Owner, Environment の頭文字）分析では，誰が主導
権を持ち，どのような世界観，あるいは根拠，信念の
もとで，誰のために，誰が変換プロセスを実施する
のかが定義される9)．MOYA は，CATOWE 分析や
ゴール指向分析をビジネスモデリングに適用した手法
であり，顧客と開発者との相互理解に効果をあげてい
る20)．CATWOE では，現状を望ましい状況へ変える
ために 3 種類のロール，すなわち，Customer，Actor，
そして Owner が使われる．W として表される世界観
を Owner の世界観であるととらえると，望ましい状
況を達成するというゴールは，Owner のゴールであ
る．RODAN では，この考え方に基づいて所有者別
ゴールモデルを開発した．
以上の様々な手法は RODAN と競合するものでは
なく，成果物のメタモデルに共通点があるのであれば，RODAN の手法断片として統合が可能である．その
際，不足しているプロセスや概念を補えば，そうして
統合された手法も RODAN と見なせる．
本稿では，ビジネス領域のメタモデルを表すことに
よって，既存の手法を拡張，統合して作られる RODAN
を紹介した．また，手法を評価するために，金庫のシ
ステムへ適用した．その結果，定義された問題文には
抜けていた重要な要求を抽出することが可能であるこ
とを示した．今後は，要求変更とビジネス領域の変化
の対応関係について調査し，RODAN の拡充を目指し
1) Alexander, I.: Misuse Cases Use Cases withHostile Intent, IEEE Software, pp.58–66, IEEE(2003).2) Anton, A.I.: Goal-Based Requirements Anal-ysis, Proc. ICRE’96, pp.136–144, IEEE (1996).3) 青山幹雄，村瀬香，中野有美：要求工学の花子さん：個人を中心とする組込ソフトウェア要求分析方法，情報処理学会研究会報告，2004-SE-144-22, pp.163–170, 情報処理学会 (2004).4) Bleistein, S.J., Cox, K. and Verner, J.: Vali-dating strategic alignment of organizational ITrequirements using goal modeling and problemdiagrams, J. Syst. Softw., Vol.79, No.3, pp.362–378 (2006).5) Bleistein, S.J., Cox, K., Verner, J. and Phalp,K.T.: B-SCP: A requirements analysis frame-work for calidating strategic alignment of orga-nizational IT based on strategy, context, andprocess, Information and Software Technology,Vol.48, No.9, pp.846–868 (2004).6) Boehm, B., Bose, P., Horowitz, E. and Lee,M.J.: Software Requirements Negotiation andRenegotiation Aides: A Theory-W Based SpiralApproach, Proc. ICSE’95, pp.243–253, ACM(1995).7) Brinkkemper, S., Saeki, M. and Harmsen, F.:Meta-Modelling Based Assembly Techniquesfor Situational Method Engineering, Informa-tion Systems, Vol.23, No.7, pp.489–508 (1998).8) CEDITI: A KAOS Tutorial (2003).http://www.objectiver.com/download/documents/KaosTutorial.pdf9) Checkland, P. and Scholes, J.: Soft SystemsMethodology in Action, John Wiley & Sons(1991).10) Chung,L.,Nixon,B.A.,Yu,E.andMylopoulos, J.: Non-Functional Requirementsin Software Engineering, Kluwer AcademicPublishers, Boston (1999).11) Eriksson, H.-E. and Penker, M.: BusinessModeling with UML, John Wiley & Sons, NewYork (2000).12) Fowler, M.: Dealing with roles, Collected pa-pers from the PLOP’97 and EuroPLoP’97 Con-ference, Technical Report #wucs-97-34, Dept.of Computer Science, Washington Univ. Dept.of Computer Science (1997).13) Harrison,W.andOssher,H.:Subject-
Vol. 48No. 8ロールに着目したビジネス領域における要求獲得手法 RODAN の提案2549
Oriented Programming (a critique of pure ob-jects), Proc. OOPSLA’93, pp.411–428, ACM(1993).14) IEEE: IEEE Recommended Practice for Soft-ware Requirements Speciﬁcations, Std 830-1998 (1998).15) 池田清彦：構造主義科学論の冒険，毎日新聞社(1990).16) Jackson, M.: Seeing More of the World, IEEESoftware, pp.83–85, IEEE (2004).17) Kaiya, H., Horai, H. and Saeki, M.: AGORA:Attributed Goal-Oriented Requirements Anal-ysis Method, Proc. 10th Anniversary IEEEJoint International Requirements EngineeringConference (RE’02), pp.13–22, IEEE (2002).18) Kavakli, V. and Loucopoulos, P.: Goal-DrivenBusiness Process Analysis Application in Elec-tricity Deregulation, Proc. CAiSE’98, LNCS,Vol.1413, pp.305–324 (1998).19) Kendall, E.A.: Role model designs and imple-mentations with aspect-oriented programming,Proc. OOPSLA’99, pp.353–369, ACM (1999).20) 木俣亜紀，斉藤信也：要求定義へのビジネスモデリング方法論の適用，プロジェクトマネージメント学会 2005 年度春季研究発表大会論文集，pp.199–204, プロジェクトマネージメント学会 (2005).21) Loucopoulos, P. and Kavakli, V.: EnterpriseKnowledge Management and Conceptual Mod-elling, Conceptual Modeling, Chen, P.P., et al.(Eds.), LNCS 1565, pp.123–143 (1999).22) 溝口理一郎，池田満，來村徳信：オントロジー工学基礎論—意味リンク，クラス，関係，ロールのオントロジー的意味論，人工知能学会誌，Vol.14,No.6, pp.1019–1032 (1999).23) Nakatani, T. and Fujino, T.: Role and OwnerBased Business Domain Analysis, Proc. AsiaPaciﬁc Software Engineering Conference 2005(APSEC2005), pp.130–137, IEEE (2005).24) 中谷多哉子，藤野晃延：RODAN のためのビジネスゴール分析手法の提案，ソフトウェア工学の基礎ワークショップ 2005，pp.129–134, ソフトウェア科学会 (2005).25) 大西淳：要求工学ワーキンググループ活動報告，情報処理学会研究会報告，2001-SE-130-18,pp.127–134, 情報処理学会 (2001).26) Reenskaug, T., Wold, P. and Lehne, O.A.:Working with Objects: the OOram SoftwareEngineering Method, Manning Publications,Greenwich (1996).27) Riehle,D.andGross,T.:RoleBasedFrameworkDesignandIntegration,Proc.OOPSLA’98, pp.117–133, ACM (1998).28) Rolland, C. and Prakash, N.: Matching ERPSystem Functionality to Customer Require-
ments, Proc. 5th International Conference onRequirements Engineering (RE’01), pp.66–76,IEEE (2001).29) 西條剛央：構造構成主義とは何か—次世代人間科学の原理，北大路書房 (2005).30) Ubayashi, N. and Tamai, T.: RoIeEP: Evo-lutionary programming for cooperative mobileagent applications, Proc. International Sym-posium on Principles of Software Evolution,Kanazawa, Japan, pp.232–240, IEEE Com-puter Society (2000).31) Wirfs-Brock, R. and McKean, A.: ObjectDesign, Roles, Responsibilities and Collabora-tions, Addison-Wesley (2003).32) 山崎利治：DW2005 のための問題，SEAMAIL,Vol.14, No.5, pp.51–52 (2005).33) Yu, E.S.K.: Towards Modelling and ReasoningSupport for Early-Phase Requirements Engi-neering, Proc.3rd International Symposium OnRequirements Engineering (RE’97), pp.226–235, IEEE (1997).34) Yu, E.S.K.: Agent Oriented as a ModellingParadigm,Wirtschaftsinformatik,Vol.43,No.2, pp.123–132 (2001).35) Yu, E.S.K. and Mylopoulos, J.: An Actor De-pendency Model of Organizational Work —With Application to Business Process Reengi-neering, Proc.Conf.on Organizational Comput-ing Systems (COOCS’98), pp.258–268 (1998).36) Zachman, J.A.: A Framework for informationSystems Architecture, IBM System Journal,Vol.26, No.3, pp.454–470 (1987).37) Zave, P. and Jackson, M.: Four Dark Cor-ners of Requirements Engineering, ACM Trans.Software Engineering and Methodology, Vol.6,No.1, pp.1–30 (1997).
(平成 18 年 12 月 5 日受付)
(平成 19 年 5 月 9 日採録)
2550情報処理学会論文誌Aug. 2007
中谷多哉子（正会員）
1980 年東京理科大学理学部応用
物理学科卒業．1994 年筑波大学大
学院経営・政策科学研究科経営シス
テム科学専攻修了．1998 年東京大
学大学院総合文化研究科広域科学専
攻博士課程修了．日本電子計算（株），富士ゼロックス
情報システム（株）を経て 1995 年よりエス・ラグー
ンを起業．2006 年より筑波大学大学院ビジネス科学
研究科准教授．オブジェクト指向分析手法，要求獲得
手法に関する研究に従事．博士（学術）．電子情報通
信学会，ソフトウェア科学会，プロジェクトマネージ
メント学会，IEEE-CS，ACM 各会員．
藤野晃延（正会員）
1996 年有限会社インアルカディア
主宰，現在に至る．オブジェクト指
向，ユースケース，パターン，要求
工学等に関わる知見を適用し，現実
世界に根差した問題解決を可能とす
るモデル追求に特に興味を持つ．ACM 会員．