「RDRAで学ぶ要件定義」に参加してきました

Jimmy

2024年5月28日 22:51

2024/5/24（金）に開催された「RDRAで学ぶ要件定義」に参加してきたので、その内容と学んだことを共有したいと思います。

おことわり

この内容は非公式なものであり、自分なりに整理したものです。
- 本記事には誤りが含まれる可能性があります。
- 間違っている部分などがあれば、コメントいただけると助かります。<(_ _)>

サマリ

RDRAは個々のダイアグラムに注力するのではなく全体のつながりを俯瞰しながら要件を組み立てていく
RDRAモデルの粒度はあくまでも要件レベルであり、DB設計まで細かくするとメンテナンスが難しくなる
RDRAモデルのアクティビティ・業務フロー図は要件を洗い出すために定義し、精度はあまり求めない

本イベントについて

RDRA MeetUp主催のオフラインイベントで、今回はRDRAを用いた要件定義方法について学ぶ会でした。

① RDRAの概説

② RDRAスプレッドシートおよびRdraGraphを用いて、RDRAモデルの構造を知るワークショップ

ツールはRDRA公式サイトからダウンロードできます。
RDRAサイト内でバージョンが異なっていたので、最新版のリンクを参考資料にまとめました。

「RDRAとはなんぞや」という方は公式サイトがあるので、そちらを見ていただければと思います。

自分なりに整理したものもあります（※1）が、ほとんどRDRAサイトの方が詳細に書かれています。

（※1）学びや気づきがあり次第、更新しています。

イベントの概要は以下です。

RDRA についての理解を深めると同時に、Spreadsheet版RDRA を使用しての要件定義体験を通じて知識を実践します。
RDRA に興味がある方や、要件定義に関わる方にとって有益な内容になるかと思います。
また、質疑応答を通して RDRA や要件定義を深く理解する場にしたいと思います。
RDRAサイトの要件定義の進め方や既存システムの可視化などの質問も歓迎です。

RDRAで学ぶ要件定義のイベント概要より

RDRAの概説とワークショップで学び・気づきがあったところ

粗く全体像を作ってから洗練する

これは前々からおっしゃっていて、自分ではわかっている状態つもりでしたが、演習をやってみると他ダイアグラムのつながりを意識せずに考えているなと気づきました。

RDRA分析ファイルには全体を見渡せるためのシートがあるのでもっと確認しながら進めるべきだなと思いました。

神崎さんが話していた要件定義の進め方は以下です。
※RDRA公式サイト（要件定義の進め方）にも記載されています。

取り敢えずRDRAシートに要素を書き出す（1週間）
RDRA分析の不整合を解消しながら、全体の整合性を取りながら、要件を組み立てる
条件（ビジネスルール）を洗い出し、RDRAモデル全体の精度を上げる

RDRAの粒度は要件レベルで

RDRAの概説にて、粒度は要件レベルで統一するとメンテナンスしやすいとお話していました。
この要件レベルの粒度はどのくらいなんだと言うところですが、自分なりに整理してみました。
※UCと情報モデル図を対象にしています。

UC（ユースケース）：それを実行することで実行した人に何かうれしいことがある（何かが実現できる）
- 要件レベルのUC
  - ○○申請を行う 👈これを行うとユーザーは何かの申請を出すことができる
- ちょっと細かいUC
  - ○○申請内容を入力する 👈これをしても申請自体は完了していない
情報モデル図：エンティティレベル以上（※2）
- 要件レベルの情報
  - 顧客、商品、出荷
- ちょっと細かい情報
  - 商品詳細、出荷明細

自分の場合、UCは要件レベルで書けていたのですが、情報モデルはDB設計レベルまで詳細に記載していました。
まだ、活用しているツールが小規模だったのでメンテナンスに困っていなかったのですが、今後規模が大きいシステムでRDRAを使うときは粒度は気を付けたいです。

（※2）
神崎さんの経験則では情報モデルからDB設計すると、大体3倍くらいの量になるとのことです。
また、情報を管理したい≒何かの状態を持っているという解釈で状態モデルを書くので、書いた情報に状態があるかどうかも粒度の細かい基準になるかも知れません。

開発対象システム以外のやりとりも書いてよい

てっきり開発対象システムだけ書くものだと思っていましたが、確かに外部環境を整理するという上ではそれ以外の情報も必要だなと気づきました。

アクティビティや業務フローは要件を組み立てるために定義しているだけであり、そこまでの精度は求めない

要件定義時点で精密に業務フローを作成しても、リリース後にそのとおりに動くことはあまりないため、そこに注力するならどの情報を管理したいかやどんな状態を持っているかなどのシステムレイヤーの精度を上げた方が良いとのことでした。

アクティビティや業務フローは考えやすく、詳細まで検討していたなと感じました。
次からはシステムレイヤー部分などにより注力しようと思います。

所感

RDRAモデルを組み立てるときに迷うところがあったので参加してみましたが、とても有意義な時間を過ごせました。
また、自分はRDRAモデルを修正していくうちに細かく書き出してしまう傾向があるとわかりました。
RDRAモデルを見直すときは粒度を気にしながら書きなおしていきたいと思います。

本イベントの参加者は20人程度でしたが、いろんな質問がとび、「なるほど、そのような観点あるな～」と勉強になりました。あまり質問できない私からするといろんな気づきを得られ、とても勉強になりました。
また、RDRA勉強会があれば参加したいと思います。

あと、懇親会で食べた親子丼おいしかったです。

参考資料

RDRAツール（2024/5/28時点の最新版です）

使い方については以下に記載されています。

RDRAについて

RDRA MeetUpについて

この記事が気に入ったらサポートをしてみませんか？