RDRAによる要件定義 概略
初めに
私が要件定義のツール、フレームワークとして利用しているものとしてRDRAがあります。
これは神崎善司さんという方が考えたもので、このフレームワークに従って要件定義を行うことで誰でもある程度のレベル・粒度で資料を作成することができます。以前にも軽く紹介したことがあったのですが、色々と進化をしておりまして、改めて過去の理解が合っているかを見直し、現在の内容にキャッチアップすると共に多少私の考えや意見も交えてご紹介できればと思います。
RDRAの概要・バージョン
RDRAを初めて知ったのは2014年あたり。以下の書籍を元に学びましたが、これがバージョンとしては1.0となるそうです。
そして2.0にバージョンアップされ、以下の書籍で説明されています。
RDRAはシステムそのものだけに目を向けず、「システムを取り巻く」様々な情報を含めてまとめ上げることを目的としています。
そのための視点として以下の４つがあります。
・システム価値：システム化する目的や価値を明らかにし、要求を元にシステム化のゴールを共有します
・システム外部環境：システムがどのように使われるのかを明らかにするために、仕事の流れや場面として業務を明示します
・システム境界：システムとの接点となる入出力を明らかにします
・システム：ビジネスを駆動する用語を使ってシステム化したい情報と状態を明らかにします
これがRDRAレイヤーと言われるものであり、これだけでも「システム」があくまで視点の１つであることがおわかりになるかと思います。
RDRAの意義
システムを作るのに何故システムだけ見ていては駄目なのか。
例えば機能１つとってみても、皆さんが今使われている、あるいは作っているシステムで、「この機能使っていない。。」とか、「この機能いらないんじゃ。。」といった機能は無いでしょうか。
その機能はそれなりに期間やコストをかけて作成したのに関わらず。。です。
そういったこともRDRAを使うことで防げるかもしれません。もう少しRDRAレイヤーについて説明することでその理由に答えたいと思います。
以下がRDRAレイヤーと概要を表した図になります。
例えば神崎さんの著書でも具体例として挙げられている図書館のシステムを例に挙げると、
アクター：図書会員
（図書会員の）要求：借りたい本をWebで予約したい
ビジネスユースケース：Web予約
Web予約の状態：未予約、予約中等
といった形になり、それぞれが右から左へ「Why」で繋がっています。
未予約や予約済みといったの状態がなぜ必要なのか
→ビジネスユースケースが存在するから
何故Web予約のビジネスユースケースが必要なのか
→そういった要求が存在するから
Webで予約したいという要求は誰の要求なのか
→図書会員
といった形でWhy(Who、Whatもありますが)による依存・関連があります。この依存・関連が存在しないものについては「そもそもそれが不要なのかもしれない」、もしくは「何かが抜けている」ということで見直しを行い、それを繰り返すことで最終的に要件定義が完了します。
もう少しまとめますと、作業としては以下の流れを繰り返すことになります。
まずはどのRDRAレイヤーからでもよいのでどんどん挙げていく
一通り挙げ終わったら関連性を見直す
関連していないものあれば要・不要や、それと紐づく要素が抜けていないかを検討する
そして、大事なのは抜け漏れを防ぐために関係者全員で行うということも重要です。
RDRAはそもそもがコミュニケーションツールであり、お客様も含め全員でRDRAを用いてコミュニケーションを取ることで、もし設計フェーズ以降で機能追加・機能拡張が発生した場合は元々要件として存在していたのかどうかというのがRDRAによって確認できる可能性があります（プロジェクトあるあるですが、こういった問題は「確認できる」と断言できるほど単純なものではないのであえて「可能性がある」という表現に留めました）。
もし私がITベンダーとして要件定義を行う場合、ファシリテーションは私になり、更にRDRAの各モデルを記述するのも私になると考えるのが妥当ではありますが、１人でこれを全て行うのは少々負担が大きいため、書記は別の人、つまり私のチームの誰かにやってもらう形が望ましいです。
RDRAを試そうと思っている皆さんも是非複数人で取り組んでください。
そして上の流れを繰り返することで例えば他との関連が存在しないビジネスユースケースや画面というのが出てくると思います。
それが不要な機能であり画面であり、情報となります。そもそもアクターがどれとも関連が無く宙に浮いていることもあるかもしれません。
RDRAは既存のシステムの把握・解析にも利用できますが、上の作業の流れによって使われていない機能や画面が明らかになるわけです。
要件定義の場合はRDRAレイヤーの左から右へと進めていく形になりますが、既存のシステムの場合は画面や情報ありきになりますので右から左へと進めていくことになるかと思います。
抑えるべきポイントとしては以下になります。
HowではなくWhyを確認するためのものであること（Howは設計フェーズ以降で決めるものになります）
コミュニケーションツールであること
一度に完璧を目指すのではなく、手順を繰り返すことで完成時に近づける（アジャイル的な考えですね）
最後に
「さわり」だけでも結構な量になってしまいましたので続きはまた別途ということで一旦記事を終えたいと思います。
最後にややRDRAそのものの話とやや外れるかもしれませんが、経験に基づく注意点をお伝えしておきます。
上でも記述しましたし、神崎さんも著書で書かれていますが、RDRAは要件定義の結果を記述したドキュメントとして扱うのではなく、コミュニケーションツールとして活用することを勧めています。
例えば、お客様が要件定義の成果物としてWordベースの要件定義書やExcelでの機能一覧を要求している場合は、当然ながらRDRAでの作成物は成果物としてみなされず、別途お客様の要求に基づく形で別途成果物を作成する必要があります。
その成果物のベースはRDRAで作成した各図になりますので、単に表現を変えただけのものではあるのですが、何を成果物とするかは事前に握っておく必要があるかと思いますのでご注意ください。
ちなみに私も同様の経験があったのですが、その際はお客様と一緒にRDRAを行い、色々とRDRAについてご理解いただいた結果、RDRAで作成した資料を成果物としてもらいました。
神崎さんは自身が代表取締役を務める株式会社バリューソースでRDRAのセミナーも開いています。
この後も何回かに分けてRDRAについて語らさせていただきますが、興味のある方は是非神崎さんのセミナーを受けてみてください。
では、今回はこの辺で。。