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レイヤーで表現されるRDRAアイコンを組み合わせて、ソフトウェア要件の全体像を表現したものです。
RDRAレイヤー
ソフトウェア要件を組み立てる時に見るべき視点をRDRAレイヤーとして表現しています。
システム価値（システム化することでどんな価値を提供するのか）
システム外部環境（システムはどのように使われるのか）
システム境界（システムとのやり取り）
システム（システム内部で持つ情報や状態）
これらのシステムからシステム価値の方向（右から左）にWhyの依存関係があり、この依存関係を守るとソフトウェア要件を論理的に説明できます。
例）
システムに情報Aをもつ、なぜなら、ユースケースAで更新する。
ユースケースAは業務Aで使用する。
業務Aをすることで、アクターに価値Aを与える。
RDRAアイコン
各RDRAレイヤーにRDRAアイコンが存在します。
※RDRAアイコンはプロジェクトごとにカスタマイズします。（以下のRDRAアイコンをすべて使用する必要はありません）
＜RDRAアイコン一覧＞
※RDRA1.0や2.0はダイアグラムで表現しています。詳細はRDRAハンドブック2.0やPlantUML で始めるリレーションシップ駆動要件分析 (RDRA)でご確認ください。
WHY（RDRAの背景は何か）
つながりを重視した要件定義手法になった背景として、2つあげられます。
① 開発するシステム全体像の可視化
従来の要件定義では、What（システムが何をするか）しか記載されておらず、その背景が示されていませんでした。その結果、仕様検討時に判断材料が不足し、手戻りが発生することがありました。また、要件間のつながりが不明確で、整合性が取れないといった課題もありました。
RDRAでは、モデル内の要素同士を関連付けることで、要件間の整合性を確保しやすくなっています。
さらに、モデルを用いて表現するため、全体像の把握が容易になります。
②要件の認識合わせの効率化
要件定義のゴールが曖昧なため、合意すべき内容が不明確なまま議論が進み、行き詰まってしまうケースが多く見られました。
RDRAは要件定義の枠組み（RDRAモデル）を提供することで、ゴールを明確に設定でき、議論が発散しにくくなる特長があります。
とくに、業務ルールや細かい仕様の検討に話題が偏りがちな場合に有効です。
WHEN/WHERE（どのタイミングで/どの工程でRDRAを活用できるのか）
基本的には要件定義時にRDRAを活用しますが、以下の場面でも活用できます。
現状を可視化したいとき
影響範囲を調べる時
開発スコープ/順番を決める時
WHO（誰がRDRAを使うのか）
基本的には要件定義を実施する方ですが、
ビジネスルールや業務の洗い出しにはステークホルダー全員の協力が必要です。
HOW（RDRAでどのように要件定義するのか）
レイヤーごとに着目したダイアグラム（RDRAモデルとはで記載済み）を作成しながら、ステークホルダーと認識を合わせていきます。
RDRAモデリングで使用するツール
代表的なツールだと、PlantUML/Mermaid、miro、Balusがあります。
また、神崎さん自作ツールもあります。
※こちらはRDRA公式ページのRDRAツールでダウンロードできます。
個人的にはmiroでステークホルダーと認識を合わせつつ、清書で神崎さん自作ツールを使っています。
RDRAモデリングの手順
RDRAスプレッドシートおよびRDRAGraphを使った要件定義の流れは以下です。
※RDRA公式ページの表形式のRDRA定義や要件定義の進め方にも記載されています。
【RDRAモデリングの前に】
RDRA定義シートを埋める前に、これだけは実現したいという要求（※）が2,3個明確になっていることが前提条件になっています。
（※）要求：要望の中で検討対象として合意されており、それを構造化したもの
【モデリング手順】
① 要求一覧や業務フローをもとにRDRAアイコンを洗い出し、RDRA定義シートに書き出す
RDRAアイコンを洗い出す順番は以下がオススメとのことです。
【ステップ1】アクター/外部システムと対象の業務/BUCを洗い出す
アクターと外部システムはRDRA定義のシート「アクター」「外部システム」に記載します。
業務/BUCは専用のシートがないため、RDRA定義のシート「BUC」の業務（A列）とBUC（B列）に記載します。
【ステップ2】BUCのアクティビティを洗い出す
ドメイン理解のため、システムを使う時の行動以外も洗い出します。
こちらも専用のシートがないため、RDRA定義のシート「BUC」のアクティビティ（D列）に記載します。
【ステップ3】業務で扱う情報を洗い出す
RDRA定義のシート「情報」に記載します。
粒度はエンティティレベルがメンテナンスしやすいですが、最初はより具体的にステークホルダー内が「そうだよね」とわかる名前で書いてから、粒度をあげるのも1つです。
【ステップ4】システムで管理する状態（業務上認識する状態）を洗い出す
思いつくものだけでOKです。
この時はまだアクティビティとUCはつなげません。
また、不要な要素や修正する部分も多いので先にマインドマップで整理しても良いと思います。
② 各RDRAアイコンを見直しながら、UC紐づける
紐づけ方は以下の2パターンです。
トップダウン
業務⇒BUC⇒アクティビティの順で紐づける
システム化するところにUCをつなげ、画面とイベントを定義する
ボトムアップ
情報、状態から紐づける
また、RDRA分析シートの不整合に表示されているエラーを解消しながら、要件をすり合わせます。
③ 条件やバリエーションを洗い出し、全体の肉付けを行い、仕様化可能な状態にする
RDRAモデリング後
UC複合図のユースケースが開発対象になります。
そのユースケースを使って、開発の順序を決めたり、工数を見積もったり、詳細の認識合わせを行ったりします。
おわりに
今回はRDRAについて、ブログ・書籍・勉強会で学んだことを5W1Hに整理してみました。
アウトプットすることで、よりちゃんと理解できた気がします。
今回の記事について、間違っている箇所などあればコメントいただけると助かります。
また、RDRAを使ってみて感じたことは別の記事で書こうかなと思います。
※以下に書きました!!