Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Tech Leverages
November 29, 2023

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

## 技術

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

Tech Leverages

November 29, 2023
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © Leverages inc. 2 Introduction 自己紹介 古庄 和也 • 所属

    ◦ ITソリューションプロダクト開発グループ • 経歴 ◦ 学生時代 友人と事業運営(自社/受託開発) ◦ 2020年4月 レバレジーズ株式会社 新卒入社 • 業務 ◦ 企業向けプラットフォームの PdM兼開発業務全般 ◦ 直近はレバテック全体のリニューアル PJに注力 • 趣味 ◦ ゴルフ、シーシャ、愛猫のブラッシング
  2. | © Leverages inc. 3 • レバテック全体のシステムリニューアル PJ • EventStorming・RDRA2.0とは •

    アジャイル開発で陥りがちな問題 • コト品質と依存方向 • EventStorming・RDRA2.0を実践 • まとめ アジェンダ INDEX
  3. | © Leverages inc. 4 1. PJの「不確実性」を極小化してアジャイル開発 を進める重要性を意識 (理解)できるようになる 2. 「利用者(ユーザー)視点のコト品質」とシステ

    ムの依存方向を意識 (理解)できるようになる 3. RDRA2.0とEventStormingを活用してモデリ ングを実践したくなる 今日のゴール 目的・目標
  4. | © Leverages inc. 6 VISION 日本を、 IT先進国に。 日本を、どこよりも進んだ IT技術を持つ国にする。 そして、ここで生まれた

    IT人材や組織の力が、 世界中のすべての課題を、 解決する。 それが、レバテックが 叶えたい未来です。
  5. | © Leverages inc. 10 • Why - プロダクト開発体制をなぜやるのか? ◦ 「事業目標・組織目標を達成する」ため、

    ◦ 「開発者体験(DevEx)の向上」を行い、 ◦ 「プロダクト開発体制を構築」する。 • What - プロダクト開発体制とはなにか? ◦ 事業軸を通してUXや仕組みを継続的に改善できる体制 ▪ 機能軸の改善だけでなく、事業軸を通した改善 ▪ 根本的な改善を行うことで新しい挑戦 • HOW - どうやって進めていくのか? ◦ 理想のシステム→組織を定義 ▪ そこに向かって進めていきたい プロダクト開発体制へ向けて プロダクト開発体制
  6. | © Leverages inc. 11 • 事業軸を通してUXや仕組みを継続的に改善できる体制を作るには ◦ 理想のシステム→組織を定義していく必要がある ▪ ※

    逆コンウェイの法則 • この段階でいきなりレバテック全体を最適化するのは難しい ◦ 事業部を横断してどんな形が理想なのかは正直わからない ◦ 当初、想定していたビッグバンリリースもリスクが大きすぎる • なので、まずは特定の事業軸から段階的に取り組んでいく ◦ 小さく成功体験を積み上げて、横横展していく想定 理想の”システム”を構築し、理想の”体制”を構築する プロダクト開発体制
  7. | © Leverages inc. 13 • 「コンウェイの法則」 ◦ システムの設計(アーキテクチャー)は、お のずと組織構造を反映させたものになる •

    「逆コンウェイの法則」 ◦ コンウェイの法則を逆手に取る ◦ 実現したいシステムの設計(アーキテク チャー)に合わせた組織構造にする 逆コンウェイの法則 プロダクト開発体制 コンウェイの法則と逆コンウェイの法則から組織構造を考えるより
  8. | © Leverages inc. 14 • レガシーシステムからの脱却 ◦ 古い技術スタックで動いているシステム ◦ バッチサーバやファイルサーバといった仕組み

    ◦ … • 密結合システムの廃止 ◦ 流入における重複判定の仕組み ◦ 人材や案件情報の複数システムにおける重複管理 ◦ … • 非構造化データの構造化 ◦ 文字列を利用したリレーション構造 ◦ EAVパターンを利用したリレーション構造 ◦ … • マスタデータの統合化 ◦ サービスごとにIDや項目ごとに異なる ◦ … 現状のシステムにおける問題や課題 システム戦略 【LT】Revtech-PJ 概要資料より
  9. | © Leverages inc. 17 • ”システム”と”データ”をあるべきところ(構造)に集約する ◦ システム統合(正規化・構造化) ▪ 契約情報

    ▪ 人材情報 ▪ 企業情報 ▪ 案件情報 ▪ 営業支援システム ▪ … ◦ マスタデータ統合化 ▪ 職種 ▪ スキル ▪ … ◦ 流入~登録に関わる仕組みの改善 ▪ 検討中 ▪ … 「集めるべきところに集める」とは システム戦略
  10. | © Leverages inc. 22 • 第1段階 ◦ システム統合(正規化・構造化) ▪ 契約(請求)切り離し

    ▪ 契約(請求)管理移行 ◦ マスタデータ統合 ▪ 職種 ▪ スキル ◦ 流入~登録に関わる仕組みの改善 ▪ ※ 検討中 • 第2段階 ◦ システム統合(正規化・構造化) ▪ マイページ統合 ▪ 人材管理移行 ▪ 企業管理移行 ▪ 案件管理移行 プロダクト開発体制移行の流れ システム戦略
  11. | © Leverages inc. 26 • イベント(コト)を起点としたモデリングする手法 の一つ • 2023/06/07のレバレジーズテックフェスで技術 顧問の加藤潤一(かとじゅん)さんに基調講演

    で紹介いただいた手法です ◦ みなさん完全に理解してますよね?😇 • 複雑なビジネスドメインを協働で探索するため の柔軟なワークショップ形式です • EventStormingについて詳しくかとじゅんさん の登壇資料にあるので、今日は概要のみの説 明でw EventStormingとは EventStorming
  12. | © Leverages inc. 28 • アイコンの繋がりによって、要求分析・要件定 義をするフレームワーク • RDRAの考え方 ◦

    要件定義は4つの視点で構成される ▪ システムが価値をもたらす視点 ▪ システムが使われる環境を表す 視点 ▪ システムとの境界を表す視点 ▪ システムそのものを表す視点 RDRA2.0とは(Relationship Driven Requirement Analysis) RDRA2.0
  13. | © Leverages inc. 29 • システム価値 ◦ システムと関係を持つ対象とそこからの 要求を捉える •

    システム外部環境 ◦ システムを取り巻く外部環境を明らかに する • システム境界 ◦ システムの外部と内部の境界を明らか にし、システムの範囲を明確にする • システム ◦ システム内部の機能とデータ構造を明ら かにする 要件定義の基本的な考え方 RDRA2.0
  14. | © Leverages inc. 30 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする •

    システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 RDRA2.0
  15. | © Leverages inc. 31 • 大きく4つに分類 ◦ 方向性を求めるもの ◦ 階層化でスコープを表すもの

    ◦ ユースケース横断で整合させるもの ◦ 要件定義の詳細を定義するもの →階層化で大規模システムに対応する ダイアグラムの関係 RDRA2.0
  16. RDRAとEventStormingの違い ちがい RDRA EventStorming(デザインレベル) 重視するもの 情報 のつながり イベント(出来事) のつながり 守備範囲

    要求~ユースケースくらいまで ユースケース前後~詳細くらい 目線 プロジェクト全体を俯瞰 詳細な出来事を注視
  17. | © Leverages inc. 37 • 目的 ◦ ビジネス価値の最大化を実現するた めに、顧客満足度の向上、変化への 対応を意識する

    ◦ 現場現物現実で、実際に役に立つ、 動くソフトウェアを提供し、顧客から のフィードバックにより継続的に改善 する • 反復増加型開発 ◦ 1週間から1ヶ月の反復期間を設け、 その反復毎に機能の追加を継続す る「反復増加型」の開発プロセスで実 現される アジャイル開発の概念 アジャイル開発 IPA アジャイル開発の進め方より アジャイル開発の概要とウォーターフォール開発との対比より
  18. | © Leverages inc. 41 • 開発スコープもわからない状態で開発だけが 先行し、初期段階に「とりあえず実装」したこと で、中盤以降、開発済みの部分と新規開発分 の整合性を確保するための手戻りが多くなる ことが原因

    • 全体視点から相互の関係性を意識しながらモ デリングをすることで克服可能! ◦ (モデリングしたくなってきましたよね?? ) アジャイルいつ終わるんだ問題 アジャイル開発 RDRA 2.0とはより
  19. | © Leverages inc. 42 • 保守開発フェーズのトラブル ◦ いろんな部門の人が、自分たちの関心 事でPJに関わるから、誰も関心を払わ ない領域がでてくる。これが障害やトラ

    ブルに繋がるし、既存システムを誰も良 くわからない状態 ◦ 開発側 ▪ 要求・要望がどこに影響するのか 良くわからない • →これもRDRAが解決したい世界 ◦ (うずうずしてきてますよね??) 番外)レバテックで見かける問題 アジャイル開発
  20. | © Leverages inc. 44 • 品質の標準規格(ISO25010より) ◦ 開発者視点と、利用者視点でそれぞれ 品質が異なる •

    モノの品質は当たり前で、モノを利用したこと で得られる高揚感や多幸感といった コトの品 質が求められる時代 品質特性 QUALIITY
  21. | © Leverages inc. 45 • 品質の標準規格(ISO25010より) ◦ 開発者視点と、利用者視点でそれぞれ 品質が異なる •

    モノの品質は当たり前で、モノを利用したこと で得られる高揚感や多幸感といった コトの品 質が求められる時代 →「ビジネス価値の最大化を実現するため に、顧客満足度の向上、変化に対応」すること が大事 →アジャイルが求められる背景でもある 品質特性 QUALIITY
  22. | © Leverages inc. 46 • 時間軸が広がっている ◦ 「コトの品質」を生み出すことが必要に なるため、プロダクトマネジメント の重要

    性が上がっている • PJは、終わらせることがミッション • プロダクトは、継続することがミッション • プロダクトが継続し続けるために、 PJが存在 していることを意識するべき • PJのその先の未来(理想)から逆算して、シス テム全体のアーキテクチャの変更容易性を高 めておく必要がある 品質特性 QUALIITY (DX時代の品質保証より)
  23. | © Leverages inc. 49 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする •

    システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 QUALITY
  24. | © Leverages inc. 50 • 要求モデル ◦ 要望/要求/要件に分類し、重要な要求の整理と実現する要件を明ら かにする •

    システムコンテキスト ◦ システム化の目的を実現するためのアクターや外部システムを示し登場人 物を明らかにする • ビジネスコンテキスト ◦ 業務の洗い出しと、業務に関わる要素を洗い出し、内容を 明確にする • ビジネスユースケース ◦ 「業務」を構成する価値を提供する単位として明確にし、分 割基準を明確にする ◦ 「業務フロー図」「利用シーン図」の単位 • バリエーション・条件 ◦ ビジネスルールを取り巻くバリエーション(種別)・条件を集 約する • 業務フロー • UC複合図 • 情報モデル ◦ システムで扱うビジネスを駆動するための用語を構造化し たもの • 状態モデル ◦ ビジネス上使用している用語の中で状態を表しているもの を構造化する 要件定義はダイアグラム単位で作成 QUALITY 依存
  25. | © Leverages inc. 61 • アジャイル開発を進める上でも一定の要件定義は重要 • 要件定義で何を決めなきゃいけないのかは RDRAを使って構造化すると PJ全体を俯瞰して「分かる」定

    数を素早く決めきれる • 「利用者(ユーザー)視点のコト品質」が重要な時代になっていて、コト品質に向かってシステムは依存し ている • RDRA2.0とEventStormingの二刀流でモデルベースの要件定義に取り組んでいる まとめ
  26. | © Leverages inc. 63 • 資料 ◦ いかに開発効率と品質を高めるか : ドメイン駆動設計と組織パターンの視点から考える

    ◦ ドメインモデルの根拠とドメインモデル貧血症の対策について ◦ RDRA と EventStroming(デザインレベル) の組み合わせの可能性 ◦ 複数のモデリング手法を取り入れることでモデル駆動が出来るようになってきた話 • 書籍 ◦ RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法 ◦ モデルベース要件定義テクニック ◦ エリック・エヴァンスのドメイン駆動設計 ◦ 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 参考資料・書籍