Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実践!RDRAを活用した既存システムの仕様変更 / Specification Changes...
Search
Imamoto Hikaru
March 23, 2024
Programming
1
6.4k
実践!RDRAを活用した既存システムの仕様変更 / Specification Changes in Existing Systems Utilizing RDRA
Imamoto Hikaru
March 23, 2024
Tweet
Share
More Decks by Imamoto Hikaru
See All by Imamoto Hikaru
RDRA/DDD/Goでモジュラーモノリスのアプリを開発してみた話 / developing a modular monolith application with RDRA DDD Go
imamotohikaru
3
2.1k
SRE課が開発中システムのCI/CDで取り組んでいるGitOpsの話 / GitOps with ArgoCD
imamotohikaru
1
1.4k
RDRAとDDDでGoのモジュラーモノリスアプリを設計してみた話
imamotohikaru
2
3.1k
Other Decks in Programming
See All in Programming
Vaporモードを大規模サービスに最速導入して学びを共有する
kazukishimamoto
4
4.3k
C#/.NETのこれまでのふりかえり
tomokusaba
1
160
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
850
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
1
290
EventSourcingの理想と現実
wenas
6
2.1k
僕がつくった48個のWebサービス達
yusukebe
18
17k
Identifying User Idenity
moro
6
7.9k
Progressive Web Apps für Desktop und Mobile mit Angular (Hands-on)
christianliebel
PRO
0
110
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
7
2.8k
JaSST 24 九州:ワークショップ(は除く)実践!マインドマップを活用したソフトウェアテスト+活用事例
satohiroyuki
0
260
Sidekiqで実現する 長時間非同期処理の中断と再開 / Pausing and Resuming Long-Running Asynchronous Jobs with Sidekiq
hypermkt
6
2.7k
gopls を改造したら開発生産性が高まった
satorunooshie
8
240
Featured
See All Featured
Facilitating Awesome Meetings
lara
49
6k
Unsuck your backbone
ammeep
668
57k
Into the Great Unknown - MozCon
thekraken
31
1.5k
Become a Pro
speakerdeck
PRO
24
5k
A designer walks into a library…
pauljervisheath
202
24k
KATA
mclloyd
29
13k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Cost Of JavaScript in 2023
addyosmani
45
6.6k
Rails Girls Zürich Keynote
gr2m
93
13k
Designing for humans not robots
tammielis
249
25k
Transcript
実践!RDRAを活用した 既存システムの仕様変更 2024.3.24 Object-Oriented Conference 2024 株式会社ラクス 今本 光 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 1
自己紹介 今本 光(いまもとひかる) 株式会社ラクス インフラ開発部 SRE課 趣味:サウナ / 日向坂46(夫婦で応援) /
野球観戦 X(旧Twitter): @imamotohikaru GitHub: @kudagonbe 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 2
今日話したいこと RDRAについて ターゲットとした既存システムについて 既存システムの仕様変更にRDRAをどう生かしたか やってみた感想 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 3
RDRAについて 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 4
RDRAとは? RDRA: リレーションシップ駆動要求分析 神崎善司さん(@zenzengood)が提唱している要件分析手法 利害関係者やシステム化目的を定義して、業務、システムとの関係性や相互作用 を明確化することで、解像度の高い要求分析を実施する手法 「RDRAレイヤー」 で表現された要件の構造ごとに、「ダイアグラム」 と呼ばれ る図的表現を作成することがRDRAでの要件定義になる
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 5
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 6
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 7
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 8
システム価値レイヤー 役割 システムが「誰にとっての価値を実現するのか」を明らかにする ダイアグラム システムコンテキスト図 システム化目的と、システムに関係するアクター、外部システムを明らかにする 要求モデル図 要求および要求元となるアクターを整理して、要件を導出する 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 9
システム外部環境レイヤー 役割 システムが「どのように使われるのか」を明らかにする ダイアグラム ビジネスコンテキスト図:「業務」と「ビジネス要素」を洗い出す ビジネスユースケース図 業務をブレイクダウンして「ビジネスユースケース(BUC)」を洗い出す 業務フロー図 BUCごとにアクターのアクティビティ(仕事)とユースケース(システムの処理)を定 義して、BUCの流れを定義したフロー図
バリエーション・条件図:ビジネスルールを取りうる値と条件で定義する 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 10
システム境界レイヤー 役割 システムと「どう関わるか」を明らかにする ダイアグラム UC複合図 ユースケースにどのような「画面(入出力)」「イベント(外部システム連携)」「情 報(操作対象)」「条件(ビジネスルール)」が関わるかを明らかにする システム外部環境レイヤーの「業務フロー図」をUC複合図の中に含み、アクター やアクティビティとの関連もまとめる場合もある 実践!RDRAを活用した既存システムの仕様変更
#ooc_2024 #ooc_2024_c 11
システムレイヤー 役割 システム化する「情報」とその情報が取り得る「状態」でシステムを明示する ダイアグラム 情報モデル図 システム化したいビジネス上の用語とその関連を明示する 状態モデル図 ビジネス上認識している「状態」を構造化して、システムで実現したい状態を明示 「情報」が「状態」を保持し、「ユースケース」によって「情報」が操作された結 果「状態」が変化するという考え方で、三者の相互作用を定義するとRDRAモデル
全体の精度が上がる 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 12
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 13
RDRAのメリット 上位RDRAレイヤーで明確にしたインプットを元に、下位レイヤーで業務やシステ ムの詳細を明確化していくことで、要求が明確化 され、要求の認識齟齬 のリスク を最小化できる 関係者が多い、ビジネスの複雑度が高い場合により効果的 「要件定義」にとどまらず「基本設計」まで踏み込んだドキュメントが完成され る システム設計のインプットとなり、用語も統一される
実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 14
RDRAの難しさ コミュニケーションや要求の明確化にリソースを要する 要求整理や分析、文書化の適切なスキルや経験が求められる 過剰な詳細化につながりやすい 「業務」や「ビジネスユースケース」の分割単位が難しい ビジネスサイドの利害関係者に積極的な参加を求める難易度が高い 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 15
ターゲットとした既存システムについて 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 16
システム特性 ラクスが提供するクラウドサービスのアカウント発行や契約変更情報を行うのに 必要な社内システム 販売管理システムに投入された情報をプロダクション環境へ連携する ラクスの大半のクラウドサービスにおいて利用されている サービスごとのIF仕様はほぼ統一されており、システムとしても小規模 Pythonで実装されており、cronでPythonスクリプトを定期的に起動するよう実装 されている 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 17
システムが抱える課題 スループット不足 当該システムのスループットが現在のアカウント発行件数に追いついていない 当該システムが処理を並列化できていないのに加え、他システムの性能やレートリ ミットも大きな要因になっている 現状は事業部の運用部門において運用カバーしているが、持続可能性が低い 並列度を上げることで現状の課題は大幅に緩和される コードの保守性が低い 適切に構造化されていないスパゲッティコードになっている 作られた当時のメンバーはおらずドキュメントも不十分で、意図がよく分からな
いコードが多い (もちろんRDRAでの要件定義もしていない) 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 18
課題解決方針 Pythonで書かれたスクリプトをGoに置き換えて並行処 理を実装する →仕様変更と同時に既存システムのコードのリプレイス も実施 →この仕様変更+リプレイスをデグレなく実現するために RDRAを活用する 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c
19
既存システムの仕様変更に RDRAをどう生かしたか 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 20
RDRAを利用した理由 ① デグレリスクの低減 メンテナンス性が低く残された情報も少ないコードをリプレイスするとデグレの リスクが大きい システムが満たすべき要求が明確になった状態で設計変更を実施するという手順 を踏むことで、安全かつ開発への不安が少ない状態で実装作業を実施することが できる 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 21
RDRAを利用した理由 ② 社内の小規模なシステムであったこと 「RDRAの難しさ」の項でも触れた通り、RDRAは本来かなりカロリーを使う手法 加えてビジネスサイドを巻き込んでRDRAモデルを定義していくのは費用対効果も 低い 小規模のシステムだったので、少ない人数で1からRDRAモデルの定義を実施する ことが可能だった 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 22
本来あるべき姿 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 23
今回の作戦イメージ 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 24
今回のプロジェクトで取った作戦 1. すべてのバッチ・APIの洗い出し 2. リバースエンジニアリング 3. システムを利用するユースケースを整理 4. 既存システムの要求をリストアップ 5.
仕様変更を要求モデルに追加 6. 整合性を取りながら下位レイヤーを変更 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 25
1. すべてのバッチ・APIの洗い出し まずはAPIやスクリプトと、その呼び出し・起動トリガーを一覧化 API呼び出しやバッチ起動のトリガーは「システムがどのように使われるか」を明 らかにする システム外部環境レイヤー において重要な要素 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c
26
2. リバースエンジニアリング 現行のソースコード、ドキュメントからRDRAの下位レイヤーで定義されるRDRA ダイアグラムを作成する 「システム」レイヤーの以下のダイアグラムを作成 情報モデル(システム内で取り扱う情報の種類や依存関係を記載) 状態モデル(情報の状態遷移とそのトリガーとなるシステムの処理を記載) 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c
27
3. システムを利用するユースケースを整理 現行のソースコード、ドキュメントに加え、「バッチ・API一覧」で洗い出した関 係システムやバッチの起動トリガーも加味して、システムが利用されている業務 やユースケースを特定し、業務フローを作成する 「システム外部環境」「システム境界」レイヤーに属するダイアグラムを作成 ビジネスユースケース一覧(BUC=業務を構成する価値を提供する単位) 業務フロー図(BUCの仕事の流れを記述する) ユースケース複合図(BUC単位で、システムの処理ごとに「画面」「情報」「条 件」「イベント」を紐づける形で記述する)
条件/バリエーション図(条件分岐やデータのバリエーションを定義) 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 28
4. 既存システムの要求をリストアップ 既存システムが満たしている要求を「要求モデル」としてリストアップして、シ ステム変更後も満たしている要件を確認 「システム価値」レイヤーの以下のダイアグラムを作成 システムコンテキスト図(関係者、関係部署、システム化の目的を明示) 要求モデル図(関係者からの要求と、要求を満たすための要件を列挙する) ここまでで、既存システムのRDRAモデル作成が完了 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024
#ooc_2024_c 29
5. 仕様変更を要求モデルに追加 「要求モデル」に対して、今回のシステム変更で追加・変更が必要となる要求を 記載 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 30
6. 整合性を取りながら下位レイヤーを変更 上位レイヤーのダイアグラムと矛盾が起きないよう整合性を取りながら、メンテ ナンス性も向上させるために下位レイヤーのダイアグラムをブラッシュアップす る 上位レイヤーから順にブラッシュアップする際、既存の実装にとらわれることな くフラットにダイアグラムを修正するよう心がけた 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c
31
やってみた感想 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 32
良かった点 設計経験の少ないメンバーにとって、ユーザーの要求や業務、ビジネスユースケ ースを意識したドキュメントと設計を考える機会となった 業務を整理した結果、不必要な仕様を削ぎ落としてシンプルにする調整をユーザ ーである運用部門と実施できた 既存の(あまり良くない)実装に引っ張られずに後続の設計・実装を行うための 基礎となった 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c
33
大変だった点 小規模システムでもやはり工数がかなりかかる 巨大なシステムに対して一から同じ試みを行う場合は相当な胆力が必要 既存の実装に引っ張られすぎていたり、ユーザーや業務目線ではなく開発目線で の資料になってしまいがちになるので、軌道修正するのが大変 新たなスパゲッティコードの再発明をしても意味が無い 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 34
まとめ RDRAを不慣れながら実践してみたが、ソースコードだけに着目した近視眼的な設 計から解き放たれて、バリューストリーム全体を捉え直す良い機会となった 今回はシステムリプレイスのために、開発者のためのRDRAを実践したが、ビジネ スサイドとの協働にもチャレンジしてみたい 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 35
ご清聴ありがとうございました 実践!RDRAを活用した既存システムの仕様変更 #ooc_2024 #ooc_2024_c 36