RDRA2.0 ハンドブック ch8 RDRA活用のために

RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法

---

RDRAによる要件定義の実際

• RDRAで解決できる種々の問題点
  • 「何かが決まったようでいて、結局何も決まっていない」
    • 要件定義でありがち
    • 議論が空中戦に終始し、具体で議論しないとこうなる
  • 要点定義書という「成果物」の目的化
    • ウォーターフォール開発でありがち
    • こと要件定義においては成果物の完成はゴールではなく、何度も見直す必要がある
  • 仕様の辻褄が合わない
    • アジャイル開発でありがち
    • 重要な部分・価値を出せる部分以外の仕様が「なんちゃって仕様」
    • 繋がりだすと辻褄が合わなくなる
    • 共通認識ができない
    • 仕様確認が不十分なまま実装するので、テスト段階で問題が発覚しだし、開発スピードが落ちてくる

RDRAの活用場面

• ウォーターフォール/アジャイル両方に対応できる
  • 要件の作り込み具合の違い
  • 実装した仕様をRDRAモデルにフィードバックするか否かの違い

要件の作り込み具合の違い

	アジャイル	WF	要件定義工程を別会社が行うケース
システム化範囲の合意	o	o	o
ビジネスルールの整理		o	o
システムの整合性確保			o

• システム化範囲の合意
  • 業務 -> ビジネスユースケース -> ユースケース の3段階で詳細化、開発範囲の明示
  • できるだけ早い段階から開発に移行したい場合、ビジネスユースケースまではRDRAで洗い出し、以降の詳細化はユーザーストーリーマッピング等の技法を使うことも
• ビジネスルールの整理
  • バリエーション、条件を使ってビジネスルールの仕様化までRDRAで表現
• システムの整合性確保
  • 情報モデル、状態モデル、ユースケースの辻褄が合っていることを確認し、精度を高める

実装した仕様をRDRAモデルにフィードバックするか否かの違い

• 開発時に明らかになった詳細な仕様をRDRAにフィードバック
• 開発中盤の開発スピード低下に対応できる
  • 仕様全体を俯瞰
  • 新規開発分に関わる影響度を事前に把握

RDRAを活かす方法

議論の土台を作る

• 闇雲にヒアリングしても議論がブレて時間がかかるだけ
• 事前に手に入る資料と、間違っていてもよいので仮設をベースにRDRAモデルを作ってみて、それをもとにヒアリングを行う
  • はじめて聞くことでも知識がつながる
  • 誤解や勘違いがはっきりする
  • 空中戦ではなく具体的な議論ができるようになる
  • 重要なことを意識しながら進められる

RDRAモデルをコミュニケーションツールにする

• 有識者と議論しながらその場で作成し同時に確認するのが良い

開発後も維持し保守開発に役立てる

• 開発中も随時更新し最新の要件として維持する
• 開発終了後も保守開発時に活用できる
  • 影響範囲調査

RDRAはツールを使って初めて効果がでる

• アイコンのつながりで意味を表す表記法なので、ダイアグラム横断的なつながりを分析できること
  • PowerPoint
    • VBAマクロで分析できる
  • Enterprise Architect
    • SQLで分析できる

アイコンからつながりをたどる

• つながりを分析することで得られる洞察の例
  • 開発者が、開発担当のユースケースに関して実装すべきこと
    • ユースケース周辺のつながりを分析する
  • 情報のライフサイクル
    • 情報につながっているユースケースを分析する
  • アクターの責務に沿った業務になっているか
    • アクターとアクティビティのつながりを分析する

要件定義を分析的にすすめる

• 要件定義の変更は整合性をとりながら進めていく必要がある
• アイコン同士のつながりを管理し、影響度を把握しながら進めるにはツールの支援が欠かせない
  • 【所感】アプリケーションコードに対するテストコードにような感じ。安心して変更を行えるようにする