目次

はじめに

この記事は、とあるプチ勉強会の中で、演習的に ICONIXプロセス を実践してみた記録です。
ICONIXプロセス・ユースケース駆動開発について学びたい方は ユースケース駆動開発実践ガイド をぜひ読んでみてください。

ざっくり概要を知りたい方は、よろしければ以下の記事もご活用ください。
https://zenn.dev/tomoeine/articles/2babb554aa0478

序文

きっかけは、宮崎のコワーキングスペース ATOMica で作業していたとある日のこと。
その日は、誕生日プレゼントとしていただいたばかりの「ユースケース駆動開発実践ガイド」を傍らに置いて作業していました。(Nさんありがとうございます!)

そこに通りがかった宮崎を代表するつよつよエンジニアEさんが「こういうテーマのプチ勉強会したいよね」と。
これはやるしかない!
ということで宮崎IT関連勉強会の Slack で参加者を募り、勉強会開催に漕ぎ着けたのでした。

第1回は、私が本を読んだアウトプットとして書いた 前段のまとめ記事 を話の入口にしつつ、Eさん&Kさんがどんどん話を拡げてくださり、ICONIXプロセスに加えてテスト駆動やDDDの話を「なるほど、なるほど」とお勉強させていただきました。

そして、本記事本題の第2回。
5人が集まりました。
今回はざっくり、「実際に何か手を動かしたいよね〜」と話していましたが、ノーテーマ。
その場で案を募ったところ、Iさんから「居酒屋のボトルキープを管理するアプリという以前からのアイデアがあるんだけどどう?」とご提案が。 そこで、前回同様Eさん&Kさんに講師をしていただきながら、IさんをドメインエキスパートとしてICONIXプロセスを進めてみる会となったのでした。

ICONIXプロセスの実践

さあ、ここからがこの記事の本題です。

モデルを洗い出す

まずはドメインエキスパートのIさんに、ざっくりとした要求をヒアリングします

要求

1
2
3
お客さんが居酒屋やスナックに行き、ボトルキープしたらそれを記録する。
お客さんは後でキープしたボトルを確認する。
お店側も、誰がどのボトルをキープしたか確認する。

この要求を元に、以下のモデルを洗い出しました。
この時点ではのモデルはドラフト版で、後で修正します。

  • restaurant(居酒屋やスナックの店舗)
  • customer(ボトルキープするお客さん)
  • kept_bottle(キープされたボトル)

ここで洗い出したモデルは、後のフェーズでもずっと使う「用語集」にもなります(DDDで言う「ユビキタス言語」)。

ユースケース図を書く

ユースケース駆動開発実践ガイドの中では「ユースケース記述の書き方」を中心に説明されていますが、これは各ユースケースを詳細に説明するためのもの ユースケースを洗い出すために、まずはユースケース図を作ります。

ユースケース作成にあたり、さらに詳しく要求を洗い出していきます。

さらに詳しい要求

1
2
3
4
5
6
7
8
9
customer は kept_bottle を記録する前に、システムへアカウント登録する。
restaurant でボトルキープしたら、アプリにそれを登録する。
restaurant が既にシステムに登録されていたらそこから選択し、登録されていなかったら自分で新たに追加する。
また、再度 restaurant に訪れ、ボトルの中身を飲みきったり残量が減った場合には、それを記録する。
restaurant も、自分自身のお店を登録する。
さらに、お店の管理者として申請する。
restaurant の管理者として正しいかどうかは administrator が確認し、承認する。
restaurant は、管理者になっているお店の kept_bottle一覧を確認する。
キープから一定期間経過した場合に、restaurant は kept_bottle を捨てることがある。

後々クラス名としてそのまま使えるようにと英語でモデル名を命名していましたが、日本語のユースケースの中で使うのは結構難しいですね。。
二重の定義になってはしまいますが、はじめは日本語でモデル名を決めて、最終的なクラス図にアップデートするときに英語に訳していく方が扱いやすいのかなぁと思いました。

そして作成したユースケース図がこちら。

ユースケース図(ドラフト版)

ユースケース図(手書き)
ユースケース図(手書き)

更新しやすいように PlantUML でも作成。(後日)

ユースケース図(PlantUML)
ユースケース図(PlantUML)

ここでさっそく、モデルに修正が必要なことに気付きました。
そう、サービスを管理する「administrator」が必要だったのです。

更新されたモデル

  • restaurant(居酒屋やスナックの店舗)
  • customer(ボトルキープするお客さん)
  • kept_bottle(キープされたボトル)
  • administrator(サービス管理者)

このユースケース図もまだドラフト版です。 以降のユースケース記述・ロバストネス図を踏まえて修正していきます。

ユースケース記述を書く

次は各々のユースケースについてユースケース記述を書きます。 勉強会では時間がないので(この記事全体のプロセスで2時間・・・!)、「ボトルをキープする」という、このサービスの核となるユースケースについて作成することにしました。 ここまでのディスカッションの中でメンバー内でのサービスイメージは共通化されているし、そんなに難しくないはず・・・
と思っていたら、出るわ出るわ不明点w
さらにディスカッションを重ね、システムに求める挙動を明確にしてきました。

「ボトルをキープする」に関するさらに詳しい要求

1
2
3
4
customer はボトルキープ前にログインが必要。
kept_bottle を登録するときは、まずボトルの写真を撮り、次に店舗を選択する。
選択可能な店舗は、位置情報を元に一覧表示される。
一覧に今いる店舗がなければ、自分で登録する。

ユースケース記述「ボトルをキープする」

以下のポイントに気をつけながら作成していきます。 - ユーザーとシステムの両側を記述する - 基本コースと代替コースを記述する

ユースケース記述(ホワイトボード)
ユースケース記述(ホワイトボード)

こちらも文字で転記しておきます。(後日)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[基本コース]
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 追加画面を表示する

当日は、ホワイトボードに書いてしまったため後から修正できずに苦しみましたw
ユースケース記述あたりからは、PCで作業してモニターに映す方が捗りそうです。

ロバストネス図を書く

慣れない作業で、みんなで頭を捻りながらなんとか作成。 ここでまたさらに、不明点が出てくる・・・ 特に「具体的にどんな画面なんだっけ?」という認識がメンバー間で統一されていないために混乱が起きました。 というわけで、簡単なワイヤーをホワイトボードに書きながら、画面への要求を固めていきます。

「ボトルをキープする」の画面に関する要求

1
2
3
4
5
- サービスはスマホアプリのイメージ。
- トップページには「keep する」ボタンが表示されていて、これをタップ後にログイン状態をチェックする。ログインしていなかったらログイン画面を表示し、ログイン後はそのまま写真撮影画面に遷移する。
- ボトルの写真を撮影後、何かボタンを押す必要はなく restaurant 選択画面に遷移する。
- restaurant 選択画面では近隣の restaurant 一覧が並んでおり、対象の restaurant をタップしたらそのまま登録される。
- restaurant 選択画面に「追加する」ボタンが表示されており、これをタップすると restaurant 追加のユースケースに入る。

ロバストネス図「ボトルをキープする」

特に以下の点に留意して作成します。

  • バウンダリ(画面)、エンティティ、コントローラの3種類のオブジェクトを描く
  • バウンダリとエンティティを名詞、コントローラを動詞として扱い、「名詞-名詞」で繋がらないようにする(「名詞-動詞」「動詞-動詞」はOK)

ロバストネス図「ボトルをキープする」
ロバストネス図「ボトルをキープする」

こちらも PlantUML で再度。

ロバストネス図「ボトルをキープする」
ロバストネス図「ボトルをキープする」

勉強会ではいきなり図を書き始めてアワアワと混乱しましたが、PlantUML で書いてみて、最初にオブジェクトを洗い出しておけば書きやすかったのかーと気付きました。次回に生かそう。

まとめ・感想

さてはて、ここまでやってみると、ユースケース図もユースケース記述にも若干の不足がありますね!
また、モデルにも属性や振る舞いを追記していけそうです。
この修正作業は、次回開催時にみんなでやっていこうと思います。

おわりに

勉強会に参加してくださった皆さん、特にみんなを導いてくれた Eさん・Kさんありがとうございます!
そしてこの勉強会のきっかけとなった「ユースケース駆動開発実践ガイド」を贈ってくださったNさんにも改めてお礼申し上げます。
第3回は5月かな?
開催後はまた記事にするつもりです。頑張ります。