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

JJUG CCC 2022 Spring 登壇資料
https://fortee.jp/jjug-ccc-2022-spring/proposal/c74c869a-b0ac-4cde-a22f-3c2592b68744

レジャー業界のSaaSを提供するアソビューで実践するRDRA + Javaによる要件定義と実装の流れを紹介します。

ソフトウェア開発において、規模の大きなプロジェクトであればあるほど要件定義と実装の断絶を起こしがちで、正しいあるべき姿が失われていくことにより長期的に開発コストが積み上がっていくことが多々あるとおもいます。
アソビューでは、RDRAとDDDのエッセンスを用いて、ビジネス要求を高い網羅性と整合性を持って整理し、長期的に要件と実装が一体となった状態を保っていくことにチャレンジしています。
本発表では実際のレジャー施設向けSaaS開発プロジェクトを具体例として紹介します。まだ道半ばのプロジェクトではありますが、一つの事例として参考にしていただければと思います。

Transcript

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

   JJUG CCC 2022 Spring

   

   江部隼矢 @junyaebe

   

   View Slide

2. 自己紹介

   ● 江部隼矢（えべじゅんや）

   ● 　　@junyaebe

   ● アソビュー株式会社 CTO

   ● Javaエンジニア

   ○ JJUG CCC 初参加

   ● 3児の父

   ● 旅行、キャンプ、温泉、お酒

   2

   

   View Slide

3. 今日の内容

   実際のプロダクト開発でRDRA+Javaで要件定義と実装をつ
   なげてみたお話

   3

   実際のプロジェクトを題材に
   

   1. どのように要件定義を進めたのか
   

   2. 定義した要件をどのようにソースコードで表現していっているのか
   

   を紹介します。

   

   View Slide

4. 全国のレジャー施設約10,000施設向けの業務支援SaaS
   開発プロジェクト

   背景

   ● 10年間に渡る戦略・事業モデルの変化による 

   [事業 ⇔ 業務 ⇔ システム] 間の実態乖離 

   ● 肥大化した手運用業務 

   ● レガシー化・ブラックボックス化したシステム 

   今後の事業戦略にマッチするシステムにすべく、いろんな
   人の夢と希望と期待とともに開始

   事例プロジェクト

   4

   

   View Slide

5. 進めていくにあたって

   ● 新規参画の開発者が早く活躍できるような環境を整備していきたい
   

   ○ 効率的にキャッチアップできるようにしたい 

   ○ 包括的な情報がまとまっている状態を維持していきたい 

   ● 陳腐化していくだけのドキュメントを作りたくない
   

   ○ フリースタイルなドキュメントは属人化する 

   ■ 勝手にさわっていいのかわからない 

   ■ 書き方もわからない 

   ○ 放置され嘘かホントかわからない情報に惑わされる 

   ● 事業実態とシステムの乖離を長期的に抑えていきたい
   

   ○ 意図しない使い方で問題がおきないようにしていきたい 

   ● あらゆるステークホルダーとの共通理解のベースを作りたい
   

   ○ 全員が同じ土台で理解することでコミュニケーションコストを減らしていきたい 

   ○ 共通理解がそのまま実装にリンクしている状態を作りたい！ 

   5

   RDRA + DDDでやってみよう！

   

   View Slide

6. RDRAとは

   ● モデルベースの要件定義手法 

   ● 株式会社バリューソースの神崎さん考案 

   ● WhatとWhyをRDRAで定義 

   

   6

   

   View Slide

7. プロジェクト準備

   7

   

   View Slide

8. プロジェクト憲章の作成・合意

   しっかり言語化・合意 

   プロジェクトの背景、要求事項、目的 

   ざっくり認識あわせ

   スケジュール、体制、予算、刷新対象スコープ 

   

   ● 経営陣・部門長レイヤーで合意 

   8

   

   View Slide

9. 要求事項の洗出し

   ● 各組織における新プロジェクト
   への期待をヒアリング 

   ● ヒアリングした結果を 戦略要
   求、業務要求、IT要求、達成
   基準に構造化

   ● それぞれに高、中、低で優先
   順位をつけ、高、中を1stス
   コープにすることを仮ぎ め

   ● 夢と希望を早い段階で構造化
   し整理し要求事項に落とし込
   みつつ期待を整理する。 

   9

   戦略要求 経営・事業として実現したい目標
   業務要求 戦略要求を実現するための施策
   IT要求 施策実行のためにシステムで実現したい要求
   実現機能 IT要求を満たすために必要な機能
   理由・背景 その機能が必要な理由
   

   View Slide

10. 要件定義セッション

    10

    

    View Slide

11. コアメンバー全員で議論しながらその場でどんどんRDRAモデルを作りあげていく

    要件定義セッション

    11

    経営ボード
    プロジェクト
    関連
    部門
    関連
    部門
    CTO PM Arch
    En QA
    事業
    責任者
    スタッフ
    事業
    責任者
    スタッフ
    他
    役員
    レポート・ヒ
    アリング
    ヒアリング
    アウト
    プット
    RDRAモデル
    ● 弊社の場合は共同作業のしやすさを重視し表（Spreadsheet）で構造管理

    ● 各モデルを行ったり来たりしながら全体の整合性を揃え精度をあげていく

    ● その場で決まらないことはステークホルダーを招集し決め方を決める

    

    View Slide

12. システム価値

    12

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

    

    View Slide

13. 業務・BUC・アクティビティ & 情報 ①

    13

    全体のバリューチェーンを起点に業務を整理し、それぞれでどのような情報が取り扱われるかを考える 

    

    バリューチェーン
    業務・BUC・アクティビティ
    情報
    ID管理される粒度を意
    識
    ユビキタス言語になるので
    名前付けの納得感が重要
    

    View Slide

14. 業務・BUC・アクティビティ & 情報 ②

    洗い出した業務と情報から、それぞれの情報を操作するUCを考える 

    14

    

    View Slide

15. 状態モデル

    15

    情報の状態を洗い出し、どのUCが情報の状態を遷移させるのかを明らかにする。 

    状態
    足りないUCに気づく
    

    View Slide

16. バリエーション・条件

    16

    ● UCごとに条件（ビジネスルール）を明確化 

    ● コンテキストごとにどのようなビジネスのバリエーションが存在するかを考える。 

    ● システムがバリエーションごとに判断を変えるか？を基準に考える 

    バリエーション・状態関係なく、単純な計算ロ
    ジックの場合もある
    

    View Slide

17. 各要素の関連付け

    17

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

    

    View Slide

18. 情報 => 概念モデル

    18

    情報
    情報の関連付けを整理し、概念モデルを作る。 

    複雑な仕様に関してはオブジェクトモデルで具体例を当て、成立するか検証する 

    

    

    

    View Slide

19. 19

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

    概念モデル
    

    View Slide

20. Spreadsheetを使って関連付けできていない孤立した要素を洗い出す

    20

    ● 例 外部システムの定義の網羅性をSpreadsheetの関数でチェック 

    

    View Slide

21. 実装への落とし込み

    21

    

    View Slide

22. アプリケーション層
    Package
    Subpackage
    ドメイン層
    RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング

    

    22

    インフラストラクチャ層
    Service
    業務
    BUC
    Activity
    UC
    プレゼンテーション層
    RDRA
    実装
    

    View Slide

23. 業務 ⇔ アプリケーション層 

    23

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

    View Slide

24. コンテキスト
    アプリケーション層
    Package
    Subpackage
    ドメイン層
    Package
    Subpackage
    RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング

    

    24

    プレゼンテーション層
    Service
    業務
    BUC
    Activity
    UC
    Domain
    Obj
    情報
    状態モデル
    バリエーション
    状態
    Enum
    インフラストラクチャ層
    条件
    RDRA
    実装
    

    View Slide

25. 情報モデル ⇔ ドメイン層

    25

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

    View Slide

26. コンテキスト
    アプリケーション層
    Package
    Subpackage
    ドメイン層
    Package
    Subpackage
    RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング

    

    26

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

    View Slide

27. UC実装

    27

    条件を定義するのはドメ
    インロジック、条件を発動
    するのはValidation、
    Controller, Service etc.
    Package
    Subpackage
    Controller
    Form
    UI
    商品管理担当者 → 基本情報登録画面

    基本情報登録条件の発動
    

    商品外部連携条件の発動
    

    POSシステムへの連携
    

    商品情報の登録
    

    

    View Slide

28. 以降のイテレーション

    28

    ● ビジネスの変化はRDRAを起点に取り組んでいく 

    ● RDRA ⇔ Javaの整合チェックはJIGを利用して出力した分析と比較するのがよさそう 

    RDRA
    Java
    JIGドキュメント
    要件定義
    ビジネス
    の変化 実装
    生成
    比較・チェック
    

    View Slide

29. まとめ

    29

    

    View Slide

30. まとめ

    手応えを感じたところ 

    ● “夢と希望”から実際のシステムの輪郭を構造化して表現できた 

    ● 要件が構造化されているため、プログラムコードへの落とし込みとマッピングがスムーズ 

    ● 新しい人がふえても、RDRAからキャッチアップしていくことが容易 

    ● 記法が統一されているためだれでもメンテナンスしていける 

    今後の課題

    ● ビジネス要件の根拠となるもの（例: 事業企画や営業で管理している契約、顧客要望、ビジネスルールな
    ど）と、RDRA間のマッピングをどうするか 

    ○ プロジェクトチームから全体へRDRAモデルの共通理解を広げる 

    ● 体制や組織変更などの大局に呑まれずRDRAと実装の整合性をあわせていく文化・ルール作り 

    ● 今後実装がすすんでいくにつれて詳細なノウハウを蓄積して発信したい 

    30

    

    View Slide

31. ご静聴ありがとうございました！

    31

    参考文献

    ● 神崎善司 （2019）『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』 

    ● 増田亨 (2017) 『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 』 技術評論社 

    

    View Slide