日本で生まれたBA方法論 RDRA：ビジネスとITを繋ぐビジネスアナリシスを知ろう！（1/2 ページ）

「網羅的で整合した要件定義を素早く行う、システムの可視化手法」RDRAとは。

[濱井和夫，ITmedia]

第1回：なぜDXにおいてビジネスアナリシスが必要なのか

第2回：ビジネスアナリシスの知識体系BABOKガイドとは（前編）

第3回：ビジネスアナリシスの知識体系BABOKガイドとは（後編）

第4回：アジャイルとビジネスアナリシス

第5回：データードリブン経営へ向けて：BDA入門

第6回：プロダクトオーナーシップ とは：POA入門

第7回：戦略と実行の橋渡し、ビジネスアーキテクチャの役割――デジタル時代を生き抜く、企業の新しい羅針盤

第8回：要件定義をツールで行なう：ビジネスアナリシスツールの紹介

第9回：ビジネスアナリストの人材育成

第10回：日本で生まれたBA方法論　匠Method

第11回：日本で生まれたビジネスアナリシス方法論：GUTSY-4

　「ビジネスとITを繋ぐビジネスアナリシスを知ろう！」の第12回目となりました。ビジネスアナリシスに関して、その大切さについての話や、知識体系であるBABOKガイド、および付随する専門領域の概説に続き、日本で生まれたビジネスアナリシス方法論が2回続きましたが、今回はその第3弾として、RDRA(Relationship Driven Requirement Analysis、ラドラと呼称)を紹介します。

　第10回で匠Methodを「『戦略アナリシス』から『要求アナリシスとデザイン定義』の知識エリアに対して有効な」と紹介しましたが、今回のRDRAは、『要求アナリシスとデザイン定義』の知識エリアに対して有効なものになります。　「網羅的で整合した要件定義を素早く行う、システムの可視化手法」というサブタイトルでIIBA日本支部でも、何回かセミナーを実施したことがあります。要件全体を俯瞰し、要件を漏れなく、無駄なく、矛盾なく定義することは大変難しく皆さん苦労するところかと思いますが、モデル（図）を使って、ビジネスからシステムまで、その関係を見える化し、関連者での議論を促進することで、それを可能にします。

BABOKの知識エリアとの関係

RDRAとは？

　RDRA は、(株)バリューソース　代表取締役社長の神崎善司氏が開発した独自の要件定義のモデリング手法です。下の6つの図のそれぞれ左側に記載された既存の要件定義の課題感に対して、右側のアプローチで、対象とする業務やシステム機能を俯瞰（ふかん）する業務地図、システム地図とも言える図を作成し、ステークホルダー間の議論を活性化させ、要件の漏れ、矛盾の洗い出し、要件の整理を行いやすくします。

左側が既存の要件定義の課題感、右側がアプローチ

基本的な考え方

　（1）開発する機能だけではなく、業務を構成する要素間の関係をアーキテクチャー（構造）として表現する

　「要求アナリシスとデザイン定義」知識エリアにあるように、要求は平たいリストではなく、価値を実現するアーキテクチャー構造を持ちます。RDRAは要求の階層として、シンプルに4つのレイヤ（システム価値、外部環境、システム境界、システム）で表現します。上位のレイヤは下位のレイヤの要素が「なぜ必要なのか？」を表現することになり、基本的には上位のレイヤから分かっていることを明らかにすることになります。

RDRAの4つのレイヤ

（2）業務を実現するモノ、コトを業務の言葉を使って図で表現する

　業務を実現する要素を下表のように定義し、そのアイコンを関係線でつなぐことにより全体の関係を見える化し、関係により言葉の意味のブレを少なくします。

要素を定義

全体の関係を見える化

（3）業務を、業務のプロセスと業務のルールに分解する

　(ア)業務のプロセスの流れをアクティビティのつながりで表現し、利用するUC、画面、情報、条件でシンプルにその構造を表現する

　(イ)業務のルールを業務の言葉で、業務的なバリエーションとその組み合わせで条件として表現する。

業務のプロセスとルールに分解

（4）最初から完璧を目指さず、俯瞰し議論して精度を上げる

　既存の手作業の業務をシステム化により効率化するといった旧来のシステム開発では顧客から正しい要件が聞き出せたのかもしれませんが、新しいビジネスをシステムと一体となって構築するような時代ではそもそもの正しい要件を顧客含めて誰も分かっていない状況もあるのではないでしょうか？　RDRAでは分かっていること、分かっていないことを見える化し、ビジネス側、業務実施者、開発者といったステークホルダーが集まって、全体を俯瞰し、議論を重ねて要件の精度を上げていきます。

全体を俯瞰し議論を重ねる

精度を上げる整合性と網羅性