RDRAを使った要件定義　概要

初めに

株式会社ネクストスケープソリューションビジネス部の小野塚です。

当社が要件定義のツール、フレームワークとして利用しているものとしてRDRAがあります。
このRDRA、こちらは株式会社バリューソースの代表、神崎善司さんという方が考えたものでして、このフレームワークに従って要件定義を行うことで誰でもある程度のレベル・粒度で資料を作成することができます。
私自身がこのRDRAを知ったのが2014年頃なのですが、そこから更に色々と進化をしておりまして、改めて過去の理解が合っているかを見直し、現在の内容にキャッチアップすると共に多少私の考えや意見も交えてご紹介できればと思います。

RDRAの概要・バージョン

RDRAは以下の書籍を元に学びましたが、これがバージョンとしては1.0となるそうです。

『モデルベース要件定義テクニック』
https://www.amazon.co.jp/dp/4798039446

そして現在は2.0にバージョンアップされています。

RDRAはシステムそのものだけに目を向けず、「システムを取り巻く」様々な情報を含めてまとめ上げることを目的としています。
そのための視点として以下の４つがあります。

システム価値：システム化する目的や価値を明らかにし、要求を元にシステム化のゴールを共有します
システム外部環境：システムがどのように使われるのかを明らかにするために、仕事の流れや場面として業務を明示します
システム境界：システムとの接点となる入出力を明らかにします
システム：ビジネスを駆動する用語を使ってシステム化したい情報と状態を明らかにします

この４つが「RDRAレイヤー」と言われるものであり、この考えだけでも「システム」があくまで視点の１つであることがおわかりになるかと思います。

RDRAの意義・思想

システムを作るのに何故システムだけ見ていては駄目なのか。
例えば機能１つとってみても、皆さんが今使われている、あるいは作っているシステムで、「この機能使っていない。。」とか、「この機能いらないんじゃ。。」といった機能は無いでしょうか。
その機能はそれなりに期間やコストをかけて作成したのに関わらず。。です。

そういったこともRDRAを使うことで防げるかもしれません。もう少しRDRAレイヤーについて説明することでその理由に答えたいと思います。

以下がRDRAレイヤーと概要を表した図になります。

例えば神崎さんの著書でも具体例として挙げられている図書館のシステムを例に挙げると、

アクター：図書会員
要求：借りたい本をWebで予約したい
ビジネスユースケース：Web予約
画面：Web予約画面
Web予約の状態：未予約、予約中等

といった形になり、それぞれが右から左へ「Why」で繋がっています。

・「未予約」や「予約済み」といった各状態は「何」によって変化するのか（or 「なぜ」変化するのか）
⇒予約画面が存在するから

・「なぜ」予約画面が存在するのか（必要なのか）

⇒Web予約のビジネスユースケースが存在するから

・「なぜ」Web予約のビジネスユースケースが存在するのか
⇒Web予約が必要とされているから

・Web予約という作業は「誰が」行うのか
⇒図書会員

といった形でWhy（Who、Whatもありますが、それもWhyに含めます）による依存・関連があります。この依存・関連が存在しないものについては「そもそもそれが不要なのかもしれない」、もしくは「何か関連する要素が抜けている」ということで見直しを行い、それを繰り返すことで最終的に要件定義が完了します。

もう少しまとめますと、作業としては以下の流れを繰り返すことになります。

まずはどのRDRAレイヤーからでもよいのでどんどん要素を挙げていく
一通り挙げ終わったら関連性を確認・見直す
関連していないものあれば要・不要や、それと紐づく要素が抜けていないかを検討する

そして、抜け漏れを防ぐために極力関係者全員で行うということも重要です。
RDRAはそもそもがコミュニケーションツールであり、お客様も含め全員でRDRAを用いてコミュニケーションを取ることで、もし設計フェーズ以降で機能追加・機能拡張が発生した場合は元々要件として存在していたのかどうかというのがRDRAによって確認できる可能性があります（「プロジェクトあるある」ですが、こういった問題は「確認できる」と断言できるほど単純なものではないのであえて「可能性がある」という表現に留めました）。

注意点として、もし私が主導でRDRAを実施する場合、ファシリテーターは私になり、更にRDRAの各モデルを記述するのも私になると考えるのが妥当ではありますが、１人でこれを全て行うのは少々負担が大きいため、書記は別の人、つまり自身のチームの誰かにやってもらう形が望ましいです。
そして上の流れを繰り返することで例えば他との関連が存在しない業務フローやビジネスユースケース、画面といったものが出てくると思います。
そもそもアクターがどれとも関連が無く宙に浮いていることもあるかもしれません。
そこが見直すべき箇所となります。
実際はその宙に浮いている要素と関連する要素が存在するはずで、単に思いついていないかもしれませんし、もしかするとそもそも不要な（そのシステムとは完全に無関係な）要素であるかもしれません。

RDRAは既存のシステムの把握・解析にも利用できますが、もし使われていない機能や画面があればそれは他の要素と関連の無い要素として浮かび上がるわけです。

ちなみに要件定義の場合、RDRAレイヤーを左から右へと進めていく形になりますが、既存のシステムの場合は画面や情報ありきになりますので右から左へと進めていくことになるかと思います。

ただし、それがルールではないので通常の要件定義も画面から思いつく場合はあるかと思いますし、それはそれで問題ありません。大事なのは最終的に必要な要素が全て洗い出せ、それぞれに関連性があることです。

ここまでの抑えるべきポイントとしては以下になります。

RDRAはHowではなくWhyを確認するためのものであること（Howは設計フェーズ以降で決めるものになります）
RDRAはコミュニケーションツールであること
一度に完璧を目指すのではなく、手順を繰り返すことで完成に近づける（アジャイル的な感じですね）

最後に

「さわり」だけでも結構な量になってしまいましたので続きはまた別途ということで一旦記事を終えたいと思います。
最後にややRDRAそのものの話とやや外れるかもしれませんが、経験に基づく注意点をお伝えしておきます。

上でも記述しましたし、神崎さんも著書で書かれていますが、RDRAは要件定義の結果を記述したドキュメントとして扱うというよりは、あくまで「コミュニケーションツール」として活用することを勧めています。
例えば、要件定義の最終成果物としてWordベースの要件定義書やExcelでの機能一覧を想定している場合は、当然ながらRDRAでの作成物は成果物としてみなされず、別途要件定義書や機能一覧等の資料を作成する必要があります。
それらの資料のベースというのはRDRAで作成した各モデル・各図になりますので、単に表現を変えただけではあるのですが、何を成果物とするかは各ステークホルダーと確認しておく必要があるかと思いますのでご注意ください。

この後も何回かRDRAについて語らさせていただくかもしれません。
ただ、あくまで私の理解になりますので、興味のある方は是非神崎さんの書籍を読んだり、セミナーを受けてみてください。

当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。

nextscape.net

（以下当社お問合せフォーム）

Microsoft Forms