見出し画像

RDRAについて、5W1Hで整理してみた

Jimmy

要件定義で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モデルはプロジェクトごとにカスタマイズします。（以下のダイアグラムをすべて作る必要はありません）

RDRAモデル図

$$
\begin{array}{|c|c|} \hline
モデル&概要 \\ \hline
システムコンテキスト図&開発対象システムの目的及び関係するアクター/外部システムを表現 \\ \hline
要求モデル図&各アクターの要求を表現 \\ \hline
ビジネスコンテキスト図&開発対象の範囲（業務）とそれにかかわるビジネス要素を表現 \\ \hline
ビジネスユースケース図&開発対象の業務を価値提供単位に分割して表現 \\ \hline
業務フロー図&業務（BUC）の流れを表現したもの \\ \hline
UC複合図&ユースケースとそれにかかわるBUCや情報/状態を紐づけ、システムが行うべきことを表現 \\ \hline
情報モデル図&開発対象システムで持つべき情報を構造化したもの \\ \hline
状態モデル図&情報が持つべき状態とその遷移を表現 \\ \hline
条件・バリエーション図&ビジネスルールや要素のバリエーションを表現 \\ \hline
\end{array}
$$

モデルの詳細はRDRAハンドブック2.0やPlantUML で始めるリレーションシップ駆動要件分析 (RDRA)で詳しく説明されています。

WHY（RDRAの背景は何か）

つながりを重視した要件定義手法になった背景として、2つあげられます。

① 開発するシステム全体像の可視化

いままでの要件定義だと、要件間のつながりが見えづらく整合がとれない課題がありました。
RDRAではモデルの要素間につながりを持たせるため、整合性が取りやすいモノになっています。
また、ドキュメントと違って一目で見やすい状態のため、より全体像を把握しやすくなります。

②要件の認識合わせの効率化

RDRAは要件定義の枠組み（RDRAモデル）を提供しているため、議論が発散しにくい特長があります。
そのため、議論が袋小路に入りにくく、効率よく要件定義を進めることができます。
業務ルールや細かい仕様に話がいきがちな場合は有効です。

WHEN/WHERE（どのタイミングで/どの工程でRDRAを活用できるのか）

基本的には要件定義時にRDRAを活用しますが、以下の場面でも活用できます。

  • 現状を可視化したいとき

  • 影響範囲を調べる時

  • 開発スコープ/順番を決める時

WHO（誰がRDRAを使うのか）

基本的には要件定義を実施する方ですが、
ビジネスルールや業務の洗い出しにはステークホルダー全員の協力が必要です。

HOW（RDRAでどのように要件定義するのか）

レイヤーごとに着目したダイアグラム（RDRAモデルとはで記載済み）を作成しながら、ステークホルダーと認識を合わせていきます。

RDRAモデリングの手順

神崎さんオススメの手順は以下です。

  1. 課題と要求から、業務/BUCを洗い出す

  2. 業務/BUCからアクター/外部システムを洗い出す

  3. 業務/BUCとアクター/外部システムから情報を洗い出す

  4. 情報が持つ情報を洗い出す

  5. 情報の状態変化のきっかけになるユースケースを洗い出す

  6. 業務/BUCとUCを紐づける（UC複合図）

  7. UC複合図を見て、不整合な部分の調整や業務ルールを洗い出す

RDRAモデリング手順（PFD）

RDRAモデリングで使用するツール

代表的なツールだと、PlantUML/Mermaid、miro、Balusがあります。
また、神崎さん自作ツールもあります。

神崎さん自作のRDRAツール

※こちらはRDRA公式ページのToolsでダウンロードできます!!

個人的にはmiroでステークホルダーと認識を合わせつつ、清書で神崎さん自作ツールを使っています。

RDRAモデリング後

UC複合図のユースケースが開発対象になります。
そのユースケースを使って、開発の順序を決めたり、工数を見積もったり、詳細の認識合わせを行ったりします。

おわりに

今回はRDRAについて、ブログ・書籍・勉強会で学んだことを5W1Hに整理してみました。
アウトプットすることで、よりちゃんと理解できた気がします。
今回の記事について、間違っている箇所などあればコメントいただけると助かります。

また、RDRAを使ってみて感じたことは別の記事で書こうかなと思います。

参考

5W1H整理時に参考にした書籍・ブログ・動画


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