2021/12/8「ユースケース駆動開発をやってみた」での発表資料です。 https://modeling-how-to-learn.connpass.com/event/229330/

1. ユースケース駆動開発の
ワークショップやってみた！
澤井 友恵（ともえーぬ）
@tomoeine

2. こんな人に聞いてもらえたらお役に立てそう
● 「ユースケース駆動開発」を読んだことがあるけど、
いざ実践投入するイメージが湧かない人
● 「ユースケース駆動開発」「ICONIXプロセス」をなんとなく知っているけ
ど、具体的なプロセスはまだあまり知らない人
● ワークショップ形式のICONIXプロセス勉強会を開いてみたい人

3. 自己紹介
フリーランスWebエンジニア
ともえーぬ @tomoeine
● 東京→宮崎移住（5年前）
● フリーランス歴３年半
● スタートアップ・ベンチャーを中心に、
スモールチームメインで開発のお手伝い
● よく使うのは Laravel, Node.js, Vue.js, Ruby
on Rails, AWS 等
● 設計や開発プロセスを学ぶのが好き
（実践はまだまだ・・・）

4. みんなでポモドーロする「minporo」

5. アジェンダ
● ICONIXプロセスへの理解
● ワークショップの進め方
● ワークショップの内容紹介
○ ドメインモデリング
○ ユースケースモデリング
○ ロバストネス分析
● ワークショップで学んだこと

6. ICONIXプロセスへの理解

7. ICONIXプロセスの全体像
● 要求定義よりも後の作業は
イテレーティブ（繰り返し）。
● 最初のドメインモデルとユースケースは
ドラフト版。
以降のプロセスでアップデートされる。
● 稚拙ですが、初心者向けの記事も書きました
のでよろしくお願いします！
https://zenn.dev/tomoeine/articles/2bab
b554aa0478
https://tomoeine.github.io/2021/04/sof
tware-design-miyazaki-202104/

8. ワークショップの進め方

9. ワークショップの参加者
先生（たち） 初学者たち
実務でICONIXプロセスを使っています
進め方を指南しますよ
私が要求を伝えます
ICONIXプロセスの経験者を指南役としてお招きした
メンバーの中からドメインエキスパートを決めた
ドメインエキスパート

10. ワークショップで実践した範囲

11. ワークショップの題材
居酒屋でボトルキープを記録するアプリ
● お客さんが居酒屋やスナックに行き、
ボトルキープしたらそれを記録する
● お客さんは後で
キープしたボトルを確認する
● お店側も、誰がどのボトルを
キープしたか確認する

12. ワークショップの内容紹介

13. ドメインモデリング

14. ドメインモデリング
ドメインエキスパート
スナックや居酒屋で焼酎のボトルをキープした際に、
スマホで写真を撮って記録するアプリが欲しいです。
なるほど。その記録を見るのは誰ですか？
ボトルをキープしたお客さんと・・・
ボトルを提供したお店ですね。

15. ドメインモデリング
なるほど。ではドメインモデルはこんな感じでしょうか？
はい。それで良いと思います。
● restaurant: 居酒屋やスナックの店舗
● customer: ボトルキープするお客さん
● kept_bottle: キープされたボトル

16. ユースケースモデリング
〜ユースケース図〜

17. ユースケース - ユースケース図
お客さんは最初に、アカウント登録をします。そして
お店でボトルをキープしたら記録します。その際、お
店を一覧から選ぶか、未登録であれば自分でそのお店
を登録します。
後日同じお店でボトルの中身を飲みきったら、再度そ
れを記録します。
お店側も、誰が何をキープしているか確認できます。
このシステムを利用する際の流れを教えて下さい。
お店を登録できるのはお客さんだけですか？
お店のオーナーも、自分のお店を登録できた方がいい
ですね。
また、オーナーのなりすましを防ぐために、管理者に
よる承認が必要です。

18. ユースケース - ユースケース図
では、ユースケース図はこうでしょうか。
新たなドメインモデルが見つかりましたね！

19. ユースケース図を踏まえてモデル図をアップデート

20. ユースケースモデリング
〜ユースケース記述〜

21. ユースケース記述
今回のシステムで最も重要なユースケース、
「ボトルをキープする」についての
ユースケース記述を作成してみましょう。
ここからはイテレーションですね！
● ドメインモデルの用語を用いる。
● バウンダリクラス（主に画面名）の名前を使う。
● ユーザーとシステムの対話の両側を記述する。
● 指示的ではなく叙述的に書く。
● 基本コースと代替コースを記述する。
● 紙芝居やGUIプロトタイプを用いる。
以下のポイントに気をつけながら作成しましょう。

22. ユースケース記述 - 基本コース
まずは「基本コース」から考えてみよう。
「ボトルをキープする」の基本コース
1. customer は名前を書いたボトルの写真を撮る
2. システムは位置情報を取得し、近隣の restaurant 一覧を表示する
3. customer は restaurant 一覧から自分の居る restaurant を選択する
4. システムは kept_bottle と restaurant と時刻を登録し、
完了画面を表示する
「基本コース」はこれで良さそうです！
ドメインエキスパートさん、どうでしょうか？

23. ユースケース記述 - 代替コース
「ユーザーがログインしていない」ケースの考慮が必要で
す。
なるほど！確かに必要ですね。
次に「代替コース」も考えてみましょう。
「代替コース」とは、いわゆる「異常系」ですよね。
「ボトルをキープする」の中でどんな代替コースがあるで
しょうか。
「ボトルをキープする」の代替コース
1. システムは、ログインしていない場合はログイン画面を表示する

24. ユースケース記述 - 基本コースと代替コース
「ボトルをキープする」の基本コース
1. customer は名前を書いたボトルの写真を撮る
2. システムは位置情報を取得し、近隣の restaurant 一覧を表示する
3. customer は restaurant 一覧から自分の居る restaurant を選択する
4. システムは kept_bottle と restaurant と時刻を登録し、
完了画面を表示する
うーん、ログインチェックしてログイン画面を表示するの
はどのタイミングなんだろう・・・？
「ボトルをキープする」の代替コース
1. システムは、ログインしていない場合はログイン画面を表示する
「基本コース」に足りない項目があるようですね。

25. ユースケース記述 - 基本コースと代替コース
「ボトルをキープする」の基本コース
1. customer は「keepする」ボタンを押す
2. システムは keep画面を表示する
3. customer は名前を書いたボトルの写真を撮る
4. システムは位置情報を取得し、近隣の restaurant 一覧を表示する
5. customer は restaurant 一覧から自分の居る restaurant を選択する
6. システムは kept_bottle と restaurant と時刻を登録し、
完了画面を表示する
「ボトルをキープする」の代替コース
2-a. システムは、ログインしていない場合はログイン画面を表示する
5-a. customer は、自分の居る restaurant が
restaurant 一覧にない場合はrestaurant 追加ボタンを押す
5-b. システムは、 restaurant 追加画面を表示する
keep 画面までの導線が足りな
かったんだ！

26. ロバストネス分析

27. ロバストネス図とは
バウンダリ
オブジェクト
（名詞）
エンティティ
オブジェクト
（名詞）
コントローラ
オブジェクト
（動詞）
● バウンダリとエンティティは名詞、コントローラは動詞として捉え、「名詞-名
詞」にならないように表現する
×バウンダリ-エンティティ ○バウンダリ-コントローラ-エンティティ
● ユースケース記述に合致させて表現する
● 代替コースも漏れなく記述する
● 詳細設計に踏み込まない
● 新たに見つけたオブジェクトをドメインモデル図に反映する

28. ロバストネス分析
ユースケース記述の上から書き出してみよう。
トップ画面 ログイン状態
か？
customer
ログイン画面
いい
え
keep 画面
はい
写真を撮る？
keep 画面で写真を撮る、でいいのかな・・・？
まずは、「撮影」ボタンを押す操作が必要でしょうか？

29. ロバストネス分析
できるだけ操作をシンプルにしたいので、トップ画面から
遷移してきた時点で、スマホのカメラが立ち上がって欲し
いですね。
なるほど！
私はここにボタンがあるのかと考えていました。
チーム内で画面のイメージが揃えた方が良さそうですね。
簡単なワイヤーフレームを作って、イメージを共有しま
しょう。

30. ワイヤーフレーム作成

31. ワイヤーフレームを踏まえたロバストネス図の修正
トップ画面 ログイン状態
か？
customer
ログイン画面
いい
え
ボトル撮影画面
はい
写真を撮る
写真をメモリー
上に保存する
この画面を踏まえると、今まで「keep画面」と呼んでいた
画面は「ボトル撮影画面」と呼んだ方がわかりやすいです
ね。

33. 完成したロバストネス図

34. ロバストネス分析を踏まえたユースケース記述の修正
「ボトルをキープする」の基本コース
1. customer は「keepする」ボタンを押す
2. システムはボトル撮影画面を表示する
3. customer は名前を書いたボトルの写真を撮る
4. システムは写真をメモリー上に保存して、位置情報を取得し、近い順に最大n件の restaurant 一覧を検索し、
restraunt 一覧画面に表示する
5. customer は restaurant 一覧から自分の居る restaurant を選択する
6. システムは kept_bottle と restaurant と時刻を登録し、
完了画面を表示する
「ボトルをキープする」の代替コース
2-a. システムは、ログインしていない場合はログイン画面を表示する
4-a. 位置情報が取得できない場合、「位置情報が取得できません」エラーメッセージを表示する
5-a. customer は、自分の居る restaurant が
restaurant 一覧にない場合はrestaurant 追加ボタンを押す
5-b. システムは、 restaurant 追加画面を表示する

35. ワークショップで学んだこと

36. ワークショップを通じて学んだこと
それぞれのプロセスでは「完璧だ！」と思っていても、
ユースケースモデリングしたらドメインモデルの不足に気づいたり、
ロバストネス分析したらユースケースの漏れに気づいたり・・・
ICONIXプロセスの流れに従うことで、参加者全員の要求への理解が深まった！
ワイヤーフレームなしで突き進んだら、ロバストネス分析で混乱してしまった
本書にある通り、ユースケースモデリングの時点でGUI紙芝居を作成しておけばよかった
ドメインモデルはゆくゆくクラス図に進化するものという前提のもと英語でドメインモデルを作ったら
現実で使う言葉と違うので以降の作業が難しくなった
やはり現実で使っている日本語を利用するべき？
その場合、クラス名とのマッピングはどうする？

37. ご清聴ありがとうございました！
澤井 友恵
@tomoeine
ユースケース駆動開発の
ワークショップやってみた！