🌟

KiroとRDRAを組み合わせてみた

に公開
要件定義
RDRA
Kiro
idea

TL;DR

• RDRA = 要件の“地図”をつくる道具
• Kiro = その地図を読ませてAIに“道路工事”させる道具

RDRA と Kiro の組み合わせは補完関係にあり有益。
2日あれば 1ヶ月くらいかかっていた小規模なシステムは作れそう。
ただ、RDRAだけではシステム全体を定義できないので追加で情報が必要になる。

AWS Kiroについて

最近 Kiro や cc-sdd というツールを利用してコードを書いて（生成して）います。
Kiroは、AWSが提供する 要件定義から実装までを一気通貫で支援するAIエンジニアリング環境 です。

開発者が自然言語や会話ベースで要件を入力すると、それを「Spec」という中間形式（構造化テキスト）に変換します。
このSpecをもとに、AIが自動的にドメインモデル、API定義、テストケース、さらにはコード生成までを行います。

たとえば次のような流れです：

  1. 要件を入力：「宿泊予約のキャンセルポリシーを管理したい」

  2. KiroがSpecを生成：

    Domain: Reservation  
Entity: CancellationPolicy  
Behavior: Create, Update, Apply

  3. AIが自動展開：

    • モデルやリポジトリ層のコードを生成
    • OpenAPI仕様書を出力
    • テストデータを自動生成

こうして、従来なら人手で設計→実装→テストと進めていた工程を、Specを中心に自動で結合できるのがKiroの強みです。

実際体験してみると、設計からタスクを生成した後はクリックをしていくだけで実装コードが生成されます。要件→設計→実装の流れで行うため、要件→設計の部分を詳細に詰めていれば生成されたコードが欲しい実装内容と大きく乖離することは少ないです。

大きく乖離するときは、 要件や設計に記載していないとき なので、そこをどう効率的に漏れなくAIに指示できるかが肝になってきます。

RDRAとの組み合わせ

RDRAで整理された要件モデルをそのままKiroに読み込ませると、AIがSpecとして再構築できるのではないかと考えました。つまり、RDRAで考え、Kiroで動かすという役割分担が自然に成立します。

・RDRAで得られるのは「構造化された認識」。
・Kiroが提供するのは「実行可能な仕様」。

この２つがつながることで、要件定義が“開発プロセスの出発点”ではなく“開発そのもの”になっていくのです。

やってみた

RDRA Agent が生成するRDRA関連モデルを元にKiroのSpecを生成してみました。

生成方法は図のようになります

  1. BUCから業務とユーザーストーリーを作成する
  2. 業務単位でKiroのSpecを作成する
  3. KiroのRequirementsを生成する（cc-sddで /kiro:spec-init [{{業務}}]{{BUCリスト}} のようなコマンドを叩く)
  4. 生成されたRequirementsの内容をRDRA Agentから生成した内容を元に次のようなプロンプトで検証します
## 1. 検証(1) - ビジネスルール
- 1. `2_RDRASpec/business_rule.md` の内容を読み取ります
- 2. 業務と{{要件}}が一致するか検証します
- 3. 一致する場合、記載内容と同様の内容が、{{要件}}にあるか検証します
- 4. 記載がない場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
- 5. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
- 6. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
- 7. 現時点での「適合」をコンソールに出力します
- 8. 現時点での「不適合」をコンソールに出力します

## 2. 検証(2) - 条件
- 1. `1_RDRA/条件.tsv` の内容を読み取ります
- 2. 1列目の「コンテキスト」と業務が一致するか検証します
- 3. 一致する場合、2列目と3列目の条件と説明の記載内容と同様の内容が、{{要件}}にあるか検証します
- 4. 記載がない場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
- 5. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
- 6. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
- 7. 現時点での「適合」をコンソールに出力します
- 8. 現時点での「不適合」をコンソールに出力します

## 3. 検証(3) - 論理データ
- 1. `2_RDRASpec/論理データ.tsv` の内容を読み取ります
- 2. 1列目の「データ名」と業務が一致するか検証します
- 3. 一致する場合、{{要件}}にある内容と論理データとの不整合（定義されていないデータを使っていないかなど）を検証します 
- 4. 不整合があった場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
- 5. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
- 6. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
- 7. 現時点での「適合」をコンソールに出力します
- 8. 現時点での「不適合」をコンソールに出力します

## 4. 検証(4) - UI
- 1. `2_RDRASpec/ui.json` の内容を読み取ります
- 2. `business_name` と業務が一致するか検証します
- 3. 一致する場合、{{要件}}にある内容と`BUCs` 以下にある画面データとの不整合（定義されていないボタンやフィールドを使っていないかなど）を検証します
- 4. 不整合があった場合、「検証結果」としてリスト名にあるディレクトリ名とセットで保持します
- 5. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
- 6. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
- 7. 現時点での「適合」をコンソールに出力します
- 8. 現時点での「不適合」をコンソールに出力します
  1. 検証した結果に不適合や改善案があれば、それらを盛り込んだ内容で要件を修正してもらう
  2. 要件を承認して設計（design）を生成する
  3. 生成順序は 2_RDRASpec/論理データモデル.md を読み込んで、リストを作成してから上から順に進める
  4. 生成された設計をRDRAが生成したモデルで検証する（まだやってない。そのまま実装進めている）
  5. 実装タスクを生成して実装を進める（Kiroでもcc-sddのどちらでも可能）

感想

思っていたよりも簡単にそれっぽいものを作ることができました。（6~7割くらいできる）
2~3日あれば1~2ヶ月かかっていた小規模なシステムなら作れそうです。（ただし、要件をちゃんと詰めておく必要がある）
改善したい内容としては、RDRAだと次のような内容が出力されないので別途要件に組み込むか、kiroのsteeringに設定が必要な感じです。

・ログイン画面がない（ログインユーザーの管理機能もない）
　→ 業務というよりシステム利用のために必要なのでRDRAで定義しておかない限り出てこない
・画面フローやメニュー、ダッシュボードがない
　→ これも業務とは基本無関係なため。あとから追加する必要がある。
・画面にあるボタンを押しても動かないときがある
　→ APIのテストは基本作成されるが、画面(UI)に関するテストがない。これは要件や設計を作成するときに追加する必要がある。

Discussion