RDRA + JavaによるレジャーSaaSプロダクトの要件定義と実装のシームレスな接続

by Junya

Slide 1

Slide 1 text

RDRA + JavaによるレジャーSaaSプロダクトの要件定義と実装のシームレスな接続   JJUG CCC 2022 Spring    江部隼矢 @junyaebe 

Slide 2

Slide 2 text

自己紹介  ● 江部隼矢（えべじゅんや）  ● 　　@junyaebe  ● アソビュー株式会社 CTO  ● Javaエンジニア  ○ JJUG CCC 初参加  ● 3児の父  ● 旅行、キャンプ、温泉、お酒  2 

Slide 3

Slide 3 text

今日の内容  実際のプロダクト開発でRDRA+Javaで要件定義と実装をつなげてみたお話  3  実際のプロジェクトを題材に   1. どのように要件定義を進めたのか   2. 定義した要件をどのようにソースコードで表現していっているのか   を紹介します。 

Slide 4

Slide 4 text

全国のレジャー施設約10,000施設向けの業務支援SaaS 開発プロジェクト  背景  ● 10年間に渡る戦略・事業モデルの変化による   [事業 ⇔ 業務 ⇔ システム] 間の実態乖離   ● 肥大化した手運用業務   ● レガシー化・ブラックボックス化したシステム   今後の事業戦略にマッチするシステムにすべく、いろんな人の夢と希望と期待とともに開始  事例プロジェクト  4 

Slide 5

Slide 5 text

進めていくにあたって  ● 新規参画の開発者が早く活躍できるような環境を整備していきたい   ○ 効率的にキャッチアップできるようにしたい   ○ 包括的な情報がまとまっている状態を維持していきたい   ● 陳腐化していくだけのドキュメントを作りたくない   ○ フリースタイルなドキュメントは属人化する   ■ 勝手にさわっていいのかわからない   ■ 書き方もわからない   ○ 放置され嘘かホントかわからない情報に惑わされる   ● 事業実態とシステムの乖離を長期的に抑えていきたい   ○ 意図しない使い方で問題がおきないようにしていきたい   ● あらゆるステークホルダーとの共通理解のベースを作りたい   ○ 全員が同じ土台で理解することでコミュニケーションコストを減らしていきたい   ○ 共通理解がそのまま実装にリンクしている状態を作りたい！   5  RDRA + DDDでやってみよう！ 

Slide 6

Slide 6 text

RDRAとは  ● モデルベースの要件定義手法   ● 株式会社バリューソースの神崎さん考案   ● WhatとWhyをRDRAで定義     6 

Slide 7

Slide 7 text

プロジェクト準備  7 

Slide 8

Slide 8 text

プロジェクト憲章の作成・合意  しっかり言語化・合意   プロジェクトの背景、要求事項、目的   ざっくり認識あわせ  スケジュール、体制、予算、刷新対象スコープ     ● 経営陣・部門長レイヤーで合意   8 

Slide 9

Slide 9 text

要求事項の洗出し  ● 各組織における新プロジェクトへの期待をヒアリング   ● ヒアリングした結果を戦略要求、業務要求、IT要求、達成基準に構造化  ● それぞれに高、中、低で優先順位をつけ、高、中を1stスコープにすることを仮ぎめ  ● 夢と希望を早い段階で構造化し整理し要求事項に落とし込みつつ期待を整理する。   9  戦略要求経営・事業として実現したい目標業務要求戦略要求を実現するための施策 IT要求施策実行のためにシステムで実現したい要求実現機能 IT要求を満たすために必要な機能理由・背景その機能が必要な理由

Slide 10

Slide 10 text

要件定義セッション  10 

Slide 11

Slide 11 text

コアメンバー全員で議論しながらその場でどんどんRDRAモデルを作りあげていく  要件定義セッション  11  経営ボードプロジェクト関連部門関連部門 CTO PM Arch En QA 事業責任者スタッフ事業責任者スタッフ他役員レポート・ヒアリングヒアリングアウトプット RDRAモデル ● 弊社の場合は共同作業のしやすさを重視し表（Spreadsheet）で構造管理  ● 各モデルを行ったり来たりしながら全体の整合性を揃え精度をあげていく  ● その場で決まらないことはステークホルダーを招集し決め方を決める 

Slide 12

Slide 12 text

システム価値  12  アクター外部システムシステムの価値を享受する人や外部システムを考え、システムの輪郭を捉える  

Slide 13

Slide 13 text

業務・BUC・アクティビティ & 情報 ①  13  全体のバリューチェーンを起点に業務を整理し、それぞれでどのような情報が取り扱われるかを考える     バリューチェーン業務・BUC・アクティビティ情報 ID管理される粒度を意識ユビキタス言語になるので名前付けの納得感が重要

Slide 14

Slide 14 text

業務・BUC・アクティビティ & 情報 ②  洗い出した業務と情報から、それぞれの情報を操作するUCを考える   14 

Slide 15

Slide 15 text

状態モデル  15  情報の状態を洗い出し、どのUCが情報の状態を遷移させるのかを明らかにする。   状態足りないUCに気づく

Slide 16

Slide 16 text

バリエーション・条件  16  ● UCごとに条件（ビジネスルール）を明確化   ● コンテキストごとにどのようなビジネスのバリエーションが存在するかを考える。   ● システムがバリエーションごとに判断を変えるか？を基準に考える   バリエーション・状態関係なく、単純な計算ロジックの場合もある

Slide 17

Slide 17 text

各要素の関連付け  17  業務 BUC Activity UC 情報イベント外部システム画面条件アクター各要素を関連付けることで人や外部システムがどうシステムと関わるかをユースケースとつなげて定義する 

Slide 18

Slide 18 text

情報 => 概念モデル  18  情報情報の関連付けを整理し、概念モデルを作る。   複雑な仕様に関してはオブジェクトモデルで具体例を当て、成立するか検証する      

Slide 19

Slide 19 text

19  アクター外部システム UC複合表状態情報バリエーション条件精度を向上させていく  概念モデル

Slide 20

Slide 20 text

Spreadsheetを使って関連付けできていない孤立した要素を洗い出す  20  ● 例外部システムの定義の網羅性をSpreadsheetの関数でチェック  

Slide 21

Slide 21 text

実装への落とし込み  21 

Slide 22

Slide 22 text

アプリケーション層 Package Subpackage ドメイン層 RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング    22  インフラストラクチャ層 Service 業務 BUC Activity UC プレゼンテーション層 RDRA 実装

Slide 23

Slide 23 text

業務 ⇔ アプリケーション層   23  アプリケーション層 Package Subpackage Service 業務 BUC Activity UC

Slide 24

Slide 24 text

コンテキストアプリケーション層 Package Subpackage ドメイン層 Package Subpackage RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング    24  プレゼンテーション層 Service 業務 BUC Activity UC Domain Obj 情報状態モデルバリエーション状態 Enum インフラストラクチャ層条件 RDRA 実装

Slide 25

Slide 25 text

情報モデル ⇔ ドメイン層  25  商品コンテキスト商品料金カテゴリ状態モデル : 商品準備中販売中アーカイブ <バリエーション > 外部連携種別基本情報登録条件商品外部連携条件状態を判断するのはドメインロジック、状態を伝えるのはEnum

Slide 26

Slide 26 text

コンテキストアプリケーション層 Package Subpackage ドメイン層 Package Subpackage RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング    26  プレゼンテーション層インフラストラクチャ層 Service 業務 BUC Activity UC Domain Obj 情報状態モデルバリエーション状態 Enum 条件 RDRA 実装 ● あくまでもとっかかりとしてのガイドライン ● 実装を進めていくなかで実装の粒度を最適化していくデータソースデータモデル外部システム XXXClient Package Subpackage Controller Form イベント IF UI 画面 Figma

Slide 27

Slide 27 text

UC実装  27  条件を定義するのはドメインロジック、条件を発動するのはValidation、 Controller, Service etc. Package Subpackage Controller Form UI 商品管理担当者 → 基本情報登録画面  基本情報登録条件の発動   商品外部連携条件の発動   POSシステムへの連携   商品情報の登録  

Slide 28

Slide 28 text

以降のイテレーション  28  ● ビジネスの変化はRDRAを起点に取り組んでいく   ● RDRA ⇔ Javaの整合チェックはJIGを利用して出力した分析と比較するのがよさそう   RDRA Java JIGドキュメント要件定義ビジネスの変化実装生成比較・チェック

Slide 29

Slide 29 text

まとめ  29 

Slide 30

Slide 30 text

まとめ  手応えを感じたところ   ● “夢と希望”から実際のシステムの輪郭を構造化して表現できた   ● 要件が構造化されているため、プログラムコードへの落とし込みとマッピングがスムーズ   ● 新しい人がふえても、RDRAからキャッチアップしていくことが容易   ● 記法が統一されているためだれでもメンテナンスしていける   今後の課題  ● ビジネス要件の根拠となるもの（例: 事業企画や営業で管理している契約、顧客要望、ビジネスルールなど）と、RDRA間のマッピングをどうするか   ○ プロジェクトチームから全体へRDRAモデルの共通理解を広げる   ● 体制や組織変更などの大局に呑まれずRDRAと実装の整合性をあわせていく文化・ルール作り   ● 今後実装がすすんでいくにつれて詳細なノウハウを蓄積して発信したい   30 

Slide 31

Slide 31 text

ご静聴ありがとうございました！  31  参考文献  ● 神崎善司（2019）『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』   ● 増田亨 (2017) 『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』技術評論社  