Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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開発プロジェクトを具体例として紹介します。まだ道半ばのプロジェクトではありますが、一つの事例として参考にしていただければと思います。

050b8cdbe92809580ed71d0d0d327e36?s=128

Junya
PRO

June 21, 2022
Tweet

Other Decks in Technology

Transcript

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


    江部隼矢 @junyaebe

  2. 自己紹介
 • 江部隼矢(えべじゅんや)
 •   @junyaebe
 • アソビュー株式会社 CTO
 • Javaエンジニア


    ◦ JJUG CCC 初参加
 • 3児の父
 • 旅行、キャンプ、温泉、お酒
 2

  3. 今日の内容
 実際のプロダクト開発でRDRA+Javaで要件定義と実装をつ なげてみたお話
 3
 実際のプロジェクトを題材に 
 1. どのように要件定義を進めたのか 
 2.

    定義した要件をどのようにソースコードで表現していっているのか 
 を紹介します。

  4. 全国のレジャー施設約10,000施設向けの業務支援SaaS 開発プロジェクト
 背景
 • 10年間に渡る戦略・事業モデルの変化による 
 [事業 ⇔ 業務 ⇔

    システム] 間の実態乖離 
 • 肥大化した手運用業務 
 • レガシー化・ブラックボックス化したシステム 
 今後の事業戦略にマッチするシステムにすべく、いろんな 人の夢と希望と期待とともに開始
 事例プロジェクト
 4

  5. 進めていくにあたって
 • 新規参画の開発者が早く活躍できるような環境を整備していきたい 
 ◦ 効率的にキャッチアップできるようにしたい 
 ◦ 包括的な情報がまとまっている状態を維持していきたい 


    • 陳腐化していくだけのドキュメントを作りたくない 
 ◦ フリースタイルなドキュメントは属人化する 
 ▪ 勝手にさわっていいのかわからない 
 ▪ 書き方もわからない 
 ◦ 放置され嘘かホントかわからない情報に惑わされる 
 • 事業実態とシステムの乖離を長期的に抑えていきたい 
 ◦ 意図しない使い方で問題がおきないようにしていきたい 
 • あらゆるステークホルダーとの共通理解のベースを作りたい 
 ◦ 全員が同じ土台で理解することでコミュニケーションコストを減らしていきたい 
 ◦ 共通理解がそのまま実装にリンクしている状態を作りたい! 
 5
 RDRA + DDDでやってみよう!

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


    
 6

  7. プロジェクト準備
 7


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

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

  9. 要求事項の洗出し
 • 各組織における新プロジェクト への期待をヒアリング 
 • ヒアリングした結果を 戦略要 求、業務要求、IT要求、達成 基準に構造化


    • それぞれに高、中、低で優先 順位をつけ、高、中を1stス コープにすることを仮ぎ め
 • 夢と希望を早い段階で構造化 し整理し要求事項に落とし込 みつつ期待を整理する。 
 9
 戦略要求 経営・事業として実現したい目標 業務要求 戦略要求を実現するための施策 IT要求 施策実行のためにシステムで実現したい要求 実現機能 IT要求を満たすために必要な機能 理由・背景 その機能が必要な理由
  10. 要件定義セッション
 10


  11. コアメンバー全員で議論しながらその場でどんどんRDRAモデルを作りあげていく
 要件定義セッション
 11
 経営ボード プロジェクト 関連 部門 関連 部門 CTO

    PM Arch En QA 事業 責任者 スタッフ 事業 責任者 スタッフ 他 役員 レポート・ヒ アリング ヒアリング アウト プット RDRAモデル • 弊社の場合は共同作業のしやすさを重視し表(Spreadsheet)で構造管理
 • 各モデルを行ったり来たりしながら全体の整合性を揃え精度をあげていく
 • その場で決まらないことはステークホルダーを招集し決め方を決める

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


  13. 業務・BUC・アクティビティ & 情報 ①
 13
 全体のバリューチェーンを起点に業務を整理し、それぞれでどのような情報が取り扱われるかを考える 
 
 バリューチェーン 業務・BUC・アクティビティ

    情報 ID管理される粒度を意 識 ユビキタス言語になるので 名前付けの納得感が重要
  14. 業務・BUC・アクティビティ & 情報 ②
 洗い出した業務と情報から、それぞれの情報を操作するUCを考える 
 14


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

  16. バリエーション・条件
 16
 • UCごとに条件(ビジネスルール)を明確化 
 • コンテキストごとにどのようなビジネスのバリエーションが存在するかを考える。 
 • システムがバリエーションごとに判断を変えるか?を基準に考える

    
 バリエーション・状態関係なく、単純な計算ロ ジックの場合もある
  17. 各要素の関連付け
 17
 業務 BUC Activity UC 情報 イベント 外部システム 画面

    条件 アクター 各要素を関連付けることで人や外部システムがどうシステムと関わるかをユースケースとつなげて定義 する

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


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

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


  21. 実装への落とし込み
 21


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

    Service 業務 BUC Activity UC プレゼンテーション層 RDRA 実装
  23. 業務 ⇔ アプリケーション層 
 23
 アプリケーション層 Package Subpackage Service 業務

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


    
 24
 プレゼンテーション層 Service 業務 BUC Activity UC Domain Obj 情報 状態モデル バリエーション 状態 Enum インフラストラクチャ層 条件 RDRA 実装
  25. 情報モデル ⇔ ドメイン層
 25
 商品コンテキスト 商品 料金 カテゴ リ 状態モデル

    : 商品 準備 中 販売 中 アーカ イブ <バリエーション > 外部連携種別 基本情報登録条件 商品外部連携条件 状態を判断するのはドメイ ンロジック、状態を伝える のはEnum
  26. コンテキスト アプリケーション層 Package Subpackage ドメイン層 Package Subpackage RDRAモデルと三層 + ドメイン層アーキテクチャへのマッピング


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

    Controller Form UI 商品管理担当者 → 基本情報登録画面
 基本情報登録条件の発動 
 商品外部連携条件の発動 
 POSシステムへの連携 
 商品情報の登録 

  28. 以降のイテレーション
 28
 • ビジネスの変化はRDRAを起点に取り組んでいく 
 • RDRA ⇔ Javaの整合チェックはJIGを利用して出力した分析と比較するのがよさそう 


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


  30. まとめ
 手応えを感じたところ 
 • “夢と希望”から実際のシステムの輪郭を構造化して表現できた 
 • 要件が構造化されているため、プログラムコードへの落とし込みとマッピングがスムーズ 
 •

    新しい人がふえても、RDRAからキャッチアップしていくことが容易 
 • 記法が統一されているためだれでもメンテナンスしていける 
 今後の課題
 • ビジネス要件の根拠となるもの(例: 事業企画や営業で管理している契約、顧客要望、ビジネスルールな ど)と、RDRA間のマッピングをどうするか 
 ◦ プロジェクトチームから全体へRDRAモデルの共通理解を広げる 
 • 体制や組織変更などの大局に呑まれずRDRAと実装の整合性をあわせていく文化・ルール作り 
 • 今後実装がすすんでいくにつれて詳細なノウハウを蓄積して発信したい 
 30

  31. ご静聴ありがとうございました!
 31
 参考文献
 • 神崎善司 (2019)『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』 
 •

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