あらためてRDRAレイヤーを整理する
RDRA（Relationship Driven Requirement Analysis）はモデルベースの要件定義手法で、「RDRAレイヤー」をもとに要件定義しています。
近年、RDRAスプレッドシートやRDRAGraphといったRDRAツールが登場し、要件定義時の情報整理やRDRAモデルの可視化が以前より格段に容易になりました。
いくつかのRDRAモデリング実施、社内の共有会やブログ記事作成を経て、改めて「RDRAレイヤー」を整理することで、RDRAの理解が深まり、より効果的な要件定義が行えるようになると考えています。
今回はその概要、構成要素や活用方法を整理してみました。
おことわり
本記事は、私自身の理解をもとに整理した内容です。
こうした解釈もあるのだな、と軽い気持ちで読んでいただければ幸いです。
RDRA自体の概要やRDRAレイヤーの詳細を知りたい方は公式ページや書籍をご覧ください。
参考資料も最後に記載しています。
RDRAレイヤーとは一体何か
簡単にいうと、要件定義時に検討しやすいように分割した階層のことを指しています。
RDRAの要件定義ではシステムとそれを取り巻く環境をつなぎながら進めることに注力しています。（※1）
しかし、取り巻く環境はたくさんあるので段階的に検討できるように「システム価値」「システム外部環境」「システム境界」「システム」の4つのレイヤーに分けています。
そして分割したレイヤーにRDRAアイコンを割り当てて、それらをつなぎながら要件定義します。
このレイヤーはRDRA1.0の時から変わっていない（※2）部分なので、RDRAを活用する上で重要な考え方だと言えます。
RDRAアイコンの詳細についてはまた別記事で書こうと思います。
（※2）
RDRAの要件定義は「システムの方向性を決め、具体的な仕様を決めるための材料を提供する必要があり、業務を構成する仕事を示され、その仕事で使用するシステムの入出力が明らかになり、入出力で使われる情報を明確にすること」を目指しています。
これにより、要件定義によく見られる機能（What）だけしか書かれていない問題を解消します。
（※3）
書籍ではRDRA2.0が紹介されており、公式ページではさらに進化しており、アイコンの種類や要件定義アプローチが変わっています。
RDRAレイヤーの詳細
システム価値
このレイヤーはシステムから一番離れており、開発対象システムの恩恵を受ける人や外部システムを整理するレイヤーです。
開発の方向性（システムの目的）を決める重要なレイヤーになります。
RDRAスプレッドシートではアクター/外部システムと機能/非機能要求シートで定義します。
システム外部環境
ビジネス的な価値につながる行動（業務）を検討するレイヤーです。
システム対象となる業務とその流れを整理します。
業務要件に近い要素で、業務の流れや活動を明確にすることで、システムの役割を理解しやすくなります。
RDRAスプレッドシートではBUCシートの業務/BUC/アクティビティ周りです。
システム境界
ユーザーや外部システムと開発対象システムとの接点を検討するレイヤーです。
「誰がどこに接点を持ち、何を入出力するか」、また「更新される情報や状態は何か」を整理します。
RDRAスプレッドシートでは、BUCシートのUCと関連オブジェクト部分を定義します。
ここで定義するRDRAアイコンのUCが開発対象（ソフトウェア要件）になります。
システム
システム化する情報、その情報が取り得る状態と業務上のビジネスルールを整理するレイヤーです。
このレイヤーは要件の要として整合性を維持するために存在します。
RDRAスプレッドシートでは、情報、状態、条件、バリエーションシート部分です。
情報をハブとして他のユースケースと繋いだり、ユースケースによる情報の変化を状態として表すことでユースケースの妥当性を評価します。
例えば、在庫管理システムでは「商品情報」が中心的な情報です。
その情報の状態（在庫切れ/在庫あり）を追跡し、UCを整理することで整合性を確保します。
RDRAレイヤー間のつながり
RDRAレイヤー間はシステムからシステム価値にWhyの依存関係（※4）になっています。
これにより要件を網羅的にあげることができます。
システムがもつ情報、状態、業務ルールを網羅するにはシステム境界（接点）を明確に整理します
システム境界のUCを網羅するには、使い方≒システム外部環境を理解することが重要です
システム外部環境の作業（開発範囲）を明確にするには、システム価値を把握する必要があります
（※4）
ここでのWhyは「なぜその要素が必要なのか」を示し、レイヤー間での因果関係を明確にする役割があります。
RDRAレイヤーの活用方法
要件定義のプロセス
RDRAスプレッドシートやRDRAGraphに明示的には記載されていませんが、要件定義を進める中で積極的に活用しています。
RDRA公式ページの要件定義の進め方を見ると、以下の順番でRDRAアイコンを定義しています。
システム価値
システム外部環境
システム
システム境界
システムを定義する前に、システム境界を考えると色々発散してしまうため、先にシステムで持っておくべきものを定義してから調整するようにしています。
すり合わせ
相手が今どこのレイヤーを話しているのか、今日はどのレイヤー部分の議論をするかなどの物差しにできます。
たとえば、要件定義のミーティング時に、議論が『システム価値』の話なのか『システム外部環境』の話なのかを整理することで、不要な混乱を防げます。
ふりかえり
ふりかえりでは、要件定義で防げた不具合があった場合、「どのレイヤーの要素が洗い出せていなかったか」「どのレイヤー部分で認識がずれていたか」を分析することで、次回注力すべきポイントが見えてきます。
たとえば、業務ルール整理の時間を増やすといった具体的な改善が見つかります。
改めて整理してみて
個人的にはシステムレイヤーの捉え方が少し変わった気がします。
どうしてもより詳細に定義しがちだったので、要件の整合性維持をメインに考えていきたいと思いました。
議論が詳細になりがちな点は自分の課題の1つなので、今後は相手がどのレイヤーで話しているのかを意識しながら進めたいと思います。
おわりに
今回はRDRAレイヤーについて、改めて整理してみました。
はじめて書籍や公式ページを読んだ時よりも深くみれたかなと感じます。
次はRDRAレイヤーに配置されているRDRAアイコンについて改めて整理したいと思います。