TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

本連載ではこれまで、RDRAの第1フェーズから第3フェーズまでの手順を通じ、業務とシステムを一体として構造化していくプロセスを解説してきました。

さらに前回は、定義したRDRAの成果物が、ソフトウェアアーキテクチャ設計やクラス設計などの設計プロセスにどのように引き継がれるかを整理しました。

RDRAによるアプローチは非常に強力ですが、どのような要件定義手法であっても共通する課題があります。

それは、要件定義立ち上げ時にかかる「全体像を描き出す労力」です。

ヒアリングやワークショップを重ねながら、関係する業務や機能の要素をひとつひとつ洗い出し、整理し、要件としてカタチにしていくという初期作業には、手法を問わず大きな労力がかかります。

本記事では、要件定義立ち上げ時の初期作業の負担を大幅に軽減し、要件定義のスピードを劇的に加速させるAI Agentツール「RDRAAgent」を紹介します。

RDRAAgentとは

RDRAAgentは、LLM(大規模言語モデル)を活用し、要件の叩き台となるRDRA形式のモデルデータを自動生成する支援ツールです。

自然言語で記述された要望を読み込み、RDRAの構造に沿った要素(アクター、業務、ユースケース、情報など)を推論します。

RDRAAgentはCLI(コマンドラインインターフェース)から実行する形式で提供されており、GitHubで公開されています。

RDRAAgentのインストール方法

RDRAAgent の入手先(GitHub)https://github.com/kanzaki/RDRAAgent_v0.6

なお、本記事執筆時点のバージョンは0.6です。正式版のリリース時にはURLが変更される可能性があります。

RDRAAgentは外部依存関係がないため、ダウンロードまたはクローンするだけですぐに利用できます。

  • 必要環境

    • OS: Windows 11 / macOS
    • Node.js: バージョン18以上推奨
    • AIツール:Claude Code(デフォルト)または Cursor
  • 方法1: GitHubから直接ダウンロード(推奨)

    • GitHubリポジトリページの「Code」→「Download ZIP」を選択し、ZIPファイルをダウンロードして展開します。
  • 方法2: リポジトリをクローン

    • 開発やカスタマイズを行いたい場合は、以下のコマンドでクローンします。
git clone https://github.com/kanzaki/RDRAAgent_v0.6.git
cd RDRAAgent_v0.6

npm install は不要です(外部依存関係がないため)。

  • 起動方法 ターミナルで以下のコマンドを実行するとメニューが起動します。
node menu.js

RDRAAgentのメニュー

RDRAAgentによる要件の生成

RDRAAgentによる要件の生成は、大きく以下の流れで進めます。

実行の流れ

  • 初期要望.txt を編集する
    • RDRAAgent_v0.6 フォルダ直下にあるファイルを編集する
  • 要件の生成
    • RDRAAgentのメニューで、1. フェーズ単位実行 または 2. 一括要件定義 を選択する
    • LLMが 初期要望.txt の内容を解析・推論し、RDRAの構成要素として整理されたテキストデータを出力する

「初期要望.txt」を編集する

初期要望.txt」は、ユーザーが作成するRDRAAgentへの入力ファイルです。

デフォルトで以下のようなサンプルが保存されているので、要件定義対象のシステムに合わせて編集してください。

# 訪問介護システム

## 背景
介護業界では、介護会員の要望に合わせ、様々な法規の中でサービススタッフの多様な働き方でスケジュールを調整する必要がある

## 要求
・サービススタッフの柔軟な働き方に対応しかつ介護会員の要望に合わせたスケジュール調整を行える仕組みを持つ

## ビジネスポリシー
・各サービススタッフの要望に合わせたスケジュール管理を行う
・訪問介護事業で小規模事業社を複数持つので、そこを一元管理を行う事業所をもつ
・サービススタッフの働き方は出来るだけ自由に設定できる
・サービススタッフのスキル別に出来る仕事を適切に配分する
・介護会員の要望に合わせたスケジュール調整を行う
・ビジネスパラメータの組合せに柔軟に対応できる業務形態にする

## ビジネスパラメータ
・介護会員とサービススタッフの自由度を保つために介護施設を分類できる
・サービススタッフの自由度を保つために働き方を細かく分類する
・介護会員の状況を細かく分類できる

## 業務概要
・介護会員の管理(名前、連絡先などの様々な属性を管理)
・効率的な訪問介護の計画
・訪問介護の実施記録を管理する
・介護費用の計算と請求及び回収

その他の「初期要望.txt」のサンプルは、Samplesフォルダに格納されていますので、参考にしてください。

要件の生成

RDRAAgentの要件自動生成はフェーズ1〜4に分かれています*1

RDRAAgentのメニューで、1. フェーズ単位実行 または 2. 一括要件定義 を選択します。

  • 1. フェーズ単位実行:実行されていないフェーズを起点として1フェーズのみ実行する
    • 例:フェーズ2まで実行されていたらフェーズ3を実行する
    • フェーズごとにファイル内容を確認・修正し、その後に次のフェーズに進みたい場合に使用する
  • 2. 一括要件定義:実行されていないフェーズから最後のフェーズまでを一括で実行する
    • 例:フェーズ2まで実行されていたらフェーズ3、4を実行する
    • すべてのファイルを一括で作成したい場合に使用する

生成ファイル

RDRAAgentでは、フェーズ1〜4の実行中に、まず0_RDRAZeroOneフォルダ配下に中間成果物のファイルが順次作成されます。フェーズ4まで完了すると、1_RDRAフォルダ配下に最終成果物のファイル群が生成されます。

中間成果物

中間成果物のファイルは、0_RDRAZeroOne フォルダの配下にフェーズごとのサブフォルダ(例: フェーズ1の場合は phase1)が作成され、各フェーズに対応するフォルダへ出力されます。

フェーズ1では以下のファイル群が出力されます。

  • アクター.tsv
  • バリエーション.tsv
  • ビジネスパラメータ.tsv
  • ビジネスポリシー.tsv
  • 初期要望分析.md
  • 外部システム.tsv
  • 情報.tsv
  • 条件.tsv
  • 業務.tsv
  • 状態.tsv
  • 要求.tsv

メニューで 1. フェーズ単位実行 を選択した場合、これらのファイルの内容を確認・修正することで精度を上げてから次のフェーズに進むことができます。

最終成果物

全4フェーズの実行が完了すると、1_RDRA フォルダの配下に以下のファイル群が生成されます。

  • システム概要.json
  • BUC.tsv
  • アクター.tsv
  • バリエーション.tsv
  • 外部システム.tsv
  • 情報.tsv
  • 条件.tsv
  • 状態.tsv
  • 関連データ.txt
  • ZeroOne.txt

これらのファイルが出力されたら、以下のいずれかのメニューを選択して、生成結果を確認します(本記事では「12. Spreadsheetに展開」の手順で進めます)。

  • 11.RDRAGraphを表示:関連データを作成しRDRAGraphを表示
  • 12.Spreadsheetに展開:RDRA定義をクリップボードにコピー

フェーズ単位の実行か一括要件定義か

RDRAAgentの開発者である神崎善司氏によると、LLMの性能が向上してきたことで、人が途中で介在せず一括で実行しても精度の高い結果が得られるようになってきているとのことです。

Modeling Forum 2025(2025年11月26日開催)での神崎善司氏の発表「要件定義の中心にモデルを置きLLMが出力した要件に責任をもつ」では、以下のように述べられていました。

  • RDRAAgentのプロセスは複数のフェーズで構成されているが、各フェーズで人が要件を検証するのは負荷が大きい。
  • そこで、フェーズ1のみ人が内容を確認し、その後は最終フェーズまで一気にAgentに生成させ、RDRA Graphでビジュアルに検証するほうが合理的である。

RDRA定義・分析Sheetへのデータ連携

RDRAAgentで生成したデータは、専用のGoogleスプレッドシート(RDRA定義・分析Sheet)に取り込むことで、RDRAの各要素をシート上で一元的に確認・編集できるようになります。以下の手順に従って連携を行ってください。

RDRA定義・分析Sheetをテンプレートからコピーする

以下の手順で「RDRA定義・分析Sheet」を用意してください。

  • RDRAAgentのメニューで 12. Spreadsheetに展開:RDRA定義をクリップボードにコピー を選択する
  • テンプレートのGoogleスプレッドシート(読み取り専用)がブラウザで自動的に開く
  • 自分のGoogleドライブにスプレッドシートをコピーする(ヘッダーメニューから ファイル > コピーを作成

RDRA定義・分析Sheetをテンプレートからコピーする

クリップボード上のテキストを元に「RDRA定義・分析Sheet」上に要件のデータを生成する

コピーして作成したシートに対して以下の操作を実施します。

  • ZeroOne シートを選択する。
  • A1セルにクリップボードのテキストを貼り付ける。
    • メニューで 12. Spreadsheetに展開:RDRA定義をクリップボードにコピー を選択した時点で、クリップボードにテキストがコピーされている。
  • ZeroOne シートの Import ボタンを押下する。

ZeroOneシートの操作

Importボタン押下後は、いくつかのダイアログが表示されます。下図の手順に従って操作してください(図はmacOS Tahoe 26.2、Chromeの場合)。

「Import」ボタン押下後の遷移

取り込みが完了したら、「BUC」シートなど他のシートを開き、データが生成されていることを確認してください。

データ生成後のBUCシート(例)

「RDRA定義・分析Sheet」の使い方・編集方法については、以下の記事を参照してください。

tracery.jp

RDRAAgentの活用がもたらす価値

RDRAAgentを活用することで、次のような価値が生まれます。

  • 初期立ち上げの圧倒的な高速化
    • これまで一から手作業で要件を拾い集め、整理・入力していた負担が劇的に削減されます。白紙から考え始めるという、最もエネルギーを要するフェーズをAIがショートカットしてくれます。
  • 本質的な作業への注力
    • 入力や作図といった作業時間が減ることで、関係者間での「要件の妥当性検討」「要素間の矛盾の分析」「合意形成」といった、人が本来時間をかけるべき本質的な価値創造の作業に注力できるようになります。
  • RDRAという「型」があるからこそ活きるAI活用
    • RDRAAgentが高精度な推論を行えるのは、RDRAという確固たる構造的フレームワークが存在するからです。出力すべき要素と関係性が明確に定義されているため、LLMは曖昧な推測ではなく、構造に沿った推論を行うことができます。

AIを活用した要件定義で人が担うべき責任

AIの支援は強力ですが、LLMが生成したモデルはあくまで「叩き台」です。AIの出力をそのまま鵜呑みにしてはいけません。

AIの出力を適切に判断するためには、人がRDRAのモデル構造そのものを正しく理解し、「要件とは何か」という本質を把握していることが不可欠です。

AIが提示した要件の整合性や妥当性を検証し、開発の目的や意図と照らし合わせて最終的な意思決定を行うのは、あくまで人間の責任です。

AIとの共創により、要件定義のプロセスは「人が一から定義する作業」から「AIが生成した要件を人が読み解き、判断する作業」へと進化しています。

最後に

本記事では、要件定義の初期立ち上げを支援するツール「RDRAAgent」を紹介しました。

RDRAAgentを活用することで、構造的で精度の高い要件定義をスピーディーに実践できるようになるでしょう。

次回は、定義した要件を仕様化するためのRDRAAgentの機能「RDRASpec」を紹介します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

RDRAの成果物と設計プロセスとの連携

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

本シリーズではここまで、RDRAによる要件定義の進め方を第1フェーズから第3フェーズまで解説してきました。

本記事では、定義したRDRAの成果物が設計プロセスにどのように引き継がれるかを整理します。

具体的には、RDRAの各成果物がクラス設計、データベース設計、画面・API・バッチ処理の設計とどのように対応するかを全体像として示します。

要件定義の目的とゴールは以下のとおりです*1

  • 要件定義の目的:「何を作るか(What)」を決めること
  • 要件定義のゴール:設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること

本記事を通じて、RDRAによる要件定義が、要件定義の目的とゴールの達成に寄与することを確認できます。

RDRAの成果物と設計の関係、全体像

RDRAのスコープ外となる要件定義の成果物

RDRAの成果物と設計の対応関係を整理する前に、まずRDRAのスコープ外となる成果物を確認します。

RDRAがスコープとしない要件定義の成果物*2には、以下があります。

  • 非機能要件一覧
  • システム構成図(システムアーキテクチャ)

RDRAのスコープ外となる要件定義の成果物

RDRAでは「非機能要求」を定義*3しますが、それを「非機能要件」へ整理するプロセスは規定されていません。

そのため、非機能要求を取捨選択し、洗練して非機能要件一覧を別途作成する必要があります。*4

システム構成図」は、主に非機能要件をもとに、システム全体の構造(システムアーキテクチャ)と設計方針を定めたものです。ハードウェアやソフトウェアの主要コンポーネント、それらの相互関係、通信方式、配置などが含まれます。

非機能要件とシステム構成図の作成についてさらに詳しく知りたい場合は、以下の記事を参照してください。

tracery.jp

tracery.jp

RDRAの成果物とクラス設計の関係

クラス設計」は、システムが扱う情報の構造と業務上の振る舞いをクラスとして表現します。

その成果物であるクラス図は、クラスとクラス同士の関係を表したもので、業務領域(ドメイン)の知識を反映していることから、一般的に「ドメインモデル」とも呼ばれます。

RDRAの成果物のうち、クラス設計の中心となるのが「情報モデル」です。情報モデルで定義された情報の構造が、そのままクラスの骨格になります。

さらに、情報モデル以外のRDRAの要素も、クラスの属性やメソッドとして設計に反映されます。

  • 状態モデル → 状態はクラスの属性として、状態を変更する振る舞いはメソッドとして設計する
  • 条件(ビジネスルール) → クラスのメソッド
  • バリエーション → 属性が取り得る値

このように、RDRAの各モデルや要素がクラスの構造に対応するため、要件定義からクラス設計への移行を体系的に進めることができます。

RDRAの成果物とクラス設計の関係

要件定義とクラス設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。

tracery.jp

RDRAの成果物とデータベース設計の関係

データベース設計(ER図、テーブル定義)」は、クラス図を基盤として進めます*5。クラス図で定義されたクラスのうち、永続化が必要なものをテーブルとして設計し、属性やリレーションを具体的なスキーマに落とし込みます。

データベース設計では、性能効率、データ品質、セキュリティ、保守性といった「非機能要件」を十分に考慮する必要があります。その際は「非機能要件一覧」を参照します。

データベース設計はRDRAの成果物から直接導出するものではありませんが、RDRAの情報モデル・状態モデル・バリエーションなどの要件がクラス図を経てスキーマに適切に反映されているかを確認することが重要です。

RDRAの成果物とデータベース設計の関係

要件定義とデータベース設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。

tracery.jp

RDRAの成果物と画面・API・バッチ処理の設計の関係

RDRAでユースケースと関連付けられた画面・イベント・タイマーが、それぞれ以下の設計の対象となります。

  • 画面 → 画面設計
  • イベント → API設計
  • タイマー → バッチ処理設計

これらの設計では、RDRAの「条件」と「バリエーション」を参照し、業務ロジック分岐を仕様に反映します。

また、処理で使用するデータについては、データベース設計で作成した「ER図」や「テーブル定義」を参照します。

さらに、「システム構成図」に記載された技術要素を前提とし、「非機能要件一覧」に定義された性能やセキュリティなどの非機能要件も考慮して設計します。

RDRAの成果物と画面・API・バッチ処理の設計の関係

要件定義と画面設計、API設計、バッチ処理設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。

tracery.jp

tracery.jp

tracery.jp

要件定義とソフトウェアアーキテクチャ設計

ソフトウェアアーキテクチャは、ソフトウェアシステムの全体構造と主要な設計上の決定を体系的に示したものです。

システム構成図」で表現されるシステムアーキテクチャがハードウェア・ネットワークを含むシステム全体の構成を指すのに対し、ソフトウェアアーキテクチャはソフトウェア部分の構造や相互作用を対象にします。

RDRAとソフトウェアアーキテクチャ設計は、直接の対応関係はありません。ただし、RDRAで定義された非機能要求を整理した「非機能要件一覧」を通じて、間接的に関係します。

ソフトウェアアーキテクチャの設計では、「システム構成図」に記載されたフレームワークやミドルウェアを前提とし、「非機能要件一覧」に定義された性能やセキュリティなどの非機能要件も考慮して設計します。

要件定義とソフトウェアアーキテクチャ設計

要件定義とソフトウェアアーキテクチャ設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。

tracery.jp

最後に

本記事では、RDRAの成果物と設計プロセスの対応関係を全体像として示しました。

RDRAで定義した各成果物が、クラス設計、データベース設計、画面・API・バッチ処理の設計へと体系的に引き継がれることで、要件定義のゴールである「設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること」が達成されます。

本シリーズでは、第1フェーズから第3フェーズまでのRDRAによる要件定義の進め方と、本記事での設計との連携を解説してきました。

次回は、RDRAによる要件定義をAIエージェントで支援する「RDRA Agent」を紹介します。

tracery.jp

参考書籍

*1:詳細は、要件定義の目的とゴールとは - TRACERY Lab.(トレラボ)を参照のこと。

*2:本メディアが推奨する要件定義の成果物。なお、システム構成図は「設計」プロセスに含める場合もあるが、本メディアでは、システムの構成要素はシステム要件定義の段階で定義すべきものと考え、要件定義の成果物に含めている。詳細は、要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】 - TRACERY Lab.(トレラボ)を参照のこと。

*3:RDRA定義・分析Sheetの「非機能要求」シートに定義する。詳細は、RDRAによる要件定義の進め方〜第1フェーズ:枠組みを作る - TRACERY Lab.(トレラボ)の「機能要求、非機能要求を記載する」を参照のこと。

*4:要求と要件の違いについては、要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.(トレラボ)を参照のこと。

*5:オブジェクト指向設計を適用する場合。

RDRAによる要件定義の進め方〜第3フェーズ(2):整合性を確認し、精度を高める

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

RDRAは、システムを構成する要素同士の関係(Relationship)を定義することで、システム全体の構造を明確に捉え、可視化できる点が大きな特徴です。

下図は、「RDRA定義・分析Sheet」におけるシート間の関連を示しています。

「RDRA定義・分析Sheet」のシート間の関連

RDRAには、システムを構成する要素同士の関係定義の整合性を自動的にチェックする仕組みが用意されています。

この仕組みにより、定義漏れや参照ミスといった不整合を早期に発見し、要件定義の精度を高めることができます

さらに、ユースケースとアクター、外部システム、情報の関係を一つの表で確認できる仕組みも備えています。

これにより、要素同士の関連を俯瞰しながら、定義内容を体系的に見直すことができます。

本記事では、不整合を検出する仕組みと、要素間の関係を俯瞰する仕組みについて説明します。

不整合を検出する仕組み(「✖不整合」シート)

シート間の関連やシート内の関係定義に不整合がある場合は、「✖不整合」シートに一覧として表示されます(下図)。

「 ✖不整合」シート(全体)

「✖不整合」シートは、大きく次の2種類の不整合検出に分類されます。

  • 参照された名前が定義されていない
  • 定義されているが「BUC」シートで参照されていない

前者では4種類の不整合を、後者では1種類の不整合を検出します(下表)。

参照された名前が定義されていない

区分 不整合内容
他シートで未定義なものをBUCシートで参照しているもの BUCシートから参照しているアクター、外部システム、情報、条件が、定義元のシートに存在しない。
情報シート 情報シートから参照している状態モデル、バリエーション、情報*1が、定義元のシートに存在しない。
状態シート 状態シートから参照しているユースケース、状態*2が、定義元のシートに存在しない。
条件シート 条件シートから参照している状態モデル、バリエーションが、定義元のシートに存在しない。

定義されているが「BUC」シートで参照されていない

区分 不整合内容
定義されているが「BUC」シートで参照されていないもの アクターシート、外部システムシート、情報シート、条件シートに定義されている要素が、BUCシートから参照されていない。

それぞれの区分の詳細については、以下で説明します。

「参照された名前が定義されていない」不整合

BUCシート、情報シート、状態シート、条件シートから参照している要素が、定義元のシートに存在しない場合に検出します。

以下では、4つの不整合チェックについて説明します。

他シートで未定義なものをBUCシートで参照しているもの

BUC」シートでは、ユースケースや業務フローの「アクティビティ」に関連する要素として、他シートに定義されている要素名を参照します*3

ここで参照した要素名が、該当するシートに定義されていない場合の不整合を検出します。対象となるシートは以下のとおりです。

  • アクター」シート
  • 外部システム」シート
  • 情報」シート
  • 条件」シート

他シートで未定義なものをBUCシートで参照しているもの

情報シート

情報」シートでは、情報要素同士の関連に加え、状態遷移モデルやバリエーションとの関連も定義します。

  • 情報要素同士の関連(「情報」シート内の参照)
  • 情報の遷移を表す状態遷移モデルへの参照(「状態」シートへの参照)
  • 情報の分類を示すバリエーションへの参照(「バリエーション」シートへの参照)

これらの参照先として指定した要素名が、定義元のシートに存在しない場合に不整合を検出します。

「✖不整合」シートの「情報シート」部分

状態シート

状態」シートでは、要素同士の関連として、以下の内容を定義します。

  • 状態から遷移先の状態への関連(「状態」シート内の参照)
  • 状態遷移に関わるユースケースへの参照(「BUC」シートへの参照)

「✖不整合」シートの「状態シート」の部分

条件シート

条件」シートでは、ビジネスルールに基づく判定に用いる判定軸として、次の要素との関連を定義します。

  • バリエーション(「バリエーション」シートへの参照)
  • 状態モデル(「状態」シートへの参照)

「✖不整合」シートの「条件シート」の部分

「参照された名前が定義されていない」不整合の解消方法

「他シートで未定義なものをBUCシートで参照しているもの」、「情報シート」、「状態シート」、「条件シート」の不整合は以下の方法で解消します。

  • 不整合を検出したシート(BUC、情報、状態、条件のいずれか)で参照している要素名が、定義元のシートに存在するかを確認し、原因に応じて修正する
    • 不整合を検出したシートで参照している要素名が誤っている場合 → 不整合を検出したシートを修正する
    • 定義元のシートに要素が定義されていない場合(または定義元シートの要素名が誤っている場合) → 定義元のシートを修正する

定義されているが、参照されていない

既に説明した他の4つの区分とは性質が異なり、定義した要素が実際のユースケースの中で使用されているかを確認するチェックです。

定義された要素が他のシートから参照されていない場合、その要素はシステムのユースケースや業務の中で使用されておらず、システムに関係のない不要な定義である可能性があります。

「定義されているがBUCシートで参照されていない」不整合

BUC」シートでは、アクター、外部システム、情報、条件などを定義する各シート(定義元シート)で定義された要素名を参照します。

この不整合チェックでは、定義元シートで定義されているにもかかわらず、BUCシートから参照されていない要素を検出します。

これにより、次のような内容を確認できます。

  • システムで使用されないアクター、外部システム、情報、条件が定義されている
  • 業務やユースケースの洗い出しが十分に行われていない

「✖不整合」シートの「定義されているが「BUC」シートで参照されていないもの」の部分

「定義されているが「BUC」シートで参照されていない」不整合の解消

「定義されているが「BUC」シートで参照されていない」場合の不整合は以下の方法で解消します。

  • 定義元シートで定義されている要素名に該当する要素が、「BUC」シートで使用されているかを確認する(参照名称の不一致の確認)
    • 「BUC」シートの参照名が誤っている場合は、「BUC」シートを修正する
    • 定義元シートの要素名が誤っている場合は、定義元シートの要素名を修正する
  • 定義元シートで定義されている要素名が、「BUC」シートで使用されていない場合(参照名称の不一致ではない場合)
    • 「BUC」シートで参照する必要がある場合は、参照を追加する
    • 「BUC」シートで参照する必要がない場合は、定義元シートの定義を削除する

要素間の関係を俯瞰する仕組み(「UC_PIVOT」シート)

「✖不整合」シートの不整合を解消したら、「UC_PIVOT」シート(下図)を参照し、ユースケースを軸に定義全体を俯瞰しながら、定義全体の妥当性を確認します。

「UC_PIVOT」シート

「UC_PIVOT」シートは、ユースケースと各要素の関係を、横軸と縦軸の2つの視点で確認します。

横軸は、ユースケースおよびビジネスユースケース単位での確認です。どのようなアクターや外部システムが関係し、どのような情報を扱うかを把握できます。

縦軸は、アクター、外部システム、情報などの各要素を軸に、どのユースケースやビジネスユースケースと関係しているかを確認します。

例えば、上記のピボットテーブルでは、アクターの「会員」を軸に見ると、「貸出期限を確認する」「予約図書を取り置く」「貸出(ビジネスユースケース)」と関係していることが分かります。

ユースケースの欄が空白の場合は、該当のアクターが業務フローの中でシステムのユースケースとは関係せず、アクティビティのみと関係していることを示しています。

最後に

RDRAでは、システムを構成する要素同士の関係を定義することで、システム全体の構造を明確に捉えます。しかし、要素同士の関係が増えるほど、定義漏れや参照ミスといった不整合が発生しやすくなります。

本記事で紹介した「✖不整合」シートは、そうした不整合を自動的に検出し、修正すべき箇所を明確にするための仕組みです。これにより、要素間の参照関係の誤りや、定義された要素が実際のユースケースで使用されていないといった問題を早期に発見できます。

また、「UC_PIVOT」シートを利用することで、ユースケースを軸に、アクター・外部システム・情報などの要素との関係を俯瞰的に確認できます。これにより、個々の定義だけでは見えにくい関係の偏りや抜け漏れを把握し、定義全体の妥当性を見直すことができます。

このように、不整合の検出と全体俯瞰の仕組みを組み合わせることで、RDRAでは要件定義の整合性と網羅性を高めることができます。

シリーズのここまでで、RDRAによる要件定義の進め方の各フェーズを説明しました。

次回の記事では、RDRAで作成した成果物が設計プロセスとどのようにつながるのかを解説します。

tracery.jp

参考書籍

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

RDRAによる要件定義の進め方〜第3フェーズ(1):システムレイヤーの要素同士を関連付ける

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

RDRAの要件定義は、思考を段階的に深めていくために、3つのフェーズに分けて進めます。

第1フェーズでは、RDRAモデルの枠組みとなる要素を定義します。

第2フェーズでは、「システム要件定義」に該当するシステム境界レイヤーおよびシステムレイヤーを中心に具体化します。

第3フェーズでは、システムレイヤーの要素同士を関連付け、要素間の関係を確定させます。そのうえで、定義内容全体に抜けや矛盾がないかを横断的に検証します(下図)

第3フェーズの進め方の概要

第3フェーズまで終了することで、要件の「仕様化」が可能になります*1

要件の「仕様化」とは、要件を具体的な仕様へと落とし込むことです。

仕様とは、要件定義で抽出された開発品目について、開発者が実装をイメージできるレベルまで、インターフェース仕様や処理ロジックを明確にしたものを指します。

たとえば、要件定義で「会員登録」画面という開発品目が抽出された場合には、「会員登録」画面の具体的なレイアウト、画面項目の配置、各項目の振る舞いを定義します。

この記事では、第3フェーズのうち「システムレイヤーの要素同士の関連付け」の具体的な進め方を説明します。

バリエーションを洗い出す

バリエーションとは、ビジネス上あらかじめ定義された区分を持ち、対象をどの観点で分類するかを定めるモデル要素です。

たとえば「会員種別」は、会員をどの種類に分けて扱うかを示す分類の軸です。

そして、「大人」「子供」といった具体的な区分が、その分類の軸に属するバリエーションの値です。

バリエーションが表すのは、名称による種別だけではありません。ビジネスルールの詳細条件を示す区分も、バリエーションに含まれます。

たとえば、遅延日数に応じて取扱いを分ける場合には、遅延日数が3日未満、7日未満、7日以上といった数値条件による区分を定義します。

バリエーションと状態の違い

RDRAでは、「バリエーション」と「状態」を明確に区別します。両者は似ているように見えますが、モデル上の役割が異なります。

状態とは、対象が時間の経過や業務プロセスの進行に伴って取り得る状況を指します。会員であれば、「仮登録」「登録済」「退会」などが状態です。

状態は業務の流れの中で変化し、遷移という振る舞いを持ちます

一方、バリエーションは分類の概念です。対象の種類の違いや、ビジネスルールの詳細条件を表します。

分類の軸(バリエーション)と、時間変化の軸(状態)を明確に区別することで、業務理解を安定させ、設計の精度を高める前提になります。

バリエーションの定義

バリエーションは、「バリエーション」シートに記載します(下図)。

バリエーションを洗い出す

バリエーションが持つ複数の値は、「」列に「、」区切りで記載します。

情報の精度を上げる

情報とは、システムが扱う概念的なデータとその関係のことです。

情報を、バリエーションや状態モデルと関連付けることで、その情報がどのような区分を取り得るのか、またどのように変化していくのかを明確にできます。

結果として、データ定義とビジネスルールの対応関係が明確になります。

情報とバリエーションを関連付ける

情報が取り得るバリエーションを、「情報」シートの「バリエーション」列に記載します(下図)。

情報とバリエーションを関連付ける(RDRA定義・分析シート)

上記のシートでは、「会員」という情報が「会員種別」というバリエーション(大人、子供)を取り得ることを明示しています。

RDRA Graphで確認すると、「会員」という情報と「会員種別」というバリエーションが関連付けられていることが可視化できます(下図)。

情報とバリエーションを関連付ける

情報と状態モデルを関連付ける

情報が取り得る状態を定義した状態モデルが存在する場合は、その名称を「情報」シートの「状態モデル」列に記載します。

記載することで、その情報がどのような状態遷移を持つのかが明示されます。

情報と状態モデルを関連付ける(RDRA定義・分析シート)

RDRA Graphで確認すると、「蔵書」という情報が「蔵書の状態」という状態モデルと関連付けられていることがわかります(下図)。

情報と状態モデルを関連付ける

条件の精度を上げる

「条件」とは、業務上またはシステム上で適用されるビジネスルールを指します。

条件と関連要素との対応関係を明確にすることで、どの要素がどの条件によって規定されるのかが整理され、ビジネスルールの解釈の揺れを防ぎ、定義の精度を高めることができます。

条件とバリエーションを関連付ける

ビジネスルールに基づいて結果を判定する際に、その判定の軸となるバリエーションを「条件」シートの「バリエーション」列に記載します(下図)。

条件とバリエーションを関連付ける(RDRA定義・分析シート)

上記のシートでは、「会員種別」と「遅延日数」をバリエーションとして記載しています。これは、ビジネスルールの結果が、これら二つの分類軸の組み合わせによって決まることを示しています。

この場合、縦軸を「会員種別」、横軸を「遅延日数」として整理すると、下表のような構造になります。

各マスは、バリエーションの組み合わせごとに適用されるビジネスルールの結果を表しています。

会員種別\遅延日数 3日未満 7日未満 7日以上
大人 制限なし 1冊制限 貸出不可
子供 制限なし 貸出不可 貸出不可

このようにバリエーションを明示することで、ビジネスルールを構造として捉えることができ、条件の抜け漏れや重複を検証しやすくなります。

RDRA Graphで確認すると、「貸出制限」という条件が「遅延日数」と「会員種別」というバリエーションと関連付けられていることがわかります(下図)。

条件とバリエーションを関連付ける

条件と状態モデルを関連付ける

ビジネスルールに基づいて結果を判定する際に、その判定の軸となる状態モデルを「条件」シートの「状態モデル」列に記載します(下図)。

条件と状態モデルを関連付ける(RDRA定義・分析シート)

上記のシートでは、「蔵書の状態」を状態モデルとして記載しています。

これは、ビジネスルール「貸出予約一覧出力条件」の結果が、「蔵書の状態」によって決まることを示しています。

RDRA Graphで確認すると、「貸出予約一覧出力条件」という条件が「蔵書の状態」という状態モデルと関連付けられていることがわかります(下図)。

条件と状態モデルを関連付ける

最後に

第3フェーズとして、システムレイヤーの要素同士の関連付けを説明しました。

バリエーション、状態、情報、条件を結び付けることで、「どの情報にどの分類軸が適用されるのか」「情報がどの状態遷移を持つのか」などが構造として明らかになります。

この関連付けにより、開発対象となるシステムモデルの網羅性が高まります。

RDRAの要件定義は、要素同士の関係を設計し、構造として意味を持たせることが重要です。

システムレイヤーまで関連付けが完了したモデルは、静的な構造(情報、状態、条件、要素同士の関連等)と動的な振る舞い(状態遷移、条件による分岐)の整合が取れた状態となるため、解釈のずれを生むことなく、そのまま仕様へと展開できる設計基盤となります。

次回は、第3フェーズの後半として、モデル全体を見直し、矛盾を解消して整合性を高める取り組みについて説明します。

tracery.jp

参考書籍

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:参考書籍のRDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確にでは、フェーズ3は、プロジェクトの状況や後続プロセスによっては、必ずしも実施する必要がない旨が記載されている。

RDRAによる要件定義の進め方〜第2フェーズ:要件を組み立てる

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

RDRAによる要件定義は、業務からシステムへと段階的に構造を組み立て、最後に全体を統合的に検証するプロセスとして設計されています。

要件定義は主に次の3つのフェーズに分けて進めます。

  • 第1フェーズ:枠組みを作る(議論の土台づくり)
  • 第2フェーズ:要件を組み立てる
  • 第3フェーズ:整合性・網羅性を確認し、精度を高める(要件定義の仕上げと仕様化の準備)

前回のRDRAによる要件定義の進め方〜第1フェーズ:枠組みを作るでは、第1フェーズの進め方について説明しました。

第2フェーズは、開発対象システムの中心部分を定義する重要なフェーズであり、3つのフェーズの中でも最も時間をかけて取り組むべき段階です(参考書籍の『RDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確に』では、要件定義全体の約60%を充てることが推奨されています)。

この記事では、第2フェーズの進め方について解説します。

第2フェーズの進め方の概要と目的

第2フェーズでは、「システム要件定義」に該当するシステム境界レイヤーおよびシステムレイヤーを中心に具体化します。

画面やイベントなどユースケースを構成する要素に加え、情報・状態・条件といった要素を関係性に基づいて整理することで、システムの振る舞いと構造を明確に定義します。

第2フェーズで定義する主な要素およびモデルは、以下のとおりです(下図)。

  • システム境界レイヤー
    • 画面
    • イベント
    • 情報(システムレイヤーの参照)
    • 条件(システムレイヤーの参照)
    • タイマー
  • システムレイヤー
    • 情報(情報モデルの洗練)
    • 状態(状態モデルの洗練)
    • 条件

第2フェーズの進め方の概要

また、第2フェーズでは、主に以下の2つのアプローチで進めます(上図)。

  • トップダウンで要件を組み立てる
    • システム境界レイヤーからシステムレイヤーへと展開し、ユースケースを段階的に詳細化します。
  • ボトムアップで詳細を見直す
    • システムレイヤーの定義を具体化したうえで、システム境界レイヤーへと遡って整合性を確認し、開発対象システムの挙動を明確にします。

トップダウンで要件を組み立てる

ユースケースを起点とし、その実行に直接関与する要素を関連付けて明示します。

具体的には、画面、イベント、タイマーに加え、関与するアクターや外部システムをユースケースに関連付けます

これにより、ユースケースがどの契機で開始され、誰が関与し、どのインターフェースを通じて実行されるのかが一貫した構造として表現されます。

ユースケースに関連付ける各要素の説明を下表に示します。

要素 説明
画面 UI(画面や帳票等)
イベント 外部のシステムやアクターとのインターフェース。
タイマー ビジネス上の締切(例:月末締、定時実施)。
アクター システムを利用する人や組織の役割。
外部システム 連携が必要な既存システムや外部サービス。

画面、イベント、タイマーを定義し、ユースケースに関連付ける

ユースケースのインターフェースとなる画面やイベント、ならびに実行タイミングを規定するタイマーを、「BUC」シートの「関連モデル1」および「関連オブジェクト」列に記載します*1

これにより、ユースケースがどの要素を契機として開始されるのかが構造として表現されます(下図参照)。

画面、イベント、タイマーを定義し、ユースケースに関連付ける(RDRA定義・分析シート)

RDRA Graphで参照すると、ユースケースに画面およびイベントが関連付けられていることを確認できます(下図)。

画面、イベント、タイマーを定義し、ユースケースに関連付ける

アクター、外部システムを関連付ける

画面にはアクターを、イベントには外部システムまたはアクターを関連付けます。これらの関係は、「BUC」シートの「関連モデル2」および「関連オブジェクト2」列に記載します。

これにより、インターフェースを介して誰がどのように関与するのかが構造的に明示されます。

アクター、外部システムを関連付ける(RDRA定義・分析シート)

RDRA Graphで参照すると、ユースケースとアクターおよび外部システムとの関係が関連付けられていることを確認できます(下図)。

アクター、外部システムを関連付ける

BUC」シートでユースケースを定義していないアクティビティ(システムを使用しないアクティビティ)に対して「関連モデル2」および「関連オブジェクト2」を定義した場合、それらは当該アクティビティに関連付けられます(下図)。

アクティビティとアクターの関連付け

ボトムアップで詳細を見直す

システムレイヤーを詳細化し、境界レイヤーとの整合性を検証します。(システムレイヤー→システム境界レイヤーのボトムアップ)。

システムレイヤーにおける情報・条件・状態を具体的に定義し、それらをユースケースに明示的に関連付けることで、ユースケースの処理内容が構造として明確になります。

さらに、システム境界レイヤーとシステムレイヤーが関係性に基づいて整理されることで、要件間の整合性が担保され、要件定義全体の精度とトレーサビリティが向上します。

情報の定義

情報を構造化し、設計する

情報」シートを用いて情報要素を整理し、情報間の構造を明確にします。「関連」列では情報同士の関係を定義し、あわせて想定される属性も具体化します。

RDRA Graphで参照することで、情報間の関係構造を可視化できます。

この構造を基に、概念データモデルを整理し、基本設計プロセスにおけるデータベース設計へと自然に展開できます。

情報シートを整備、情報を構造化する

情報をユースケースに関連付ける

BUC」シートの「関連モデル1」および「関連オブジェクト」列に、「情報」シートで定義した情報名を記載することで、ユースケースと情報を明示的に関連付けます。

これにより、各ユースケースがどの情報と関連しているのかを、構造として表現できます。

情報をユースケースに関連づける(RDRA定義・分析シート)

RDRA Graphで参照すると、ユースケースと情報が関連付けられていることを確認できます(下図)。

情報をユースケースに関連づける

条件の定義

条件とは、業務上またはシステム上で適用されるビジネスルールや制約を指します。

これは、ユースケースの実行可否や処理分岐を規定する要素です。

第2フェーズでは、条件を体系的に抽出し、該当するユースケースに明示的に関連付けます

これにより、ユースケースの分岐・制約が構造として整理されます。

条件の抽出

条件を抽出し、「条件」シートに整理して記載します(下図)。

条件を抽出する

ここでは条件の詳細化よりも、必要となるビジネスルールの網羅的な抽出に重点を置きます。

条件の具体的な定義や精緻化は、第3フェーズで実施します。

条件をユースケースに関連付ける

抽出した条件を「BUC」シートの「関連モデル1」および「関連オブジェクト」列に記載します(下図)。

条件をユースケースに関連づける(RDRA定義・分析シート)

「BUC」シートに記載した条件とユースケースの関係をRDRA Graphで参照すると、下図のように両者の関連構造が可視化されます。

これにより、各ユースケースに適用される条件の抜け漏れや整合性を俯瞰的に確認できます。

条件をユースケースに関連づける

状態の定義

第2フェーズでは「状態」シートを第1フェーズの内容からさらに詳細化し、定義の精度を高めます。

状態をさらに洗い出すとともに、状態遷移の契機となるユースケースを「遷移UC」列に記載し、その遷移結果となる状態を「遷移先状態」列に記載します(下図)。

状態定義とユースケースの関連付け(RDRA定義・分析シート)

状態」シートに記載した内容をRDRA Graphで参照すると、状態とユースケースとの関係および状態遷移の構造が、下図のように可視化されます。

これにより、状態遷移の整合性や、遷移に関係するユースケースとの関連を俯瞰的に確認できます。

状態定義とユースケースの関連付け

最後に:第2フェーズの成果物の全体像

第2フェーズの成果物の全体像を下図に示しました。

第2フェーズの成果物の全体像

第1フェーズでは、企画プロセスで検討された内容を前提に、「要求の確認」と「業務要件定義」を主に進め、システム全体の枠組みができあがります。

第2フェーズでは、第1フェーズで構築した枠組みに基づき、「システム要件定義」を具体化します。これは、RDRAにおけるシステム境界レイヤーおよびシステムレイヤーを詳細化するプロセスに相当します。

ユースケースを起点に、画面、イベント、タイマー、情報、状態、条件といった要素を整理し、それぞれを相互に関連付けていきます。これにより、業務の流れとシステム内部の振る舞いが一本の構造として結び付けられ、開発対象となるシステムの全体像が把握しやすくなります。

第3フェーズでは、システムレイヤーをさらに詳細化するとともに、全体の整合性・網羅性を検証し、要素間の矛盾や抜け漏れを確認し、仕様化に耐えうる精度へと引き上げます。

次回は、第3フェーズの具体的な進め方について解説します。

tracery.jp

参考書籍

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:シート記載上の注意:「BUC」シート内で同一のユースケースを複数行にわたって記載する場合、2回目以降の行では、「関連モデル1」および「関連オブジェクト」列は空白とします(例:上図のUC列「蔵書の貸出を登録する」)。

RDRAによる要件定義の進め方〜第1フェーズ:枠組みを作る

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

RDRAによる要件定義は、要件を個別に整理するのではなく、まず全体の構造を明らかにし、その上で要素同士の関係性を定義しながら段階的に具体化していく点に特徴があります。

そのため、要件定義は主に次の3つのフェーズに分けて進めます。

  • 第1フェーズ:枠組みを作る(議論の土台作り)
  • 第2フェーズ:要件を組み立てる
  • 第3フェーズ:整合性・網羅性を確認し、精度を高める(要件定義の仕上げと仕様化の準備)

なかでも第1フェーズは、後続フェーズで扱う要件の方向性やスコープを定める重要な段階です。

ここで認識のずれや抜け漏れがあると、以降の要件定義全体に影響を及ぼします。

本記事では、この第1フェーズに焦点を当て、RDRAを用いて枠組みをどのように構築していくのかを具体的に説明します。

第1フェーズの進め方の概要と目的

第1フェーズでは、RDRAモデルの枠組みとなる要素を定義します。

  • システム価値レイヤー
    • 機能要求、非機能要求
    • アクター
    • 外部システム
  • システム外部環境レイヤー
    • 業務
    • ビジネスユースケース(BUC)
    • アクティビティ
  • システム境界レイヤー
    • ユースケース(UC)
  • システムレイヤー
    • 情報
    • 状態

第1フェーズの進め方の概要

定義は、システム価値レイヤーから始め、システム外部環境レイヤー、システム境界レイヤー、システムレイヤーの順に、左から右へ進めます。

第1フェーズの目的は議論の土台を作ること

第1フェーズの目的は、システム化対象となる業務全体とシステム化の範囲を早期に可視化し、関係者間で共通認識を形成するための「議論の土台」を整えることです。

そのため、このフェーズでは詳細な正確さには踏み込まず、後続フェーズでの精緻化を前提として、対象となる要素を漏れなく洗い出すことを重視します。

参考書籍『RDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確に』では、第1フェーズは時間をかけすぎず、スピーディーに要素を洗い出すことを重視すると述べられています。そのため、以下のような目安で時間を配分することが推奨されています(下表)。

フェーズ 内容 時間の割合 1か月(20日)の場合
1 枠組みを作る 10% 2日
2 要件を組み立てる 60% 12日
3 整合性・網羅性を確認し精度を上げる 30% 6日

システム価値レイヤーを定義する

第1フェーズでは、システム価値レイヤーを構成するすべての要素(機能要求、非機能要求、アクター、外部システム)を対象とします。

これら、システムが「何の価値を提供するのか」を表す要素を最初に明らかにすることで、以降の要件定義を進めるための明確な起点を定めます。

システム価値レイヤーを定義する

機能要求、非機能要求を記載する

要件定義の開始時点で、すでに明らかになっている機能要求および非機能要求を、「機能要求」シートと「非機能要求」シートに記載します。

これら2つのシートに記載された内容は、他のRDRAシートとは関係付けられず、RDRA Graphにも反映されません。

本シートの目的は、要件定義を進める過程において、開発にあたり前提となっている大きな要求を立ち戻って確認できるようにすることです。

具体的な機能要求は、RDRAの他のシート(例:「BUC」シートにおけるユースケースや画面)として定義されるため、本シートには詳細な要求は記載しません。

そのため、システムが目指すべき方向性を示す観点から、特に重要な要求のみに絞って記載します。

機能要求、非機能要求をリストアップする

上図の「機能要求」シート、「非機能要求」シートの「アクター」には、ヒアリングなどで要求を出したアクターの名前を記載します。

アクターをリストアップする

システムに関わる人の役割(アクター)を「アクター」シートに定義します。

アクターをリストアップすることで、後続の定義において、業務やアクティビティについて、誰の役割として行われるものか、システムで支援すべき作業か、どの立場の利用を想定したユースケースかを判断できるようになります。

アクターをリストアップする

外部システムをリストアップする

関係する外部システムを「外部システム」シートに記載します。

第1フェーズでは詳細なインターフェース設計には踏み込まず、社内の他システムや外部サービスとの連携有無と関係性を整理します。

これにより、どの機能を自システムで担い、どの機能を外部システムに委ねるのかを判断できるようになり、後続のユースケース定義や外部インターフェースの検討を円滑に進められるようになります。

外部システムをリストアップする

システム外部環境レイヤーを定義する

第1フェーズでは、システム外部環境レイヤーを構成するすべての要素(業務、ビジネスユースケース、アクティビティ)を対象とします。

ただし、第1フェーズの目的は、システムの全体像を明らかにし、関係者間で共通認識を形成するための「議論の土台」を整えることにあるため、すべての要素を正確に洗い出す必要はありません。

業務やビジネスユースケースを洗い出すことで、システム化対象のスコープがおおよそ把握できれば、このフェーズの目的は達成できます。

システム外部環境レイヤーを定義する

業務、ビジネスユースケースを洗い出す

システム化の対象となる「業務」と、その業務を構成する「ビジネスユースケース」を、「BUC」シートの「業務」列と「BUC」列に定義します(下図)。

BUC」シートは、RDRAによる要件定義のコアとなるシートです。

業務、ビジネスユースケースを洗い出す

ここでいう1つの「業務」とは、部署や課やチームなどの組織単位で担われる業務のまとまりを指します。

ビジネスユースケース(BUC)は業務フローを表す単位であり、1つのビジネスユースケースは1つの業務フローに対応します。

アクティビティを洗い出す

ビジネスユースケース(1つの業務フロー)を構成する「アクティビティ」を洗い出し、「BUC」シートの「アクティビティ」列に記載します(下図)。

アクティビティとは、業務フローの中で実行される個々の作業や行動を指します。

アクティビティを洗い出すことで、1つのビジネスユースケースが、業務フローを一連の目的を持った流れとして過不足なく表しているかを確認できます。

その結果、ビジネスユースケースが大きすぎる場合は分割し、細かすぎる場合は統合することで、後続フェーズに進むための粒度を揃えられます。

アクティビティを洗い出す

システム境界レイヤーを定義する

第1フェーズでは、システム境界レイヤーの要素として、ユースケース(UC)を対象とします。

ユースケースを洗い出すことで、どの業務をシステムでサポートするのかが明らかになり、システム化の範囲を可視化できます。

システム境界レイヤーを定義する

ユースケースのリストアップ

業務フローを構成するアクティビティのうち、システムを使用するアクティビティに対してユースケースを定義し、「BUC」シートの「UC」列に記載します(下図)。

「アクティビティ」列の右隣にユースケースを記載することで、当該アクティビティに対応するユースケースであると定義されます。

ユースケースのリストアップ

システムレイヤーを定義する

第1フェーズでは、システムレイヤーの要素として、情報および状態を対象とします。

「情報」とは、システムが扱う概念的なデータおよびそれらの関係を指します。

「状態」とは、業務上管理すべき情報が取り得る状態*1を指します。

ここでは、業務、ビジネスユースケース、業務フロー(アクティビティ)、ユースケースを洗い出す過程で現れた概念を、「情報」や「状態」として整理し、一覧化します。

詳細な構造や厳密な定義には踏み込まず、まずはシステムで扱う対象を把握することを重視します。

これにより、システムがどのようなデータを扱うのかという観点からシステムの輪郭が明確になります

また、業務は状態の変化を前提に進むため、状態を整理することで、業務とシステムの関係性を捉えられるようになります。

システムレイヤーを定義する

情報のリストアップ

システムで扱うデータを「情報」シートに記載します(下図)。

シート内の「コンテキスト」とは、同じ役割を持つ情報、状態、条件、バリエーションをまとめる単位です。

システムの特定領域(ドメイン)におけるシステムレイヤーの要素を整理し、まとめて管理するために利用します。ドメイン駆動設計における「区切られた文脈(Bounded Context)」を想定すると、設計プロセスへつなげやすくなります。*2

情報のリストアップ

状態のリストアップ

状態を、「状態」シートに記載します(下図)。

状態のリストアップ

最後に:第1フェーズの成果物の全体像

第1フェーズの成果物の全体像を下図に示しました。

第1フェーズの成果物の全体像

第1フェーズでは、企画プロセスで検討された内容を前提に、「要求の確認」と「業務要件定義」を重点的に進めます。

これは、RDRAにおけるシステム価値レイヤーおよびシステム外部環境レイヤーに相当します。

また、業務要件定義からシステム要件定義へとつなぐために、システム境界レイヤーとしてユースケースを抽出し、あわせて情報状態を洗い出すことで、システム全体の輪郭を明らかにしました。

これらの作業を通じて、要件定義全体の前提となる「枠組み」が定まります。第1フェーズで行っているのは要件を細かく詰めることではなく、システムの価値、業務の全体像、システム化の範囲を構造として整理し、関係者間で共有可能な状態を作ることです。

この段階では、正確さや完成度よりも、後続フェーズで議論を進めるための共通の前提を揃えることを重視します。

第1フェーズで認識のずれやスコープの誤りを残したまま進むと、第2フェーズ以降で要件を精緻化しても、手戻りや判断の迷いが生じやすくなります。

続く第2フェーズでは、第1フェーズで整えた枠組みを前提として、「システム要件定義」を中心に要件を具体化していきます。

具体的には、次のような作業を通じて、要件同士の関係性を明確にしていきます。

  • ユースケースの詳細化(画面、イベント、情報、条件、タイマーの抽出とユースケースへの関連付け)
  • システムレイヤーの詳細化(情報、状態、条件、バリエーションの定義)
  • アクターと画面の関連付け(どのUIからアクターが操作するかを定義する)
  • 外部システムとイベントの関連付け(外部システムと外部インターフェースの関連付け)

次回は、第2フェーズの進め方を説明します。

tracery.jp

参考書籍

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

要件定義手法RDRAの概要と全体像

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーの haru です。

要件定義は、システム開発の成否を左右する重要なプロセスです。しかし実務では、一定のフォーマットや手順に沿って整理していても、要件同士の関係性が十分に可視化されなかったり、関係者ごとに解釈がずれたり、設計段階で手戻りが発生したりと、多くの課題が生じがちです。

筆者は2020年から実プロジェクトで RDRA を活用してきました。いまでは、RDRAを使う前にどのように要件定義を進めていたのか思い出せないほど、日々の実務に深く根付き、なくてはならない手法になっています。要件の整理・構造化・合意形成が自然に進み、要件定義の質とスピードは大きく向上しました。

RDRA(ラドラ)(Relationship Driven Requirement Analysis)は、要件同士の関係性を構造的に整理し、ビジネスとシステムを一体として可視化するための要件定義手法です。関係者間で共通の前提と構造を共有しながら要件を具体化できるため、認識齟齬や手戻りの少ない開発を実現できます。

本記事では、RDRAの基本的な考え方から、V字モデルにおける位置付け、4つのレイヤー構造、さらに実務を支える各種ツールまで、RDRAの全体像を体系的に解説します。

RDRAの概要

RDRAは「Relationship Driven Requirement Analysis」の略で、株式会社バリューソースの神崎善司氏が提唱する要件定義手法です。

システムを構成する要素同士の関係(Relationship)を定義することで、システム全体の構造を明確に捉え、可視化することができます。

要件を構造的に捉えることの価値

要件を構造的に捉えることの価値は、要件を個々の点としてではなく、「関係性によって意味づけられた全体構造」として整理できる点にあります。

RDRAでは、要素同士の関係を起点に要件を定義するため、個々の機能やルールがどの要素と結び付いているのかを明確にしながら、要件を積み上げていくことができます。

その結果、要件の抜け漏れや重複、矛盾といった問題を要件定義の早い段階で発見しやすくなり、「なぜこの要件が必要なのか」「この要件がなくなると何が困るのか」といった説明も、論理的に行えるようになります。

これは、後工程での手戻りや、完成後に「使われないシステム」になるリスクを下げることに直結します。

さらに、変更や追加が発生した場合でも、関係性をたどることで影響範囲を把握できるため、感覚や経験に頼らない判断が可能になります。

その結果、開発者・業務担当者・意思決定者の間で共通の理解を持ちながら議論でき、要件定義における合意形成を安定して進められます。

システム開発全体(V字モデル)での位置づけ

RDRAは要件定義の手法であり、主にV字モデルにおける要件定義(業務要件定義、システム要件定義)に位置付けられます(下図)。

RDRAのシステム開発全体(V字モデル)での位置づけ

RDRAでは、企画プロセスで整理された事業の背景や狙い、要求を入力として受け取り、「システム価値レイヤー」で定義します。

業務要件定義の内容は、「システム外部環境レイヤー」、システム要件定義の内容は、「システム境界レイヤー」「システムレイヤー」の二つで定義します。

RDRAのレイヤーについては、後述します。

また、RDRAの成果物は、要件を関係性を含んだ構造として表現しているため、要件定義の後プロセスである基本設計に対しても、「なぜその機能が必要なのか」という意図を保ったまま情報を引き渡すことができます。

その結果、要件定義と設計の間で起こりがちな解釈のズレや属人化を防ぎ、V字モデル全体を通した一貫性のある開発を支える役割を果たします。

RDRAの全体像

RDRAの全体像を下図に示します。

RDRAの全体像

RDRAは4つのレイヤーで構成されます。以降では、各レイヤーの役割と、それぞれを構成する要素やモデルについて説明します。

システム価値レイヤー

システムが実現すべき価値に着目します。「このシステムは誰にとって、どのような価値を提供するか」を明らかにします。

要素 説明
要求 機能要求、非機能要求。システムで何を実現するか。
アクター システムを利用する人や組織の役割。
外部システム 連携が必要な既存システムや外部サービス。

システムレイヤーの要素を取りまとめるためのモデルには、以下のようなものがあります。

モデル 説明
アクター群 同じ役割をもつアクターをまとめる。 業務・BUCとの関わりを、俯瞰的な視点で見ることができる。
外部システム群 同じ役割をもつ外部システムをまとめる。業務・BUCとの関わりなど、俯瞰的な視点で見ることができる。

システム外部環境レイヤー

システムがどのように使われるかを表します。「誰が何の業務を行い、その結果どんな価値を提供するか」を業務フローとして示します。

要素 説明
業務 ビジネスの最上位のまとまり。例:販売管理や在庫管理など。
ビジネスユースケース(BUC) 業務フローの単位。
アクティビティ 人やシステムが行う仕事の単位。

システム境界レイヤー

ユーザーや他の外部システムがシステムとどう関わるかを示します。システムとのインターフェースを明確にします。

要素 説明
ユースケース(UC) システムが提供する具体的な機能単位。
画面 UI(画面や帳票等)
イベント 外部のシステムやアクターとのインターフェース。
タイマー ビジネス上の締切(例:月末締、定時実施)で実行される処理。
情報 ユースケースから参照する。システムレイヤーの節を参照のこと
条件 ユースケースから参照する。システムレイヤーの節を参照のこと

システムレイヤー

システム内部を表現します。

要素 説明
情報 システムが扱う概念的なデータとその関係。
状態 業務上管理すべき対象のとりえる状態(「注文」の状態の例:「受注済」、「出荷準備中」など)。
条件 業務上またはシステム上のビジネスルール。
バリエーション ビジネス上認識している区分や種別。「会員ステータス」の例:「プラチナ」「ゴールド」「シルバー」

システムレイヤーの要素を取りまとめるためのモデルには、以下のようなものがあります。

モデル 説明
コンテキスト 同じ役割をもつ情報、状態、条件、バリエーションをまとめる。システムの特定領域(ドメイン)のシステムレイヤーの要素をまとめて管理する単位として利用できる
情報モデル 複数の「情報」をひとつのモデルにまとめたもの
状態モデル 複数の「状態」と、それらの間の遷移をまとめて定義したモデル

RDRAのモデルを定義するためのツール

RDRAには、目的に応じて複数のツールが用意されています。それぞれの役割と関係性を、下図に示します。

RDRAのモデルを定義するためのツール

RDRAによる要件定義作業の中心となるのが、「RDRA定義・分析Sheet」です。

このシートでは、システムを構成する要素と、それらの関係性を表形式で整理・定義します。要件を関係性とともに構造化して記述することで、RDRAモデルの基盤となる情報を一元的に管理できます。

さらに、シートで定義した内容をグラフィカルなモデルとして視覚的に俯瞰するためのツールが「RDRA Graph」です。個々の要素のトレーサビリティ集約した単位での凝集度や結合度の把握など、さまざまな視点から定義情報を分析し、定義の精度を上げることができます。

RDRA Graphは「関連データ」シートのデータをクリップボードにコピーし、シート内のリンクから起動できます。

RDRA Graphの画面が起動されたら、ヘッダメニューの「OBJECT LIST」や「DIAGRAM」からモデルを参照してください。なお、RDRA Graphで表示したモデルは参照専用です。

RDRA Graphの画面

また、LLMを活用してモデルの叩き台を生成する支援ツールとして、「RDRA ZeroOne」と「RDRAAgent」が用意されています。「RDRA ZeroOne」はWeb画面から、「RDRAAgent」はCLIから実行でき、RDRA形式のモデルデータを自動生成します。

これらのツールで生成したテキストデータを「RDRA定義・分析Sheet」に取り込むことで、要件を一から手作業で整理する負担を大幅に削減でき、要件定義の初期立ち上げを高速化できます。その結果、検討や、分析、合意形成といった本質的な作業に、より多くの時間を充てることが可能になります。

まとめ

本記事では、RDRAの基本的な考え方から、V字モデルにおける位置付け、4つのレイヤー構造、そして実務を支える各種ツールまで、RDRAの全体像を解説しました。

RDRAの本質は、要件を個別の項目として管理するのではなく、要素同士の関係性を軸にシステム全体を一つの構造として捉える点にあります。これにより、要件の抜け漏れや矛盾を早期に発見できるだけでなく、「なぜ必要なのか」を説明可能な、納得感のある要件定義を行えるようになります。

筆者自身、2020年から複数の実プロジェクトでRDRAを継続的に活用してきましたが、企画から設計へと情報を一貫した形で引き継ぎやすいため、解釈のズレや属人化を防ぎ、後戻りの少ない開発を実現できています。

また、GoogleSheet・RDRAGraph・LLMツールを組み合わせることで、構造化と可視化、そして自動生成を両立し、要件定義のスピードと品質を同時に高められる点も大きな強みです。

要件定義を「作業」ではなく「構造を設計するプロセス」として捉え直したい方にとって、RDRAは有効な選択肢の一つです。

次回からは、図書館システムのサンプルを題材に、RDRAの詳細について順を追って確認していきます。

tracery.jp

参考書籍

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

V字モデルの各レイヤー(要件定義、運用テスト・システムテスト編)

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

この記事ではV字モデルのレイヤーのうち、「要件定義」プロセスと「運用テスト」「システムテスト」プロセスについて説明します。

V字モデルの各レイヤーの説明は以下の記事を参照してください。

tracery.jp

V字モデル上の「要件定義」と「運用テスト」「システムテスト」

業務/システムで、何を実現するかということに焦点を当てたWhatのレイヤーでは、「要件定義」プロセスと「運用テスト」プロセス、「システムテスト」プロセスを実施します。

Whatのレイヤーは、V字モデルのWhyレイヤー(企画のプロセスがある)の下にあり、「企画」プロセスで定めた「Why」を実現するためのレイヤーです。

V字モデル上の「要件定義」プロセスと「運用テスト」「システムテスト」プロセス

V字モデルでは、右側のプロセスが左側のプロセスの検証を行う役割を果たします。

要件定義は、大きく次の2つに分類されます。

  • 業務要件定義:事業の目的を達成するために、業務として「何を・どのように行うか」を明確にし、業務の目的・手順・ルールを整理する。
  • システム要件定義:業務要件を実現するために、システムとして「どのような機能・性能・制約で支援するか」を具体的に定める。

これら2つの要件定義は、開発後のテストプロセス(運用テスト、システムテスト)と対応します。

業務要件に基づいて実際の運用を確認するのが運用テスト、システム要件に基づいて動作を検証するのがシステムテストです。

それぞれの特徴を以下に整理します。

テスト名 主な観点 主な実施者
運用テスト - 業務要件の観点から、業務が実際に問題なく運用できるかを確認
- 操作手順や運用ルール、帳票・通知など業務成果物を検証
- 業務担当者
- ビジネス側責任者
システムテスト - システム要件の観点から、システム全体が仕様どおりに動作するかを確認
- 機能、性能、セキュリティなど非機能面も含めて検証
- システム開発者
- 品質保証担当者

運用テストとシステムテストは、本番稼働前の最終テストです。

特に、実運用に近い環境でテストを実施することで、環境差による不具合や想定外の業務上の問題を早期に発見しやすくなります(下図)。

運用テストとシステムテストの違い

以下、それぞれのプロセスを説明します。

要件定義プロセス

以下の図に、要件定義プロセスの全体像を示しました。要件定義は、大きく業務要件定義システム要件定義に分類されます(下図)。

要件定義プロセス

要件定義プロセスについては、『要件定義とはそもそも何か』の連載で説明していますので、詳細をご参照ください(以下は連載の第1回です)。

tracery.jp

運用テストプロセス

運用テストは、業務要件の観点から、業務が実際に問題なく運用できるかを確認します。

操作手順や運用ルール、帳票・通知など業務成果物を検証します。

ビジネス側が開発側に依頼した開発内容を検証するためという目的も含まれるので、『受け入れテスト』と呼ぶこともあります。

運用テストの観点

運用テストの目的は、業務要件定義で定めた業務の流れやルールが、システム上で正しく再現され、実際の運用として成立しているかを確認することです。

主に次の観点からテストを実施します。

  • 業務フローに沿って、システムを用いながら業務を一連の手順として遂行できるか
  • ユースケース(システムを利用する具体的な場面)において、想定どおりの操作・結果が得られるか

これらの業務観点に加え、運用全体の妥当性を確認するため、以下の観点からも検証します。

  • 事業要件が実際に満たされ、業務を通じて事業上の価値が発揮されているか
  • システム要件(機能要件・非機能要件)が、運用に必要な品質レベルを満たしているか

これらを総合的に確認することで、システムが業務運用を安全かつ確実に支える状態にあるかを最終的に評価します。

運用テストプロセスの観点

システムテストプロセス

システムテストは、システム要件の観点から、システム全体が仕様どおりに動作し、期待した品質を満たしているかを確認します。

機能要件・非機能要件をもとに、画面操作やバッチ処理、外部システムとの連携などを総合的に検証します。

開発側が作成したシステムが要件定義書どおりに実装されているかを確認する工程であり、システムの完成度と品質を保証する役割を担います。

システムテストプロセスの観点

システムテストの目的は、システム要件定義で定めた機能・性能・制約が、システム全体として統合的に動作し、要求どおりの品質を備えていることを確認することです。 開発工程の最終段階として、システムの完成度と運用準備性を総合的に検証します。

主に次の観点からテストを実施します。

  • システム要件(機能要件・非機能要件)が、運用に耐えうる品質水準を満たしているか
  • ハードウェア、ネットワーク、外部システム、ソフトウェアなど、関連要素が相互に連携し、全体として安定して動作するか

これらのシステム観点に加えて、運用フェーズでの実効性を確認するため、次の視点からも検証を行います。

  • 想定した業務フローやユースケースに沿って、利用者が業務を正確かつ効率的に遂行できるか
  • システムの稼働により、業務上求められる成果や情報が確実に得られるか

これらを総合的に検証することで、システムが要件定義段階で期待された品質を満たし、業務運用に移行できる状態であることを確信する段階が、システムテストです。

システムテストプロセスの観点

最後に

この記事では、V字モデルにおける「要件定義」プロセスと、「運用テスト」「システムテスト」プロセスの関係について解説しました。

「要件定義」プロセスは、システム開発において何を作るのか(What)を明確にします。

これに対応して、「運用テスト」は業務要件が実際の運用で満たされているかを、業務担当者が最終的に確認するプロセス、「システムテスト」はシステム要件が仕様どおり実現されているかを、開発者が最終的に検証するプロセスです。

運用に耐えうるシステムをリリースするためには、業務担当者の視点(業務が確実に遂行できるか)と、システム開発者の視点(システムが安定して動作するか)の双方からテストを実施することが不可欠です。

そのうえで、業務・システムが連携し、事業要件を満たしながら持続的に価値を生み出す状態を目指すことが重要です。

次回の記事では、V字モデルにおける「基本設計」プロセスと「結合テスト」の関係を説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860