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

Slide 1

Slide 1 text

実践！RDRAを活用した既存システムの仕様変更 2024.3.24 Object-Oriented Conference 2024 株式会社ラクス　今本光実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 1

Slide 2

Slide 2 text

自己紹介今本光（いまもとひかる）株式会社ラクスインフラ開発部 SRE課趣味：サウナ / 日向坂46（夫婦で応援） / 野球観戦 X(旧Twitter): @imamotohikaru GitHub: @kudagonbe 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 2

Slide 3

Slide 3 text

今日話したいこと RDRAについてターゲットとした既存システムについて既存システムの仕様変更にRDRAをどう生かしたかやってみた感想実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 3

Slide 4

Slide 4 text

RDRAについて実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 4

Slide 5

Slide 5 text

RDRAとは？ RDRA: リレーションシップ駆動要求分析神崎善司さん(@zenzengood)が提唱している要件分析手法利害関係者やシステム化目的を定義して、業務、システムとの関係性や相互作用を明確化することで、解像度の高い要求分析を実施する手法「RDRAレイヤー」で表現された要件の構造ごとに、「ダイアグラム」と呼ばれる図的表現を作成することがRDRAでの要件定義になる実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 5

Slide 6

Slide 6 text

実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 6

Slide 7

Slide 7 text

実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 7

Slide 8

Slide 8 text

実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 8

Slide 9

Slide 9 text

システム価値レイヤー役割システムが「誰にとっての価値を実現するのか」を明らかにするダイアグラムシステムコンテキスト図システム化目的と、システムに関係するアクター、外部システムを明らかにする要求モデル図要求および要求元となるアクターを整理して、要件を導出する実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 9

Slide 10

Slide 10 text

システム外部環境レイヤー役割システムが「どのように使われるのか」を明らかにするダイアグラムビジネスコンテキスト図：「業務」と「ビジネス要素」を洗い出すビジネスユースケース図業務をブレイクダウンして「ビジネスユースケース(BUC)」を洗い出す業務フロー図 BUCごとにアクターのアクティビティ(仕事)とユースケース(システムの処理)を定義して、BUCの流れを定義したフロー図バリエーション・条件図：ビジネスルールを取りうる値と条件で定義する実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 10

Slide 11

Slide 11 text

システム境界レイヤー役割システムと「どう関わるか」を明らかにするダイアグラム UC複合図ユースケースにどのような「画面(入出力)」「イベント(外部システム連携)」「情報(操作対象)」「条件(ビジネスルール)」が関わるかを明らかにするシステム外部環境レイヤーの「業務フロー図」をUC複合図の中に含み、アクターやアクティビティとの関連もまとめる場合もある実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 11

Slide 12

Slide 12 text

システムレイヤー役割システム化する「情報」とその情報が取り得る「状態」でシステムを明示するダイアグラム情報モデル図システム化したいビジネス上の用語とその関連を明示する状態モデル図ビジネス上認識している「状態」を構造化して、システムで実現したい状態を明示「情報」が「状態」を保持し、「ユースケース」によって「情報」が操作された結果「状態」が変化するという考え方で、三者の相互作用を定義するとRDRAモデル全体の精度が上がる実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 12

Slide 13

Slide 13 text

実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 13

Slide 14

Slide 14 text

RDRAのメリット上位RDRAレイヤーで明確にしたインプットを元に、下位レイヤーで業務やシステムの詳細を明確化していくことで、要求が明確化され、要求の認識齟齬のリスクを最小化できる関係者が多い、ビジネスの複雑度が高い場合により効果的「要件定義」にとどまらず「基本設計」まで踏み込んだドキュメントが完成されるシステム設計のインプットとなり、用語も統一される実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 14

Slide 15

Slide 15 text

RDRAの難しさコミュニケーションや要求の明確化にリソースを要する要求整理や分析、文書化の適切なスキルや経験が求められる過剰な詳細化につながりやすい「業務」や「ビジネスユースケース」の分割単位が難しいビジネスサイドの利害関係者に積極的な参加を求める難易度が高い実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 15

Slide 16

Slide 16 text

ターゲットとした既存システムについて実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 16

Slide 17

Slide 17 text

システム特性ラクスが提供するクラウドサービスのアカウント発行や契約変更情報を行うのに必要な社内システム販売管理システムに投入された情報をプロダクション環境へ連携するラクスの大半のクラウドサービスにおいて利用されているサービスごとのIF仕様はほぼ統一されており、システムとしても小規模 Pythonで実装されており、cronでPythonスクリプトを定期的に起動するよう実装されている実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 17

Slide 18

Slide 18 text

システムが抱える課題スループット不足当該システムのスループットが現在のアカウント発行件数に追いついていない当該システムが処理を並列化できていないのに加え、他システムの性能やレートリミットも大きな要因になっている現状は事業部の運用部門において運用カバーしているが、持続可能性が低い並列度を上げることで現状の課題は大幅に緩和されるコードの保守性が低い適切に構造化されていないスパゲッティコードになっている作られた当時のメンバーはおらずドキュメントも不十分で、意図がよく分からないコードが多い（もちろんRDRAでの要件定義もしていない）実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 18

Slide 19

Slide 19 text

課題解決方針 Pythonで書かれたスクリプトをGoに置き換えて並行処理を実装する →仕様変更と同時に既存システムのコードのリプレイスも実施 →この仕様変更+リプレイスをデグレなく実現するために RDRAを活用する実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 19

Slide 20

Slide 20 text

既存システムの仕様変更に RDRAをどう生かしたか実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 20

Slide 21

Slide 21 text

RDRAを利用した理由 ① デグレリスクの低減メンテナンス性が低く残された情報も少ないコードをリプレイスするとデグレのリスクが大きいシステムが満たすべき要求が明確になった状態で設計変更を実施するという手順を踏むことで、安全かつ開発への不安が少ない状態で実装作業を実施することができる実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 21

Slide 22

Slide 22 text

RDRAを利用した理由 ② 社内の小規模なシステムであったこと「RDRAの難しさ」の項でも触れた通り、RDRAは本来かなりカロリーを使う手法加えてビジネスサイドを巻き込んでRDRAモデルを定義していくのは費用対効果も低い小規模のシステムだったので、少ない人数で1からRDRAモデルの定義を実施することが可能だった実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 22

Slide 23

Slide 23 text

本来あるべき姿実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 23

Slide 24

Slide 24 text

今回の作戦イメージ実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 24

Slide 25

Slide 25 text

今回のプロジェクトで取った作戦 1. すべてのバッチ・APIの洗い出し 2. リバースエンジニアリング 3. システムを利用するユースケースを整理 4. 既存システムの要求をリストアップ 5. 仕様変更を要求モデルに追加 6. 整合性を取りながら下位レイヤーを変更実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 25

Slide 26

Slide 26 text

1. すべてのバッチ・APIの洗い出しまずはAPIやスクリプトと、その呼び出し・起動トリガーを一覧化 API呼び出しやバッチ起動のトリガーは「システムがどのように使われるか」を明らかにするシステム外部環境レイヤーにおいて重要な要素実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 26

Slide 27

Slide 27 text

2. リバースエンジニアリング現行のソースコード、ドキュメントからRDRAの下位レイヤーで定義されるRDRA ダイアグラムを作成する「システム」レイヤーの以下のダイアグラムを作成情報モデル(システム内で取り扱う情報の種類や依存関係を記載) 状態モデル(情報の状態遷移とそのトリガーとなるシステムの処理を記載) 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 27

Slide 28

Slide 28 text

3. システムを利用するユースケースを整理現行のソースコード、ドキュメントに加え、「バッチ・API一覧」で洗い出した関係システムやバッチの起動トリガーも加味して、システムが利用されている業務やユースケースを特定し、業務フローを作成する「システム外部環境」「システム境界」レイヤーに属するダイアグラムを作成ビジネスユースケース一覧(BUC＝業務を構成する価値を提供する単位) 業務フロー図(BUCの仕事の流れを記述する) ユースケース複合図(BUC単位で、システムの処理ごとに「画面」「情報」「条件」「イベント」を紐づける形で記述する) 条件/バリエーション図(条件分岐やデータのバリエーションを定義) 実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 28

Slide 29

Slide 29 text

4. 既存システムの要求をリストアップ既存システムが満たしている要求を「要求モデル」としてリストアップして、システム変更後も満たしている要件を確認「システム価値」レイヤーの以下のダイアグラムを作成システムコンテキスト図(関係者、関係部署、システム化の目的を明示) 要求モデル図(関係者からの要求と、要求を満たすための要件を列挙する) ここまでで、既存システムのRDRAモデル作成が完了実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 29

Slide 30

Slide 30 text

5. 仕様変更を要求モデルに追加「要求モデル」に対して、今回のシステム変更で追加・変更が必要となる要求を記載実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 30

Slide 31

Slide 31 text

6. 整合性を取りながら下位レイヤーを変更上位レイヤーのダイアグラムと矛盾が起きないよう整合性を取りながら、メンテナンス性も向上させるために下位レイヤーのダイアグラムをブラッシュアップする上位レイヤーから順にブラッシュアップする際、既存の実装にとらわれることなくフラットにダイアグラムを修正するよう心がけた実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 31

Slide 32

Slide 32 text

やってみた感想実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 32

Slide 33

Slide 33 text

良かった点設計経験の少ないメンバーにとって、ユーザーの要求や業務、ビジネスユースケースを意識したドキュメントと設計を考える機会となった業務を整理した結果、不必要な仕様を削ぎ落としてシンプルにする調整をユーザーである運用部門と実施できた既存の（あまり良くない）実装に引っ張られずに後続の設計・実装を行うための基礎となった実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 33

Slide 34

Slide 34 text

大変だった点小規模システムでもやはり工数がかなりかかる巨大なシステムに対して一から同じ試みを行う場合は相当な胆力が必要既存の実装に引っ張られすぎていたり、ユーザーや業務目線ではなく開発目線での資料になってしまいがちになるので、軌道修正するのが大変新たなスパゲッティコードの再発明をしても意味が無い実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 34

Slide 35

Slide 35 text

まとめ RDRAを不慣れながら実践してみたが、ソースコードだけに着目した近視眼的な設計から解き放たれて、バリューストリーム全体を捉え直す良い機会となった今回はシステムリプレイスのために、開発者のためのRDRAを実践したが、ビジネスサイドとの協働にもチャレンジしてみたい実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 35

Slide 36

Slide 36 text

ご清聴ありがとうございました実践！RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 36