この記事はGoodpatch Advent Calendar 2022 18日目の記事です。

ソフトウェアエンジニアの池澤です。

ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。

今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。
なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。

RDRA（ラドラ）とは？
ユースケースとは
RDRAをゲーミフィケーション（RPG）で例える
- RPGに例えるとイメージしやすい
RDRA2.0を理解しやすくカスタマイズ
- ユビキタス言語
- RDRA用アイコン
RDRAの図式解説（カスタマイズ版）
RDRAの先へ
まとめ
- 追記

RDRA（ラドラ）とは？

概要

リレーションシップ駆動要件分析（Relationship Driven Requirement Analysis）は神崎善司氏が作成した要件定義手法です。頭文字を取ってRDRAと書き「ラドラ」と読みます。

これまでの要件定義は機能一覧と詳細仕様を大量のドキュメントとして作成し、読み込み把握が大変だったり、開発側も実装機能がサービスの何に繋がっているのか、何のWhy・Whatを解決するための機能なのかが分からないといった課題がありました。

こうした課題に対して各種業務とシステムの関係を4つのレイヤーに分け、それをアイコンと線で結ぶことで関連を見えるようにした手法がRDRA（ラドラ）です。

RDRAのバージョン

書籍『モデルベース要件定義テクニック』
いわゆるRDRAバージョン1.0です。要件定義で業務やアクター等をアイコンと線で繋ぎ、関連性を分かりやすくした手法です。
書籍『RDRA2.0 ハンドブック』
RDRAバージョン2.0です。要件定義を軽量でスピーディーに回そうとしたが、RDRA1.0ではダイアグラムをがっつり作らないといけない重い手法と捉えられてしまいました。そのため不要なダイアグラムや表現をスリム化したものになっています。Kindle Unlimitedにて0円で購読できます。

これまでの要件定義でよくある問題

これまでの要件定義ではこんな課題がありました。

抽象論での空中戦による認識ズレ
- 同じ議論が繰り返される
- 何が決まって、何が決まっていないのかはっきりしない
開発工数が見積もりづらい
- 機能単体での詳細仕様しかなく影響範囲が分からない
- 概念モデルや状態管理の元となる情報や状態条件がなく複雑度が分からない
認識共有されず内容把握も難しい
- 全体像を誰も分からない
- 一覧と詳細な細部の資料しかなくしかも読みづらく負担が大きい
- コミュニケーションコストが高い
断片的な情報が出てくる
- 会議の度にスコープが変わったり根拠があいまい
- 思いつきやそもそも論が頻発し、粒度、抽象度も統一されていない
開発時になぜこの要件が必要かWhyが見えない
- 開発する際、ユースケースや業務背景が理解できない
- 本来やりたかった事が実装しきれない
- 手直しが多数発生
- Whyが分からないので開発は変更指示待ちの姿勢となってしまう
- 要件の段階で業務課題と切り離されてしまい後工程フェーズで業務意図とのずれに気づけない
開発実装時の要件修正が困難
- 実装フェーズで開発側から要件不備を疑っても自ら判断する術がない
- 開発側からの要件不備が適切に取り上げられない
要件の抜け漏れが発生しやすく修正しづらい
- 抜け漏れがないか判断するのが非常に難しい

期待される要件定義の姿

RDRAでは以下のような改善を図ります。

要件を決める仕組みを持つ
- ビジネス価値〜要求〜ユースケースまでのつながりを説明できる
- 変更時の影響範囲を把握できる
- 複雑になってきた時に情報を整理しやすい
- 業務の広さ/深さでの規模が見通しやすく追加も簡単
見積もり可能な要素を持つ
- ユースケースや情報、状態から量と複雑度を見積もり可能
- 見積もりの根拠が分かりやすい
システム設計
- 実装へスムーズに入れる
- システムに対してユースケースや情報、状態の繋がりが見える
- ユースケースや情報モデルがUIデザインやシステム設計時にも使用できる
共通認識のための土台となる
- 業務視点で書かれ、BIZ側も開発側もなぜこの要素が必要か分かる
- 開発ではなくビジネス視点で書くので共通の視点で会話し会議中に判断合意しやすい

公式サイト

www.rdra.jp

実際のRDRAサンプルや導入企業の声

RDRAが効果的なケース

元々日本のERPや複雑な業務の要件として作られた経緯があります。
そのため担当者や事業部、外部業者がたくさん関わるものや「ヒト・モノ・カネ」がメインの関心事であるケースで有効です。

RDRAが不向きなケース

Adobe Photoshopのようなグラフィックソフトやオンラインホワイトボードツール（StrapやMiro等）のように、ソフトウェアの関心事が「ヒト・モノ・カネ」よりも、要素の描画や加工、フィルター、演算にあるようなもの。こうしたものは業務より機能への要件が多いのでRDRAは不向きです。

ユースケースとは

ユースケースについてネットで調べると様々な定義や作法が出てきて混乱してしまいます。シナリオに沿った文脈の振る舞いを定義したものというあいまいなものであったり、逆にICONIXのように厳密かつ長文で複雑なルールであったりと様々なものがあります。

またアジャイル開発等では「ユーザーストーリー」という類似した言葉もあり、ユースケースとユーザーストーリーの違いもばらついています。

そこで私は要件定義でのユースケースについて以下のポイントで考えています。

ユースケースのポイント

業務やシナリオに出てくる言葉を元に「誰が」「何を」「どうする」の構文にあてはめたもの
場合によって「何々をしたいため」といった「理由」や「目的」を追加しても良い
原則一行程度の長さでコンパクトにまとめる
語尾を「〜できる」で終わらせると主語の自由選択で行動を取ることもやめることも含ませられるので活用する。
業務側と機能側のユースケースでは抽象度や行動部分でばらつきが生じやすい。その場合は「業務ユースケース」「機能ユースケース」のように先頭に「業務」「機能」をつける
「ユーザーストーリー」は機能ユースケースとして扱う。（実際この定義でやってもあまり困らない）
「業務ユースケース」は、RPGで言うとギルドの目線から見たクエスト依頼の計画定義の工程になる。ここでサービスがどう使われるのかを表していく。
「機能ユースケース」は、RPGで言うと冒険者の目線から見たダンジョン内部やギミックの動作・攻略の工程になる。ここで機能がどう使われるのかを表していく。
業務ユースケース・機能ユースケース両方に当てはまるユースケースもあり得るが、重複自体はあっても問題はない。（「ログインでユーザ認証できる」「マイページでユーザ情報を登録・確認できる」等）。その場合、ギルドの目線・冒険者の目線のように関心事で分けて使用する。

業務ユースケース

RPGで言うと「ギルドの目線」から見たクエスト依頼の計画定義の工程になる。ここでサービスがどう使われるのかを表していく。ビジネスのゴール・シナリオや業務フローを進めるために戦略・戦術タスクを抽象度の高いユースケースで描いたもの。
逆に具体的な画面やボタン操作といった「ギミック」要素については関心を持たない。

経営や事業部、ビジネスチームで企画の狙いやサービスプロセスを確認したりするケースや、業務の流れを概念的に表して企画書内で業務フローとして記載するのに使われる。

いわば『ギルド』がゲームシナリオ進行のために、様々なクエスト依頼を作成するのに似ている。このクエストを達成する毎にゲームシナリオが進行し、メインストーリー（ビジネス目標）もゴールに近づくというものにあたる。

業務ユースケースの例

顧客の利用促進を図るため、顧客の関心のあるトレンド業務情報を定期配信できる
事務局が登録途中での顧客離脱箇所を把握できる
顧客は入力した情報が外部ユーザに公開されることを認識できる
受注状況を確認する

機能ユースケース

RPGで言うと「冒険者の目線」から見たダンジョン内部やギミックの動作・攻略の工程になる。ここで機能がどう使われるのかを表していく。
業務ユースケースが抽象度の高いビジネス上のシナリオや業務フローだとしたら、機能ユースケースは具体的なUI画面やボタン構成、クリック後の処理、それら機能により得られる結果内容を指す。
具体的な画面やボタン操作といった「ギミック」の処理動作やそれをまとめた機能群＝「ダンジョン」と達成結果について関心を持つ。

UIデザイナーやエンジニアが手を動かし制作する具体物や処理内容を定義・設計・実装するのに使われる。
スクラム開発でいうプロダクトバックログアイテムに近いイメージのもの。

いわば『冒険者』がダンジョン攻略のために、様々なギミックを操作し、何らかの出力や状態変化を起こし、ダンジョン攻略を通してクエスト依頼を達成するというものにあたる。

機能ユースケースの例

顧客が料金・機能を一覧で確認できる
ログインユーザが気になる案件を検索し結果画面からお気に入り登録ができる
ユーザが検索結果から一番近い目的地を選択できる
顧客がプロフィール情報を登録できる

RDRAをゲーミフィケーション（RPG）で例える

RPGに例えるとイメージしやすい

RDRAでは様々な図やアイコンが出てきます。
これらの作成ルールに気を取られると、肝心の業務要件の整理や求めるユースケースへの意識が薄くなったり、どの観点や粒度で捉えればいいのか分からなくなりがちでした。
そのため私は要件定義とゲーミフィケーションをミックスして想像しています。ドラゴンクエストのようなRPGに出てくるクエストやダンジョンを業務や機能になぞらえて、粒度や範囲をイメージしていますのでご紹介します。

ゲームシナリオ・ボード

RDRAで「システム価値」レイヤーでは、登場するアクターや業務要求、外部システムを設定して行きます。

RPGで例えると、これはボードゲームでの駒やルール、RPGでのメインシナリオや登場人物としてイメージすると捉えやすくなります。

RDRA	RPGイメージ
「システム価値」レイヤーでのアクター、要求	ゲームの駒、ルール、ゲームクリア条件

クエスト

RDRAで「システム外部環境」レイヤーでは、誰が何を行うのかや対象システムがどのように使われるのかを表します。実施する業務や業務フローをまとめ、そこで扱われる情報や他の業務との連携を設定して行きます。

RPGで例えると、これはギルドが冒険者に依頼する『クエスト』としてイメージします。
RPGではよく冒険者ギルドの掲示板にクエスト依頼の紙が貼られています。その内容には達成したい業務依頼や業務達成結果として持ってきてほしいもの、達成後にアンロックされる関連クエストがあったりしますが、このクエストをイメージして業務を捉えます。

RDRA	RPGイメージ
「システム外部環境」レイヤーでの業務、業務フロー	クエストの依頼、達成後の関連するフロー、関連するクエスト依頼の解放

「ギルドの目線」という観点

RDRAを作っていると業務の細分化やフロー、機能との違いで迷うことがあります。
そんな時は「ギルドの目」というものを意識してみると良いです。例えばボタンのクリックや入力、登録・編集・削除など具体的な操作を考えている場合、それは冒険者がダンジョン攻略で行う具体作業にあたります。これは具体度が高すぎるのでクエスト範囲外にあたります。

依頼主であるギルドは業務目的のためにクエスト依頼（業務）を設計します。そのクエストが達成されるとギルド業務を次ステップへ進めることが可能になります。しかしギルド側は依頼側であり、具体的なダンジョン内部（機能やUI）の様子には関心を持っていません。

こういう目線を持つとRDRAの業務の抽象度を維持して、UI画面やデータ等の機能に寄り過ぎることを防止しやすくなります。

ポイント

具体的なUI画面や操作が出てきたら、クエスト範囲外のことをやっていないか確認する
自分は現場で具体的な行動をしないこと。業務依頼して結果をもらう立場で考え、高い抽象度を維持する

ダンジョン

RDRAで「システム境界」レイヤーでは、対象システムとアクターが業務を通じてどう関わるのかを表します。アクターとシステムが接するためにはUI画面や表示する情報データが必要です。そのUIやデータを使って実行したい業務ユースケースが行えるようにしておくことがシステム境界に求められます。

RPGで例えると、ダンジョンが森、氷、溶岩等の各種属性タイプ（UI画面、表示データ等）で構成されているとします。冒険者は特定のクエスト達成を目指してダンジョンに探索に行きます。
途中宝箱や落とし穴、扉の鍵探し、ボス敵等のギミック（機能）をくぐり抜けながらダンジョンを達成（業務ユースケースの実施）し、クエスト依頼結果（業務の状態変化や出力結果）を持ち帰るイメージです。

ダンジョン攻略の上流には、ギルドの意図するクエスト（業務）やメインシナリオ（サービス目標・価値したい提供）が繋がっています。このつながりを辿れるのがRDRAの狙いの一つです。WhyやWhatが知りたければ上流を辿れば確認できるようになっています。

なおRDRAではHowを関知しないという方針があります。ここでいうHowは機能のことでダンジョンのギミック（機能）に当たります。そのためRDRAではギミック（機能）部分を業務ユースケースでの表現に留めたものを作成します。いわばダンジョンでの入出力結果までを定義して、機能仕様はブラックボックス扱いにする形です。
エンジニアが開発するためには機能部分も必要になりますが、ここはRDRA以外の方法で機能一覧や機能仕様を作る必要があります。

RDRA	RPGイメージ
「システム境界」レイヤーでのUI画面、情報、業務ユースケース	ダンジョンの属性タイプ（UI画面、表示データ等）、宝箱や落とし穴、扉の鍵、ボス敵等のギミック（機能）、ダンジョン攻略達成（業務ユースケースの実施）

「冒険者の目線」という観点

冒険者はクエスト依頼（業務）を実際に実行して行きます。
クエスト達成するためには様々な属性（画面、データ等）のダンジョンに入り、色んなギミック（機能）を攻略し、クエスト依頼を達成（出力結果・状態変化）して行きます。
ダンジョンの中の様子はギルド側では関知せずブラックボックス扱いですが、冒険者の観点ではむしろ主戦場としてダンジョンの詳細や仕様に関心があてられます。

こうすると具体的な機能やUI画面等は一旦ダンジョン内でやればいいので、粒度の整理が付けやすくなります。頭に具体的なUIや操作が浮かんだら、ダンジョン設計側にまかせればいいと整理がしやすくなります。

ポイント

具体的な機能やUI画面や操作が出てきたらダンジョン内部で冒険者がやることと捉え、クエスト（業務）とダンジョン（機能）が混在しないようにする
ダンジョン攻略の上流には、ギルドの意図するクエスト（業務）やメインシナリオ（サービスの目標・価値提供）がある。WhyやWhatが知りたければ上流を辿れば確認できる

RDRA2.0を理解しやすくカスタマイズ

RDRAではたくさんの図（ダイアグラム）やアイコンが出てきます。
私が学習していく中で冗長だったり分かりにくいと感じる部分がいくつかありましたので、用語やアイコンをカスタマイズさせてもらっています。この方がよりRDRAの学習コストを下げ、良さが活かせると思いますのでご紹介します。

ユビキタス言語

基本的にはRDRA以降の機能要件と区別できるよう、RDRA由来の名称には「業務〜」を付けるようにしています。他にも一般的にイメージしやすくなるように修正して使っています。

カテゴリ	RDRAオリジナル	カスタマイズ	理由・補足
ダイアグラム	ビジネスコンテキスト	サービス俯瞰図	簡潔表現にする。ドメイン駆動設計のコンテキストと混同防止
ダイアグラム	システムコンテキスト	システム俯瞰図	簡潔表現にする。ドメイン駆動設計のコンテキストと混同防止
ダイアグラム	要求モデル図	業務要求モデル図
ダイアグラム	情報モデル図	業務情報モデル図
ダイアグラム	ビジネスユースケース図	業務図	ビジネスユースケース図の中にさらに複数のビジネスユースケースアイコンがあり分かりにくい。業務の詳細仕様なので業務図とする
ダイアグラム	状態モデル図	業務状態モデル図
ダイアグラム	バリエーション	情報パターン図	主語が推測しづらいため情報を付ける。情報の内訳を表すのでパターンとする
ダイアグラム	ユースケース複合図業務フロー、利用シーン付き	業務バリエーション図	冗長なので短くする。先頭に業務を付ける。業務のフローと展開を表すのでバリエーションとする
アイコン	ユースケース	業務ユースケース	先頭に業務を付ける。
アイコン	条件	情報ステータス	主語が推測しづらいため情報を付ける。情報の分岐状態を表すのでステータスとする
アイコン	画面	UI/画面	画面以外のUIやインターフェースも含めた表現にする

RDRA用アイコン

RDRAではアイコンに定義や制限は特にされていません。しかし基本となるアイコンは初期アイコン指定が合った方が分かりやすく収集する手間も減らせます。そのためMaterial iconsを使ってデフォルト定義をしておきます。

名称	Material icon	補足
アクター	Person
組織	Groups
システム	Home Work	主にサービスシステム自身用に使用
外部システム	Corporate Fare
業務	Work	RDRAの業務アイコンのこと
業務バリエーション	Badge	RDRAのビジネスユースケースアイコン（BUC）のこと
業務ユースケース	Flip Camera Android	RDRAのユースケースアイコン（UC）のこと
アクティビティ	Play For Work
利用シーン	Keyboard
情報	Info Outline
情報ステータス	Call Split	RDRAの条件のこと
UI/画面	Web
イベント	Notifications Active

RDRAの図式解説（カスタマイズ版）

フライドポテト卸し管理システムを作ってみる

RDRAの学習の中で業務を分ける際、売店や大手流通、コンビニ向けという例えが出てきます。このシーンを聞くと、いつも私は子供の頃塾へ通う途中にジャスコの売店で食べたフライドポテトのカリカリした食感と油の香りを思い出しました。（アイスのコーンみたいな円すいの紙にたっぷり盛られていて確か100円ぴったりでした）
なので、サンプルでフライドポテト卸しシステムをRDRAで組んで、懐かしのジャスコ（売店）へ届けられるようにしてみたいと思います。

サービス俯瞰図

フライドポテト卸し管理システムを作ります。このサービス全体像と、サービスに連携する他部署（配送事業部）や外部システム（大規模農家が運営するポテト商材調達システム）が表されています。
顧客企業がフライドポテトを卸してほしい時にこのフライドポテト卸し管理システムへ納品依頼すると、担当者が調整し配送部門へ配送依頼するシステムです。

システム俯瞰図

このシステム面で関わる要素の全体像です。顧客企業の納品依頼や自社の受注担当者が主に使います。また配送事業部へはフライドポテト配送依頼の通知が飛びます。在庫不足だったら商材調達システムへも通知が飛びます。

業務要求モデル図

各アクターや顧客等のステークホルダーが行いたい業務要求が表されています。

業務情報モデル図

業務上取り扱う情報モデルの図です。
システム設計ではないのでER図のような詳細は不要です。ドメイン駆動設計でのドメインモデルを業務寄りに抽象化した感じです。プロジェクトや対象業界によって粒度や範囲は様々です。

業務図

RDRAでいう「ビジネスユースケース図」にあたります。
ここでは多数ある業務の内、「フライドポテト受注管理」業務について表します。売店、大手流通、コンビニで受注が分けられます。また受注後には在庫確認と配送依頼が待っています。
この業務内容で売店、大手流通、コンビニのような同一業務の種別での区分け方を水平分割といい、受注、在庫、配送のようなフロー的な区分け方を垂直分割といいます。
ここはクエストの範囲になります。

業務状態遷移図

RDRAでいう「状態遷移図」にあたります。
業務を通じた結果、起こる状態遷移について表します。システム設計のState管理のような状態遷移ではなく業務の観点で捉えます。「ギルドの目」で見る感じです。

情報パターン/情報ステータス

RDRAでいう「バリエーション図」や「条件」にあたります。
RDRAでは条件仕様を業務バリエーション図（ユースケース複合図）の中でばらけて記載されていました。これだと一元的に条件内容を把握しづらいので情報ステータス図として1箇所にまとめます。

情報ステータスには配送地域：北海道、東北、関東のように条件に紐づく値が定義されます。
情報パターンは「情報」アイコンで表される業務情報の内訳を書く形になります。

業務バリエーション図

RDRAで最も大事な図の一つです。
元々は「ユースケース複合図業務フロー、利用シーン付き」という名前でした。
当初は一つの業務バリエーションについてフロー的なものであれば「業務フロー」、単体で完結するものであれば「利用シーン」と区別されており、業務ユースケースのwrapperが多種類（業務バリエーション、業務フロー、利用シーン）あるようなRDRA仕様でした。

しかしモダンな開発現場では業務が外部SaasやAPI連携することが増えたり複雑になってきたので、全部まとめて「ユースケース複合図業務フロー、利用シーン付き」となったようです。

ここはちょっとRDRA仕様が混沌としていますね。
私は業務バリエーションを以下のように捉えて整理しています。

業務を展開・細分化したもの
内部に1つ以上の「業務ユースケース」を持っている

業務ユースケースとダンジョン

業務バリエーション図には「業務ユースケース」が出てきます。この「業務ユースケース」こそがRPGでのダンジョンにあたります。
よく見ると業務ユースケースには情報アイコンやUI/画面アイコンが紐づいています。これがダンジョンの属性タイプ（森、氷、溶岩等）を構成します。
業務ユースケースにつながる線がダンジョン達成の前後関係になります。また、「業務状態遷移図」に出てくる業務ユースケースではダンジョン達成した結果起こる状態遷移を表現しています。

ダンジョン内部はRDRAでは設計対象外として扱いますので、RDRAはサービス俯瞰図から業務ユースケースまでを定義するものとも言えると思います。

RDRAの先へ

機能仕様について

RDRAではHowを扱わない、つまり機能仕様についてはノータッチになります。 RPGでいうとダンジョン内部やギミック仕様はブラックボックスのままになります。しかし実際に開発へ実装やシステム設計を依頼する際は、当然機能についても求められることが多いです。

また、例えばオフショア開発の場合は業務要件でやりたいことや流れが明確であったとしても、具体的な機能仕様がないと開発見積もりができないケースもあります。

※ 追記（2023/12/20）
Howにあたる機能要件定義について別記事を作成しました。
機能ユースケースを軸にHowであるUIスペックや実装への連携について、実際のサービス開発で使用しブラッシュアップした内容でご紹介しています。
『RPGダンジョンライクに要件定義を例えながらWhy-What-Howをつなげる方法を説明してみた』

goodpatch-tech.hatenablog.com

機能仕様の実例や手法

例えば次のスライドではRDRA後にICONIXというユースケース駆動の要件定義手法につなげているケースです。Zenn > モデルベースで要件定義をやってみた > RDRA2.0を1年半つかって実感した効果

GoodpatchではUIモデリング設計やUI Specを作成し、別途作成する機能仕様とUIをユースケースで連動させながら開発連携を行なったりしています。

業務ユースケースと機能ユースケース

業務と機能を洗い出しそれぞれをユースケースで繋げると、Why・What・Howが一本化し見通しの良い仕様となります。また要件定義から実装を完了後に、システム側仕様書も含めた「サービス全体仕様マニュアル」が必要になった際もシステム設計ドキュメントへのリンクや更新が行いやすくなります。

機能ユースケースを抽出するには

業務要求としてやりたいことや業務ユースケースが既にある場合は、ここから機能の洗い出しを行ないます。
このフェーズではまだこれといった要件定義手法等が無く、さらに業務ドメインや業界、商習慣でも求められる機能が異なったりします。そのためたたき台を作ってはメンバーですり合わせというオーソドックスなやり方が多そうです。

sudoモデリング法

ドメイン駆動設計のDDD-Community-Jp主催者の松岡幸一郎氏の動画にsudoモデリング法というものが掲載されていました。具体的なアクターを図で描きながら、出てきた要素をドメイン情報や機能として洗い出していく手法です。スピーディーかつ簡単にできるのでとても効果的に思いました。

www.youtube.com

ユースケースロールプレイ

私がRDRAをカスタマイズしながら必要なUIや機能を洗い出す時に使ったものです。
やり方はまずRDRAで作成した「業務ユースケース」と「情報」「UI/画面」アイコンを持ってきます。それを元に、アクターがどんな行動をして業務ユースケース内容を実現していくのかを図上でロールプレイングゲームをするようにイメージして要素を書き込んで行きます。
そこで出た情報や機能を別紙に記載して行きます。

このロールプレイして必要となったものを「機能ユースケース」として定義していくというものです。 RPGに例えると、実際に冒険者を業務ユースケースのダンジョンに探索させて、ダンジョン達成に必要なギミックや情報、UIのイメージを都度拾っていく感じです。

ユースケースロールプレイから抽出した機能ユースケース

No.1 受注担当者が商材在庫一覧を確認できる
No.2 受注担当者が納品差分を確認できる
No.3 受注担当者が不足分商材の調達依頼ができる
No.4 システムが数量と期限情報を付けて調達依頼通知ができる

まとめ

だいぶ長文になってしまいました。
RDRAは概要はなんとなく分かっても図やアイコンの使い方についてはやや学習コストが高く、私も社内で勉強会を何度か開催しましたが、図の理解はやはり負担高そうですね。

要件定義は一見無味乾燥なように見えますが、RPGゲームの制作者になりきってクエストやダンジョンを作っているんだと思い込めるとゲームのレベルデザインやシナリオ設定のように見え、面白く思えてきたりしました。

要件定義の本当の目的は、プロジェクトメンバーが空想を湧かせてユーザが喜んでサービスを使ってくれる様子や、その喜びのためにこの機能のUIや開発が求められているんだというイメージを共通認識できることとと思います。
メンバー全員が同じ心象風景を描き観点を合わせてサービスを作れる、それがきっと良い要件定義であり良いプロジェクトなのだろうと思います。

追記

2022/12/20
公開後、RDRA制作元の神崎善司さんご本人からこの記事のツイートを頂きました。大変光栄です。ありがとうございました。

RDRAをRPGの視点から説明した記事
今までにない切り口の説明なのでとても新鮮
ギルドの目線　冒険者の目線など　私の発想からは決して出てこない視点だったのでとても勉強になった
RPGを知っている人は私の説明よりこの記事の方が分かりやすいと思う
- Goodpatch Tech Blog https://t.co/9b1I4FZb49
— 神崎　善司 (@zenzengood) 2022年12月19日

2023/12/20
Howにあたる機能要件定義について別記事を作成しました。機能ユースケースを軸にHowであるUIスペックや実装への連携について、実際のサービス開発で使用しブラッシュアップした内容でご紹介しています。こちらも合わせてご覧ください。