Requirement Development Alliance

ビジネスユースケースとビジネスフロー

要求開発アライアンス2010年6月定例会

河野 正幸

チュートリアルシリーズ第五回

www.openthology.org

本チュートリアルのテーマ

価値の高い要求を開発するためには

–対象業務の本質を深く理解することが不可欠

– しかし、業務の素人にはこれがなかなか難しい

–なぜなら、業務の全体像を把握しないまま、細部を理解しようとしているから

–では、どうすればこの問題が解決できるのか？

ビジネスユースケースで業務の全体像を素早く把握し、それをベースにビジネスフローや概念モデルで細部を深く理解すれば、業務の本質を踏まえた価値の高い要求を発見・発明しやすくなる

www.openthology.org

ビジネスユースケース図にまつわる4つの疑問

Q1.書いてあること

はしごく当たり前のことだよね。わざわざ描く必要があるの？

Q2.使い道がよくわか

らない。いったい何に役立つ図なの？

Q3.どれくらいの大きさ

で業務を切り出せばビジネスユースケースと呼べるのか？わかりづらい！

Q4.この図では

業務の実行順序がよくわからないよね？

www.openthology.org

Ａ１．なぜわざわざ描く必要があるのか？

ゴール

スコープステークホルダー

ゴールからスコープが導かれ、スコープからステークホルダーが導かれ、ステークホルダーから再びゴールが導かれるというサイクルを何度か繰り返してゴール、スコープ、ステークホルダーを徐々に明確にしていく

ビジネスユースケース図や業務コンテキスト図はこのアクティビティを実施する上で有用なツールである

要求開発のスタート時点では、業務の全体像（ゴール、スコープ、ステークホルダー）をざっくりと把握して関係者で共通認識を持つことが重要。そのためのツールとして役立つ。

業務の概要をわかりやすく可視化し、ゴールと照らし合わせながら、要求開発のスコープを関係者で合意する

対象業務範囲（スコープ）に存在する利害関係者とその役割、責務をもれなく把握する

対象業務に存在する課題や、ステークホルダーの期待・要望などを考慮してめざすべきゴールを明確にする

www.openthology.org

Ａ２．いったい何に役立つの？用途がわからない

以下の3つの用途に照らし合わせてみると、ビジネスユースケース図の有用性

が見えてくる。

1. プロジェクトの分析対象業務の概要を素早く掌握し、ゴール、スコープ、ステークホルダーを関係者が共通認識するために利用する(A1で説明）

2. 要求開発プロジェクトで扱う業務知識と要求を体系的に分類・整理するための枠組みとして利用する

3. プロジェクトの具体的な活動計画を立案するために利用する

www.openthology.org

例１：ハイレベルのビジネスユースケース図

ゴール

業務スコープステークホ

ルダー

用途１．ゴール、スコープ、ステークホルダーを共通認識する

www.openthology.org

例１：ハイレベルのビジネスユースケース図

基本的に新車販売や中古車販売といったBUCの単位で業務が完結しているので、その単位でビジネスフローや概念モデルを作成して業務知識を整理したり、要求を分類すると、要求開発に必要な情報を体系的に管理しやすい

用途２．業務知識や要求を体系的に分類・整理するための枠組みを提供する

www.openthology.org

例１：ハイレベルのビジネスユースケース図

個々のBUCは基本的に独立して検討できるものである。また、BUC毎にステークホルダーも異なる。従って、BUC

の単位で要求開発チームの主担当と、参加してもらうステークホルダー、ならびに活動内容・スケジュールを立案すると、ムダの少ない計画が立案しやすい。

用途３．プロジェクトの具体的な活動計画を立案する

www.openthology.org

例2：詳細レベルのビジネスユースケース図新車販売の詳細を表現したBUC図 例１よりかなり粒度がこまかく、これがQ3の

疑問につながっている。

しかし、業務をある程度詳細に理解するにはこのレベルの詳細度で把握することも必要。

www.openthology.org

Ａ３．ビジネスユースケースの粒度って？

ビジネスカテゴリ

バリューチェーンプロセス

ビジネスユースケース

業務アクティビティ

システムユースケース

システムユースケースアクティビティ

ソフトウエアコンポーネント

ビジネス領域

情報システム領域

商品、市場、流通、生産などの軸で組織のビジネスを分類したレベルで識別されるサービス(例：新車販売、中古車販売、サービス販売、用品販売など)

機能の分類と階層関係

ビジネスカテゴリ毎のバリューチェーンプロセスのレベルで識別されるサービス(例：商品企画、広告宣伝、購買、販売、アフターサービスなど)

バリューチェーンプロセスの中に存在するビジネスユースケースレベルのサービス(例：引合、見積、受注、車両手配、架装手配、納車、売掛金回収など)

ビジネスユースケースの中でさまざまなエージェントが実施する業務活動レベルのサービス（ビジネスユースケースの実行シナリオの1ステップに相当）(例：見積条件をヒアリングする、概算見積を提示する、見積書を発行するなど)

業務アクティビティのうちシステムがサポートするシステムユースケースレベルのサービス(例：見積を登録する、見積書を印刷するなど)

システムユースケースの実行シナリオの中でシステムが実施し利用者に提供するサービス(例：過去の見積情報をコピーする、損益を計算するなど)

システムユースケースアクティビティの実現に関わるソフトウエアコンポーネントが提供するサービス(例：顧客情報照会画面、見積登録コントローラ、見積エンティティなど)

親機能

子機能

追跡可能性

例1

ハイレベル

例2

詳細レベル

ビジネス領域の機能階層の色々なレベルでビジネスユースケース図を作成しているので混乱する。

しかし、複数のレベルで業務機能を可視化して把握することは全体像を体系的に理解するためには必要。

自分たちがどのレベルの議論をしているのかを明確にして複数のレベルの図を使い分ければ良い。厳密な粒度の定義を求めるよりは、関係者全員が業務について共通認識できる内容であることの方が重要。

「ビジネスユースケース図」と称するのをやめて「業務コンテキスト図」と呼び、表記をUMLのユースケース図に準じていると説明した方が判り易いかもしれない。

www.openthology.org

まだすっきりしない人へ：ビジネスユースケースの定義

顧客

商品を販売する

注文を受け付ける

受注担当者

受注を記録する

出荷を記録する商品を納品する

出荷担当者

運送会社

販売管理システム

在庫を確認する

カタログ販売会社ビジネスユースケース

(業務の反応)

ビジネス境界 (業務スコープ) システム境界(システムスコープ)

システムユースケース

(システムが実現する機能)

外部のビジネスアクター (業務の外部にいるサービス要求者または提供者)

内部のビジネスアクター

(業務担当者)

システムアクター

(システムの利用者)

商品の注文

(Tel or FAX)

ビジネスイベント

入金を確認する

外部からのビジネスイベントに対する業務の反応がビジネスユースケースである

ビジネスユースケースには人間が実施する機能とシステムに実現させる機能（システムユースケース）の両方が含まれる

開発手法の用語の定義に悩んでも何も生まれない。重要なのは業務を理解することである。

金融機関

商品の引き渡し

(宅配便)

www.openthology.org

Ａ４．この図では業務の実行順序がわからないよね？

業務の実行順序はビジネスフローで表現すれば良い。 ビジネスフローも業務コンテキスト図（ビジネスユースケース図）と同様に複数の機能階層レベルで表

現する必要がある。 レベル毎に表記方法を区別しておくと、どちらのレベルの図かが判り易い。

商品企画 販売広告宣伝

納車引合 受注見積

顧客から見積条件をヒアリングする 見積書を発行する

ディーラー在庫を確認する

値引き条件を店長に確認する

クレジット会社に与信をチェックする

顧客に見積書を渡す

見積書を発行する在庫を照会する

営業担当が見積条件を入力する

システムが見積内容をDBに登録する

営業担当が見積計算結果を確認する

システムが見積金額を計算して画面に表示する

システムが見積書を印刷する

サービス販売 用品販売 新車販売 中古車販売ビジネスカテゴリ

バリューチェーンプロセス

ビジネスユースケース

業務アクティビティ

システムユースケース

システムユースケースアクティビティ

見積登録画面見積登録コントローラ

見積書印刷サービス

見積Entityソフトウエア

コンポーネント

購買

代金決済売掛金回収

自動車メーカーに納期を確認する

例3

ビジネスプロセス図

例4,5

業務フロー図

ビジネスユースケースレベルの業務機能がどう相互作用しているか

ビジネスユースケースの実行シナリオ

www.openthology.org

ビジネスプロセス図とは

プロセス

受信イベント

入力オブジェクト

<<物理的>>入力オブジェクト

<<人々>>制御オブジェクト

<<ゴール>>ゴールオブジェクト

<<物理的>>物理的オブジェク

ト

情報オブジェクト

送信イベント

出力オブジェクト

<<物理的>>出力オブジェクト

<<制御>> <<達成>>

<<供給>> <<供給>>

ハンス・エリクソンとマグヌス・ペンカーがUMLのアクティビティ図をビジネスモデリング用に拡張した記法

ゴールオブジェクト ：プロセスが達成すべき目標。展開された目標のうち該当プロセスに割り当てられるもの

入力オブジェクト ：プロセス内で消費されたり生成されたりする物理的リソース、情報リソース

出力オブジェクト ：プロセスによって産出、加工される成果物としての物理的リソース、情報リソース

供給オブジェクト ：プロセスに参加はするが消費されたり生成されたりしない物理的リソース、情報リソース

制御オブジェクト ：プロセスを管理、制御、制約する人やビジネスルールなどの物理的/情報リソース

受信イベント ：業務イベントの受信を示す

送信イベント ：業務イベントの送信を示す

www.openthology.org

例3：ビジネスプロセス図

新車販売のビジネスフローを表現したビジネスプロセス図

ビジネスユースケースレベルの業務機能

www.openthology.org

例４．ビジネスユースケースシナリオ

ユースケース名 見積（来店）

使用時のコンテキスト 店舗に来店した顧客からの見積依頼を受けて見積回答をする

スコープ 新車販売

主アクター 店舗営業担当者

ゴール ・見積回答のリードタイムを現状の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

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

www.openthology.org

ビジネスユースケース単位で概念モデリングを実施する

基本的に新車販売や中古車販売といったBUCの単位で業務が完結しているので、その単位でビジネスフローや概念モデルを作成して業務知識を整理したり、要求を分類すると、要求開発に必要な情報を体系的に管理しやすい

用途２．業務知識や要求を体系的に分類・整理するための枠組みを提供する

www.openthology.org

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