シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像
- RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
- RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
- RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
- RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
- RDRAの成果物と設計プロセスとの連携
- 要件定義をAIで加速する「RDRA Agent」その1〜LLMがモデルの叩き台を自動生成
- 要件定義をAIで加速する「RDRA Agent」その2〜要件を仕様化するRDRASpec（本記事）
- RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
- RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
- RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編（近日公開予定）
- RDRAで見積りを行う方法その4〜アジャイル開発（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
前回は、LLMを活用してRDRA形式の要件モデルを自動生成するツール「RDRA Agent」を紹介しました。
RDRA Agentには、生成した要件を仕様化するための機能「RDRASpec」が用意されています。
仕様化とは、要件を開発チームが設計・実装できるレベルまで具体的かつ明確に定義することです。
つまり、「何を実現したいか（要件）」を「どう実現するか（仕様）」へ変換する作業であり、仕様化は要件の曖昧さを排除し、開発時の認識のずれや手戻りを防ぐうえで欠かせません*1。
本記事では、この「RDRASpec」の機能について紹介します。
RDRASpecが作成する仕様
RDRASpecでは、以下の3種類の仕様を作成します。
- 論理データモデル
- ビジネスルール
- 画面仕様
仕様の作成方法
仕様化した成果物を作成するには、メニューから21.仕様の作成：論理データ構造/画面/ビジネスルールを選択します。
実行が完了すると、2_RDRASpecフォルダ内に以下のファイルが出力されます。
- 論理データモデル.md
- ビジネスルール.md
- 画面仕様.json
以下では、RDRASpecが作成する論理データモデル、ビジネスルール、画面仕様のそれぞれについて説明します。
論理データモデル
論理データモデル.mdには、以下の内容が出力されます。
- エンティティ定義
- ER図（Mermaid形式）
- 論理データモデルの設計ポイント
- データモデルの実用性
上記のうち、エンティティ定義とER図（Mermaid形式）について以下で説明します。
エンティティ定義
データモデルを構成するエンティティを、データ名（エンティティ名）、項目名、タイプ（型）、主キーかどうか（isKey）、説明の各要素で定義し、表形式で表したものです（下図）。
ER図（Mermaid形式）
エンティティ定義をもとに、エンティティ間のリレーションシップをER図（Mermaid形式）で表したものです（下図）。
ビジネスルール
ビジネスルールが、条件、バリエーション、および状態モデルの関係を元に定義されます（下図）。
RDRA Agentに含まれている訪問介護システムのサンプルでは、以下のカテゴリのビジネスルールが出力されました。
- スケジュール管理
- スタッフ管理
- 会員管理
- 請求計算
- 施設管理
- 法規制対応
このように、RDRAで定義した条件・バリエーション・状態モデルの情報をもとに、業務上の判断基準や制約がビジネスルールとして体系的に整理されます。
画面仕様
画面仕様.jsonには、BUC（ビジネスユースケース）とアクターごとの画面情報が出力されます。
BUC・アクター別画面の表示
画面仕様を確認するには、メニューから22.BUC・アクター別画面を表示するを選択します。
選択すると、PC上でHTTPサーバーが起動し、ブラウザが自動的に開いて画面イメージが表示されます。
下図は、スケジュール計画業務のスケジュール計画フローの業務において、サービススタッフが操作する「スタッフスキルと要望提供画面」を開いた例です。
現時点で確認できる画面仕様は簡易的なものですが、画面に表示されたデータ項目を見ながら、項目の過不足や名称の妥当性を検証する用途に活用できます。
たとえば、要件定義の段階で画面項目の抜け漏れを早期に発見し、手戻りを防ぐといった使い方が効果的です。
仕様化の参考書籍
要件（要求）の仕様化についてより深く理解したい方は、以下の書籍が参考になります。
最後に
本記事では、RDRA Agentの仕様化機能「RDRASpec」を紹介しました。
RDRASpecを活用することで、要件定義で整理した情報をもとに、論理データモデル・ビジネスルール・画面仕様といった設計の入力となる成果物を効率的に作成できます。
定義した要件をRDRASpecで仕様化することで、要件の解像度が上がり、曖昧さや矛盾を早期に発見できます。これにより、要件の適切性を具体的な仕様レベルで検証でき、後のプロセスでの手戻りリスクを低減できるでしょう。
次回は、RDRAで定義した要件をもとに見積りを算出する方法を紹介します。
*1:本メディアでは、「要件の仕様化」を「基本設計」プロセスに含めます。仕様化とは要件を「どう実現するか（How）」を定義する作業であり、設計の領域に属すると考えるためです。ただし、「要件の仕様化」を要件定義プロセスに含めるか、基本設計プロセスに含めるかは議論が分かれるところです。要件定義に含める場合は、要件定義の段階でHowにまで踏み込んだスコープを扱い、基本設計ではそれをインプットとしてさらに精緻化していくという考え方になります。いずれの立場をとるにせよ、要件と仕様の境界を開発チーム内で合意しておくことが重要です。
