Introduction of Business Use-Case and Business Flowin Requirement Development

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

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

ビジネスユースケース図にまつわる4つの疑問 Q1.書いてあることはしごく当たり前のことだよね。わざわざ描く必要があるの？ Q3.どれくらいの大きさで業務を切り出せばビジネスユースケースと呼べるのか？わかりづらい！ Q2.使い道がよくわからない。いったい何に役立つ図なの？ 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：詳細レベルのビジネスユースケース図 例１よりかなり粒度がこまかく、これがQ3の新車販売の詳細を表現したBUC図疑問につながっている。 しかし、業務をある程度詳細に理解するにはこのレベルの詳細度で把握することも必要。 www.openthology.org

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

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

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

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

Introduction of Business Use-Case and Business Flowin Requirement Development

by Kent Ishizawa on Jul 05, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Introduction of Business Use-Case and Business Flowin Requirement Development — Presentation Transcript