概要

「RDRA モデリングを体験しよう」に参加しました。似たような書籍では、「ユースケース駆動開発実践ガイド」を読みました。今回の予習のために、「RDRA2.0 ハンドブック」で概要を知り、Optro のビジネスケースも読んできた状態でした。

作者:神崎善司

感想

RDRA の第一人者がハンズオン形式で教えてくれる、いい機会でした。 RDRA がどこからとりかかるのか本ではわかりにくかったので、良いとっかかりになりました。スプレッドシートを使った RDRA のやり方、モデリングの練習にしやすい「ビジネスモデル 2.0 図鑑 #全文公開チャレンジ」の紹介と、今後も使えそうな内容も学ぶことができてよかったです。

ICONIX プロセスのロバストネス図と同様に、How と Why、What を完全に切り分けて要件定義を行うメソッドを学ばないと結局何を作りたいのか不明瞭になりがちなので、復習をしたいです。書籍では RDRA は関連図がメインだったので、スプレッドシートで実装する方法だったのはついて行きづらかったです。若干、進行スピードが速く感じましたが、2 時間でやるならおそらくこれが限界ですね（あと、自分の予習不足です。。。）。

自身については完全に予習不足でした。概念や用語をなんとなく把握していたのですが、実際に手を動かして作ったわけではないので、実際に考えるときにはついていくのに精一杯でした。参加するときには、RDRA2.0 の内容を手で動かした状態で参加する方がいいです。今回、2 回目だったので 3 回目の機会があれば、しっかり準備してリベンジしようと思いました。

内容

内容は以下のような感じでした。ハンズオンのフローを意識しながら、RDRA2.0 を読み直したいと思います。

## 導入

「RDRA モデリングを体験しよう」

狙い

- 要件定義は「決める」肯定
- 決めるための仕組みを体感する
  - 今回は Google Sheets を使用
- モデリング
  - 爆然とした形にする

本日の対象は「ビジネスが成立していない」場合
ビジネスが成立していない -> ビジネスの仕組みを考える
ビジネスが成立している -> ビジネスを支えるの仕組みがある

## RDRA の説明

ハシュタグ「#RDRA」

RDRA の構造
下から上に依存がある
- システム価値 要求、アクター、外部システム
- システム外部環境 業務、ビジネスユースケース、業務フロー、アクティビティ、条件、バリエーション
- システム境界 ユースケース、画面、イベント
- システム 情報、状態

イベントは外部システムとつながる
ユースケースは単位

## スプレッドシートの説明

9 つのシート、機能要求と非機能要求は使わない
頭の中では関係性を意識する

BUC シートに業務、BUC、アクティビティ、UC などを記述する
アクティビティに会員では画面を使う -> ユースケースがない

条件のシートはバリエーション、状態モデルと関連している状態ののか意識する
条件にはバリエーションと状態モデルの組み合わせ

状態シート、には状態モデル、状態、状態 UC、状態遷移

アクターシートには分類とアクター名を書く

## ワークの説明

Optro を書く

- このビジネスは
  - アクターの関心に関わる
  - 関わる個人、会社は？
  - 時や（Optoro）の業務は？
  - 扱う情報は？
  - 関心のある状態は？

- アクター
- 個人
- 会社
- 扱う情報

## ハンズオン 1

- アクターを探す
- 外部システムを探す
- 業務の単位を探す
  - 点線で囲われた箇所に業務として名前をみる
  - 大手小売-倉庫
  - 倉庫-修理業者
  - Optitune-再販サイト
  - 再販サイト-Optoro,Inc.
- 業務を分解を考える
  - BUC の洗い出し
    - BUC の価値・責務は？
    - その BUC は何ができたらいいの？

## ハンズオン 2

- バリエーション
  - 商品にはどんな種類があるの?
  - どんな種類の会社がありますか？
  - 条件の軸に結びつきやすい
- 情報
  - 関わるアクター、外部システムはどのような情報で仕事をしているのか?
  - 情報を洗い出す
- 状態
  - わざわざ ID で管理するする必要はなに？
  - アクションに結びつきやすい


## 休憩


## ハンズオン 3 仕事の組み立て

- アクティビティ
  - BUC の一連の流れを確認
- ユースケース
  - システムとの関係をユースケースで表現


## ハンズオン 4 システムを組み立てる

- アクターとの関係
  - そのシステムに誰が関わるのか?
  - 画面-アクター
- 外部システム
  - その外部に関わる外部システムは?
  - イベント-外部システム

- 情報
  - 情報をつなげて意味を語る
  - UC と情報をつなげる
- 状態
  - 状態を遷移させる
  - 遷移を UC に

以下は質問コメントです。拾えるものだけメモしたので支離滅裂になっていますが、読み直したときに得られるものがあるかもしれません。

- 人がアクションを取るために参照するのが、情報


バリエーションは早い段階ででる

一般論としては、バリエーションはポンチ絵レベルでだしやすい。そのあと、情報レベルでだして、そこから 状態煮出すことが多い

BUC は難しい
質問：業務と BUC の粒度の違いがよく掴めませんでした。
システムが小さいとかわらない

より大規模になるとアクターが同一業務でもわかれることがあるので、BUC がより細かくなる（かもしれない
大規模になりすぎてしまう

業務、BUC、アクティビティを省いて UC のみを書くのは不都合ありますか？
一人（説明する人がいない）なら大丈夫

状態は遷移前と遷移後を考える
遷移前と遷移先を考えると、抜け漏れなどが見えてくる

アクティビティと UC は同じになりがち
PC を使うところと使わないところわける

情報は「when に what に how したよ」。情報を操作することで状態がかわる
あるユースケースで情報を操作することで、状態が別の状態に遷移すること

参照シートを使うと未定義が整理されてよさそう

RDRAはHowを考えない、WhatとWhyにのみ注力する

マイクロサービスに適用するときは、RDRAは切り分ける

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

「RDRA モデリングを体験しよう」参加感想

概要

感想

内容