connpass
https://ddd-alliance.connpass.com/event/54308/
先日、「DDD Alliance! ドメイン駆動設計 RDRA Night!」」というイベントがありました。
そんとき書いたブログはこちら。
「DDD Alliance! ドメイン駆動設計 RDRA Night!」に参加してきたのでブログにメモ。https://t.co/VzZsWXjsTn#DDDAlliance
— makopi23 (@makopi23) 2017年4月17日
今回はその続編ということで、ワークショップを通じて実際に手を動かしてRDRAの勘所を体験する、というインベントです。
ブログを書いてネタバレにならないか、と神崎さんにお聞きした所、「問題ない」とのことだったので、自分の復習用にメモを書いてみる。
RDRAワークショップ
ワークショップをやる前に、RDRAの概要について説明がありました。
前回イベントでもブログに書いたけど、今回もさらっとメモ。
要件定義には何を定義すればいいのか
- 要件定義を「システムだけでなくシステムをとりまく環境」まで考える。
要件定義の構造を定義する
- 何が定義されていないといけないのか。４つの視点で構造化する。
- システム価値、・・・ 価値を与えているものは何かを見る。人と外部システムをとらえる。価値は人がきめるので、誰がかかわるのか決める。
- システム外部環境 ・・・ どう使われるのか。システムの外部環境は、業務フローか、書けないならシーンを明確にする。
- システム境界 ・・・ 人と外部システムとの連携部分。
- システム ・・・ 機能とデータとドメイン構造を書く。
- RDRAでは、モデルも状況によって使い分けするが、４つの視点は変わらない。
- 視点ごとに作るモデルを省いたりする。
要件分析の枠組み
- RDRAでは、４つは依存関係が大事。依存関係があるから要件が早く決まる。
- 「システム」を決めるためには「システム境界」が決まってないといけないし、「システム境界」は「システム外部環境」が決まってないといけない。
- 外側に視点をずらしていく。
- 外側がWhyになっている。なぜ、はすべて外側にある。
コンテキストモデルからシステム境界まで
- イベント ・・・ 外部システムとどういうやりとりをするのか
- プロトコル ・・・ 状態遷移図
- 「６．外部システムとのプロトコルを整理」では、はビジネス上認識しているユーザの状態を整理する。
- オブジェクト指向のクラスではまだ見えてないので、それに対する状態遷移図ではない。
- 「未出荷リスト」を出してくれ、という要求に対して、「未出荷」という状態を捉える。
- 「７．ユースケースに関わるユーザーインタフェースを洗い出す」では、業務フローからユースケースが出てきて、それに画面をひっつけてインタフェースを出す。
- 画面のレイアウト考えましょう、という話ではない。
- 必要に応じて画面のラフスケッチを書く。
- 「８．ユースケースを実現する機能を洗い出す」で、RDRA for DDDでは「機能モデル」はほとんど書かない。
- 「９．アクションを機能に対応付ける」で、イベントを機能に結びつける。今回は機能はないのでやらない。
- 「１１．機能とデータを突き合わせる」で、機能とドメインを結ぶ。
RDRA for DDD
- RDRA for DDDは深く分析する部分をdddにまかせている。
- 「システム境界」は、ユースケースを中心に画面とイベントとアクターがくっついてる。
RDRA for DDD システム地図
- 今回のワークショップでは、システム地図を作成する。１枚で全部書く。
- システム地図を使って１枚で全部書くのと、RDRA for DDDで４領域を分けて書くのと、あんまりかわらない。
- ４領域を全部ひっつけるとシステム地図になる。今回は時間がないので、システム地図を書く。
グループ演習：システム地図を作る
今回は、実案件よりは簡単な題材でRDRAを実践してみるとのこと。
纏まったドキュメントを作る、というよりも、２時間で要求定義として形をまとめることが目的。
繋げてものを考えると、ある程度形になることを経験する。
今回は「RDRA Map Maker」というツールを使いました。
参加者にはツールのURLが公開され、３人１チームで、各チームにPC１台、このツールをインストールしました。
お題
- 「会議室.com」という、会議室を貸したい人と借りたい人をつなぐサイトを作りましょう。
- 貸会議室を営む会社から開発依頼を受けた想定で、マッチングビジネス用のサイトを開発する。
- アクターに対する利用シーンを繋げて、情報まで洗い出すところまでやって完了。
ホワイトボードの左にあるとおり、「アクター」から「情報」まで順に洗い出していきます。
- アクター
- 要求
- 利用シーン
- ユースケース
- 外部システム
- イベント
- 画面
- 情報
チームに別れて、RDRAのワークショップを実施中！
— Kentaro Takasaki (@ken_takasaki) 2017年4月18日
各チーム熱く語り合いながら、アクターや要求、利用シーン、ユースケース、外部システム、イベント、画面・・・と各要素を順番に洗い出してます！ #DDDalliance pic.twitter.com/FjHN8cN6AC
「アクター」と「要求」
うちのチームは「アクター」と「要求」は以下のように洗い出しました。
アクターの洗い出しは比較的すんなりいったけど、ステークホルダーをどこまで考えればよいのかは気にする必要ありそう。
あと、「要求」は別画面に洗い出すように、との指示でした。この理由は後述の質疑応答にて。
「利用シーン」と「ユースケース」
利用シーンは「どういうふうに使えると嬉しいのか」を書くとのこと。
が、これが案外、難しい。どのチームも「利用シーン」を出すのに苦労してたようです。
というのも、この次の「ユースケース」との違いがわからなくて・・・ウチのチームも苦労しました。
神崎さん曰く、「利用シーン」より先に「ユースケース」を考えても問題ないとのこと。
「ユースケース」が安定すれば「利用シーン」はいらなくなるとのこと。
というわけで、うちのチームも「ユースケース」と「利用シーン」を同時に考えるように進めました。
一番左が「アクター」、真ん中が「利用シーン」、一番右が「ユースケース」。
「外部システム」と「イベント」
次は外部システムを洗い出しました。
うちのチームでは、「認証システム」と「決済システム」を外部システムとしました。
次に、外部システムとユースケースをイベントで結びます。
「イベント」は「入金」と「認証」としました。
赤枠が「外部システム」で、青枠が「イベント」。
「画面」と「情報」
最後に、「画面」と「情報」を分析します。
こんな感じで出来上がり。四苦八苦しながらもなんとなく形になりました。
発表
今回、3人チームで5チームあったので順に発表していき、随時、質疑応答がありました。
ピザとビールが届いたので、美味しく戴きながらの発表ｗ
質疑応答や意見交換で出た、神崎さんや増田さんや参加者からのコメントメモ。
図示する効果
- 要求は網羅できない。なので、重要なやつだけ覚えておいて図にする。
- 図を作ってるといろいろ見えてくる。
- そうすると、「こうしよう」と決められる。
「要求」だけ別タブで設計した理由
- 「要求」に戻って、「～～できること」と決める
- 「要求」だけ違うシートに書いたのは、その要求でコントロールするため。
- 要求を出していって、それでコントロールする。
オブジェクトを繋げる線
- 矢印の向きは考慮しない。（考慮してもよいが）
ユースケース
- 「利用シーン」と「ユースケース」の違いがしっくりこないという意見が多い印象。
- 「予約をする人」と、「その予約を見ている人」は別のユースケース。
イベント
- RDRAはシステムを使った仕事の単位で考える。
- 「入出金」は入金と出金の両サイドあるが、自社の立場でどちらになるのかを考えるほうがよい。
- UML的には外部システムをアクターと捉えることもあるけど、RDRAでは外部システムとアクターを分ける。
- 「バッチ処理」とかは「手段」なので、RDRAの地図では表現しない。
- 外部システムがイベントに繋がって、そのイベントがユースケースに繋がる。
- イベントは外部のシステムの何とつながるのか、の「何と」を表す。
アクターとユースケースの間に利用シーンを挟むのは？
- アクターとユースケースを直でつなぐのはあり。
- ユースケースが安定してるなら、利用シーンはいらない。
- ユースケースは「システム境界」。
- れがまとまらないなら「システム外部環境」を置きましょう。それが利用シーンになる。
- ユースケースを利用シーンより先に考えるチームが多い。
- そのあとロジック洗い出しをする。計算ロジックとか判断ロジック。
- ここまでに機能と情報は洗い出せてる。
- どういうロジックが独自性なんだ、と探していく。
DDD
- DDDはコアのロジックを探していく。
- DDDはシステム全体をどうつくるか、というのにはフォーカスしてない。
- RDRAで全体地図を作り、どこから攻め込むかを広く浅く見て、コアの部分をDDDで攻める。
情報
- 最後に洗い出した「情報」は、DBテーブルやクラスではない。
- 業務的な情報のこと。イメージは伝票。階層構造。
付箋の使用
- 付箋で出すと発散方向に向かうので、どう収束させるか考える必要がある。
- 線で結ぶ。
- 粒度を決めたらそのままうまくいくか、というと、うまくいかない。
- なのでとにかく出してみて、「このくらいの書きっぷりだね」と感じ取る。
網羅性
- 画面中心だと、網羅しているか、とかわからない。
- そいういうのをもうちょっと網羅してるとか、タイミングがどうあればいいのか、とか考え始めるとユースケースとか考えないと見えてこない。
シーケンス図ではダメなのか
- シーケンス図とRDRAは対比できない。
- シーケンス図はあんまり書かない。なぜなら、網羅してないから。
- シーケンス図を書くくらいなら、状態遷移図を書くかな。
まとめ
- 「画面」と「ユーザーストーリー」の関係を結びつけてみると、いろいろわかる。
- とにかく繋げてみる。違う視点の要素をつなげてみる。
- それをチェックするのはSIでもWebサービスでも価値がある。
- 今回伝えたかったのは、「繋げると議論ができる」という点。
- アクターとか利用シーンはシステム境界の外で、価値に関わる。
- ユースケースとかはシステム境界。
そんなこんなで発表や質疑応答が22:00まで続きました。19:00開始なので、たっぷり3時間。
懇親会
発表会終了後、更にお菓子やおつまみも追加され、23:00頃まで懇親会。
美味しくいただきながら、神崎さんや増田さんといろいろ会話させていただきました。
感想
先日の講演ベースのイベントに加え、こーゆうワークショップが別に設けられ、手を動かす機会があるのは凄く良いですね。
短い時間ではありましたが、手と頭を使ってチームで意見交換しながら１つの成果物を作るのは良い経験になりました。
RDRAは初めてだったのでシステム地図の作成には四苦八苦しましたが、議論を重ねつつとりあえず書いてみると、いろいろ見えてきて、更に議論が活性化される。
線で繋ぐと異なる視点間の関係性が見えてきて、更に議論が活性化されます。
関係性(リレーションシップ)で駆動するシステムの地図作り。RDRAの真髄と、実用性を実感できる良いワークショップでした。
— 増田 亨． (@masuda220) 2017年4月19日
見ず知らずのメンバーが集まったチームで、短い時間のなかで、ユビキタス言語がみるみる育っていく光景は、感動的ですらあった。 https://t.co/QvvOSrdwbm
あと、図書館で本を借りてきました。
体系的に学ぶのと復習を兼ねて、読んでみたいと思います。
関係者の皆様、ありがとうございました。
