EventStormingとRDRA2.0で大規模レガシーシステムのフルリニューアルPJに挑む

## 技術

プロダクト開発体制, EventStorming, RDRA, 大規模レガシーシステム, リニューアル, 逆コンウェイの法則, アジャイル, コト品質, 依存方向

Transcript

1. EventStormingとRDRA2.0で 大規模レガシーシステムの フルリニューアルPJに挑む レバテック開発部　古庄 和也
2. |　© Leverages inc. 2 Introduction 自己紹介 古庄 和也 • 所属 ◦ ITソリューションプロダクト開発グループ • 経歴 ◦ 学生時代 友人と事業運営(自社/受託開発) ◦ 2020年4月 レバレジーズ株式会社 新卒入社 • 業務 ◦ 企業向けプラットフォームの PdM兼開発業務全般 ◦ 直近はレバテック全体のリニューアル PJに注力 • 趣味 ◦ ゴルフ、シーシャ、愛猫のブラッシング
3. |　© Leverages inc. 3 • レバテック全体のシステムリニューアル PJ • EventStorming・RDRA2.0とは • アジャイル開発で陥りがちな問題 • コト品質と依存方向 • EventStorming・RDRA2.0を実践 • まとめ アジェンダ INDEX
4. |　© Leverages inc. 4 1. PJの「不確実性」を極小化してアジャイル開発 を進める重要性を意識 (理解)できるようになる 2. 「利用者(ユーザー)視点のコト品質」とシステ ムの依存方向を意識 (理解)できるようになる 3. RDRA2.0とEventStormingを活用してモデリ ングを実践したくなる 今日のゴール 目的・目標
5. レバテックのVision
6. |　© Leverages inc. 6 VISION 日本を、 IT先進国に。 日本を、どこよりも進んだ IT技術を持つ国にする。 そして、ここで生まれた IT人材や組織の力が、 世界中のすべての課題を、 解決する。 それが、レバテックが 叶えたい未来です。
7. 「日本を、IT先進国に」 「レバテックを、IT先進企業に」するために 「開発とデータが強い組織・システム」が必要。 「プロダクト開発体制」を構築していく。
8. Revtech-PJ
9. Revtech-PJ(略称:リバプロ)というプロジェクトを やっています レバテックの「データ」「プロダクト」「オペレーション」「システム」を、再設計 (ReDesign)、再構築(ReArchitect)し、 非連続な事業成長へ向けてプロダクト開発体制を構築するPJの総称です。
10. |　© Leverages inc. 10 • Why - プロダクト開発体制をなぜやるのか？ ◦ 「事業目標・組織目標を達成する」ため、 ◦ 「開発者体験（DevEx）の向上」を行い、 ◦ 「プロダクト開発体制を構築」する。 • What - プロダクト開発体制とはなにか？ ◦ 事業軸を通してUXや仕組みを継続的に改善できる体制 ▪ 機能軸の改善だけでなく、事業軸を通した改善 ▪ 根本的な改善を行うことで新しい挑戦 • HOW - どうやって進めていくのか？ ◦ 理想のシステム→組織を定義 ▪ そこに向かって進めていきたい プロダクト開発体制へ向けて プロダクト開発体制
11. |　© Leverages inc. 11 • 事業軸を通してUXや仕組みを継続的に改善できる体制を作るには ◦ 理想のシステム→組織を定義していく必要がある ▪ ※ 逆コンウェイの法則 • この段階でいきなりレバテック全体を最適化するのは難しい ◦ 事業部を横断してどんな形が理想なのかは正直わからない ◦ 当初、想定していたビッグバンリリースもリスクが大きすぎる • なので、まずは特定の事業軸から段階的に取り組んでいく ◦ 小さく成功体験を積み上げて、横横展していく想定 理想の”システム”を構築し、理想の”体制”を構築する プロダクト開発体制
12. |　© Leverages inc. 12 今日、理想を定義しても、 1年後には理想は変わっているかもしれない。 ただし、探索と適応を行わなければ 向かうべき方向性や可能性は見えてこない。 なので、 理想を目指して探索を行い、適応の獲得を目指す。 理想は変わるもの プロダクト開発体制 不確実性の時代に「生き残る組織」に変わる「組織アジャイル」の始め方より
13. |　© Leverages inc. 13 • 「コンウェイの法則」 ◦ システムの設計（アーキテクチャー）は、お のずと組織構造を反映させたものになる • 「逆コンウェイの法則」 ◦ コンウェイの法則を逆手に取る ◦ 実現したいシステムの設計（アーキテク チャー）に合わせた組織構造にする 逆コンウェイの法則 プロダクト開発体制 コンウェイの法則と逆コンウェイの法則から組織構造を考えるより
14. |　© Leverages inc. 14 • レガシーシステムからの脱却 ◦ 古い技術スタックで動いているシステム ◦ バッチサーバやファイルサーバといった仕組み ◦ … • 密結合システムの廃止 ◦ 流入における重複判定の仕組み ◦ 人材や案件情報の複数システムにおける重複管理 ◦ … • 非構造化データの構造化 ◦ 文字列を利用したリレーション構造 ◦ EAVパターンを利用したリレーション構造 ◦ … • マスタデータの統合化 ◦ サービスごとにIDや項目ごとに異なる ◦ … 現状のシステムにおける問題や課題 システム戦略 【LT】Revtech-PJ 概要資料より
15. どうやって、解決するか？
16. 「集めるべきところに集める」
17. |　© Leverages inc. 17 • ”システム”と”データ”をあるべきところ（構造）に集約する ◦ システム統合（正規化・構造化） ▪ 契約情報 ▪ 人材情報 ▪ 企業情報 ▪ 案件情報 ▪ 営業支援システム ▪ … ◦ マスタデータ統合化 ▪ 職種 ▪ スキル ▪ … ◦ 流入~登録に関わる仕組みの改善 ▪ 検討中 ▪ … 「集めるべきところに集める」とは システム戦略
18. 「集めるべきところに集めて」 それぞれのシステムとデータが ”独立化”し”疎結合化”された状態を目指す ※ あくまで現状で想定しているイメージです
19. 「大規模リニューアルを計画的に進める」 とにかく少しでも前に進める！
20. とはいえ、15年以上積み上げてきた システム・業務オペレーションは 複雑で膨大・・・
21. 顧客価値・システム戦略・事業戦略の 3軸から計画的にPJを進める必要がある
22. |　© Leverages inc. 22 • 第１段階 ◦ システム統合（正規化・構造化） ▪ 契約（請求）切り離し ▪ 契約（請求）管理移行 ◦ マスタデータ統合 ▪ 職種 ▪ スキル ◦ 流入~登録に関わる仕組みの改善 ▪ ※ 検討中 • 第２段階 ◦ システム統合（正規化・構造化） ▪ マイページ統合 ▪ 人材管理移行 ▪ 企業管理移行 ▪ 案件管理移行 プロダクト開発体制移行の流れ システム戦略
23. 今回の発表ではRevtech第1段階の内、 レバテックフリーランス稼働者向けのUXに関わるシステ ム・データ領域のPJで、 古庄が実践した内容に絞ってお伝えしていきます。
24. キーワードは4つ ・EventStorming ・RDRA2.0 ・アジャイル開発 ・コト品質と依存方向
25. キーワードは4つ ・EventStorming ・RDRA2.0 ・アジャイル開発 ・コト品質と依存方向
26. |　© Leverages inc. 26 • イベント(コト)を起点としたモデリングする手法 の一つ • 2023/06/07のレバレジーズテックフェスで技術 顧問の加藤潤一(かとじゅん)さんに基調講演 で紹介いただいた手法です ◦ みなさん完全に理解してますよね？😇 • 複雑なビジネスドメインを協働で探索するため の柔軟なワークショップ形式です • EventStormingについて詳しくかとじゅんさん の登壇資料にあるので、今日は概要のみの説 明でw EventStormingとは EventStorming
27. キーワードは4つ ・EventStorming ・RDRA2.0 ・アジャイル開発 ・コト品質と依存方向
28. |　© Leverages inc. 28 • アイコンの繋がりによって、要求分析・要件定 義をするフレームワーク • RDRAの考え方 ◦ 要件定義は4つの視点で構成される ▪ システムが価値をもたらす視点 ▪ システムが使われる環境を表す 視点 ▪ システムとの境界を表す視点 ▪ システムそのものを表す視点 RDRA2.0とは(Relationship Driven Requirement Analysis) RDRA2.0
29. |　© Leverages inc. 29 • システム価値 ◦ システムと関係を持つ対象とそこからの 要求を捉える • システム外部環境 ◦ システムを取り巻く外部環境を明らかに する • システム境界 ◦ システムの外部と内部の境界を明らか にし、システムの範囲を明確にする • システム ◦ システム内部の機能とデータ構造を明ら かにする 要件定義の基本的な考え方 RDRA2.0
30. |　© Leverages inc. 30 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする • システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 RDRA2.0
31. |　© Leverages inc. 31 • 大きく4つに分類 ◦ 方向性を求めるもの ◦ 階層化でスコープを表すもの ◦ ユースケース横断で整合させるもの ◦ 要件定義の詳細を定義するもの →階層化で大規模システムに対応する ダイアグラムの関係 RDRA2.0
32. RDRAは要求分析/要件定義の手法 EventStormingはイベント分析の手法 RDRAとEventStormingの違い
33. 目的や目線が全く異なる RDRAとEventStormingの違い
34. RDRAとEventStormingの違い ちがい RDRA EventStorming(デザインレベル) 重視するもの 情報 のつながり イベント(出来事) のつながり 守備範囲 要求～ユースケースくらいまで ユースケース前後～詳細くらい 目線 プロジェクト全体を俯瞰 詳細な出来事を注視
35. RDRAとEventStormingの違い RDRA と EventStroming(デザインレベル) の組み合わせの可能性 より
36. キーワードは4つ ・EventStorming ・RDRA2.0 ・アジャイル開発 ・コト品質と依存方向
37. |　© Leverages inc. 37 • 目的 ◦ ビジネス価値の最大化を実現するた めに、顧客満足度の向上、変化への 対応を意識する ◦ 現場現物現実で、実際に役に立つ、 動くソフトウェアを提供し、顧客から のフィードバックにより継続的に改善 する • 反復増加型開発 ◦ 1週間から1ヶ月の反復期間を設け、 その反復毎に機能の追加を継続す る「反復増加型」の開発プロセスで実 現される アジャイル開発の概念 アジャイル開発 IPA アジャイル開発の進め方より アジャイル開発の概要とウォーターフォール開発との対比より
38. アジャイル開発で陥りがちな問題
39. アジャイル開発　　　　　　
40. アジャイル開発いつ終わるんだ問題
41. |　© Leverages inc. 41 • 開発スコープもわからない状態で開発だけが 先行し、初期段階に「とりあえず実装」したこと で、中盤以降、開発済みの部分と新規開発分 の整合性を確保するための手戻りが多くなる ことが原因 • 全体視点から相互の関係性を意識しながらモ デリングをすることで克服可能！ ◦ (モデリングしたくなってきましたよね？？ ) アジャイルいつ終わるんだ問題 アジャイル開発 RDRA 2.0とはより
42. |　© Leverages inc. 42 • 保守開発フェーズのトラブル ◦ いろんな部門の人が、自分たちの関心 事でPJに関わるから、誰も関心を払わ ない領域がでてくる。これが障害やトラ ブルに繋がるし、既存システムを誰も良 くわからない状態 ◦ 開発側 ▪ 要求・要望がどこに影響するのか 良くわからない • →これもRDRAが解決したい世界 ◦ (うずうずしてきてますよね？？) 番外)レバテックで見かける問題 アジャイル開発
43. キーワードは4つ ・EventStorming ・RDRA2.0 ・アジャイル開発 ・コト品質と依存方向
44. |　© Leverages inc. 44 • 品質の標準規格(ISO25010より) ◦ 開発者視点と、利用者視点でそれぞれ 品質が異なる • モノの品質は当たり前で、モノを利用したこと で得られる高揚感や多幸感といった コトの品 質が求められる時代 品質特性 QUALIITY
45. |　© Leverages inc. 45 • 品質の標準規格(ISO25010より) ◦ 開発者視点と、利用者視点でそれぞれ 品質が異なる • モノの品質は当たり前で、モノを利用したこと で得られる高揚感や多幸感といった コトの品 質が求められる時代 →「ビジネス価値の最大化を実現するため に、顧客満足度の向上、変化に対応」すること が大事 →アジャイルが求められる背景でもある 品質特性 QUALIITY
46. |　© Leverages inc. 46 • 時間軸が広がっている ◦ 「コトの品質」を生み出すことが必要に なるため、プロダクトマネジメント の重要 性が上がっている • PJは、終わらせることがミッション • プロダクトは、継続することがミッション • プロダクトが継続し続けるために、 PJが存在 していることを意識するべき • PJのその先の未来(理想)から逆算して、シス テム全体のアーキテクチャの変更容易性を高 めておく必要がある 品質特性 QUALIITY (DX時代の品質保証より)
47. コトの品質と依存方向
48. コトの品質と依存方向 既視感...？？？
49. |　© Leverages inc. 49 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする • システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 QUALITY
50. |　© Leverages inc. 50 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする • システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 QUALITY 依存
51. |　© Leverages inc. 51 依存 ＝
52. RDRA2.0とEventstormingを実践
53. 1. 「契約」ドメインのビジネスコンテキスト・ユースケースを調査 2. 開発メンバーでEventStorming実施 3. システムコンテキストを共通言語かして要件定義へ 4. 各要求モデルの定義・構造化 a. CJMを元にユーザーストーリーマッピング ←イマココ 5. ステークホルダーとの RDRA・EventStorming実施 システムフルリニューアルPJ推進に向けてやってきたこと
54. 契約のビジネスコンテキスト・ユースケースを概念化
55. EventStorming実施(1回目)
56. EventStorming実施(1回目)
57. EventStorming実施(1回目)
58. EventStorming実施(1回目) 合計2時間でコンテキスト分けられたの は大きな収穫でした！ 特定領域のみ完全にコンテキストを 分離できたことで、PJ全体を俯瞰した際 に依存関係のなく、進められるドメインを 分離できた →システムコンテキストの不確実性を局 所化したPJに切り出し成功！
59. システムコンテキストを共通言語化して要件定義へ 特定のコンテキストの情報モデルと状態モ デルを構造化したことで、具体的にステー クホルダーとの要望レベルを解像度高く実 現できる状態になった
60. CJMを元にユーザーストーリーマッピングを行い要望レベルを構造化
61. |　© Leverages inc. 61 • アジャイル開発を進める上でも一定の要件定義は重要 • 要件定義で何を決めなきゃいけないのかは RDRAを使って構造化すると PJ全体を俯瞰して「分かる」定 数を素早く決めきれる • 「利用者(ユーザー)視点のコト品質」が重要な時代になっていて、コト品質に向かってシステムは依存し ている • RDRA2.0とEventStormingの二刀流でモデルベースの要件定義に取り組んでいる まとめ
62. 品質向上と手戻りリスク軽減するために、 RDRAとEventStormingの実践していきま しょー！
63. |　© Leverages inc. 63 • 資料 ◦ いかに開発効率と品質を高めるか : ドメイン駆動設計と組織パターンの視点から考える ◦ ドメインモデルの根拠とドメインモデル貧血症の対策について ◦ RDRA と EventStroming(デザインレベル) の組み合わせの可能性 ◦ 複数のモデリング手法を取り入れることでモデル駆動が出来るようになってきた話 • 書籍 ◦ RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法 ◦ モデルベース要件定義テクニック ◦ エリック・エヴァンスのドメイン駆動設計 ◦ 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 参考資料・書籍