「クラウドサービス開発の肝はサービス横断の機能開発」に参加してきました
2023/10/12（木）に開催された「クラウドサービス開発の肝はサービス横断の機能開発」に参加してきたので、その内容と学んだことを共有します。
おことわり
この内容は非公式なものであり、自分なりに整理したものです
以下の内容には誤りが含まれる可能性があります
間違っている部分などがあれば、コメントお願いします
サマリ
RDRAですばやく要件定義するためには、スコープの認識合わせを最優先に行うこと
優先度の高いユースケースは複数のコンテキストをまたぐもの、もしくは状態を変えるもの
RdraGraphはRDRAモデルをいろんな視点から確認できるツール
クラウドサービスの全容を事前に把握しておくと、実際の現場でヒアリングや類推が行いやすくなる
RDRAの難しさはビジネス上に登場する要素をどのRDRA要素に分類するかということ
本イベントについて
RDRA(※1)という要件定義手法を用いて、クラウドサービス開発のポイントをワークショップを交えながら学ぶ会でした。
RDRAの概説とRdraGraph(※2)の見方
クラウドサービスの簡単なワークショップ
（YouTubeの音声が切れていたため、今回の記事に載せていません）クラウドサービス サービス横断の機能について
RdraGraphを使ったワークショップ
(※1) Relationship Driven Requirement Analysis（リレーションシップ駆動要件分析）
(※2) RDRA発案者の神崎さん自作ツール
イベント概要
クラウドサービスを素早く開発するために、サービスそのものとサービス横断の機能を切り分け、価値につながる部分に集中する必要があります。
一方システム開発現場で囁かれる相反する二つの現実があり、これがプロジェクトのコミュニケーションを妨げています
・動くものを見ながら仕様を考えよう ・システムは辻褄合わせ 辻褄合わせのポイントが分からない開発は混乱する
この二つの現実はサービスとバックエンドの役割を明確にすることで、住み分けられるようになります
今回の勉強会ではサービス横断で必要になるバックエンドの機能を辻褄を合わせるポイントを把握しながら理解します
１．サービス横断で必要になる機能の説明
・ 過去数十のプロジェクト経験から独断と偏見でまとめた機能
２．上記機能をグラフィカルなツールで確認
・ ユースケース、情報、状態など辻褄を合わせるポイントを確認
・ これらをまとめた単位の結合度、凝集度を確認しAsIsのポリシーに整理
３．ToBeに向けてポリシーの改善
・ ポリシーに従ってRDRAモデル（GoogleSheet）を改善
・ グラフィカルツールで結合度、凝集度の把握
一連のワークでサービスそのものに集中するためのサービス横断の機能を理解します ※今回は物流を伴わないクラウドサービスを対象にします
会の構成としては、1の説明パートと、実際にそれをテーマにRDRAダイアグラムなどを使用してミライトデザインのチームで手を動かしながら2、3を説明に従いながら進めていきますので、参加者の方も同じくお手元で手を動かしながら参加していただけるとより実践的な体験をしていただけると思います。
RDRAの概説とRdraGraphの活用について
まずは神崎さんからRDRAの概説とRDRAツールであるRdraGraphの活用方法についての説明がありました。
RDRAについて、公式ページに詳しく記載されています。
ここでは私が学んだことを記載します。
素早く要件定義するポイント
先に大まかに全体像を把握してから、精度をあげていくこと
スコープの認識合わせを最優先に行うこと
一部分を細かくすると空中戦になりやすい
RDRAの洗い出し順序
システム対象の業務/BUC
システムが持つ情報と状態
アクティビティとUC
とにかくザクっと洗い出すことが重要、精度は後回し
アクティビティとUCを洗い出す作業と並行して、業務やBUCをブラッシュアップしていく
RDRA2.0から新たに増えた要素
RDRA2.0(※3)から新たにコンテキストが増えた
コンテキストは情報、状態、バリエーション・条件を1つのグループにまとめたもの
システムが大規模になると、グループに分けた方が全体像を把握しやすくなる
(※3) RDRA2.0については、RDRA2.0ハンドブックを参照のこと
RdraGraphツールの見方
RDRAをより有効に活用してもらうため、神崎さんが自作したツール
RDRAモデルを作成するときは、スプレッドシートツール(※4)を使用するが、より視覚的に把握しやすくするために開発された
階層が存在しており、いろんな視点でモデルを確認し、システムの全体像や整合性を確認する
(※4) 公式ページからダウンロード可能
業務/BUC視点
要件モデル
システム横断
アクターとシステム関連系
イベントとシステム関連系
こちらは、RdraGraphで確認しようとすると真っ白な画面が出てきてしまうため、よくわかりませんでした。。
重要なUCの見分け方
状態を変化させているUC
状態を変える≒何かしらの情報を変化させているはず
複数のコンテキストをまたぐUC
いろんな情報に影響を与えている
クラウドサービス システム横断の機能について
神崎さんがクラウドサービス企業のシステム開発に携わってきて、得た知識を共有していただきました。
クラウドサービスを提供するにはどんな機能が必要なのか、
以下の書籍などを見て、事前に把握することでヒアリングしやすくなるとのことでした。
クラウドサービスの構成要素
マーケティング業務
カスタマーサクセス業務
サービス申し込み業務
会員活動管理業務
精算業務
代理店管理業務
サポート業務
サービス管理業務
サービス横断の業務
受注前活動（SoE）
受注活動
会員管理
課金精算
管理対象サービス
RdraGraphを使ったワークショップ
このセッションではRdraGraphを使いながら、以下を検討していました。
※イベント参加者はワークショップの様子を観察していました。
ユーザーストーリーの確認
コンテキストの分け方について
重要なUC・影響が大きいUCを見つける
バックログの単位を考える
保守開発時で確認すべきポイント
ビジネスで登場するさまざまな要素をRDRAでどう表現するか
ユーザーストーリーの確認
基本的には要件モデル - アクターを確認する
ユーザーストーリーを確認するときには、ユーザーとの設定部分だけでなく、それを裏で支えている部分も把握すること
コンテキストの分け方について
分け方に正解はないが、よくあるケースとしてトランザクションとリソースで分ける
トランザクション：記録する作業（受注等）
リソース：ライフサイクルを管理するもの（顧客情報等）
分け方（パターン）を身に着けておくと、ヒアリングしやすくなる
コンテキストはできるだけ疎結合・高凝集が良い
リソースのコンテキストは蜜結合になりやすい
重要なUC・影響が大きいUCを見つける
状態を変化させるUCはUC-状態モデルで確認できる
複数のコンテキストをまたぐUCは全UCで確認できる
バックログの単位を考える
全UCを見ると分かりやすい
コンテキスト⇒プロダクトバック
UC⇒スプリントバックログ
保守開発時で確認すべきポイント
保守開発は入出力部分に変更がかかる
入出力部分
画面（UC）
バリエーション
条件
RDRAでは上記のアイコンにつながっている部分を確認して、影響度を調べる
① 影響がある入出力を探す
② ①の入出力につながっているUCを見つける
③ ②につながっている情報を探す
④ ③につながっているUCを見つける
👆が変更の影響を受けている可能性があるUC
ビジネスで登場するさまざまな要素をRDRAでどう表現するか
ビジネス要素をどのRDRAアイコンで紐づけるかが難しいポイント
参加してみて
RdraGraphツールの見方はいまいち分かっていなかったため、今日のイベントはとても有意義でした。
イベントの様子が動画にも残っているのでRdraGraphの扱い方に迷ったら、この動画を再確認しようかなと思います。