初めに
株式会社ネクストスケープ ソリューションビジネス部の小野塚です。
今回もRDRAの記事となります。これで第3回目となります。
1回目が以下の記事で、ざっくり概要を説明させていただきました。
2回目が以下になりまして、バージョンによる違いは何かを私の考え交えて記述しました。
さて、今までの記事においてはRDRAは幾つかの図＝モデルを書くことで要件定義を進める方法でした。そして、1.0から2.0になって不要なモデルも無くし、より簡略化・洗練されてきた。。というのがここまでの流れです。
しかしながら、RDRA2.0であってもそれなりの規模のプロジェクトになってしまうとアクターを初めとした各要素の数が非常に多くなり、関連を表す線が蜘蛛の巣のように入り乱れる形となり、少々見づらくなることがありました。
そこで一昨年～昨年頃から神崎さんが考えられたのがGoogleスプレッドシートを用いたRDRAになります。
RDRA2.0では表形式、一覧で表せるものは一覧で表そうという考えがありましたが、これを更にRDRA全体に適用したものがこのGoogleスプレッドシートによるRDRAです。まずは以下のリンクでRDRA用スプレッドシートを開いてみてください。
2.RDRA定義分析_V1.0 - Google スプレッドシート
これはRDRAを考えた神崎さんが作成されたもので、閲覧のみ可能な所謂テンプレート的なファイルですので、メニューバーの「ファイル」から「コピーを作成」を選択し、自身のGoogleスプレッドシートにコピーします（Googleアカウントが必要になりますのでご注意ください）
そして、改めてこのファイルを見ると色々なシートがありますのでそれぞれについて触れていきたいと思います。
表形式によるRDRA 概要
ファイル名に「V1.0」とありますが、実は先日2月15日にバージョンアップされまして、それまでは0.98が最新でした。
今まではRDRA定義とRDRA分析ということで別々のスプレッドシートになっていたのですが、V1.0で統合された形となります。
今までのダイアグラム形式でのRDRAは「パッと見の」わかりやすさや自由度において秀でた点がありましたが、この表形式のRDRAではスピード感を重視しています。
RDRAというのは各RDRAレイヤーにおける各要素同士の「関連」を確認することがポイントであり、ダイアグラム形式では線で結ぶことで関連を明らかにしていましたが、表形式では同じ行に並べることで関連を表すようにしています。
また、モデル間では名前で関連付けていましたが、表形式でも（シート間の）名前で関連付けています。
今回は実際に今までのRDRAで用いられてきた図書館システムのサンプルデータを入れつつ各シートの内容をご紹介できればと思います。「アクター」等、RDRAで使われる用語の説明であったり、こういった要素を挙げてどうするの？といったRDRAの基本的な内容については割愛させていただきますので、そのあたりは神崎さんのセミナーや著書、そして私の記事等をご覧ください。
「アクター」シート・「外部システム」シート
まずはRDRAにおける最初のモデル、「システムコンテキスト」ですが、これは要件定義の対象となるシステムに関連するアクターと外部システムを以下のような図で表したものになります。
※本記事でのRDRAモデルについては以下の神崎さんの書籍からダウンロードできるパワーポイント資料から抜粋もしくは利用させていただきました
https://www.amazon.co.jp/dp/B07STQZFBX
『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』
表形式では「アクター」シート、「外部システム」シートがありますので、それぞれにアクター、外部システムを挙げていきます。
まずは「アクター」シート。
過去の記事やRDRAの書籍で例に挙げられていた図書館のシステムでは図書館を利用する「会員」と、図書館員である「図書館員」と「司書」の３つのアクターが挙げられますので上のようになります。アクター群はアクターをまとめるグループ名です。
次に「外部システム」シートでは今回のシステムに関連する外部システムを挙げます。外部システム群はアクター同様、グループ名です。
上で書いた通り、RDRAでは他のモデルとの関連は名前で結びつけるようにしていますが、「モデル間」が「シート間」に代わるだけですので名前は統一させるようにしてください。
このようにスプレッドシート上に羅列していくだけですのでこれだけでも図に書くよりも素早く定義できることがわかると思います。
要求モデルとしての「機能要求」・「非機能要求」シート
次にRDRAでは要求モデルを記述するわけですが（以下の図がそれです）、
表形式では「機能要求」「非機能要求」シートがあるのでここで挙げていきます。
これもダイアグラム形式で書くのとあまり変わらないため、違和感も無さそうですね。
ビジネスコンテキスト図・ビジネスユースケース図
次に「業務」と「ビジネスユースケース」を洗い出していきますが、RDRAのモデルでは「ビジネスコンテキスト図」「ビジネスユースケース図」がこれにあたります。
まずは「BUC」シートのA列が業務に該当しますので挙げていきます。
図書業務の例ですと「貸出・返却」「会員管理」「蔵書管理」となります。
そして各業務に関してビジネスユースケース図を書いていきます。以下は「会員管理」業務の例です。
この図は「BUC」シートで表しますのでA列に「業務」、B列に「BUC」を入力し、更に「関連モデル２」列に「アクター」を設定し、「関連オブジェクト２」列に具体的なアクターの名前を入力します。
※上のスクリーンショットでは途中に存在する列を非表示にしていますのでご注意ください
ユースケース複合図としての「BUC」シート
神崎さんのRDRAのサイトではこの後は「情報と状態の洗い出し」ー＞「アクティビティ、UC、アクター、外部システムの洗い出し」ー＞「UCに情報・画面・イベントを繋げる」ー＞「条件とバリエーションの洗い出し」といった流れになりますが、私としては「アクティビティ、UC、アクター、外部システムの洗い出し」ー＞「UCに情報・画面・イベントを繋げる」。。の順番の方がやりやすかったです。
ただ、ダイアグラム形式のRDRAと同様、繰り返し見直すことになりますので順番はあまり重要ではないという理解です。
プロジェクトの性質・内容やステークホルダーの方々の知見によってどの順番が洗い出しやすいかも変わってくるかと思いますので、実際にやってみて最終的に抜け漏れが発生しなければOKです。
「BUC」シート ー アクティビティ
次に各BUCに紐づくアクティビティを挙げていきます。私だけかもしれませんが、後述のユースケースとアクティビティがごっちゃになりがちです。そのあたりは今までのRDRAの手順と同様、繰り返し見直すことで修正していきます。
「BUC」シート ー 情報、状態
次に同じく「BUC」シートに情報を書いていきます。
例えば図書館システムであれば「貸し出されている本」「蔵書情報」「予約されている本」といったところです。
前回の記事でも書いた通り、本であればタイトルや作者等、様々な情報があるかと思いますが、RDRAではそこまで細かく上げることはせず、上で挙げたようにある程度まとまった括りで列挙していきます。
「BUC」シート ー ユースケース
次に「F」列にUC、ユースケースを書いていきます。
RDRAでのユースケースは「要件定義の対象となるシステムを利用する作業」になります。ですのでビジネスユースケースの「貸出フロー」のアクティビティの１つに「蔵書を貸出す」というものがあった場合、そのユースケースは（システムを使って）「蔵書の貸出を登録する」というものになります。
「BUC」シート ー 画面
次に各ユースケースに対応する画面を挙げていきます。
画面名称をここで深く考えてもしょうがないので、ユースケースをそのまま画面名にするという考えで良いと思います。例えば上の例のように「蔵書の貸出を登録する」ユースケースであれば画面名は「貸出登録画面」といった形です。変に名前を凝ってしまうと何をする画面かわからなくなってしまうので。。
今までの流れですと「情報」を挙げて、その後「画面」を、となるのですが、個人的には画面を先に挙げて、「その画面で扱う」情報を考えていく方が情報を挙げやすいような気もしているのですが、それは私がエンジニアでシステム寄りに考えてしまうからかもしれません。
例えば上の内容であれば、「蔵書を貸出す」アクティビティで「貸出登録画面」（「貸出画面」の方がわかりやすいかも）を挙げ、その画面で表示・もしくは変更されるべき情報は「貸出図書情報」、「蔵書情報」、「貸出予約情報」があるよね。。といったように考えていくのではないかと思います。
とはいえ、それはある程度想像がつくシステムだからだと思いますし、結局は抜け漏れが無ければよいわけです。
途中にも書きましたが、繰り返し見直して追加・変更・削除を繰り返すところは今までのRDRAと変わりませんので、自身と各ステークホルダーの中で話し合いつつ、順番はあまり気にせずにとにかく必要と思われる情報を挙げていくという気構えで良いのではと思っています。
アクター、外部システムとの連携
次に「アクター」シート及び「外部システム」シートに挙げたアクター、外部システムと、それに関連する「H」列の関連オブジェクトを探し、BUCシートの「I」列に書いていきます。
これでRDRAのビジネスコンテキスト、システムコンテキスト、ビジネスユースケースが網羅できることになります。
「条件」シート
次に「条件」シートです。図書館システムであれば貸出期限といった条件をこのシートで挙げていきます。
そしてここで挙げた条件が「BUC」シートのどのユースケースに使われるか確認し、以下のように「BUC」シートの「G」及び「H」列に追記していきます。
「バリエーション」シート
あとは「バリエーション」シート、例えば会員であれば大人と子供の２種類存在するのであれば以下のように記述します。
「状態」シート
次に「状態」シート。状態遷移が発生する要素をここで挙げておきます。遷移先と遷移元、そして遷移のトリガーとなるユースケースをこのシートに記述します。
「情報」シート
「BUC」シートに挙げた情報もこちらの「情報」シートにまとめるようにしてください。先ほどの「バリエーション」と「状態」はこの「情報」に紐づくはずなので、このシートでその関連性を記述するようにします。
「不整合」シート
そして今回のスプレッドシートによるRDRAのポイントの１つとなるのが「不整合」シートです。今までのRDRAと今回のスプレッドシートにを用いたRDRAの違いとしては各モデルで図として表していた内容をスプレッドシートに落とし込んでいくというものになります。
そして、スプレッドシートに変えることで数多くの情報を一覧として見れたり、手軽に書けたりといったメリットがありました。しかしながらそれ以外にももう幾つかこのスプレッドシートによるRDRAのメリットがありまして、その１つが「不整合」シートになります。
RDRAでは各モデルとの関連性を確認し、関連が存在しない要素が存在する場合はそれが不要な要素であったり、もしくは存在すべき（関連すべき）要素が別にあるということで見直しの対象となります。
ただ、要素が増えれば増えるほど各モデルにおける要素の関連性の有無が見つけ出しにくくなるという問題がありまして、これを解消するのがこのシートになります。
つまり、もしそういった関連性が無い要素があればこのシート上にそれを表示してくれるのです。
例えばアクター。下の「不整合」シートのスクショでは何も表示されていません。つまり、全てのアクターが関連付けされていることになります。
次にあえて「アクター」シートから「司書」を削除してみましょう。この「司書」というアクターは「BUC」シートには記載されています。
そうすると以下のように「司書」が「不整合」シートに表示されます。他の要素についてもこういった形で表示され、関連の有無をここで確認できるわけです。
「RDRA Graph」との連携
そしてもう１つのポイントが「RDRA Graph」という、これも神崎さんが作られたツールですが、このツールにスプレッドシートで作成したデータを投入することで図として表現できるというものです。まずは「関連データ」シートを開き、そのシートの右側に書かれた指示に従って特定の範囲のデータをコピーします。
そして、以下のリンクをクリックし、RDRA Graphを開きます。
RDRA Graphの上部メニューからDATAー＞Import Dataを選択します。
以下のようなダイアログが表示されるのでその中に上でコピーしたデータを貼り付けて「取込」ボタンを押します。
すると以下のように入力データがRDRAのモデルとして表現されます。以下の図の「貸出・返却」をクリックしてみましょう。
以下のように「貸出・返却」のビジネスユースケース図が開きます。
更にビジネスユースケースの「貸出フロー」をクリックすると以下のように「貸出フロー」に紐づくアクティビティやユースケース、そしてそれらに紐づくアクターや情報・条件が、RDRAモデルでいうところのユースケース複合図として表示されます。
スプレッドシートにすることで図として表すことをあきらめたわけではなく、別ツールを用意することで簡単に図示することもできるようにしたわけです。
また、最初に書いたように要素が多くなるとRDRA2.0でも見づらくなってしまいますが、RDRAGraphは単純に図示するだけでなく、上位階層同士の関係のみを表現することもでき、それにより全体を俯瞰できるようにもしています。
RDRAは要件定義のための優れたツールだと思うのですが、RDRAの各モデルを書くにあたって、神崎さんは図を書くためのツールとしてEnterprise Architectやパワーポイントを挙げていました。またそのためのプラグイン等も提供いただいています。
ただ、それでも利用することにややハードルの高さを感じる方もいたかと思います。
特にEnterprise Architectは操作に多少慣れも必要になりますので。
更にEnterprise Architectもパワーポイントも有料ですが、Googleスプレッドシートは無料です。そしてRDRA Graphも無料で利用できます。
このスプレッドシートとRDRA Graphを使う方法であればその最初のハードルが非常に低くなり、より簡単にRDRAを導入できると思います。
ただ、要件定義の初期の段階ほどダイアグラム形式の方が複数のステークホルダーが集まって話し合う場合にわかりやすいと思うので、
１．最初の段階はEAやPowerPointで図を書く
２．ある程度のところまで話が進んだらそれをスプレッドシートに落としてそれ以降はスプレッドシートで進める
３．スプレッドシートとRDRA Graphとを行き来しつつまとめていく
という流れであったり、あるいは最後までRDRA Graphに頼らずに各種モデルを自ら書いていく。。という方法でも全然良いと思います。神崎さんはそれを禁止しているわけではありませんので。
終わりに
今回の記事はここまでとします。
RDRA2.0から更に進化し（記述方法が変わっただけなのでバージョンは2.0のままのようですが）、扱いやすいものとなりました。
ダイアグラム形式は「わかりやすさ」に重点を置き、表形式は「視認性の良さ」「書きやすさ」というところに重点を置いたものだと考えていますので是非皆さんのやりやすい方法で取り入れてみてもらえればと思います。
さて、これだけでも十分素晴らしい進化だと思うのですが、神崎さんは昨年夏からこのRDRAを更に進化させており、私もキャッチアップしているところです。
近々その成果をアウトプットしたいと思います。
今までの記事でも紹介させていただきましたが、RDRAについて詳しく知りたい方は最初に挙げた書籍『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』や、神崎さんのセミナー等を受けてみてください。
https://vsa.co.jp/img/service.pdf
(↑神崎さんの会社、バリューソースのサービス一覧)
当社ネクストスケープは新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。
（以下当社お問合せフォーム）
