RDRA学習ロードマップ
RDRAが広まってきているので情報源を充実させたい
リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。
RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。
要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。
— 増田 亨. (@masuda220) May 26, 2020
RDRAで可視化されたビジネスルール(バリエーション・条件・状態モデル)をビジネスロジックとして実装しています。
ドメイン駆動設計の実装例としても参考にしてください。
https://t.co/UyFscwKMPi#CCSR手法
ユースケースをよくみたらCRUDしかないけど、これが本当にやりたいことですか?みたいなこというとだいたい違うんですって返ってる。ビジネスルールが何かはそこで聞ける場合もある。なので、適切な質問は必要だけど何を質問したらいいか…。RDRAはそのヒントになると思います。
— かとじゅん (@j5ik2o) August 8, 2019
もちろんRDRAは必ずしもDDDと組み合わせる必要はなく、単体でも要件定義手法として導入できます。RDRAは数ある要件定義手法の中でもエンジニアにとっても馴染みやすい手法だと私は思っていて、その理由は素早く要件をまとめて遅滞なく開発に取り掛かることを重視しているため、またイテレーティブに設計・開発からのフィードバックを経て要件を洗練できるためです。ソースコードを書く方法論に近い感覚で要件定義も行う、というように私は捉えています。
さて、RDRAは着実に広がりを見せているものの、実際に仕事で運用に載せたときの課題、つまり現実世界で実践してみて初めてぶつかる課題を解決するような情報はまだ少ないと言えます。そこでRDRAに取り組みたい人に向けて知識のギャップを埋めるため、私が考えるおすすめRDRA学習のロードマップを紹介します。もちろんこれにとらわれずにRDRAの学習を進めることはできますが、情報源を探す参考になると信じています。
書籍の紹介
まずは提唱者である神崎さん本人が書いたRDRAの書籍です。RDRAの特徴である簡素な各種ダイアグラムを使い、それらを議論の土台として、素早く要件定義を進めていく方法が解説されています。全体で100ページちょっと(私の持っている第1.1紙版だと132ページ)なので、手軽に読める反面、説明が簡潔になりすぎている部分があるので、この本だけではピンとこない人もある程度いるでしょう。次に紹介する書籍とセットで読めばグッと理解も深まるので、この本を読んでRDRAについてもっと知りたいと思った方は、ぜひ次の「モデルベース要件定義テクニック」も合わせて読んでください。
こちらは同じく神崎さん本人が書いた、いわば「RDRA 1.0」の本で、とても丁寧でわかりやすく手法自体とその背景も含めて解説されています。特に冒頭の章で挙げられている、要件定義の現場でありがちな問題点は、自分で要件定義を行う人間だけでなく、その影響を受けて開発のやりにくさを感じている人なら思わず納得してしまうはずです。2013年の本なので、その後のRDRA2.0では変更され改善されたテクニックもあります。ただし、それも含めて2冊合わせてよむと理解が深まり、こちらの本で学んだ知識も全くムダにはなりません。RDRA2.0ハンドブックと比べ、実例も豊富なのでその点も参考になるでしょう。
イベントへの参加
上記2冊の書籍を読んで、よりRDRAへの理解を深めたい、神崎さん本人の話を聞きたい、という方はConnpassを中心にRDRA関連の勉強会に参加することをおすすめします。昨今勉強会はオンラインで行うのがトレンドになっているので、地方在住の方でも参加できる機会は増えています。数週間に一度程度RDRA関連の勉強会は開催されているようです。もちろん勉強会に参加することを好まない人もいると思うので、そういう方は以下で紹介する別の方法で勉強を続けられると良いと思います。
過去にはセッションの少なくとも一部でRDRAを扱ったものに、こういったイベントがありました。
- 2019/03/18 RDRA4IoT 勉強会
- 2019/07/09 RDRA2.0の紹介と体験ワークショップ
- 2019/07/23 【再演】RDRA2.0の紹介と体験ワークショップ
- 2019/09/24 BPStudy#145〜進化する要件定義(RDRA meets DDD)
- 2019/09/24 BPStudy#145〜進化する要件定義(RDRA meets DDD) 懇親会
- 2019/10/22 RDRA WorkShop !!
- 2019/10/23 第3回astah関西勉強会「もやもやを分解しよう」
- 2019/12/10 RDRA WorkShop !! #2
- 2019/12/14 レガシーをぶっつぶせ。現場でDDD!2nd 「インプット<アウトプット!」第一部
- 2019/12/14 レガシーをぶっつぶせ。現場でDDD!2nd 「インプット<アウトプット!」第二部
- 2020/01/29 RDRA2.0勉強会@札幌
- 2020/03/30 BPStudy#151〜オブジェクト指向、モデリング、設計 LT大会[リモート開催]
- 2020/06/19 第2回 実践者に学ぶ 設計手法・方法論セミナー
- 2020/06/29 RDRA+プロトタイピングおよび仕様化事例紹介[リモート開催]
- 2020/07/01 【ペチオブ】物語モデリングハンズオン【少人数限定】
- 2020/07/30 BPStudy#155〜要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法
とくにRDRA MeetUp、BPStudy、ペチオブの3つのグループは今もRDRA関連の勉強会を頻繁に開催しているようなので、Connpassからグループに登録して通知を受け取るようにすると見逃しがなくなります。
神崎さんのスライド
具体的なRDRAの実践例を見たい方は、神崎さん自身が公開しているスライドをごらんください。とくにこの2つのケースはダイアグラムが豊富で、現実での適用例を把握するのにぴったりです。私はRDRAダイアグラムを描く際、この2つを参考にするためいつも開きっぱなしにしています。
Enterprise ArchitectのRDRAプラグインによるサポートがすごい
RDRAの書籍で神崎さんも強調していますが、RDRAはツールのサポートがあると飛躍的に使いやすくなります。現在市場に出回っているツールの中では唯一と言っていいかもしれないツールとしてEnterprise ArchitectのRDRAプラグインがあり、こちらのYouTube動画を見れば、マウスのクリックでどんどん関連する情報をたどっていける便利さ、ダイアグラム間の整合性を確認できる便利さがおわかりいただけると思います。
RDRA2.0の書籍では神崎さんが作ったパワーポイント用プラグインもあるので、パワーポイントが利用できる方はそちらを試しても良いでしょう。
最後は実践
あるていどRDRAに詳しくなったら、自分で手を動かしてダイアグラムを描いきましょう。手を動かして初めて分かることもたくさんあります。RDRAは成果物がダイアグラムという非常に明確な形のため、自分ひとりで練習するのにも向いている手法です。この辺も私がソースコードを書く感覚とRDRAを実践する感覚が近いと感じている理由です。
もちろん仕事仲間など複数人で取り組むほうが学べることは多いのですが、必ずしも他人を巻き込むことは容易ではありません陰キャ。一緒に学んでくれる仲間がいるかいないかに関わらず、時間のあるときに自分一人で練習できると上達も早くなります。取り組む対象としては
- 自分が仕事で今取り組んでいるシステム
- 自分が過去に仕事で取り組んだシステム
- インターネット上などで見た、気になるシステム
など、何でもいいので自分が興味のある対象システムについて、RDRAのダイアグラムを起こしてみてください。できれば複数のシステムについて実践するのがよく、とくに初心者のうちは1つのシステムにこだわって深く掘り下げるより、同じ手法を複数の対象システムに適用する方が学習の効率が良いです。
もしあなたが資金に余裕がある場合、Enterprise Architectのライセンスを買いましょう。先に述べたように、ツールのサポートがあることは非常に強力です。これは普段
- IDE: Integrated Development Environment
- CI: Continuous Integration
などのサポートを受けて開発しているエンジニアにはわかりやすいのではないでしょうか?Enterprise Architectを買わない場合は、パワーポイントでもCacooでもLucidChartでも代替ツールを使えば良いです。私は残念ながら資金がたりずEnterprise Architectを買っていません。
おまけ、ツイート検索
自分でRDRAを実践するようになったら、TwitterでRDRA関連のつぶやきを検索するのもおすすめです。提唱者である神崎さんのツイートはもちろんのこと、キーワード=RDRAで検索すると興味深いつぶやきがいくつも出てきます。 要件定義の話なので、どうしても抽象度の高いつぶやきが多いのですが、ピンとこなかったら無理して解釈しようとはしないでください。
それでも何となく共感を感じるつぶやきがあったら、ただ頷くだけではなく、自分の課題領域でどこまでそのつぶやきが当てはまるのか、あるいは当てはまらないケースはあるのか、なぜ現場でその大切さが認識されていないのか、そうやって考えるのが頭の体操になります。
システムは見えないから難しいと言われるが、それと同じくらいビジネスが見えていない
— 神崎 善司 (@zenzengood) August 5, 2020
よく言われることだが、RDRAでシステムの可視化を行っていると「何を行っているか」は分かるが、「なぜそれを行っているかが」分かっていないことをよく目にする
BUCの価値を明確にするためにカスタマージャーニーマップやサービスブループリントなどのツールを使うことが有効と考えている
— 神崎 善司 (@zenzengood) May 10, 2020
そこでそれらのツールとRDRAの関係を整理した pic.twitter.com/f7Kdam9pAT
AsIsを整理し「今はこうなっている」を表し、要求をAsIsのRDRAモデルにマッピング(要求は業務、BUC、UCのレベルがある)し、重要なものを洗い出す
— 神崎 善司 (@zenzengood) March 20, 2020
ToBeのモデルを整理する中で、実現すべきことを「要件」として整理
要求を中心にToBeを組立ることで、「要求はこうだ」「今後はこうする」を表現できる pic.twitter.com/IHIEQFVk0o