RDRAについて、5W1Hで整理してみた
要件定義でRelationship Driven Requirement Analysis（以下、RDRA）を使っており、その時に調べた内容や参加した勉強会をもとに5W1Hで整理してみました。
※調べた書籍や勉強会については「参考にした書籍・ブログ・動画」に記載しています。
間違えている部分があれば、コメントいただけると助かります。
WHAT：RDRAとは何か
WHY：RDRAの背景は何か
WHEN/WHERE：どのタイミングで/どの工程でRDRAを活用できるのか
WHO：誰がRDRAを使うのか
HOW：RDRAでどのように要件定義するのか
まとめ
RDRAはシステムの全体像を、すばやく、かつ整合性を保ちながら明確にする軽量なモデルベース要件定義手法
RDRAモデルはシステム全体像の把握、現状システムの可視化、コミュニケーションの土台として活用できる
神崎さん自作のツールを使うとよりRDRAの効果が実感できる
WHAT（RDRAとは何か）
RDRAはシステムの全体像を、すばやく、かつ整合性を保ちながら明確にする軽量なモデルベース要件定義手法です。
この手法では、システムの外部環境（システムの使われ方）からシステム内部（データ、状態）までのつながり（関係性）を重視しています。
RDRAはドキュメントを作成するのではなく、要件を見える化し、合意し、定義する作業を要件定義と捉えています。
（※）要件 ≒ 要求を満たすために、システムが提供するもの
RDRAレイヤー
ソフトウェア要件を組み立てる時に見るべき視点をRDRAレイヤーとして表現しています。
システム価値（システム化することでどんな価値を提供するのか）
システム外部環境（システムはどのように使われるのか）
システム境界（システムとのやり取り）
システム（システム内部で持つ情報や状態）
これらのレイヤーは「Why」でつながっており、ソフトウェア要件を論理的に説明できます。
例）
ユースケースAはある価値を実現する○○業務で使うためにある。
そのためにシステムには情報Bが必要で情報Bには状態Cを持つ必要がある。
RDRAモデルとは
RDRAレイヤー合わせて作成されるダイアグラムの総称です。
※RDRAモデルはプロジェクトごとにカスタマイズします。（以下のダイアグラムをすべて作る必要はありません）
モデルの詳細はRDRAハンドブック2.0やPlantUML で始めるリレーションシップ駆動要件分析 (RDRA)で詳しく説明されています。
WHY（RDRAの背景は何か）
つながりを重視した要件定義手法になった背景として、2つあげられます。
① 開発するシステム全体像の可視化
いままでの要件定義だと、要件間のつながりが見えづらく整合がとれない課題がありました。
RDRAではモデルの要素間につながりを持たせるため、整合性が取りやすいモノになっています。
また、ドキュメントと違って一目で見やすい状態のため、より全体像を把握しやすくなります。
②要件の認識合わせの効率化
RDRAは要件定義の枠組み（RDRAモデル）を提供しているため、議論が発散しにくい特長があります。
そのため、議論が袋小路に入りにくく、効率よく要件定義を進めることができます。
業務ルールや細かい仕様に話がいきがちな場合は有効です。
WHEN/WHERE（どのタイミングで/どの工程でRDRAを活用できるのか）
基本的には要件定義時にRDRAを活用しますが、以下の場面でも活用できます。
現状を可視化したいとき
影響範囲を調べる時
開発スコープ/順番を決める時
WHO（誰がRDRAを使うのか）
基本的には要件定義を実施する方ですが、
ビジネスルールや業務の洗い出しにはステークホルダー全員の協力が必要です。
HOW（RDRAでどのように要件定義するのか）
レイヤーごとに着目したダイアグラム（RDRAモデルとはで記載済み）を作成しながら、ステークホルダーと認識を合わせていきます。
RDRAモデリングで使用するツール
代表的なツールだと、PlantUML/Mermaid、miro、Balusがあります。
また、神崎さん自作ツールもあります。
※こちらはRDRA公式ページのToolsでダウンロードできます!!
個人的にはmiroでステークホルダーと認識を合わせつつ、清書で神崎さん自作ツールを使っています。
RDRAモデリングの手順
RDRAスプレッドシートおよびRDRAGraphを使った要件定義の流れは以下です。
※RDRA公式ページの表形式のRDRA定義や要件定義の進め方にも記載されています。
【RDRAモデリングの前に】
RDRA定義シートを埋める前に、要求（※）定義が完了し、重要な要求が明確になっていることが前提条件になっています。
RDRAモデルでいうと、システムコンテキスト図および要求モデル図は作成し、ステークホルダーと合意を取ることが必要です。
（※）要求：要望の中で検討対象として合意されており、それを構造化したもの
【モデリング手順】
① 要求一覧や業務フローをもとにRDRA定義シートを埋める
RDRA定義シートを埋める時の順番は以下がオススメとのことです。
課題と要求から、業務/BUCを洗い出す
業務/BUCからアクター/外部システムを洗い出す
業務/BUCとアクター/外部システムから情報を洗い出す
情報が持つ情報を洗い出す
情報の状態変化のきっかけになるユースケースを洗い出す
業務/BUCとUCを紐づける（UC複合図）
UC複合図を見て、不整合な部分の調整や業務ルールを洗い出す
② RDRA分析シートの不整合に表示されているエラーを解消しながら、要件をすり合わせる
③ 条件やバリエーションを洗い出し、全体の肉付けを行い、仕様化可能な状態にする
RDRAモデリング後
UC複合図のユースケースが開発対象になります。
そのユースケースを使って、開発の順序を決めたり、工数を見積もったり、詳細の認識合わせを行ったりします。
おわりに
今回はRDRAについて、ブログ・書籍・勉強会で学んだことを5W1Hに整理してみました。
アウトプットすることで、よりちゃんと理解できた気がします。
今回の記事について、間違っている箇所などあればコメントいただけると助かります。
また、RDRAを使ってみて感じたことは別の記事で書こうかなと思います。
※以下に書きました!!
参考
5W1H整理時に参考にした書籍・ブログ・動画
RDRA関連のブログ記事
この記事が気に入ったらサポートをしてみませんか？