新規サービス開発で RDRA を使っている話

2021.10.29 モデルベースで要件定義をやってみた での発表資料です。

Transcript

1. © 2021 ASOVIEW Inc. 
 1
 新規サービス開発で RDRA を使っている話 モデルベースで要件定義をやってみた 
 2021.10.29
 アソビュー株式会社
 竹内 大介

2. © 2021 ASOVIEW Inc. 
 2
 0. 目次
 1. 自己紹介
 2. どんなプロジェクトか？
 3. RDRAを使ってみた(AsIs)
 4. RDRAを使ってみた(ToBe)
 5. まとめ

3. © 2021 ASOVIEW Inc. 
 3
 1. 自己紹介
 - 竹内 大介
 - 開発マネージャ / バックエンドエンジニア
 - 主にチケットシステムを担当
 - 社内業務改善プロジェクトにも従事

4. © 2021 ASOVIEW Inc. 
 4
 2. どんなプロジェクトか？ 
 『遊び』のデジタル流通プラットフォーム
 テクノロジーを駆使して流通の不便を解決し、
 生活者の遊ぶ機会を最大化し、また事業者の経営効率化を実現しています。
 
 
 アソビュー！って？

5. © 2021 ASOVIEW Inc. 
 5
 2. どんなプロジェクトか？ 
 - アソビュー！の裏側を支えるシステムの刷新プロジェクト
 - ツアー・アクティビティやレジャー施設の入場チケットといった商品管理業務や精算 業務を行う
 - 約 8 年間増改築を続けてきた社内システム
 - 業務プロセス簡略化と多様な商品を扱えるようにする
 プロジェクト概要

6. © 2021 ASOVIEW Inc. 
 6
 2. どんなプロジェクトか？ 
 - 要件定義中
 - RDRA で AsIs を作成し ToBe BUC を整理途中
 - 状態、条件、バリエーションを整理して BUC を精査中 - 主にスプレッドシートでアウトプット 現在の状況

7. © 2021 ASOVIEW Inc. 
 7
 2. どんなプロジェクトか？ 
 - PO, PM, テックリードの 3 名
 - いずれのメンバーも RDRA 未経験
 - 対象業務（システム）はだいたい把握している
 - 事前にプロジェクト憲章を作成済み
 - 主にオンラインミーティングで作業実施 with 神崎さん
 体制

8. © 2021 ASOVIEW Inc. 
 8
 3. RDRAを使ってみた (AsIs) 
 - システムスコープは一旦忘れて業務に関連するアクターを列挙
 - 業務でどのような情報を扱うかも列挙
 アクター、外部システム、情報の洗い出し
 ✓ 特に難しいことはなく改めて認識を確認できた
 ✓ 改めて洗い出すと思った以上に要素がでてくる

9. © 2021 ASOVIEW Inc. 
 9
 3. RDRAを使ってみた (AsIs) 
 - システム化しなさそうな部分も含めてアクティビティ・UC を抽出
 - UC で扱う情報も整理する
 UC洗い出し
 ✓ アクティビティ、UCの抽出粒度が難しい。業務の理解度合いで変わりそう。作業を 進める中で感覚を掴んでいった
 ✓ 業務の詳細というより、全体像の把握やチームの認識を合わせることを優先（コミュ ニケーションの土台）
 ✓ よくわからない箇所は有識者へのヒアリングや既存システムを動かして理解を深め た

10. © 2021 ASOVIEW Inc. 
 10
 3. RDRAを使ってみた (AsIs) 
 - 洗い出した内容を使って誰が何の業務を行っているか整理する
 業務とアクターの分析
 ✓ アクティビティやアクター、外部システムの過不足を見つけられるのが良い
 ✓ システム化スコープについてこのあたりから認識を合わせはじめた

11. © 2021 ASOVIEW Inc. 
 11
 3. RDRAを使ってみた (AsIs) 
 - リストアップした情報をもとに関連を引く
 - 状態はリストアップし図示
 - 検討する中でバリエーションもリストアップ
 ✓ ここでも全体把握、認識あわせを重視
 ✓ PPT で記載したが共同作業やりづらいので他のツール使ってもよいかも
 情報・状態の構造化

12. © 2021 ASOVIEW Inc. 
 12
 3. RDRAを使ってみた (AsIs) 
 - 業務要求と非機能要求を整理し重要な要求を明らかにする
 - プロジェクト憲章の内容と要求を整合させる
 要求の洗い出し
 ✓ 事業長にヒアリングを実施
 ✓ 事業環境により変化していくので適宜見直しが必要

13. © 2021 ASOVIEW Inc. 
 13
 3. RDRAを使ってみた (AsIs) 
 - AsIs で整理した要求の IT 要求の達成基準を明らかにする
 - この要求かどの UC に関連するか？
 IT要求の解像度を上げる
 ✓ 今回どのあたりの UC や機能に手が入りそうか見えてきた

14. © 2021 ASOVIEW Inc. 
 14
 3. RDRAを使ってみた (AsIs) 
 - アクティビティや UC はあまり粒度が細かくない、詳細化が済んでいない
 - このあとどう進めるか？
 • シナリオ１：AsIsで要件の詳細化をしてから ToBeに行く - 作業が増えるがToBeの議論がブレにくくなる • シナリオ２：ToBeで要件の詳細化を行う - 作業が早くなるがToBeの議論がブレやすい • シナリオ３：ToBeのイメージを合わせて AsIsの詳細化を行う - 手間がかかるがToBeの議論が具体化しやすい ここまでの状況と次の進め方
 ✓ シナリオ２で進め、必要に応じて3も取り入れる
 ➢ ToBe の全体イメージを早めにつけることを優先した ➢ ToBe を進めていく中で必要な箇所は AsIsを詳細化する
15. © 2021 ASOVIEW Inc. 
 15
 4. RDRAを使ってみた (ToBe) 
 - 要求を元にあたらしい情報構造を検討する
 - 前段でオブジェクトモデルを作成した
 ✓ オブジェクトモデルから書くと整理しやすい。迷ったら立ち戻れるのが良い
 ✓ miro を使ってオンラインで議論しながらの作業がスムーズにできた
 情報モデルの検討

16. © 2021 ASOVIEW Inc. 
 16
 4. RDRAを使ってみた (ToBe) 
 - 要求を加味して AsIs を元にベースを作る
 - アクター、外部システム - 業務、BUC、Job(アクティビティ)、UC - UC と情報モデルとの接続も行う
 - 想定される画面や外部システムも接続する
 ✓ 徐々にシステムの輪郭が見え始めてくる
 ✓ UC を細かくしていくと状態やバリエーションを見つけることも
 ➢ 例：[UC] アクティビティ商品を登録する、チケット商品を登録する ▪ アクティビティ、チケットは商品のバリエーション？ アクター、BUCの洗い出し

17. © 2021 ASOVIEW Inc. 
 17
 4. RDRAを使ってみた (ToBe) 
 - 状態遷移を行う UC と状態を関連付ける
 ✓ 状態と UC の関連付けで足らない UC が結構見つかる
 ✓ 状態遷移にUCが関連付けられることで状態をイメージがしやすくなる
 状態モデルの検討

18. © 2021 ASOVIEW Inc. 
 18
 5. まとめ
 良かった点
 - 要件を整理する枠組みとして RDRA は良さそう
 - UC を中心にアクター、情報、状態、条件が関連付けられ俯瞰できる - ToBe モデルを書き進めると自然と BUC が精査されていく
 - 特別なツールがなくても始められる
 
 難しかった・まだわからない点
 - BUC, アクティビティ, UC の粒度をそろえるのが難しい
 - 粒度が粗いところは理解が不足しているということかもしれない - 現在は情報を整理して記載するのがやっと。モデルをまだ活用できていない
 - モデル変更時のトレーサビリティとか - 現在詳細化までできていないので、そのあたりはまだ未知数
 - 仕様化や開発イテレーションにどうつなげていくかはまだこれから
 使ってみた感想

19. © 2021 ASOVIEW Inc. 
 - 既存システム(AsIs) と ToBe モデルの突き合わせ
 - 重要な BUC の仕様詳細化
 - UI のラフスケッチ
 - ER図・論理データモデル
 19
 5. まとめ
 次のステップ

20. © 2021 ASOVIEW Inc. 
 
 お気軽にこちらまで！ 
 https://www.asoview.co.jp/career 
 20
 6. 宣伝
 アソビューではエンジニアを募集しています！！