RDRA２.０についてまとめみた（後編）

#はじめに
RDRA２.０についてまとめみた（前編）の続きになります。
前編ではRDRA２.0へ取り組むモチベーションや特徴、ざっくりした概要を説明しました。
後編ではもう一度RDRA２.0の特徴について理由を添えて説明したいと思います。
また、RDRA２.0で作成する各レイヤーの関係性や成果物についての説明を行いたいと思います。

目次

• 1.RDRA2.0の特徴について
• 2.各レイヤーの関係性について
• 3.各レイヤーの成果物についての説明

#1.RDRA2.0の特徴について
RDRA2.0の特徴として**『RDRA２.0とはシステムの全体像を素早く、整合性を保ちながら明確にする』**ことが挙げられています。この特徴について「全体像を素早く」と「整合性を保ちながら」という２つの観点に分けて理由を分析しまとめました。

##RDRA２.0が素早く要件の全体像を把握できる理由
ポイント1. 作るモノが明確で、アイコンを利用することで、作成スピードを早くできる
４つのレイヤーに当てはめて整理することで要件を素早く定義できる。また、ユースケースと情報や遷移フロー、区分、ルールとの繋がりが文章で表現するよりアイコンで表現する方が作成するスピードが速く、変更も容易です。

ポイント2.各仕様のWHY（理由）が明確に表現される
各仕様のインプットは上流のレイヤーとなります。そのため、仕様について認識の相違があった場合は上流のレイヤーの認識を合わせることで仕様の認識合わせが行えます。

ポイント3.関わるアクターやシステム要件を網羅するために利用せず、重要なモノのみ抽出して分析を行う
システムの要件は要件定義の中で明確になるので、初期段階の要望や枝葉の要求は捨てて、重要な要求・課題の分析に時間を割きます。同じく関わるアクターや外部システムも同様に洗い出そうとしてはいけないとのことです。
※RDRA２.0を利用して、関わるアクターや外部システム、要求や要件を網羅的に出そうとするのはアンチパターンとして記載されています。このように網羅的な表現を行おうとする場合は、一覧表などで表現することをお勧めしています。

以上３つのポイントが「RDRA２.0が素早く要件の全体像を把握できる理由」に関するものになります。
続いて、RDRA２.0がいかに整合性を保つことに優れているか整理しました。

##　RDRA２.0によって整合性を保つことができる理由
ポイント1.システム価値からシステムまでを繋ぐ事で、要求に沿ったシステムか確認できる
先ほど、「ポイント2.各仕様のWHY（理由）が明確に表現される。」でも記載した通り、仕様について上流のレイヤーに遡る事で認識確認が行えます。
例としてRDRA2.0 ハンドブックで登場する図書館システムの要件定義資料を参考に説明したいと思います。

RDRA２.0では、異なるレイヤー間をアイコンで紐付けることができます。
下記図では、要求モデル図とUC複合図を「会員」というアクターで紐づけました。
要求モデル図にて会員は、「Web検索したい」と「Web予約したい」という２つの要求がわかります。
一方UC複合図を確認すると、「貸出本の予約・取消をする」というUCに「蔵書検索」と「貸出予約」という画面アイコンがUCに紐づいています。
異なる２つのレイヤーである要求モデル図とUC複合図をアクターで紐づけることで、要求に沿ったシステムであることが確認できます。この通り、アイコンで紐づけることで要求に沿ったシステムか確認できます。

ポイント2.情報モデルと状態モデルをユースケースと紐づける事で、情報モデルや状態モデルに対して過不足なくユースケースが切られているか確認できる
情報モデルと状態モデルはシステムの整合性を担保するための重要なダイアグラムです。この情報モデルと状態モデルをハブとして各ユースケースを紐づけることにより、整合性の確認が行えます。
整合性の確認を行える理由について、RDRA2.0 ハンドブックで以下の様に記載されています。

状態モデルはユースケース横断で、システムが実現すべき状態を表しています。全ての「状態」を遷移させる「ユースケース」が揃っていれば、システム化に必要な重要な「ユースケース」が出揃っていることになります。同様に「状態」を実現するための「情報」が出そろっている必要があります。次にユースケースが状態を遷移させるために必要な情報が結びついていれば、ユースケースの精度が高いことを意味しています。

整合性確認の方法の一つに、情報モデルを中心におき各ユースケースを並べる事で、情報のライフサイクル（CRUD）が満たされているか確認することができます。

また、システム境界レイヤーの「UC複合図」とシステムレイヤーの「状態モデル図」の関係を確認する事で、状態と情報の整合性や、UCと情報の整合性が確認できます。
下記図書館モデルの例でどのように整合性を確認するか、一例を紹介します。

• 状態と情報の整合性について

状態モデル「貸出中」にフォーカスします。
状態モデルの「貸出中」は、「蔵書の貸出を登録する」ユースケースによって遷移していることがわかります。
一方、UC複合図のユースケース「蔵書の貸出を登録する」を確認すると、「貸出図書」と「蔵書」に紐づいており、貸出中である状態変化を「貸出図書」に登録していることがわかります。
このことから「貸出中」は「貸出図書」で実現されることがわかり、整合性としても問題なさそうなことがわかります。

• ユースケースと情報の関係

状態モデルの「貸出中」から「在庫中」への状態遷移にフォーカスします。
状態モデルの「貸出中」から「在庫中」はユースケース「貸出図書の返却を登録する」が行っています。このユースケース「貸出図書の返却を登録する」に紐づく情報である「蔵書」「貸出図書」「貸出予約」の整合性を確認します。このユースケースは「貸出図書」「蔵書」を更新し、次の予約がないか「貸出予約」を確認していることがわかり、整合性としても問題なさそうなことがわかります。
このように状態遷移と情報を紐付けて説明できるので、整合性として問題なさそうなことがわかります。

#2.各レイヤーの関係性について
上記の通り、RDRA２.0はシステムの全体像を素早く、整合性を保ちながら明確にすることができます。
前編にて、RDRA2.0は４つのレイヤー「システム価値」「システム外部環境」「システム境界」「システム」から構成されると説明しましたが、ここでは、この４つのレイヤーがどのような関係性で成り立っているのか説明したいと思います。「システム価値」「システム外部環境」「システム境界」「システム」の上流・下流関係とその作成粒度について、下記の図でまとめました。

また、同じ概念を表すアイコンは同じ図形・同じ名称にすることを強く意識してください。
著者では「ダイアグラムを一つずつ完成させるような進め方ではなく、同時並行的に複数のダイアグラムを作成・編集」していくのが良いと記載していました。
※各レイヤーで作成する成果物をダイアグラムと呼んでいます。

#3.各レイヤーの成果物についての説明

システム価値

###　各構成要素の概要

• 要求モデル
  • システム化への要求を書き出すことで、システム化の方向性を明らかにする。
  • 下手に全ての要求に対して整理を行うと膨大な時間がかかるため、枝葉の要求は切り捨てる。
• システムコンテキスト
  • システム化の目的、システムに関わる人や外部システムを把握するために整理する。
  • 重要なステークホルダーの要求を押さえているか否かを確認することが目的である。
  • 関わるアクター、外部システムを全て洗い出す目的で作成しないこと。

システム外部環境

システム外部環境は「ビジネスコンテキスト」「ビジネスユースケース 」「業務フローor利用シーン」「バリエーション・条件図」の４つのダイアグラムで構成されます。

###　各構成要素の概要

• ビジネスコンテキスト

• トップレベルの業務を明らかにし、その業務に関わるビジネス要素である、関係する会社や組織を洗い出すことが目的。

• 「業務」はトップレベルの仕事を分類することを意識する。その際には、顧客が普段認識している単位をそのまま使うことが大事。

• 洗い出した業務は「業務アイコン」として業務を表す図形を割り当てアイコン化する。

• 洗い出した「業務」について、以下の観点で問題がないか確認する。

  • 各「業務」の粒度感は適切か？（大き過ぎたり、小さすぎたりしていないか）
  • 各「業務」が横並びにして違和感がないか？

• 「業務」に関わるもの「ビジネス要素」として配置する。

  • 「ビジネスユースケース」の違いを生み出すものを中心に洗い出す
  • 「ビジネス要素」を洗い出すことで、「バリエーション・条件」や、「情報モデル」を洗い出すきっかけになる

• ビジネスユースケース

  • 「ビジネスコンテキスト図」で明示された「業務」を「ビジネスユースケース」にて更にブレークダウンする。
  • ブレークダウンの方法は垂直分割と水平分割の２種類がある。
    • 垂直分割：ビジネスユースケースを階層的に分割する
    • 水平分割：同じ業務内容を関係する「ビジネス要素」の違いから分ける
  • 「ビジネスユースケース」の分割基準を明らかにすることが重要。分割基準を明らかにして不要なビジネスユースケースの増加を防ぐこと。
  • 「業務」と「ビジネスユースケース」の両方ともその名前は現場で使われている用語を使い、さらに現場で認識している仕事の分類に近い方がより望ましいです。
  • ビジネスユースケース数に比例して、ユースケースも増える。これは同じ機能があちこちに散らばった保守が難しいシステムと言え、システム規模も増える傾向にある。

• 業務フロー
  • システムが使われる環境を明らかにすることが目的
  • ビジネスユースケース単位に作成する。
  • 関係するアクター間を一連の仕事（アクティビティ）の流れとしてフローを明示し、システムを使う仕事（アクティビティ）にユースケースをつなぎ、システムと関わる部分を明示する。
  • ユースケース名は「XXXをXXXする」の形式で書くとわかりやすい。

• 利用シーン

  • 業務を仕事の流れとして表現できない場合に「業務フロー図」の代わりに使用する。
  • アクターが抱える課題や問題の解決がイメージできるシナリオまたは箇条書きで記述する。
  • この課題や問題に対してユースケースを紐付け、システムを使うメリットを表す。

• バリエーション・条件図

  • 商品の分類や取引先の分類などビジネス上把握している値を表現する。
  • 「バリエーション」を整理することがビジネスルールの把握につながる。
  • ビジネス上使われているルールを条件として表現する。

####業務・BUC・UCの関係性
システム外部環境では業務・ビジネスユースケース・ユースケースと３つの業務に関連するアイコンが登場します。この３つの関係性がわかりづらいなと思ったので、洗い出し方法とその観点という視点でまとめてみました。

システム境界

システム境界は「UC複合図」で構成され、システム外部環境にて業務フローや利用シーンを整理せず、UC複合図で表す方法もあります。

###　各構成要素の概要

• UC複合図
  • 「ユースケース」を中心としたダイアグラムで、ユースケースに関わる要素を集めシステムが行うべきことを表現する。
  • 画面は画面、帳票などの人のユーザーインターフェースを表し、物理的な画面ではなく論理的な意味のある入出力単位としての画面を扱う。
  • 「外部システム」と連携する場合は「イベント」を「ユースケース」に結びつける。
  • 「イベント」は論理的に意味のある単位で洗い出す。（連携方式は考慮しないのでファイルやAPIなどの実現方法は無視して一律、「イベント」として表現する）

• UC複合図（業務フロー・利用シーン含む）
  • ビジネスユースケース全体を俯瞰して見たい場合に利用する。
  • 比較的仕事の流れがシンプルな場合に用いる。
  • 業務フローや利用シーンを含めることで細かくなりすぎる場合は、「業務フロー図」「利用シーン図」と「UC複合図」を分けて表現する。

システム

システムは「情報モデル」と「状態モデル」で構成されます。

###　各構成要素の概要

• 情報モデル

  • 「ユースケース」が操作する対象になり、複数の「ユースケース」を整合させるHUBになる。
  • 人がビジネスを駆動するために使っている用語を整理する。
  • 現場で使われている用語の関係性を可視化することが重要である。そのため、情報同士の関係性を線で結び表す。
  • ER図のような詳細なモデルは記載しないこと。

• 状態モデル

  • 現場で使われている用語の関係性を可視化し、「ユースケース」を状態遷移に対応させることで、「ユースケース」が実現する状態の変化を明らかにすることが目的。
  • システムの状態をビジネス上使われている用語で表すこと。（システムの内部状態は表現しない）
  • 状態の遷移を「ユースケース」で対応させることで、重要なユースケースが網羅しているかを確認できる。

#まとめ
RDRA２.0がシステムの全体像を素早く、整合性を保ちながら明確にするのに有効であるとわかりました。また、私自身、最初にRDRA２.0自体の全体像やどういうものか具体的なイメージができていませんでした。こうやってまとめることで、RDRA２.0の外観は掴むことができたと思いました。
あとは実際にRDRA２.0を利用して作図したり、それを元に実装を行いより具体的にイメージを掴み、ツールとして使いこなせるようになりたいと思います。
今回まとめた内容はRDRA２.0のほんの一部です。宣伝みたいになりますが、このRDRA2.0 ハンドブックで勉強いただきたいです。