業務理解の深化と実践～ドメインモデリングで基幹システムを捉える

Slide 1

Slide 1 text

Slide 2

Slide 2 text

尾髙敏之株式会社MonotaRO CTO-Oﬃceグループ在庫モダナイズチームシニアアーキテクト 2 2023年11月にモノタロウ入社。 IT職歴の大半を事業会社のIT部門で過ごし、biz/sysの関係構築や要件定義などの超上流工程に取り組んできたが、「質とスピード」という言葉に出会ってからは品質→保守性に目を開き、モノタロウ入社後は良い構造とは？を求めてチームとすり合わせる日々。最近はイベントストーミングの企画やファシリテートで声をかけてもらうことが多くなってきた。撮影は @nrslib さん

Slide 3

Slide 3 text

3 本セッションでお伝えしたいこと ● モノタロウは、いかにしてビジネスアジリティを獲得しようとしているか ● ビジネスの構造に即した柔軟なアプリケーションアーキテクチャを構築する ● 組織の成長を加速する

Slide 4

Slide 4 text

4 モノタロウで基幹システム刷新を行う背景

Slide 5

Slide 5 text

システムと組織 BtoB を対象に、自ら間接資材の在庫を持ち、自らオンラインで売るEC企業コールセンター、商品採用、物流、マーケティング、データサイエンス、 IT など多くの業務とシステムを自社開発、自社運用もしているフルスタック EC カンパニー事業紹介 5

Slide 6

Slide 6 text

システムと組織事業紹介商品点数 2475万点ユーザー数約1112万件売上（連結） 2881億円グローバルにサービス展開　※前年比 +13.3% 6

Slide 7

Slide 7 text

わたしたちについて 7 事業成長サイクル取扱商品点数拡大顧客数拡大在庫点数拡大売上・利益拡大スケールアップ=利便性アップ •新規顧客獲得増 •ロングテール商品の購入頻度向上 •商品の在庫化が進むことによって納期短縮、利便性向上 •プライベートブランド化も推進し利益率向上 •検索ワード数拡大 •ワンストップショッピングの幅拡大（取扱商品点数2,475万点） •周辺商品の取扱拡大

Slide 8

Slide 8 text

わたしたちについて 8 売上・登録口座数推移売上は順調に増加その裏でサービス、機能、顧客の増加により業務の複雑性も増加売上2,000億円突破 2009.12 東証一部変更 (計画値) （百万円）（千口座）

Slide 9

Slide 9 text

モノタロウのビジネスモデル事業成長サイクルのもと、商品数、顧客数、注文数が増加、それにともなって図の各ネットワークも拡大していく。結果、トランザクション数と複雑性が増す。ドメインロジックも激増。各領域毎にスケールできる状況にしていきたい。 9

Slide 10

Slide 10 text

我々が提供しているサービスは高度化していく中で、差別化の要因として必要な業務の複雑性（本質的複雑性）に、長年のビジネス/組織の拡大などによって生じた不要な複雑性（偶有的複雑性）が付随し、取り組むべき課題に集中できなくなっている。この不要な複雑性を取り除き、業務とシステムの可変性を再び取り戻すことが必要。っっｘ取り組むべき課題不必要な複雑性、煩雑さ以前現状未来っっｘっっｘっっｘっっｘっっｘっっｘ不必要な複雑性が増えた結果、本来取り組むべき課題に集中できない課題を分割すること、不必要な煩雑さを減らすことで、本来取り組むべき課題に向き合える状態になる 10 ２つの複雑性

Slide 11

Slide 11 text

11 ● 基幹システムの拡張とビジネスの成長により複雑さが増し、変更容易性が失われてしまった ● 業務の拡張とそれに付随する「複雑性」はモノタロウの差別化ポイントでもある（本質的複雑性） ● 継続的な会社の成長のため競争優位の源泉となる複雑性とは何か、改めて構造的に整理 ● その複雑性を基幹システムに落とし込むことで、業務とソフトウェアの可変性を取り戻し、会社の成長につなげる ● 「複雑性を基幹システムに落とし込む」には、モデリングにより事業要求に根ざしたアーキテクチャとすることが重要業務とソフトウェアの可変性を取り戻す

Slide 12

Slide 12 text

12 ドメイン分割とイベントストーミング　～ドメインモデリング

Slide 13

Slide 13 text

● 仮決めしたドメインにそって組織を再編した（逆コンウェイ戦略） ● 既存アプリケーションの各コンポーネントをドメインに割り当てた ● ドメインチーム毎にアプリケーションの実行環境分けた 13 ドメイン分割の前にやったことチームをドメインに従って再編成

Slide 14

Slide 14 text

● 協働的に業務プロセスをモデリングするワークショップの1手法 ● 業務側（ドメインエキスパート）とエンジニアが一緒に行う ● ワークの結果がソフトウェア設計のインプットになる 14 イベントストーミングとは

Slide 15

Slide 15 text

1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す 6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 15 イベントストーミングの進め方より詳細を知りたい方は、アマゾンウェブサービスジャパンソリューションアーキテクトの福井さんの以下の動画がおすすめ実践！モノリスからマイクロサービス！ Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo

Slide 16

Slide 16 text

まずは顧客フルフィルメント業務全体を広範囲にイベントストーミング。エンジニア、業務担当者、マネージャーなど総勢30名ほどが参加して全体感を共有。ただしこれだけでは、システムの設計からはほど遠い。。。。 Web注文キャンセル受注保留引当て出荷指示調達出荷配送実践① 業務全体をイベントストーミング 16

Slide 17

Slide 17 text

17 受注/配送ドメイン境界議論実践② 特定の領域でさらに分析特に受注/配送ドメイン境界が曖昧だったため議論を深めた。この議論を通じて、受注ドメインの責務について論点出しができた。受注引当在庫出荷 ※これもあくまで１トピックで他の境界や業務整理が必要なところについて随時、分析を加えています

Slide 18

Slide 18 text

一度に全てを把握することは不可能。全体から入りつつ、段階的に境界と繋がりを見極めていく必要がある。抽象度の異なる複数のモデルを往復しながら進めていく手間のかかる作業。全体から入り、段階的に詳細化し分析するビッグピクチャー（広範な業務全体のプロセスモデル）コンテキストマップ * （区切られた文脈の関係図）プロセスモデル (特定業務領域の詳細なプロセスモデル) 18

Slide 19

Slide 19 text

各モデルの棲み分け 19 コンテキストマップ構造のモデル流れのモデルドメイン全体ビッグピクチャ業務領域プロセスモデルドメインモデル

Slide 20

Slide 20 text

各モデルの棲み分け＋観点 20 コンテキストマップ構造のモデル流れのモデルドメイン全体ビッグピクチャ業務領域プロセスモデルドメインモデル業務的業務的ほぼ業務的 (詳細化するとアプリ設計に) アプリ的

Slide 21

Slide 21 text

「流れ」のプロセスモデルから「構造」のドメインモデルを導き出すにはギャップが大きい。プロセスモデルから集約とコマンドを抜き出し、集約の構成要素(概念)を見極め、概念の関係性を表すモデルを作成した。実践③ 流れから構造を導き出すリードモデル・主要な属性操作 (ドメインロジック) ユースケース (業務イベント) 21 概念構成図はこちらでもビジネスとアプリケーションを繋げるモデリング - Speaker Deck

Slide 22

Slide 22 text

22 やってみてわかったこと ● イベントストーミングで、複数の関係者が課題認識や前提を作れるのはかなり有効 ● 大規模なイベントストーミングは半日から１日程度。ただしそれで終わりではない ● 最初はビジネス全体を対象に、その後詳細化して特定の領域で行っていく ● 結果、分析はかなり時間と期間を要す。実際に我々は大まかなドメイン境界を決め、実装のPoC開始まで５ヶ月程度かけている。(専任メンバー＋関係者） ● ソフトウェア設計に落とし込むにはイベントストーミングだけではギャップがあり、他にも様々なワークでモデルを洗練させていく ● モデリングのセオリーはあるがそれを全部やる時間はなく、必要に応じて領域と手法を変えて探索的にモデルを深めていく必要があり、かなり高度な判断となるモデリングを行っての実際

Slide 23

Slide 23 text

何度も実施することで共通する考え方、質問が身についた ● そのドメイン(業務領域)の責務は何か、責務に照らして何をすべきか(すべきでないか) ● 集約の境界は適切か、過剰な一貫性を要求していないか ● 別々の文脈で登場する同じ名前の概念は、まったく同じ値を指しているか ● エンティティや属性、振る舞いの名前は適切か ● ある概念の本質は何か、抽象化して拡張性を持たせるべきか ● 一回の分析やワークで全てを決めきらない別の観点でも(モデルでも)整合性を検証しながら、決まっていく基本的にはユビキタス言語の発見と徹底した利用、境界に細心の注意を払う、カプセル化などイベントストーミングの説明でも触れたものが重要 23 モデリング進め方のポイント

Slide 24

Slide 24 text

24 新システムのアーキテクチャと現行システムからの移行

Slide 25

Slide 25 text

ここに「Stock 在庫」があるが、これは在庫数管理業務ではなく在庫計画などの戦略的な業務 ● そもそもモノタロウにおける在庫数管理業務は、受注，配送，発注，倉庫といった周辺業務の中に溶け込んでおり、ドメインとして確立していない ● システム構築当初の「小さいモノリスアプリ」として考えると、業務に必要な関心事を自ら持つことは一定の合理性があった ● 「在庫数管理業務」が複数ドメインの密接な結合点であるため、難易度は高いがここを最初に整理すると判断 25 在庫ドメインの分析を最初のターゲットにした

Slide 26

Slide 26 text

26 各種課題を解決するアーキテクチャ PoCアプリケーションが実証したい課題と解決策を要約・抜粋 ● 共用DBにある在庫状況は周辺業務の密結合点で、複数の業務の関心事が混在している（業務領域間の結合度を下げる） ○ 業務領域を基本単位として現行モノリスから切り出し、データも独自に管理する ○ 他業務領域とは非同期連携（イベント駆動）とする ● 在庫に関する業務知識が散在しており、また共有DBのデータ構造に依存する業務が多い（業務知識とデータ構造をカプセル化する） ○ 業務領域ごと独自管理するデータに関する操作もひとまとめにする ○ 業務が扱うデータと、公開するデータのモデルを分ける（CQRS） ● 在庫状況TBLは履歴情報を保有できない（変更の履歴を持ち、任意の時点の状態を再現する） ○ 業務イベント保有し、その積み上げによって最新の状態を得る（Event Sourcing）

Slide 27

Slide 27 text

27 説明：既存DBの変更をDMSが検知してReadReplicaに書き込み、 AWS Lambdaがドメインイベントに変換する。ドメインイベントはMSKに割り当てられたトピックに登録され、さらに後続のドメインロジックにより処理されて EventStoreに記録され、 ReadModelにも反映される。移行ステップは部分的に③の状態新システムのアーキテクチャ概要

Slide 28

Slide 28 text

28 現行システムからの移行計画その１ ①EventSourcing＋CQRS環境を構築 ②既存DBの変更をドメインイベントに変換＋新ReadModelDBで業務遂行 ③ドメインアプリが既存DB更新とイベント発行を並行

Slide 29

Slide 29 text

29 現行システムからの移行計画その２ ④既存アプリによる既存DB更新と、既存DBの変更検知を廃止 ⑤既存DBへの参照を廃止＋猶予措置として新ReadMoelDBの内容を既存DBに書き戻し

Slide 30

Slide 30 text

30 新アーキテクチャ移行のつらみ ● 現行のモノリスから安全に業務領域を分離するには、責務とインタフェースを他領域と調整しつつ、分離による影響を最小に抑える工夫が必要 ● 「モノリス＆共有DB」と「イベント駆動＆データメッシュ」間の技術的なギャップを乗り越えるには、アプリケーションのリアーキテクチャリングが必要（ドメインロジックとそれ以外を整理するチャンス!?） ● 「イベント駆動＆データメッシュ」の実現を支援するプラットフォームの整備・運用が不可欠 ● イベントソーシングもCQRSもドメインモデルもオブジェクト指向も扱えるようになるには教育コストがかかる

Slide 31

Slide 31 text

31 業務領域間の取り組みを整合させるには

Slide 32

Slide 32 text

32 個別の業務領域で検討は進んだ ● これまでの営み ○ 基幹業務全体を俯瞰 ○ 在庫数管理がフルフィルメントと調達の密結合点か ○ 在庫数管理を分離、関心事の分離を進める ● 在庫数管理・フルフィルメントといった個別の業務領域でモダナイズを進めることができている

Slide 33

Slide 33 text

33 改めて各業務領域間の関係を見極める ● モダナイズが進む領域でも、他領域とのインタフェースは想定の域を出ない ● 各領域がボトムアップで検討を進めるとともに、トップダウンでも全体像を描き、領域間の関係を整理する

Slide 34

Slide 34 text

34 個別領域の検討を加速する ● 整理された全体構成の蓋然性を高めるためには、各領域の内部構造を検討しなければならない ○ 結果として個別領域の検討を促進することに繋がる ○ さらに、「全体俯瞰」「問題領域特定」「改善検討」「全体の整合確認」「個別領域検討促進」のように視点を上下して俯瞰と個別を行き来しながら検討を進められ、全体と個別の整合を維持することにも繋がる

Slide 35

Slide 35 text

35 整合を維持しアジリティを生む現状未来っっｘっっｘっっｘっっｘっっｘっっｘさらに未来エンジニア個々人が内部品質に対する意識を上げ、組織がコミットする

Slide 36

Slide 36 text

36 まとめ：これまでの成果と今後の展望

Slide 37

Slide 37 text

● モノタロウが進めるサプライチェーン高度化の取り組みが進められている ● 特にサイトでの在庫表示や配送のサービスレベルアップが進んだ ● 現状は商品引き当て、在庫、受注まわりを中心に刷新中 ● 今後は、商品、顧客など他業務ドメインにも展開する 37 これまでの成果と今後の展望

Slide 38

Slide 38 text

38 【再掲】本セッションでお伝えしたいこと ● モノタロウは、いかにしてビジネスアジリティを獲得しようとしているか ● ビジネスの構造に即した柔軟なアプリケーションアーキテクチャを構築する ● 組織の成長を加速する

Slide 39

Slide 39 text

39 まとめ ● モノタロウは、サービスを高度化していく中で生じた偶有的複雑性を取り除くことでビジネスアジリティを取り戻します ○ それはドメインモデリングにより業務理解を深め、認知負荷と予測不能な変更コストの低減で実現します ● ビジネスの構造に即した柔軟なアーキテクチャは、全体と個別モデルの整合を保ち、変更容易性が必要な部分を見極めてモデリングコストを投じることで実現します ● 全体と個別で視点を行き来することで個別領域のモダナイズを促進する効果も期待できます