オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2010年6月定例会発表資料です。 Open Community "Requirement Development Alliance" 2010/06 regular meeting of the presentation materials.

1. Requirement Development Alliance
要求開発アライアンス2010年6月定例会
チュートリアルシリーズ第五回
ビジネスユースケースとビジネスフロー
河野 正幸

2. 本チュートリアルのテーマ
価値の高い要求を開発するためには
– 対象業務の本質を深く理解することが不可欠
– しかし、業務の素人にはこれがなかなか難しい
– なぜなら、業務の全体像を把握しないまま、細部を
理解しようとしているから
– では、どうすればこの問題が解決できるのか？
ビジネスユースケースで業務の全体像を素早く把握し、
それをベースにビジネスフローや概念モデルで
細部を深く理解すれば、業務の本質を踏まえた
価値の高い要求を発見・発明しやすくなる
www.openthology.org

3. ビジネスユースケース図にまつわる4つの疑問
Q1.書いてあること
はしごく当たり前のこ
とだよね。わざわざ
描く必要があるの？ Q3.どれくらいの大きさ
で業務を切り出せばビ
ジネスユースケースと
呼べるのか？
わかりづらい！
Q2.使い道がよくわか
らない。いったい何に
役立つ図なの？ Q4.この図では
業務の実行順
序がよくわから
ないよね？
www.openthology.org

4. Ａ１．なぜわざわざ描く必要があるのか？
要求開発のスタート時点では、業務の全体像（ゴール、スコープ、ステークホルダー）を
ざっくりと把握して関係者で共通認識を持つことが重要。そのためのツールとして役立つ。
対象業務に存在する課題や、ステーク
ホルダーの期待・要望などを考慮して
ゴール めざすべきゴールを明確にする
対象業務範囲（スコープ）
に存在する利害関係者と
その役割、責務をもれな
く把握する
ステーク 業務の概要をわかりやすく
スコープ 可視化し、ゴールと照らし合
ホルダー
わせながら、要求開発のス
コープを関係者で合意する
ゴールからスコープが導かれ、スコープからステークホルダーが導かれ、ステークホルダーから再びゴールが導か
れるというサイクルを何度か繰り返してゴール、スコープ、ステークホルダーを徐々に明確にしていく
ビジネスユースケース図や業務コンテキスト図はこのアクティビティを実施する上で有用なツールである
www.openthology.org

5. Ａ２．いったい何に役立つの？用途がわからない
以下の3つの用途に照らし合わせてみると、ビジネスユースケース図の有用性
が見えてくる。
1. プロジェクトの分析対象業務の概要を素早く掌握し、ゴール、スコープ、ス
テークホルダーを関係者が共通認識するために利用する(A1で説明）
2. 要求開発プロジェクトで扱う業務知識と要求を体系的に分類・整理するため
の枠組みとして利用する
3. プロジェクトの具体的な活動計画を立案するために利用する
www.openthology.org

6. 例１：ハイレベルのビジネスユースケース図
用途１．ゴール、スコープ、ステークホルダーを共通認識する
業務
ステークホ スコープ
ルダー
ゴール
www.openthology.org

7. 例１：ハイレベルのビジネスユースケース図
用途２．業務知識や要求を体系的に分類・整理するための枠組みを提供する
基本的に新車販売や中古車
販売といったBUCの単位で
業務が完結しているので、そ
の単位でビジネスフローや概
念モデルを作成して業務知
識を整理したり、要求を分類
すると、要求開発に必要な情
報を体系的に管理しやすい
www.openthology.org

8. 例１：ハイレベルのビジネスユースケース図
用途３．プロジェクトの具体的な活動計画を立案する
個々のBUCは基本的に独立
して検討できるものである。
また、BUC毎にステークホル
ダーも異なる。従って、BUC
の単位で要求開発チームの
主担当と、参加してもらうス
テークホルダー、ならびに活
動内容・スケジュールを立案
すると、ムダの少ない計画が
立案しやすい。
www.openthology.org

9. 例2：詳細レベルのビジネスユースケース図
例１よりかなり粒度がこまかく、これがQ3の
新車販売の詳細を表現したBUC図
疑問につながっている。
しかし、業務をある程度詳細に理解するに
はこのレベルの詳細度で把握することも必要。
www.openthology.org

10. Ａ３．ビジネスユースケースの粒度って？
機能の分類と階層関係
親機能 商品、市場、流通、生産などの軸で組織のビジネスを分類したレベルで識別
ビジネスカテゴリ
されるサービス
(例：新車販売、中古車販売、サービス販売、用品販売など) 例1
ビ バリューチェーンプロセス ビジネスカテゴリ毎のバリューチェーンプロセスのレベルで識別されるサービス ハイ
(例：商品企画、広告宣伝、購買、販売、アフターサービスなど)
ジ レベル
ネ
バリューチェーンプロセスの中に存在するビジネスユースケースレベルのサービス
ス ビジネスユースケース
領 (例：引合、見積、受注、車両手配、架装手配、納車、売掛金回収など)
域 例2
ビジネスユースケースの中でさまざまなエージェントが実施する業務活動レベルの
詳細
業務アクティビティ レベル
追 サービス（ビジネスユースケースの実行シナリオの1ステップに相当）
跡 (例：見積条件をヒアリングする、概算見積を提示する、見積書を発行するなど)
可
能 業務アクティビティのうちシステムがサポートするシステムユースケースレベルの
システムユースケース
性 情 サービス
報 (例：見積を登録する、見積書を印刷するなど)
シ
ス システムユースケース システムユースケースの実行シナリオの中でシステムが実施し利用者に提
テ アクティビティ 供するサービス
ム (例：過去の見積情報をコピーする、損益を計算するなど)
領
域 ソフトウエアコンポーネント
システムユースケースアクティビティの実現に関わるソフトウエアコンポーネント
が提供するサービス
子機能
(例：顧客情報照会画面、見積登録コントローラ、見積エンティティなど)
ビジネス領域の機能階層の色々なレベルでビジネスユースケース図を作成しているので混乱する。
しかし、複数のレベルで業務機能を可視化して把握することは全体像を体系的に理解するためには必要。
自分たちがどのレベルの議論をしているのかを明確にして複数のレベルの図を使い分ければ良い。厳密な粒度の定義を求めるよりは、
関係者全員が業務について共通認識できる内容であることの方が重要。
「ビジネスユースケース図」と称するのをやめて「業務コンテキスト図」と呼び、表記をUMLのユースケース図に準じていると説明した方
が判り易いかもしれない。
www.openthology.org

11. まだすっきりしない人へ：ビジネスユースケースの定義
システムアクター
(システムの利用者)
ビジネス境界 (業務スコープ) システム境界(システムスコープ)
金融機関
ビジネスユースケース カタログ販売会社
(業務の反応)
受注担当者
ビジネスイベント 販売管理システム
商品を販売する
商品の注文 受注を記録する
(Tel or FAX) 注文を受け付ける 入金を確認する 在庫を確認する
商品の引き渡し
顧客 (宅配便)
出荷を記録する
商品を納品する
内部のビジネスアクター
(業務担当者) システムユースケース
運送会社
(システムが実現する機能)
出荷担当者
外部のビジネスアクター (業務の外部にいるサービス要求者または提供者)
外部からのビジネスイベントに対する業務の反応がビジネスユースケースである
ビジネスユースケースには人間が実施する機能とシステムに実現させる機能（システムユースケース）
の両方が含まれる
開発手法の用語の定義に悩んでも何も生まれない。重要なのは業務を理解することである。
www.openthology.org

12. Ａ４．この図では業務の実行順序がわからないよね？
 業務の実行順序はビジネスフローで表現すれば良い。
 ビジネスフローも業務コンテキスト図（ビジネスユースケース図）と同様に複数の機能階層レベルで表
現する必要がある。
 レベル毎に表記方法を区別しておくと、どちらのレベルの図かが判り易い。
ビジネス ビジネスユースケースレ
サービス販売 用品販売 新車販売 中古車販売
カテゴリ ベルの業務機能がどう
相互作用しているか
バリュー
商品企画 広告宣伝 購買 販売
チェーン 例3
プロセス ビジネスユー
ビジネス スケースの実
プロセス図 行シナリオ
代金決済
ビジネス 引合 見積 受注 納車
売掛金回収
ユースケース
例4,5
業務
業務 顧客から見積条件を
ヒアリングする
ディーラー在庫を 自動車メーカーに 値引き条件を クレジット会社に
見積書を発行する
顧客に見積書を フロー図
確認する 納期を確認する 店長に確認する 与信をチェックする 渡す
アクティビティ
システム 在庫を照会する 見積書を発行する
ユースケース
システムが 営業担当が
システム 営業担当が
見積金額を計算して 見積計算結果を
システムが見積内容を システムが
見積条件を DBに登録する 見積書を印刷する
ユースケース 入力する 画面に表示する 確認する
アクティビティ
見積登録 見積書印刷 見積
ソフトウエア 見積登録画面
コントローラ サービス Entity
コンポーネント
www.openthology.org

13. ビジネスプロセス図とは
ハンス・エリクソンとマグヌス・ペンカーがUMLのアクティビティ図をビジネスモデリング用に拡張した記法
<<人々>> <<ゴール>>
制御オブジェクト ゴールオブジェクト
入力オブジェク <<制御>> <<達成>> 出力オブジェク
ト ト
プロセス
受信イベント 送信イベント
<<物理的>> <<物理的>>
入力オブジェクト 出力オブジェクト
<<供給>> <<供給>>
<<物理的>>
情報オブジェク
物理的オブジェク ト
ト
ゴールオブジェクト ：プロセスが達成すべき目標。展開された目標のうち該当プロセスに割り当てられるもの
入力オブジェクト ：プロセス内で消費されたり生成されたりする物理的リソース、情報リソース
出力オブジェクト ：プロセスによって産出、加工される成果物としての物理的リソース、情報リソース
供給オブジェクト ：プロセスに参加はするが消費されたり生成されたりしない物理的リソース、情報リソース
制御オブジェクト ：プロセスを管理、制御、制約する人やビジネスルールなどの物理的/情報リソース
受信イベント ：業務イベントの受信を示す
送信イベント ：業務イベントの送信を示す
www.openthology.org

14. 例3：ビジネスプロセス図
新車販売のビジネスフローを表現したビジネスプロセス図
ビジネスユース
ケースレベルの
業務機能
www.openthology.org

15. 例４．ビジネスユースケースシナリオ
ユースケース名 見積（来店）
使用時のコンテキスト 店舗に来店した顧客からの見積依頼を受けて見積回答をする
スコープ 新車販売
主アクター 店舗営業担当者
ゴール ・見積回答のリードタイムを現状の1時間から30分以内に短縮する
・見積提示後・即受注の案件の割合を70％以上に引き上げる
・値引額を本体価格の5%以内に抑える
事前条件 顧客から見積に必要な全ての情報が受領できていること
事後条件 顧客の見積依頼に対して必要な見積を30分以内に完了し、見積書を送付していること
主成功シナリオ 1.顧客が見積依頼をする
2.店舗営業担当者は見積条件を顧客から聞き取り、ヒアリングシートに記入する
3.店舗営業担当者はヒアリングが完了したら、希望の飲み物をお出しして、しばらく待って頂くよう伝える
4.店舗営業担当者は在庫と納期の確認をする
5.「支払方法が割賦の場合]店舗営業担当者はクレジッドカード会社に顧客の与信を確認する
6.店舗営業担当者は値引額を決定する
7.店舗営業担当者は見積書を発行し、顧客に説明する
8.顧客は見積書の内容をもとに購入の意思決定をする
拡張 4.a.ディーラー在庫が無い場合
4.a.1.店舗営業担当者は自動車メーカーの国内営業担当者に該当車種仕様の納期回答を依頼する
4.a.2.自動車メーカーの国内営業担当者は生産計画から納期を調査して回答する
4.a.3.店舗営業担当者はメーカーからの納期回答結果を受け、顧客の希望に沿えない場合には代案（色・グレード違いな
ど）を提案する
5.a.与信が通らない場合
5.a.1.店舗担当者は顧客にその旨を伝え代案に関する提案をする
6.a.値引額が車両本体価格の5%を超過する場合
6.a.1.店舗営業担当者は店長に値引額の上乗せを相談する
6.a.2.[店長が承認した場合]その値引額で見積書を作成する
6.a.3.[店長が承認しない場合]値引の上限額を店長と決定し、顧客と交渉する。場合によっては代案を提案する。
www.openthology.org

16. 例５．業務フロー図
顧客来店時の見積業務手順の詳細を表現した業務フロー図
www.openthology.org

17. ビジネスユースケース単位で概念モデリングを実施する
用途２．業務知識や要求を体系的に分類・整理するための枠組みを提供する
基本的に新車販売や中古車
販売といったBUCの単位で
業務が完結しているので、そ
の単位でビジネスフローや概
念モデルを作成して業務知
識を整理したり、要求を分類
すると、要求開発に必要な情
報を体系的に管理しやすい
www.openthology.org

18. 例６：概念モデル図 見積を対象にモデリングした概念モデル図
www.openthology.org