勝手にＲＤＲＡを語る夕べで語られたことまとめ
ホーム > 要件定義 > RDRA（ラドラ）◆「勝手にRDRAを語る夕べ」というイベントとこの記事について
connpassに「語る夕べ」というグループがあります。2018/07/18に「勝手にRDRAを語る夕べ」というイベントが開催され、RDRA（ラドラ）という要件定義の手法について語る会が開催されました。
この記事は、そのイベントに私が参加した際のメモと、別の参加者がtwitterで呟いたことをまとめたものです。
ある程度RDRAを知っている人に対して語る会なので、いきなりこの記事を読んでもよくわからないと思います。
「◆参考資料」に記載した資料がRDRAをちゃんと整理して説明しています。RDRAを提唱している神崎さんの資料です。整理された情報が欲しい人はその資料を見て下さい。
この記事は、その資料を見た後で見ると、為になるところが少しはあるかもしれない。。。という記事です。
◆参考資料
本はこちら
・RDRA（ラドラ）：Relationship Driven Requirement Analysys
・モデルベース要件定義 at BPStudy（発表資料）
・「要求分析ツリー」を使って要求の構より抜粋造をとらえる
・要求工学知識体系(REBOK)概説
・合意形成手法「リザルトチェイン」適用事例
・UModel におけるダイアグラム
・「要件定義」の4つの構造と依存関係に着目した実践手法
・JAD(Joint Application Development)
◆前提知識（ＲＤＲＡ概要）
「前提知識（RDRA概要）」の章はイベント関係なく私が個人的にまとめたものです。
RDRA（ラドラ）：Relationship Driven Requirement Analysys
リレーションシップ駆動要件分析
要件定義の目標
明確なコンセプトに基づいて各要件が適切に洗い出された要件定義は、次の3つの特性を兼ね備えている。
・網羅性：コンセプトの具現に必要な要件がもれ、重複なく示されている。
・整合性：各要件が基本コンセプトおよび他の要件と整合したものになっている。
・表現力：それぞれの要件がわかりやすく表現されている。
要件定義にまつわる問題
要件定義で多く見られる事象
・全体像が見えてこない。
・顧客と打ち合わせをリードできない。
・まとまらない会議
・シーズ中心
・議論がすぐ袋小路に入る
リレーションシップ駆動要件分析(RDRA)
要件定義を4つの領域に分解して捉える。
上記4領域を、モデルを使って整理していく。
領域ごとに対応する基本ダイアグラムがある。
基本ダイアグラム
網羅性を担保するために、基本ダイアグラムを使用する。
1. システム価値
システムは誰にとってどのような価値があるのかを要求として明らかにする。
使用するモデル：コンテキストモデルなど
コンテキストモデルの例
2. システムの外部環境
システムの価値を実現するための業務や利用シーンを明らかにし、システム境界を決める前提を明確にする。
使用するモデル：業務フローなど
業務フローの例
3. システム境界
システムと外部環境との境界に位置する部分を捉え、それを表現します。
人が関わる部分はユースケースと画面・帳票モデルでシステム境界を表します。
外部システムに関わる部分はイベントモデルとプロトコルモデルでシステム境界を表します。
使用するモデル：ユースケース図など
ユースケース図の例
4. システム
システム内部構造に関係する要件として、データモデルまたはドメインモデル、機能モデル、ビジネスルールを明らかにします。
ビジネスルール
関係ダイアグラム
基本ダイアグラムで整理したモデルを連結したダイアグラム（関係ダイアグラム）を作成することで、要件の整合性が取れているかを確認する。
各ビューの間で要件に不整合が生じていないことを確認するため、基本ダイアグラムのモデル要素を1つの図に混在させて書いたもの。
整合性を確認するために、関係ダイアグラムを使用する。
1.システム外部環境の関係ダイアグラム
業務フロー＆ユースケース
利用シーン＆ユースケース
2.システム境界の関係ダイアグラム
ユースケース＆画面・帳票
3.システムに関する関係ダイアグラム
機能複合モデル
機能を中心に、画面、ユースケース、データ、ドメインを結びつけ、全体としての整合性をチェックします。
トレーサビリティチェック
上記のような関係ダイアグラムを利用することで、システムの各部分が別の部分に正しく対応づいていること（トレーサビリティ）のチェックに役立てることができます。
下図のノートと吹き出しが各ダイアグラム間の関係性について着目するポイント
◆ＲＤＲＡについて（イベントの内容）
ここからがイベントの内容
今回の語る夕べはRDRAと近いテクニックを比較して理解を深めるという形式でした。
本になっているのはRDRA 1.0
今年（2018年）になってRDRA 2.0 という考え方を出した。
RDRA 1.0ではシステム要求がRDRAの範囲で一部業務要求まで見ている感じだったのだけれど、2.0では軸足が業務要求に移ってきた。
RDRA 1.0では、網羅性が取れる点が大きなメリットでした。2.0では業務要求なので網羅性はあまり言わなくなりました。業務の網羅性は取れないですから。
要望、要求、要件について
・要望、要求、要件を定義している
「要望」という言葉はみんなが好き勝手に定義しているのでブレやすい。
人によって要望、要求、要件の定義が異なる。
参考
⇒いろんな人が好き勝手言ってる言葉。
本では以下のように定義している。
・要望：ヒアリングしたものをそのまま記録
・要求：要望は矛盾や重複があるので整理して構造化。構造化は木構造で整理することが多い。
・要件：最終的に実施するもの
・RDRAでは、ヒアリングした項目を構造化したものを要求とし、要求の中からシステムで実現されなければならないことを要件と定義しています。
・RDRAでは要望・要求・要件をモデル化します。モデル化する際には、木構造や、複雑な場合は関係図（要求や要件間の関係を図にする）を使用します。
例えばこういうもの
「要求分析ツリー」を使って要求の構造をとらえる ｜ 日経 xTECH（クロステック）
要求工学における要望、要求、要件
・要求工学では、要望、要求、要件で分けない。要求で統一している。
要求工学では要望・要求・要件を『ほにゃらら要求』という（英語では全部requirementなので）のですが、事業要求・業務要求・システム要求といった言葉が近い概念として対応します。
共通フレーム2007の定義
共通フレーム2007における要望、要求、要件の関係
共通フレーム2007における要望、要求、要件の関係より抜粋
ステークホルダー要求とその他の要求との関係
・お客様に業務の話を聞きに行ったとしても、お客様はシステムの問題を語り続けるかもしれません。
だから、ステークホルダー要求は業務、システム、ソフトウェアそれぞれにあります。
・RDRAで言う要望、要求、要件は上の図で言うステークホルダー要求。
ステークホルダーが喋ったことを構造化しようと言っている。
ステークホルダー要求、事業要求、業務要求はシステム化する上でのインプット。
システム要求、ソフトウェア要求はその結果。アウトプット。
・To-BeとAs-Isの差分を要求と捉える人と(XDDP)、
To-Beそのものを要求と捉える人の2種類がいる(USDM)。
テストエンジニアにとって要求というと清水吉男さんのXDDPやUSDMで言うところの“要求”の定義に馴染みが深い人が多いのですが、RDRAの要求はちょっと違います。
RDRAでは、ヒアリングして差分は聞くが、メインはAs-Is あるべき姿をモデル化する（P38 1.3.5の図1-10）
要件定義で参考になる本
・要求の専門家 ←要求工学系。アカデミックに近い文脈。
・要求エンジニア
・開発者向けの本 ←RDRAはここ。要件定義をやったことのない開発者向けの本。
合意形成とコミュニケーション
仕様に近いものをモデルで表現している。
・RDRAでは、お客様が語った『問題』や『夢』をヒアリングしてあるべき姿をモデル化します。
そのため、神崎さんは「合意形成」や「コミュニケーション」に興味があります。To-Beモデルです。
清水さんのUSDMではAs-Isとの差や『仕様を導くための要求』に重きを置いています
お客さんと会話しやすいモデルとしにくいモデルがある。
価値と業務は顧客と会話しやすい。
| RDRAで言う・・・ | 左をREBOK（要求工学）で言うと・・・ |
|---|---|
| 網羅性 | 完全性に近い。業務の世界で網羅性を言うと破綻する。 ⇒スコープを決める。システムは限られたスコープの中で網羅性を求める。 |
| 整合性 | 追跡可能性 |
| 表現力 | 要求の専門家は気にしない。 |
RDRAの言葉は要求の専門家が使う言語とずれていてもやもやする。
RDRAに書かれている、システム開発の困りごと。
・全体像が見えてこない
・コンセプトが不在、不十分
・会議をファシリテートできない
・顧客をリードできない
→開発者の立ち位置で書かれている本だということがわかる。
書かれている困りごとは「開発者の困りごと」。
顧客サイドならこういう表現にはならない。
要望ダイアグラム、機能要求ダイアグラム、非機能要求ダイアグラム
・要望ダイアグラムでは、ヒアリングしたものを『そのまま』整理します。ヒアリングしたことを要約してはいけません。
・機能要求ダイアグラムと非機能要求ダイアグラムでは、要望を重複を排除するなどしながら綺麗に整理します。
・機能要件ダイアグラムと非機能要件ダイアグラムでは、プロジェクトでやることを確定します。
これをベースライン設定といいます。神崎さんは、システム実現可能性まで考慮していそうです。
リッチピクチャ
・RDRAの要求ダイアグラム（P172 図4-3）はリッチピクチャに似ている。
リッチピクチャ
要求工学知識体系(REBOK)概説より抜粋
・漫画と吹き出しを用いて、どのような意見があるのかを俯瞰する絵
・直感的な現状把握を行うことが目的である。
・公式なテクニックや定まった形式はない。
・ステークホルダの意見、世界観、問題意識を把握することに意義がある。
・発言者の位置にも意味があり、描き手の意図が反映される。
・近い、遠い、中央、周辺
要件定義の構成要素
ここがRDRAで一番な重要ポイント
価値、環境、境界、システム内部(P52)
おそらくBSCの戦略マップを参考にしたのだと思われる。
| 要求工学の分類 | RDRAにおける構成要素 | システムを使って生み出す価値 |
|---|---|---|
| ビジネス要求 | システム外部環境 | システムを取り巻く環境 |
| システム要求 | システム境界 | システムとユーザーの接点 |
| ソフトウェア要求 | システム内部 | システムそのもの |
RDRAというと、モデル化に目が行きがちだけれど、そっちは別の所で学べば良くて、それよりも『要件定義の4つの構成要素』が大切。
４つとは
・システムを使って生み出す価値
・システムを取り巻く環境
・システムとの接点
・システムそのもの
この４つをモデルを使って繋いでいく。
オニオンモデル
RDRAにおける構成要素がオニオンモデルに似ているという話
要求工学知識体系(REBOK)概説より抜粋
|オニオンモデル|RDRAで言う| |---|---| |社会・環境、顧客、企業|システム価値| |業務・ユーザ|システム外部| |業務・ユーザとITシステムの間|システム境界| |ITシステム、ソフトウェア|システム|
・神崎さんのアプローチは、『ヒアリングした言葉を“要件定義の４つの構造モデル”に当てはめる』方式。
要求工学では『モデルを元にしてヒアリングをしていく』方式。
・システム境界の代表的なものは、ユースケースと画面・帳票です。外部インターフェースも含まれます。
書籍に「システムとの接点になる視点。業務フローもしくは独立した作業内でシステムを使うところがシステム境界となる」とありますので。
・RDRAでは外部開発環境重視といいます。私の解釈では業務要求を重視するという意味です。要求工学では当たり前の話です。
なぜ当たり前の事がRDRAの特長となっているかというと、要求獲得工程に絡めるようになってきた開発者はシステム化をすぐに考えてしまうからです。
・業務に関心が無い開発者がいます。そういう人はお客様が業務要求についてお話しされていても
『それは良いです。どういうシステムが欲しいのですか』とやってしまう。RDRAでは、そういう人に対して業務要求の重要さを説く。
・RDRAでは、アイデアをモデルに反映して議論を積み上げて合意形成し徐々に形にしていきます。
・お客様によっては「議論（ディスカッション）しましょう」というと受け入れてもらえない事があります。そういう時にはレビューしてくださいと言うとうまくいく事があります。
『お客様との議論』が受け入れられない現場がある理由は、『情報は伝えた。オマエら専門家なんだから答えを持ってこい』という（一緒にプロジェクトをやらない）お客様が少なからずいるから。
そういうお客様でもレビューはしてくださる。同じ内容なんだけどね。
コンテキスト図
RDRAでいうコンテキスト図（P169 4.4.3）はおそらくDFDのレベル0
要求工学では、ゴール指向アプローチ（CAOSとか）があるが、あまりうまくいかない。
目的から決めましょうというアプローチはまず無理。
・要求を獲得する時に教科書通りに『目的はなんですか？』と初っ端に聞くのは悪手です。
『何をどう実現するか？』といった手段を先にお客様に話し尽くしてもらって、その後、ゴール（目的）をまとめる。詳しい方法はリザルトチェーンを勉強してね。
・RDRAでは要求がシステムに網羅的に反映されていることを確認することを重視します。
何故なら（オブジェクト指向を勉強した実践経験が少ない）開発者にはTo-Beモデルの素晴らしさに引っ張られて、お客様の要求を蔑ろにしてしまう人がいるから。
オブジェクト指向一本やりの人が要件定義を作ろうとすると、To-Beモデルに走る。
⇒顧客の要求が入らない。作ったTo-Beを顧客に押し付けようとする。
・基本ダイアグラムは、いろいろな情報が抜け落ちている
インフラ系は落ちている。
場所系の話。業務はどこでやるのか？
RDRAではシステムの運用について語っていない。
システム運用とか、移行のラフスケッチがない状態では見積もれないはずなのだが。。。
モデルの整合性
これがRDRAの売りの一つ。
ドキュメントフロー／トレーサビリティマップ
ドキュメント間のフロー
何のために作るのか、何がインプットになるのか。
ステークホルダー要求つまり、システムが生み出す価値からシステムまでのトレーサビリティを重視しているのがRDRAです。
・ドキュメント間の関係性を図示してまとめることはとても大切です。書かなくてはならないドキュメント一覧はあってもそのフローが書かれていない事が多いから
・モデル間もドキュメントフローと同じように、モデル間のトレーサビリティが取れる関係線を描き全体像を明らかにすること。
整合性記述レベル（P108, 図2-30）
最初に作成したモデルと後で作成したモデルでは精度が変わってしまう（時間の経過とともに見直しが必要になってくる）。
このため、古い情報を新しい情報と同じ精度に挙げていく必要がある。
T字形テクニック
①全体を浅く掘る。
②1ヶ所を深くする。
③深くしたところを横に広げる
浅く全部やって、「ここだ！」って所を深掘りして、それを横展開しろってこと。
「 時間の経過とともにバラバラ（粒度が）になる。」とはなにか？
（そこで）T字形テクニック
最初は浅く全部やれ。
深くやるところを見つけて掘り下げてから横展開しろ。
補足：T字形テクニックを使うと、領域ごとのばらつきが発生しやすい。
状態遷移について
書籍の中に「プロトコルモデル」というものがあるが、参加者も主催者も「よくわからん」と言っていた。
使用しているUMLは状態遷移図なのでそこから状態遷移の話になった。
・業務シナリオテストを作る時に、業務の状態遷移とシステムの状態遷移を抑えて置くとビシバシバグが見つかります。
・業務シナリオテストでは、バグを指摘するのではなく仕様通りであっても、『この業務シナリオを通らないなら使えねーんだよ』って問題を指摘する。
・炎上プロジェクトの火消しに行ったときに、状態遷移の仕様が定義されていないことがあった。
案の定、プログラムでは、沢山の条件のアンドで分岐していた。
全部を作り直せなかったのでしようしょと開発者へのヒアリングで状態遷移図を描いてテストして火消しした。
・業務の状態を保持するのにデータベースを使います。
業務要件定義の段階で正しく分析できていれば、素直な実装ができます。
分析を端折っため、ある業務の状態を表現するのに、３つのテーブルにばらけてある７つの項目が必要でした。
プロトコル状態マシン
参考
業務に使えるかはわからないけど、知識があると抜けているかどうかがわかる。
例えば
・業務の状態遷移
・リソース系の状態遷移
・イベント系の状態遷移
主催者が経験した例
業務の状態遷移がないがゆえに状態の持ち方がひどいプロジェクトがあった。
7項目の and 条件で状態が決まるようになっていて、～～日付が null だと1つの状態だったり・・・。
QA
- Q. 環境→ステークホルダ要求→システム要求→ソフトウェア要求のなかでどこまでトレーサビリティを取るべきか？
- A. ステークホルダ要求までのトレーサビリティを重視しており、モデルの選択もトレーサビリティのとりやすさも重視している(と理解している。)
- Q. 要求のゴールをどう決めるのかが見当たらない
- A. 書いてないです。
- Q. 要求エンジニア向けの書籍でおすすめのものは？
- A. 要求向けでなくIT戦略(CIO)向けの本。システム投資をどうするか？など目的や価値判断の本。チェックリストなどがあるが、逆に言うとそれを作れば良い(ゴールとなる)
- Q. 事業要件とのトレーサビリティをRDRAではどのように取りますか？
- A. RDRAは事業要件、別の言い方をすると、経営戦略やIT戦略との整合性は明示的には書かれていません。 それらもステークホルダー要求として取り扱っていると解釈できます。
◆参考資料集（再掲）
本はこちら
・RDRA（ラドラ）：Relationship Driven Requirement Analysys
・モデルベース要件定義 at BPStudy（発表資料）
・「要求分析ツリー」を使って要求の構より抜粋造をとらえる
・要求工学知識体系(REBOK)概説
・合意形成手法「リザルトチェイン」適用事例
・UModel におけるダイアグラム
・「要件定義」の4つの構造と依存関係に着目した実践手法
・JAD(Joint Application Development)