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

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

Junya
June 21, 2022

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

Junya

June 21, 2022
Tweet

Other Decks in Technology

Transcript

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

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

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


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

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


    • それぞれに高、中、低で優先 順位をつけ、高、中を1stス コープにすることを仮ぎ め
 • 夢と希望を早い段階で構造化 し整理し要求事項に落とし込 みつつ期待を整理する。 
 9
 戦略要求 経営・事業として実現したい目標 業務要求 戦略要求を実現するための施策 IT要求 施策実行のためにシステムで実現したい要求 実現機能 IT要求を満たすために必要な機能 理由・背景 その機能が必要な理由
  4. コアメンバー全員で議論しながらその場でどんどんRDRAモデルを作りあげていく
 要件定義セッション
 11
 経営ボード プロジェクト 関連 部門 関連 部門 CTO

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

  5. 各要素の関連付け
 17
 業務 BUC Activity UC 情報 イベント 外部システム 画面

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

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


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

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


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

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

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

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

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

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