RDRAを活用した開発業務をふりかえってみる
RDRA(Relationship Driven Requirement Analysis)を開発業務で活用してみてから、しばらくたったのでいったんふりかえってみたいと思います。
おことわり
あくまでも個人の所感です
「こんなこと言っているんだな～」と思ってみていただければと<(_ _)>
活用した背景
開発業務にて、どのように進めると効率よくステークホルダーと認識合わせられるのか悩んでいました。
その同じ時期にRDRA勉強会があり、参加したところ、「これは活用できそうかも」と思い、使ってみることにしました。
RDRAとは
RDRAはシステムの全体像を、すばやく、かつ整合性を保ちながら明確にする軽量なモデルベース要件定義手法です。
この手法では、システムの外部環境（システムの使われ方）からシステム内部（データ、状態）までのつながり（関係性）を重視しています。
RDRAで使用するモデルや進め方については、RDRA公式サイト等を参照してください。
RDRAを活用したところ
RDRAは主にふるまい整理と影響範囲の検討で活用していました。
どうやって使ったか
ふるまい整理時
まず、業務フロー図、PFD、プロトタイプ（紙芝居的なもの）を使って、ステークホルダーと認識合わせを行います。
その後、RDRAモデルに落とし込み、また不明点や確認点が出たら、再度ステークホルダーに確認するというサイクルを回しました。
最初からRDRAモデルを作成しなかった理由は、ステークホルダーにわかりやすいものを使った方が認識齟齬が起きにくいと考えたためです。
本当はRDRAモデルを一緒に見ながら認識合わせできた方が効率よかったと思いますが、ステークホルダーがBUC、UC等の用語にあまり慣れていない印象を受けたため、認識合わせしたモデルを清書する感じでRDRAモデルを使いました。
RDRAモデルの作り方は勉強会で教えていただいた順番にしました。
※RDRA公式サイトの要件定義の進め方にも記載されています。
影響確認
変更要望を整理し、影響がある業務、UCや情報を探すときにRdraGraphを使いました。
RDRAを活用して、感じたこと
大きくそれることなく、進めることができた
RDRAは大枠の進め方が決まっているため、大きくそれることはありませんでした。
またRDRAはシステムにつながる業務、情報やビジネスルールも整理するため、「こういう使い方はないか？」「こういった場合はどうなるのか？」「この情報は他の業務で使われていないのか」等のシステムのふるまい以外の会話も増えました。
全体像が分かりやすい&影響範囲をすぐに調べられる
ここはRdraGraphを使って感じたメリットであり、私自身一番助かった部分になります。
いままではExcel、ソースコードたよりに自力で調べていたで、要素のつながりを簡単に確認できでとても助かりました。
影響範囲分析の短縮につながったと思います。
また、いろんな視点でモデルを表示できるので抜け漏れチェックも行いやすかったです。
RDRAモデルと一緒に確認しながら進めるにはある程度時間が必要
RDRAモデルを理解するにはBUCやUCなどの用語、状態モデル、情報モデルの理解が必要になります。
開発業務をやっている方なら、理解しやすいかもしれないですがソフトウェア開発に携わっていない人がいきなり見るのは難しそうだなと感じました。
ここは私の説明の仕方も良くなかったところもあるので、次の機会までにはよりわかりやすい説明をしたいなと感じました。
今後どうしていきたいか
他の方がどのようにRDRAを使っているか気になっているので、RDRAの公式ブログや事例発表を確認したいと思います。
また既存システム理解でも活用できるとのことだったのでやってみたいと思います。
参考資料
この記事が気に入ったらサポートをしてみませんか？