実践！RDRAを活用した既存システムの仕様変更 / Specification Changes in Existing Systems Utilizing RDRA

1. 実践！RDRAを活用した 既存システムの仕様変更 2024.3.24 Object-Oriented Conference 2024 株式会社ラクス　今本 光 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 1
2. 自己紹介 今本 光（いまもとひかる） 株式会社ラクス インフラ開発部 SRE課 趣味：サウナ / 日向坂46（夫婦で応援） / 野球観戦 X(旧Twitter): @imamotohikaru GitHub: @kudagonbe 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 2
3. 今日話したいこと RDRAについて ターゲットとした既存システムについて 既存システムの仕様変更にRDRAをどう生かしたか やってみた感想 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 3
4. RDRAについて 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 4
5. RDRAとは？ RDRA: リレーションシップ駆動要求分析 神崎善司さん(@zenzengood)が提唱している要件分析手法 利害関係者やシステム化目的を定義して、業務、システムとの関係性や相互作用 を明確化することで、解像度の高い要求分析を実施する手法 「RDRAレイヤー」 で表現された要件の構造ごとに、「ダイアグラム」 と呼ばれ る図的表現を作成することがRDRAでの要件定義になる 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 5
6. 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 6
7. 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 7
8. 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 8
9. システム価値レイヤー 役割 システムが「誰にとっての価値を実現するのか」を明らかにする ダイアグラム システムコンテキスト図 システム化目的と、システムに関係するアクター、外部システムを明らかにする 要求モデル図 要求および要求元となるアクターを整理して、要件を導出する 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 9
10. システム外部環境レイヤー 役割 システムが「どのように使われるのか」を明らかにする ダイアグラム ビジネスコンテキスト図：「業務」と「ビジネス要素」を洗い出す ビジネスユースケース図 業務をブレイクダウンして「ビジネスユースケース(BUC)」を洗い出す 業務フロー図 BUCごとにアクターのアクティビティ(仕事)とユースケース(システムの処理)を定 義して、BUCの流れを定義したフロー図 バリエーション・条件図：ビジネスルールを取りうる値と条件で定義する 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 10
11. システム境界レイヤー 役割 システムと「どう関わるか」を明らかにする ダイアグラム UC複合図 ユースケースにどのような「画面(入出力)」「イベント(外部システム連携)」「情 報(操作対象)」「条件(ビジネスルール)」が関わるかを明らかにする システム外部環境レイヤーの「業務フロー図」をUC複合図の中に含み、アクター やアクティビティとの関連もまとめる場合もある 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 11
12. システムレイヤー 役割 システム化する「情報」とその情報が取り得る「状態」でシステムを明示する ダイアグラム 情報モデル図 システム化したいビジネス上の用語とその関連を明示する 状態モデル図 ビジネス上認識している「状態」を構造化して、システムで実現したい状態を明示 「情報」が「状態」を保持し、「ユースケース」によって「情報」が操作された結 果「状態」が変化するという考え方で、三者の相互作用を定義するとRDRAモデル 全体の精度が上がる 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 12
13. 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 13
14. RDRAのメリット 上位RDRAレイヤーで明確にしたインプットを元に、下位レイヤーで業務やシステ ムの詳細を明確化していくことで、要求が明確化 され、要求の認識齟齬 のリスク を最小化できる 関係者が多い、ビジネスの複雑度が高い場合により効果的 「要件定義」にとどまらず「基本設計」まで踏み込んだドキュメントが完成され る システム設計のインプットとなり、用語も統一される 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 14
15. RDRAの難しさ コミュニケーションや要求の明確化にリソースを要する 要求整理や分析、文書化の適切なスキルや経験が求められる 過剰な詳細化につながりやすい 「業務」や「ビジネスユースケース」の分割単位が難しい ビジネスサイドの利害関係者に積極的な参加を求める難易度が高い 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 15
16. ターゲットとした既存システムについて 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 16
17. システム特性 ラクスが提供するクラウドサービスのアカウント発行や契約変更情報を行うのに 必要な社内システム 販売管理システムに投入された情報をプロダクション環境へ連携する ラクスの大半のクラウドサービスにおいて利用されている サービスごとのIF仕様はほぼ統一されており、システムとしても小規模 Pythonで実装されており、cronでPythonスクリプトを定期的に起動するよう実装 されている 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 17
18. システムが抱える課題 スループット不足 当該システムのスループットが現在のアカウント発行件数に追いついていない 当該システムが処理を並列化できていないのに加え、他システムの性能やレートリ ミットも大きな要因になっている 現状は事業部の運用部門において運用カバーしているが、持続可能性が低い 並列度を上げることで現状の課題は大幅に緩和される コードの保守性が低い 適切に構造化されていないスパゲッティコードになっている 作られた当時のメンバーはおらずドキュメントも不十分で、意図がよく分からな いコードが多い （もちろんRDRAでの要件定義もしていない） 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 18
19. 課題解決方針 Pythonで書かれたスクリプトをGoに置き換えて並行処 理を実装する →仕様変更と同時に既存システムのコードのリプレイス も実施 →この仕様変更+リプレイスをデグレなく実現するために RDRAを活用する 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 19
20. 既存システムの仕様変更に RDRAをどう生かしたか 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 20
21. RDRAを利用した理由 ① デグレリスクの低減 メンテナンス性が低く残された情報も少ないコードをリプレイスするとデグレの リスクが大きい システムが満たすべき要求が明確になった状態で設計変更を実施するという手順 を踏むことで、安全かつ開発への不安が少ない状態で実装作業を実施することが できる 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 21
22. RDRAを利用した理由 ② 社内の小規模なシステムであったこと 「RDRAの難しさ」の項でも触れた通り、RDRAは本来かなりカロリーを使う手法 加えてビジネスサイドを巻き込んでRDRAモデルを定義していくのは費用対効果も 低い 小規模のシステムだったので、少ない人数で1からRDRAモデルの定義を実施する ことが可能だった 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 22
23. 本来あるべき姿 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 23
24. 今回の作戦イメージ 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 24
25. 今回のプロジェクトで取った作戦 1. すべてのバッチ・APIの洗い出し 2. リバースエンジニアリング 3. システムを利用するユースケースを整理 4. 既存システムの要求をリストアップ 5. 仕様変更を要求モデルに追加 6. 整合性を取りながら下位レイヤーを変更 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 25
26. 1. すべてのバッチ・APIの洗い出し まずはAPIやスクリプトと、その呼び出し・起動トリガーを一覧化 API呼び出しやバッチ起動のトリガーは「システムがどのように使われるか」を明 らかにする システム外部環境レイヤー において重要な要素 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 26
27. 2. リバースエンジニアリング 現行のソースコード、ドキュメントからRDRAの下位レイヤーで定義されるRDRA ダイアグラムを作成する 「システム」レイヤーの以下のダイアグラムを作成 情報モデル(システム内で取り扱う情報の種類や依存関係を記載) 状態モデル(情報の状態遷移とそのトリガーとなるシステムの処理を記載) 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 27
28. 3. システムを利用するユースケースを整理 現行のソースコード、ドキュメントに加え、「バッチ・API一覧」で洗い出した関 係システムやバッチの起動トリガーも加味して、システムが利用されている業務 やユースケースを特定し、業務フローを作成する 「システム外部環境」「システム境界」レイヤーに属するダイアグラムを作成 ビジネスユースケース一覧(BUC＝業務を構成する価値を提供する単位) 業務フロー図(BUCの仕事の流れを記述する) ユースケース複合図(BUC単位で、システムの処理ごとに「画面」「情報」「条 件」「イベント」を紐づける形で記述する) 条件/バリエーション図(条件分岐やデータのバリエーションを定義) 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 28
29. 4. 既存システムの要求をリストアップ 既存システムが満たしている要求を「要求モデル」としてリストアップして、シ ステム変更後も満たしている要件を確認 「システム価値」レイヤーの以下のダイアグラムを作成 システムコンテキスト図(関係者、関係部署、システム化の目的を明示) 要求モデル図(関係者からの要求と、要求を満たすための要件を列挙する) ここまでで、既存システムのRDRAモデル作成が完了 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 29
30. 5. 仕様変更を要求モデルに追加 「要求モデル」に対して、今回のシステム変更で追加・変更が必要となる要求を 記載 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 30
31. 6. 整合性を取りながら下位レイヤーを変更 上位レイヤーのダイアグラムと矛盾が起きないよう整合性を取りながら、メンテ ナンス性も向上させるために下位レイヤーのダイアグラムをブラッシュアップす る 上位レイヤーから順にブラッシュアップする際、既存の実装にとらわれることな くフラットにダイアグラムを修正するよう心がけた 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 31
32. やってみた感想 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 32
33. 良かった点 設計経験の少ないメンバーにとって、ユーザーの要求や業務、ビジネスユースケ ースを意識したドキュメントと設計を考える機会となった 業務を整理した結果、不必要な仕様を削ぎ落としてシンプルにする調整をユーザ ーである運用部門と実施できた 既存の（あまり良くない）実装に引っ張られずに後続の設計・実装を行うための 基礎となった 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 33
34. 大変だった点 小規模システムでもやはり工数がかなりかかる 巨大なシステムに対して一から同じ試みを行う場合は相当な胆力が必要 既存の実装に引っ張られすぎていたり、ユーザーや業務目線ではなく開発目線で の資料になってしまいがちになるので、軌道修正するのが大変 新たなスパゲッティコードの再発明をしても意味が無い 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 34
35. まとめ RDRAを不慣れながら実践してみたが、ソースコードだけに着目した近視眼的な設 計から解き放たれて、バリューストリーム全体を捉え直す良い機会となった 今回はシステムリプレイスのために、開発者のためのRDRAを実践したが、ビジネ スサイドとの協働にもチャレンジしてみたい 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 35
36. ご清聴ありがとうございました 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 36