RDRAのすすめ RDRA1.0と2.0の違い
前回はRDRAという要件定義のフレームワークについて、その概要を紹介させていただきました。
RDRAを私が最初に知った時のバージョンは1.0でした。これが以下の著書で2.0に進化していたので改めて内容を確認し、それをアウトプットするのが目的だったのですが、前回はそこまで辿り着けませんでしたので、今回は1.0と2.0の違いについて言及したいと思います。
RDRA1.0と2.0の違いは大きく以下の３つになります。
１．ダイアグラムのシンプル化
２．業務フロー、利用シーンを洗い出す方法の明示
３．ビジネスルールの記述方法の明示
前回同様、本記事では私の考えや意見も含まれておりますのであらかじめご了承ください。
ダイアグラムのシンプル化
ダイアグラムのシンプル化ですが、神崎さんも自著で触れられており、更に私の在籍する会社内でも同様の意見があったのですが、モデルが多く存在していたためにそれらを作ることが目的となってしまいがちであったり、それらを更新し続けることが負担となっている場合があり、以下のモデルがRDRA2.0としては「外されて」います。
ユースケースモデル
画面モデル
イベントモデル
機能モデル
「外されている」というのは作成が禁止されているわけではなく、完全に無くなっているわけでもありません。神崎さん曰く「一覧を作成すれば用が足りる」という扱いになっています。
「ユースケースモデル」も「ユースケース」という概念を外しているわけではなく、あくまで「ユースケースモデル」という図をRDRA2.0から外しただけであり、ユースケース自体はRDRA2.0の中でもユースケース複合図等で普通に扱われています。
「イベントモデル」も同様で、ユースケース複合図の中で各イベントを記述するようになり、イベントのみをまとめる図は外されました。
「機能モデル」は機能を羅列したものなのでこれは確かに一覧で事足りると思います。
そして最後に「画面モデル」なのですが、こちらは個人的にお気に入りのモデルでした。
この「画面モデル」、どういったものかといいますと、こちらはRDRAとは関係無く「UIコンポーネント図」とも呼ばれているようでして、画面の要素をクラス図のように表現する方法です。
以下のように構成されます
画面名（クラス名に相当）
表示項目（属性に相当）
入力項目（操作に相当）
この手法を使うと、画面の構造を視覚的に整理しやすくなります。例えば、ログイン画面を表す場合、以下のように描けます。
要件定義レベルでこういった形で画面を挙げておくことで設計フェーズに移りやすい部分もあったかと思うのですが、要件定義ではWhyを追求すべきであり、Howではないということで外されているようです。
また、RDRAのモデルの１つとして盛り込んでしまうと皆さんの携われているシステムもそうかもしれませんが、画面数が非常に多いシステムでは確かにメンテナンスが困難になってしまいます。
ただ、廃止した他のモデルにも言えるのですが神崎さんはこれらをRDRA2.0で扱わなくなっただけで「禁止」はしていません。RDRA2.0に「補足する」形で各自・各プロジェクトが「必要であれば」一覧としてExcel等に記述するか、RDRA1.0の時のモデルとして記述していけばよいのかなと思っています。
抜け漏れを失くすためには、そして特に既存システムの解析に用いる場合には画面モデル、せめて画面の一覧は記述するようにして、各モデルまたは各モデル内の各要素との関連を把握できるようにすることをお勧めしたいと思います。
業務フロー、利用シーンを洗い出す方法の明示
これも個人的にはダイアグラムのシンプル化と関連する内容なのかなと思っています。
内容としては
ビジネスコンテキスト図という図が「システム外部環境レイヤー」（前回の記事参照）の上位にあり、そこで業務を明らかにする
業務をビジネスユースケースとして分割していく
ビジネスユースケースにおいて業務フロー・利用シーンがある
業務フロー・利用シーンがユースケースと結びつく
という段階的な流れ・繋がりを明確にしたというのがRDRA2.0における1.0との違いのようです。
1.0では「業務モデル」、「利用シーン」といったモデルが別々に存在しており、各モデルの要素は以下のようになります。
・業務モデル：「アクター」と「業務」
・利用シーン：「アクター」と「利用シーン」
他のモデルでもアクターは存在しますので、アクターとの結びつきで抜け漏れを確認するという形でした。
ただ、それでは他の要素との関連性が見えづらいのと、抜け漏れが起きやすいということで「業務」→「ビジネスユースケース」→「業務フロー・利用シーン」→「ユースケース」といった段階的な流れで記述するようになったという理解です。
実際、RDRA2.0における利用シーン図では「アクター」と「利用シーン」、「ユースケース」が要素となっており、他の図、モデルとの関連性がより明らかになっています。
ビジネスルールの記述方法の明示
現場で実際に使っている条件や規則、制約を「ビジネスルール」として、RDRAモデル内に記述するようにします。
これもあまり複雑なものではなく、「バリエーション」もしくは「条件」として表形式でまとめるだけです。
例えばやはり遊園地の料金を例に挙げると以下のようになりまして、これをユースケース複合図に含めたり、別資料として他の条件・バリエーションとまとめて記述したりしています。
そのままと言えばそのままなのですが、こういった形にすることで「より簡単に書ける」・「わかりやすい」表現ができるようになりました。
この「ビジネスルール」ですが、「システムの」条件や規則・制約ではなく、現場における条件、規則であることに注意が必要です。このビジネスルールは最初の記事に挙げた４つのレイヤーのうち、システム外部環境もしくはシステム境界に位置するものになります。
最後に
あくまでRDRAはコミュニケーションツールであり、システム化しなくてはいけないものは何かを明らかにするための手法です。
画面等をモデルとして別々に書くよりも、ユースケースと組み合わせてそれがどう関連しているか、元々の思想として存在する「システムを取り巻く様々な情報を含めてまとめ上げる」というところをより重要視かつ、図として視覚化できるようになっています。
例えば先ほどの「ダイアグラムのシンプル化」では画面を軽視しているわけではなく、必要に応じてそのプロジェクトに応じて深堀りして書き込んでいけばよいのではと思います。
神崎さんも各モデルの書き方について「こういう要素がありますよ」ということは書いているのですが、「こう書かなければ。。」ということは書いていません。それを表すものとして、RDRA1.0ではUMLに準拠した書き方が多かったイメージがあるのですが、アイコンも結構自由な形になっています。
あくまでも要件定義がうまく行えるためのポイントを押さえてほしいというのが神崎さんの伝えたいところかと思います。
次回の記事ではこの「書き方は問題ではない」ということをより明確化できると思います。