1. いまさらユースケース
エムスリー株式会社 木村將
1

2. はじめに
 ここでは要求分析の作業のうち、「要求を伝
える」事を取り上げます
 ウォーターフォールモデルのいわゆる「要件
定義」ということではありません
 UML（Unified Modeling Language : 統一モデ
リング言語）の一つであるユースケース図の
話もありますがソフトウェアエンジニアリン
グの話ではありません
2

3. こんな経験ありませんか？
要求仕様をあいまいなまま進めたことによる
失敗
3

4. こんなこと経験ありません
こんな経験ありませんか？
か？
「アンケー
トでユー
ザーの不満 「完璧だよ
を調べた」 ね！いつ頃 「・・・よ
できる？」 くわからな
いからとり
あえず×2倍
「何が必要 にしておこ
とされてい う・・・」
るかも考え
た」
開発者
「ビジネス
インパクト
も十分検討 曖昧なストーリー、
した」
曖昧な説明
4

5. 5

6. なぜそのような不幸が起こるの
こんな経験ありませんか？
か？
要求仕様は関係者に正確
に伝わっていましたか？
6

7. こんな経験ありませんか？
プロジェクトの計画には要求仕様の策定が必
要
要求仕様の策定
要求
要求
シナリオ 規模の
期間に
見積も
り
変換 計画
要求
要求
シナリオ
大変な思いをするプロジェクトは
この部分の精度が悪かったり共有
できていなかったりする
7

8. こんな経験ありませんか？
要求仕様を決める3つの活動
 要求を収集する
 行動観察
 アンケート
 インタビュー など
 要求を分析する
 会議体
 プロトタイプ
 ビジネスフロー など
 要求を伝える
 フローチャート
 ユースケース
 画面遷移 など
8

9. こんな経験ありませんか？
実際に発生した問題
 トップダウン式の曖昧な要求仕様では計画作り
が困難です
 コミットメントされたスケジュールの中では、
後から気づいたシナリオを納期に合わせるため
開発サイドにしわ寄せがいきます
 これらが常態化すると開発サイドは「自衛」の
ためスケジュールに多くのバッファを取るよう
になります
9

10. このような問題を解決するた
めの開発手法の提言は色々あ
る。
ですが今回取り上げたい
のはその前段の話
10

11. こんな経験ありませんか？
経験して感じたこと
 どんな開発手法も要求分析は必要
 仕様変更に柔軟なことと、要求仕様を曖昧なま
まにしておいて良いということは意味が違う
 「要求仕様書」を作ることを目的とすると余
計負担が増える
 「要求仕様を伝えること」を目的とするのが
正解 11

12. 要求仕様を曖昧にしない取り組
み
いつ？だれが？どのように？
12

13. いつ誰がどのように？
いつやる？
要求は常
に発生す
要求が発生したとき るものと
考えサイ
クルには
企画する 組み込ま
設計／実
ない 計画
装
要求仕様を決め
る
テスト／
要求分析 リリース
評価
・要求を収集する
・要求を分析する
・要求を伝える
13

14. いつ誰がどのように？
誰がやる？
 企画をリードする人、作る人、ビジネス上の
判断ができる人が一緒に行うのが効果的
ビジネス
オーナー
デベロッ マーケ
パー ター
14

15. いつ誰がどのように？
どのようにやる？
 例えばレビュー時に要求をホワイトボードに書
き出す
 決まったフォーマット、成果物は無い
 綺麗に文書化するためのリソースは必要ない
 手書きのレベルで十分
 最低限何を満たしたいのか？（ゴールはどこ
か？）を明確にする
 ゴールを満たすためのもっと手軽な代替手段はある
かもしれない
15

16. こんなレベルでも十分伝わり
いつ誰がどのように？
ます
ホワイトボードに直接殴り書き
16

17. 17

18. いまさらユースケース
最近ユースケースについて見なおしてみた。
実はタイミングと目的次第では効果的に運用
できるのではないか・・・？
18

19. いまさら？
19

20. 本気？
20

21. 本気です
21

22. 超本気
22

23. ユースケースって？
ユースケースは、新システムやシステムの改善にあたっての要求を文
書化する技法である。各ユースケースは1つ以上の「シナリオ」を提供
し、その中でシステムやエンドユーザーや他のシステムがどのように
相互作用を行ってビジネスの目標を達成するかを描く。ユースケース
では技術的な専門用語を排し、エンドユーザーやその分野の専門家に
わかる用語を使うのが望ましい。ユースケースはソフトウェア開発者
とエンドユーザーが共同で執筆することも多い。
ユースケースはソフトウェアの挙動を説明する単純なツールである。
ユースケースにはユーザーがインターフェイスを通してソフトウェア
を動作させる全ての方法に関する文章による記述が含まれる。ユース
ケースはソフトウェア内部の動きは記述されないし、どう実装される
かも説明されない。単にユーザーが何かをソフトウェアにさせる際の
手順を示すだけである。このような形で全てのユーザーとシステムの
やり取りが記述されている。
Wikipediaより
23

24. 24

25. ユースケースとは
要はシステム要件を洗い出すこと
 X販売システム
 顧客はXを購入します
 新規顧客の場合、顧客情報を登録します
 決済手続きをします
 クレジット支払いが選べます
 携帯支払いが選べます
 PayPal支払いが選べます

26. ユースケースとは
UMLに従いモデル化すると理解が早い
X販売システム
クレジット
決済手続き
カード
<<include>>
携帯支払い
Xを購入する
顧客
<<extend>> PayPal
新規顧客情
報を登録す
る
26

27. ユースケースとは
モデル化する目的は？
 要件の理解・共有が容易
 登場人物（人に限らず）とその関係性を示せ
ること（主語が明確になる）
 ビジネスサイド、開発サイドの双方で共通の
認識が持てる
27

28. 28

29. ユースケースとは
ユーザーストーリーにも展開しやすい
3千円以上の購入で送料を無料にする
携帯支払いで支払う
クレジットで支払う
決済手続き PayPalで支払う
購入後は決済番号をメールで通知する
・・・・・・
・・・・・・
29

30. ユースケースとは
気をつけるポイントは3つ
 そのユースケースでシナリオは立てられます
か？
 ユースケースから立てたシナリオは言葉で説
明できますか？
 適切に見積もりできる単位ですか？（大雑把
すぎず細かすぎない）
30

31. ユースケース図の書き方
これだけ覚えておけば大丈夫
31

32. ユースケース図の書き方
先ほどの図を例に
X販売システム
クレジット
決済手続き
カード
<<include>>
携帯支払い
Xを購入する
顧客
<<extend>> PayPal
新規顧客情
報を登録す
る
32

33. ユースケース図の書き方
サブジェクト
X販売システム
開発対象であるシステム
33

34. ユースケース図の書き方
アクター
ユーザーや連携する外部シス
テムなど
顧客
34

35. ユースケース図の書き方
ユースケース
システムの振る舞い
Xを購入する
35

36. ユースケース図の書き方
汎化
クレジット
決済手続き
カード
携帯支払い
PayPal
抽象的な要素を具体的に表す
36

37. ユースケース図の書き方
include（包含）
決済手続き
<<include>>
Xを購入する
依存関係
例：Xを購入するには決済手
続きが必要
37

38. ユースケース図の書き方
extend（拡張）
拡張
条件によって行われる
例：新規ユーザーの場合は顧
客情報を登録する
Xを購入する
<<extend>>
新規顧客情
報を登録す
る
38

39. ユースケース図の書き方
アドバイス
 「ユーザーの行動」ではなく「行動したこと
で得られること」=「システムが何をしてく
れるか」を考えると書きやすい
例： 「氏名を入力」ではなく「ユーザー登
録」
 登場人物は人に限らない
39

40. ユースケース図の書き方
悪いユースケース
 開発者は細かくなりすぎ
 そうでないひとは簡単すぎ
40

41. ユースケース図の書き方
考えてみよう
自動販売機のユースケースを考え
てみよう
41

42. 最後に
42

43. ユースケース図を書くことを目的とし
最後に
ない
 多少UMLから外れても気にしない
 include とかextendとかは、大きいユース
ケースを分割するテクニック。無理に使わな
くていい
 必要が無いならやらないことも大事
 例えばプロジェクトの規模や難度によって判断
するなどの柔軟性をもたせる 43

44. 44