RDRAを試してみた感想とか
背番号8です。お久しぶりです。
お仕事で要件分析・定義を行う機会があり、 RDRA（Relationship Driven Requirement Analysis）を試してみたので感想文を書いていきます。
RDRAとは
要件定義やシステムの仕様を可視化するための手法の一つで 網羅性と整合性を兼ね備えた要件定義を素早く行うことができる と紹介されており どんどん作ってどんどん直す というのを前提としています。
RDRAレイヤーと呼ばれる視点の異なる4つレイヤーに対し、アイコンを矢印や線で繋げたダイアグラムを作成していきます。
以下の図のように内側から外側へ向けての依存関係を持ち、外側へ行くほど抽象度が高まります。
各レイヤーはそれぞれ以下のような役割を持ちます。
RDRAを試すきっかけ
わたしが入社する以前に、以下の書籍の輪読会が開催されていたこともあって社内での関心は高かったようですが、なかなかタイミングに恵まれず…、やったこともないので腰が重く…、という状況が続いていたようです。
そんな最中、新規プロジェクトの上流から関わる機会があったのと、テックリードから背中を押していただいたというのをきっかけに試験的に RDRA を実践してみる運びとなりました。
前提
成果物の位置づけ
今回はあくまでお試しなので RDRA の成果物については要件を分析するための一時的な情報として位置づけ、オフィシャルなドキュメントとして長期的にメンテナンスは行わないものとしました。
利用ツール
書籍やこちらのサイトにてRDRAに特化したツールが紹介されていますが、ビジネスサイドのメンバーと共同で作業をするうえでは、普段から使い慣れているツールがのほうが良かったために miro を採用しました。
RDRA実践
※以降、登場するRDRAの成果物は私の考えたオレオレECサイトの構築を前提としたもので、実際の業務とは一切関係ありません。
システム価値レイヤー
今回、RDRAを実践する段階で、抽象度の高い情報（アクター、要求、システム化の目的、業務）は概ねプロダクトオーナーから共有がなされていたため比較的スピーディーに作業を行うことができました。
利用者の要望や、システム化の背景を整理することは、価値のあるシステムを作るうえで非常に重要ですので良い取り組みのように思います。
システム外部環境レイヤー
続いてビジネスコンテキスト図、ビジネスユースケース図の作成を通じてシステム化する業務の整理を行いました。
各業務とビジネス要素という概念を線で繋ぐことで、対象の業務で扱う項目が可視化されるのが良いですね。
業務フロー図
業務フロー図に関してはビジネスサイドの方々と共にウォークスルーしたのちに議論するといった取り組みに活用してみました。
開発部内では検知できない懸念をヒアリングできたり、疑問点の解消とフロー修正をその場でインタラクティブに行えたりと効果的な取り組みになったなという実感があります。
また、ここで洗い出したユースケースはシステムで実現すべき項目なのでそのまま開発チケット作成するところまでいけちゃうのもいい感じでした。
システム境界, システムレイヤー
システム境界レイヤー以降の下位階層は具体的なシステムの要件を示すものであり、当社で別途管理している仕様を取りまとめたドキュメント群と内容が被ってしまうことから一旦作業をストップしました。
その後、ドメインモデルを考える機会があったのでRDRAの情報モデルを活用してみました。モデリングの方針を概念レベルで議論・認識を揃えるためのたたき台とするなどスポットでの活用でも十分に有用性があるなと感じています。
試してみて
Pros
アイコンをダイアグラムで繋ぐという作業は文字を書くよりもスピード感がありますし、出来上がった成果物は文字を眺めるよりもストレスが少ないように思います。
プロジェクトの途中から参加したメンバーへの導入も比較的スムーズだったことや非開発者とのコミュニケーションも円滑だったことからもそのことが言えると思います。
Cons
miro が柔軟過ぎたり、メンテナンスできる人も限られてしまいそうという理由からオフィシャルなドキュメントとして長期的にメンテナンスしていくイメージがあまり湧いていないというのが正直なところです。
これに関しては情報のインプットが足りないだけな気もするので引き続き探求をしていければと思っています。
人材募集
RDRAでの要件定義に関心のあるかたも募集中ですので是非ご連絡ください。
この記事が気に入ったらサポートをしてみませんか？