実践RDRA〜RDRA2.0実践報告と感想
佐藤治夫氏：それでは始めたいと思います。これまで（他のセッションで）「RDRA（ラドラ）」という用語がいくつか出てきていると思うんですけど、そのRDRAを実践した報告と感想を発表したいと思います。
自己紹介します。佐藤治夫と言います。株式会社ビープラウドの代表をやっています。Twitterのアカウントは@haru860です。会社としてはPyQという、Pythonをオンラインで学べるプラットフォームと、あとconnpassもうちの会社で開発をしています。あとはこの勉強会、BPStudyを主催しています。
今日のアジェンダですが、まずはデジタル・トランスフォーメーション（DX）時代の課題をお話して、そのあとRDRAについて簡単に紹介します。その後、RDRAを今回の実案件でどう実践したかというのをモデルを交えて説明します。最後にまとめとしてRDRAを採用して得られた効果をお話します。
インターネットが登場して、目的が変わった
まずDX時代の課題です。DXと言いますけど、結局はデジタル化・システム化ということだと思います。まず時代の課題としては、インターネットが普及する前は既存業務をシステム化することで合理化するのが目的だったと思います。
インターネットが登場してきて「これはいろんなビジネスにも使えそうだ」となったときに、フワッとしたアイディアからビジネス価値を創造していくことが目的になった。そういうものに目的が変わってきたということで、難易度がアップしてきたと思います。
DX時代の2番目の課題は技術の進化と選択肢の増加です。ここに書いてある図で見ると、左側ですね。1990年ぐらいはホストコンピュータの技術だったり、オープンシステムと言われるVBとか、クライアントサーバシステムみたいなもの、あとはRDBぐらいができていればよかったのが、だんだんWebが広がり、スマホが普及し、クラウド、IoT、AI、〇〇Techといろいろ出てきたので、選択肢が増えて、難しくなってきました。
DX時代の課題はアイデアをかたちにする力の不足
これらを総括すると、DXが難しくなってきた原因を一言で言うと、アイデアをかたちにする力が不足していて、難しくなってきていることだと思います。左側がビジネスサイドで右側がエンジニアサイドを示しているんですけど、アイデアからシステムに落とし込んでいくところに断絶があります。目的の変化による開発の難易度アップと、技術の進化と選択肢の増加が理由です。
ビジネスサイドのほうは、もちろんソフトウェアの開発プロジェクト経験は少ないですし、右側のエンジニアサイドのほうはビジネス経験が少ないです。それが理由で断絶が起きてしまっています。
技術サイドがビジネスサイドに歩み寄って行くほうが早い
じゃあどうするんだということで、まずビジネスサイドが技術を学んで歩み寄っていくという方法と、技術サイドがビジネスサイドに歩み寄っていく方法があると思います。おそらくこの（技術サイドがビジネスサイドに歩み寄って行く）方法が早いかなと思っています。
この三角形の一番上がビジネス価値なんですけど、ビジネス価値、要求、仕様、設計、実装ときて、下の技術サイドのほうを身に付けようとしたら、少しプログラミングを学んだだけでは難しいと思います。上のビジネスサイドのほうは、抽象的に理解もしやすいことも多いですし、学ぶ量も技術に比べたら少ないです。なので、技術サイドが歩み寄ったほうが早いと思っています。
DXへの橋渡しとして、RDRAの活用が有効
技術サイドが歩み寄って取りまとめるときに起こる問題としては、左側のビジネスサイドのほうの経験が少ないゆえに、断片的な情報が出てきたり、もともと話していた根本を覆すジャストアイデアみたいなものが出てきたり、加えて空中戦による認識のズレがあります。あとは、どのように取りまとめるかというのも属人的になっていて、なかなかシステムまで落とし込むのは難しい、ということが起こります。
そういう状況の中ではまとまらないし、終わらないというふうになってしまうんですけど、僕はそのDXの橋渡しとして、RDRAの活用が有効だと思っています。今回は、このRDRAを実プロジェクトで実践してみた結果を報告します。
RDRAとは？
RDRAは、Relationship Driven Requirement Analysisのことで、今日発表した神崎さんが考案している手法です。書籍では『RDRA2.0 ハンドブック』と『モデルベース要件定義テクニック』という本が出ています。『モデルベース要件定義テクニック』は2013年に出ていて、RDRA1.0ベースなんですけど、要件定義で発生する問題と解決策が詳しく語られていて、これは普遍的な話なので大変役に立つと思っています。
RDRAの全体像ですね。（スライドを見て）こういうかたちで、左からシステム価値、あとはシステム外部環境を定義して、システム境界を定義して、最後にシステムを定義する流れで進めて、モデルを定義していきます。RDRAがカバーする領域は、先ほどの三角形の中で、仕様を決めるところぐらいのギリギリのラインだと思っています。Howはやらないので、仕様の細かいところと設計は範囲に含まれていません。
RDRAの実践
ここが今日の本題で、RDRAの実践例を紹介します。事例として取り上げるのは、大手製造企業の主要プロセスのオートメーション化です。先方の担当者はプログラムを書ける、システムをわかる人でした。そういうコンテキストがありました。その担当者からの情報を基に、今回RDRAでやってみました。
私が要件定義と基本設計をメインで担当して、期間としては2019年の年末ぐらいから2020年の3月初めぐらいまでやっていました。
どういう（モデル）を書いたかというと、まずはビジネスコンテキストをやりました。NDA（秘密保持契約）があるので、実際のモデルとは異なるんですけど、簡単に言うと拠点Aから材料が出荷されてきて、拠点Bでその材料を入荷して製造して、お客さんに向けて出荷する業務をRDRAで作りました。ビジネスコンテキストも実際はこんな感じでしたね。こういうふうにシンプルに、一番抽象度の高いモデルを書きました。
次に業務フローです。先ほど業務が洗い出されたところが、その各業務ですね。今回はビジネスユースケースを省いて、直接業務フローを作りました。こういうかたちで業務フローを書いていって、業務フローのアクティビティにつながるユースケースを導出しました。業務フローで契約を登録したりログインしたり、材料を受け入れたり、ロットNoを発行したりみたいなところのユースケースを導出しました。
ここが本来のやり方とは少し違うかもしれません。UC複合図と書いてある左下にぼやけた図がありますが、実際のUC複合図というのは、ユースケースが中心にあって、画面と、どういう情報を扱うのか、イベント、あとはビジネスロジックの条件を書くことになっています。
先ほどヒロさん（林宏勝氏）のICONIXという話が出ましたけど、私はユースケースとICONIXのロバストネス図を使ってUC複合図を書いていきました。これは入出庫するユースケースの例なんですけど、オペレーターが使う入出庫の画面が青で、バウンダリがあって、その画面にアクセスするのがAPI3つですね。
これをUC複合図のイベントと捉えて、APIを書きました。あとは一番右がテーブルのエンティティですね。このエンティティを書いて、これは情報にあたりますと。こういうかたちで画面とAPIとエンティティを抽出していきました。
UC複合図の後フェーズとしては、ユースケースから導出した画面モデルの画面仕様を書きました。あとはAPIが導出されているので、API定義ですね。入力パラメータとAPIの処理と実際のレスポンス、出力は何かというのを書きました。あとは、この案件はGraphQLで作ったので、そのAPIの定義、論理的なものを元に、スキーマとクエリとミューテーションを定義していきました。
点線が縦に入っているんですけど、右側はRDRAの対象外になります。HowはRDRAの対象外なので、画面仕様とかAPI定義も対象外になります。
情報モデルというところで、先ほど4つのテーブルが導出されていましたが、他にもUC複合図を書いていくと、それを取りまとめていくうちに、ER図、クラス図が導出されていくので、それを全体の図として取りまとめていくことをやりました。ER図もRDRAの対象外です。
あとは状態モデルです。実際はもうちょっと複雑なんですけど、実際に製造するものは、最初は材料で、ユースケースの受け入れで材料を受け入れて、仕掛製品というものになって、品質の検査をして、在庫品になって出荷というユースケースで、出荷されて製品になるというところの業務フローを、ユースケースと交えて書きました。こうやって記載することで、状態モデルとユースケースがリレーションできます。
紹介したモデルの全体像です。左から始めてビジネスコンテキストがあって、ビジネスコンテキストによって導出された業務を業務フローに書いて、業務フローのアクティビティからそのアクティビティを構成するユースケースを導出して、その導出されたユースケースから画面とAPIとイベント、エンティティ、情報モデルを導出して、それぞれの仕様設計を書いていくというやり方をしました。
あとは情報モデルを取りまとめてER図に持って行きました。あとは状態モデルです。ユースケースとつないでやりました。このまま実装すればいいということを「実装Ready」と書いてますけど、それを要件定義と基本設計の完了と位置付けました。
規模としてはUC複合図が15個、APIが39個、テーブルが72個導出されましたというぐらいのシステムです。今回作成したモデルは、この赤のところですけど、左側の青いところは今回紹介は省きました。
RDRAを採用して得られた効果
RDRAを採用して得られた効果です。まずは情報を整理しやすかったことがあげられます。業務担当者から多くの情報が出てくるので、その情報をどうやって取りまとめるかが課題でした。
業務フローだったり、業務ルールだったり、データだったり、画面というのがバラバラで出てきますが、それらを取りまとめる場所（モデル）がわかっているというだけで、この情報はどのモデルの話なんだろうと考えながらやることができ、枠組みに従って整理できたのは、けっこうやりやすかったです。
次に情報の保守性の向上です。「関心事の分離」と書いてあるんですけど、三角形の上にいくほど抽象度が高いので、変更や変化が少ない情報です。そういうものをちゃんとまとめておいた上で、画面仕様だったりAPI仕様だったり、あとはER図は変更が入りやすいので、書いても捨てちゃってもいいと思うし、あとはソースコードで表すのもいいのかなと思っています。
ということで、要件定義から設計、実装までの関心事は分離できたなと。こういう情報が抽象的な情報と具体的な情報が一緒に入ってしまうと、「情報が腐る」「ドキュメントが腐る」みたいな問題があります。
加えて、トレーサビリティの向上です。APIがどのユースケースで使われているのか、APIがその業務で使われているのか、テーブルがどのユースケースで使われているか、テーブルがどのAPIで使われているかという、影響範囲が特定しやすくなりました。ただ図を書いただけではダメなんですけど、ちょっとツールで工夫したので、トレーサービリティを向上できました。
今回やってみて、UC複合図が、先ほどヒロさんの話の中で「要件と実装をつなげる」という話がありましたが、糊付け的な役割、仕様と設計、実装を紐づけるための重要な位置付けだなと感じました。
RDRAは名捕手だ
RDRA使いは名捕手のようだと思いました。野球で捕手というのは監督の意図を知って流れを読んで試合を作る役割です。あとは女房役ということで、投手の投げたい球を言わなくても知っている存在です。名チームに名捕手ありと言われますけど、捕手というのは目立たない存在でヒーローインタビューにもあまり上がってこない。ヒーローにはなりません。
先ほどのDXでのプロジェクトでも、RDRAを使う人は経営者の意図を知って、情報の流れを読んでプロジェクトを作っていく役割です。企画者のこともよく知っていて、実際にモノを作るプログラマーのことも知っている女房役だと思います。
成功プロジェクトに、名RDRA使いがいると思います。RDRA使いは目立たない存在ですが、プロジェクトを見える化して全体をうまくいかせています。みんな褒めてくれないんだけど、うまく回している影の存在だなと思いました。
まとめです。DX時代の課題としては、アイデアをかたちにする力が不足しています。ビジネスサイドと技術サイドが断絶していているのが現状です。断絶の理由はそれぞれのサイドのそれぞれの経験不足、ソフトウェア開発の導入目的が、合理化からビジネス価値の創造に変化して、企画の難易度がアップ。そして、技術の進化と選択肢の増加があります。
あと情報を取りまとめるとき、バラバラに出てきたり空中戦になってきたり、取りまとめ方が属人的になってしまう。そういうところで、RDRAが有効なんじゃないかと思って、今回使ってみましたと。RDRA2.0を実践した結果、実装Readyの状態にもっていけて、戻りの少ない開発ができていると感じています。
情報の整理のしやすさ、情報の保守性向上、トレーサビリティの向上が得られた効果です。成功プロジェクトに、名RDRA使いありということで、終わります。ご清聴ありがとうございました。
