RDRA2.0 ハンドブック
Relationship Driven Requirement Analysis (RDRA) という要件定義の手法（業務のモデリング手法？）があるらしい。どのくらい知られているものかはわからないが、内容の納得度は高かった。はじめよう！ 要件定義 ～ビギナーからベテランまで の内容とも通底する部分があり、正しい内容が書いてあると言えそうだった。
本書で扱っているのは要件定義、つまり現実の業務（ドメイン）をどう抽象化（モデリング）するかという領域。抽象化したものをシステムで実現するので、とても大切なもの。
例えば DDD なんかの本や記事をみていても、ドメインをどうモデリングするかより、それをどうコードで表現するかの議論のほうが盛り上がっているように見える。確かにそれも難しく大切な分野だが、一方でモデリングそのものの方が方法論が確立しておらず、職人芸に頼られており、重要度も高い領域だと思う。自分が知らないだけかもしれないが、モデリングの議論はもっとあっても良いのになと思う。
個人的な解釈だが、RDRA の特徴としては以下がある。
- 要件定義というふわっとしたものを、4 つのレイヤーに分類したこと
- システムが提供する価値 ~ 業務の分析 ~ ユースケース化 ~ システムが扱うデータ、という感じ段階的に具体化
- 具体の方から根本の方へ依存関係がある
- 各レイヤーを行ったり来たりしながらモデリングを磨くことを推奨していること
- 各レイヤーには「ユースケース」や「情報」などの共通部分があり、それらをキーに連結している
- レイヤーを行ったり来たりとは、つまり抽象度を上げたり下げたりしながら分析しましょうということ
- ウォーターフォール的に進めるよりも、ある程度コードを書きながら設計をブラッシュアップした方が良いものができるので、これは経験的に納得感がある
- コミュニケーションツールとしての側面を強調していること
- 単にドメインを分析するだけでなく、分析結果をもとに各所とコミュニケーションを取ることが大事と述べている
- 要件定義は、後続のフェーズに比べふわっとしている（不確実性が高い）ので、議論が発散したり、同じ話を何回もしたりしがち
- 生産性という意味でも、また手戻りはあとになるほど被害が大きいという意味でも、こうしたファシリテーションの難しさを解決することは、思った以上に重要だと考えている
結果として出来上がる成果物は、たとえば “はじめよう！ 要件定義 ～ビギナーからベテランまで” 読書メモ - Please Sleep で紹介されているものと似ている。でもこれらの特徴により、より精度の高いものが作れそう（あるいは経験値が少なくてもこの手法に乗ることである程度の品質がだせそう）に思えた。
具体的には各レイヤーで次のように分析していく。
「システム価値」レイヤー
そもそもなぜシステムを作るのか。関連するアクターや外部システムを洗い出し、システムがあることでどんな価値（便益）があるのかを明文化する。
わりと当たり前な結論の成果物になりがちなんだけれど、ここが合意できていないとプロジェクトは絶対にうまくいかない。実はとても重要な部分。
「システム外部環境」レイヤー
実際にどういう要求、業務があるのかを分析し、それを実現する「ユースケース」を洗い出す。
業務を行うのは「システム価値」レイヤーで洗い出したアクターなので、そのアクターにちゃんと価値が提供できているのかを確認できる。
ユースケースとは、その業務を実現するためのシステム操作のことで、これが「システム境界」レイヤーとの接点となる。
「システム境界」レイヤー
ユースケースごとに、画面などどんなインターフェースか、どのようなデータを操作するのかを分析する。
「システム」レイヤー
「情報」と「状態」を定義する。情報とは DDD のエンティティや値オブジェクトのようなもの。状態は情報がとりうる状態。RDRA ではユースケースが情報を操作し状態が変わるという抽象化の仕方をしている。いろいろなユースケースが情報を操作し状態が遷移していくという考え方。概念データモデルを作る作業に近いかも。
最終的にシステム全体にまたがるのが情報と状態で、ここから逆算しながらユースケースや要求に漏れや矛盾ががないかをブラッシュアップしていく。