RDRAで学ぶ要件定義から設計へ その１
この記事の背景
弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが出てきました。
その背景として、作って貰った課題となるシステムについて、コーディングが絡む設計面については問題なかったのですが、
- システムの全体感が捉えきれていない
- 捉えるためのドメイン調査が足りていない
- 業務（ビジネス）とシステムの境界があやふやに捉えて表現してしまっている
- 業務フローの粒度がちぐはぐになっている
- 業務の全体像が見えていないので、派生して必要になる機能が漏れてしまっている
といったような問題点があったので、これらをしっかりと身につけてもらうには、要件定義から設計を一度インプットした上で、実際に業務でイメージしながら活用・経験してもらうことで伸びていって貰おうということになりました。
要件定義から設計を一度インプットする際に、弊社でよく活用している体系だってまとまっていてライトに進めやすいので RDRA を軸にレクチャーしていくことになりました。 一つの方法を知ると、他にも応用が効くので、RDRA で学んだことは要件定義から設計をするといったプロセスにおいて活きてくるハズです。
また、どうせレクチャーするなら、自分の知見をまとめなおすということも合わせてやってしまおうということで、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめておこうという一石二鳥な連載記事になる予定です。
今回の「その１」では、RDRA とはどんなものなのかといったことと、システム価値レイヤーについて、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。
RDRA とは？
RDRA は、神崎善司氏が考案したリレーションシップ駆動要件分析(Relationship Driven Requirement Analysis)の略語で、「らどら」と読みます。 要件を素早く決定するために、網羅的で整合の取れた要件を組み立てられる仕組みを提供するモデルベースの要件定義手法です。
詳しくは、神崎さんの以下のホームページを見ていただくのと
http://k-method.jp/k-method.jp
こちらの神崎さんが書かれた本を読んでいただくと、より深く知れます。
RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法
この記事では、神崎さんの本から少し引用させていただきつつ、僕が RDRA を活用している際の思いやテクニックを中心に書いていきます。
要件定義では何を定義するのか
要件定義とは、名前の通り、何をシステム化するか要件を決めます。
どういったビジネスを展開していて、どういった業務の中で、どんな要求があってといったところから要求を分析して、その中からシステム化する要件を機能要件や非機能要件として、まとめていきます。
RDRA では、要件定義書といった文書化をするのではなく、モデルで要件を定義しています。 なぜ、モデルで定義していくかといった点について神崎さんの本では、
システム機能（画面、機能、データなど）のことしか書かれていない要件定義書では、具体的な仕様化ができずシステム化はうまくいきません。「なぜ」このような機能が必要なのかが書かれておらず、画面や機能を深掘りしようにも、そのための判断材料が欠けているからです。 〜 RDRA2.0 ハンドブック から引用 〜
と書かれています。
要件定義をしていく中で、どうしてそれをシステム化するのか、どうしてその機能は必要なのか、といったような要求や業務やビジネスといった背景がない状態だと、ただただその機能だけを見て開発してしまったり、書かれたことが要求からすると足りなかったりと、作ったものがあまり価値の無いものになってしまいます。
根拠があって、システム化することが大事です。
「なぜ」このような機能が必要なのかが遡れるようになっていると、その根拠を踏まえて設計やプログラミングを実施していくことができるようになり、価値があるものを作りやすくなっていきます。
RDRA では、その遡りができるように 4 つの視点で分類をしながら、システムの要件定義を捉えています。
RDRA が提供する 4 つの視点
RDRA は、全体像に記載した通り、以下の 4 つの視点で分類しています。
- システム価値
- システム外部環境
- システム境界
- システム
「システム価値」は、
- システムコンテキスト図
- 要求モデル図
といったダイアグラムで、システム化することの価値を表現するレイヤーです。
システム外部環境は、
- ビジネスコンテキスト図
- ビジネスユースケース図
- 業務フロー図
- 利用シーン図
- バリエーション・条件図
といったダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったシステムを使う上での環境を表現するレイヤーです。
システム境界は、
- ユースケース（UC）複合図
といったダイアグラムで、システム化する単位の「（システム）ユースケース」と画面やイベント、情報と条件を組合わせることで、開発対象となる入出力、情報、条件といったものを明確に表現するレイヤーです。
システムは、
- 情報モデル図
- 状態モデル図
といったダイアグラムで、ビジネス上で使っている用語を構造化して情報や状態をシステム化対象として表現するレイヤーです。
このようなダイアグラムで要件を定義することで、ダイアグラムを階層化して繋がりのある形でシステムを俯瞰することができると共に、以下の様にコミュニケーションの土台ができることによる認識共有がしやすいといったメリットが生まれます。
図の利点は、打ち合わせで使いやすいことです。ダイアグラムは「作って終わり」というドキュメントとして捉えるのではなく、要件を定義するためのコミュニケーションツールと捉えることが大事です。つまり、要件定義を「ドキュメント作成作業」と考えるのではなく、「要件を可視化し、合意し、定義する作業」と捉えることです。RDRAはコミュニケーションを促進し、素早く要件を合意するための仕組みを提供しています。RDRAの目的はドキュメントを作ることではなく、コミュニケーションの土台を作ることです。 〜 RDRA2.0 ハンドブック から引用 〜
ダイアグラム表現の方法
RDRA は、
- Power Point でのツール*1
- Enterprise Architect*2
- Google Spreadsheet*3
などで表現が可能となっています。
miro などのツールを活用して同様に描いていくこともできますが、これらを使って表現すると関係性を持った形でモデルやダイアグラムが管理できるので、RDRA の本質である関連性を持って要件や機能を管理することができるようになります。
根拠があって、システム化
前段で書きましたが、
「なぜ」このような機能が必要なのかが遡れるようになっていると、その根拠を踏まえて設計やプログラミングを実施していくことができるようになり、価値があるものを作りやすくなっていきます
RDRA は、この「なぜ」について、下図の様にダイアグラムやモデル要素の関連（リレーション）で遡っていくことができます。より上流で検討したものに依存している形になっています。
そのため、根拠を踏まえて機能や情報を考えていくことができるようになります。
この様にそれぞれがつながっていくことで、
- 要求に沿ったシステムであるか否かを確認
- 影響度の分析や整合性、網羅性を確認できる
といったことが、RDRA ではできる様になっています。
システム価値レイヤー
システム価値レイヤーは、
- システムコンテキスト図
- 要求モデル図
といったダイアグラムで、システム化することの価値を表現するレイヤーです。
最上位のオーバービューになるので、この先、システムを考えていく中で、立ち返ってくる原点が表現されたものとなります。 なぜ、このシステムを作るのか、誰が関わるのか、誰がどういった要求を持っているのか、そういったことを表現していきます。
システムコンテキスト図
要件定義の最初の時点でプロジェクトメンバーの認識を合わせるために作成するのが「システムコンテキスト図」 〜 RDRA2.0 ハンドブック から引用 〜
システムコンテキスト図を描くことで、システム化の目的や、システムに関わる人（アクター）や外部システムを洗い出します。
- システムスコープを決めるための認識を合わせる
- システム化するにあたっての判断基準となる目的を明確にする
といった効果があります。
全て洗い出すと、情報が多くなりすぎてしまうこともあるので、重要なものだけにフォーカスして上げていくものになります。
システムコンテキスト図 高崎Tips
アクターはロール名で上げるものだが、描いたアクターが抽象的な名称になっていたりすると、どの様な関係者か分からなくなる。そのため、その人に対する説明やコメントを残しておくと良い。そのアクターの認識合わせがずれてしまっていると、何をやっている人かがズレたまま話が進んでしまうので、具体化もしておくと共有しやすい。その際には、抽象的なロール名から、実際に担当している具体的な人物名を出したりして、顧客と認識合わせをしています。
外部システムについては、どう連携させるか、していくのか、メモがあると良い。そういった連携方法が分かるとイメージもつきやすいです。
外部システムってどんな機能を持っているかを把握しておかないと、後々、機能を考えていく際にも分かりにくい。外部システムを知るには、そのシステムのマニュアルやヘルプ等の説明を見ると情報を得ることができイメージもつきやすいです。どんな機能があるか分かっていると、そこから将来の連携や機能追加とかにも繋がっていくと思っています。
全体的に、色々と付加情報をつけていくことでシステムコンテキスト図を育てると、より伝わりやすいかなと思っています。もちろん、書きすぎちゃうとどの情報が重要なのか分からなくなるので、重要な情報を簡潔に記載しておくのが良いですが。
要求モデル図
プロジェクトを始める段階で要求一覧のようなものは用意されているはずです。それらの要求から重要なものを選び出し、要求の関係を整理することでシステム化の方向性を明らかにする 〜 RDRA2.0 ハンドブック から引用 〜
要求モデルを描くことで、要望レベルなのか、要求レベルなのか、要件レベルなのかといった要求レベルと、誰がその要求を持っているのかといったアクターとの関係を整理できます。
システムコンテキスト図で洗い出されたアクター（ステークホルダー）をベースに、どの様な要求を持っているかを紐付けて整理していきます。
それらを整理することで、システム化の方向性が明らかになってくるので、
- 重要な要求の整理と実現する要件を明らかにする
- 重要なステークホルダーの要求を把握する
といった開発するシステムにとって、重要なものは何かということが洗い出されてきます。
要求モデル図 高崎Tips
話を聞いていて要求が想定された際に、すぐに追加するのではなく、深掘りして聞く。Q&A 的に深掘りしていく中で、その要求が要望なのか、要求なのか、要件なのかといったレベル感を把握したり、今欲しいのか将来で良いのかといった時期感をしっかりと把握する。そうすることで、要求の重要性が見えてくる。
その要求が重要なのか、システムコンテキスト図の目的に立ち返って判断する。
目的は意思決定の最上位の判断基準なので、これが定まると意思決定が早まります。複数の案があった時にも目的に一番沿ったものにすれば、判断に迷いがなくなります。従って、地味ですが目的を決めることはとても重要なことです 〜 RDRA2.0 ハンドブック から引用 〜
といった様に、システムコンテキスト図の目的があることで、要求を整理して、やるべきことを判断する際の指針となっていきます。
- 将来的に追加するものも情報を残しておく（諸説あり）
この話を考えた時に、RDRA の産みの親である神崎さんや、深く使用されている増田さんらとも Twitter で議論になったので、そのスレッドトップを掲載しておきます。
社員に #RDRA レクチャーをしている際に出た質問
— Kentaro Takasaki | アクティアCOO (@ken_takasaki) 2022年2月4日
要件を聞いている中で出てくる将来的な話を取っておくと、設計考慮に使えたり将来の提案に活きると聞いたが、どう残すのが良いか？
僕の回答は、
①各モデルにメモで残す
②要望レベルで要求モデルに書いておく
③別途、一覧で残す
皆はどうしてる？
今回は、ここまで。
次回は、「システム外部環境」についてまとめていこうと思います。
*1:詳しくは、 要件定義の散歩道 - RDRAにビジネスルールを盛り込むためにxTextやドローツールを試してみたが、PowerPoi... を参照ください。ダウンロード先は、RDRA2.0 ハンドブックに記載されています
*2:詳しくは、 Enterprise ArchitectでRDRA 2.0を利用する - UML/SysML/BPMNモデリングツール Enterprise Architect を参照ください
*3:神崎さんが絶賛開発中なので、そのうち公開されてくるのではないかと思います
