20241217 競争力強化とビジネス価値創出への挑戦：モノタロウのシステムモダナイズ、開発組織の進化と今後の展望

Transcript

1. 競争力強化とビジネス価値創出への挑戦 ：モノタロウのシステムモダナイズ、開 発組織の進化と今後の展望 2024/12/17 株式会社MonotaRO CTO 普川泰如 1 © 2024 MonotaRO Co., Ltd. All Rights Reserved.
2. 普川泰如 （ふかわ たいすけ） 株式会社 MonotaRO　CTO taipuka0 慶応義塾大学環境情報学部卒業、 SIer企業を経て2009年にオイシックス・ラ・大地 に入社、2016年同システム副本部長。 2019年にモノタロウに参画。 2021年1月に ECシステムエンジニアリング部門長、 2022年4月に執行役CTO/VPoEに就任。 顧 客体験の向上をアジリティ高く行うべくシステム全体のモダナイゼーションと組織作 りを推進中。 趣　味 ランニング　マラソン　PB3時間56分 トレラン　　高尾山、奥多摩周辺の山が多い キャンプ　　なぜか焚き火台３台所有、ほぼ焚き火をしている 2 自己紹介
3. 3 早速ですが、 みなさんの会社では何のため にソフトウェア開発をしてい ますか？
4. 4 事業活動の当事者としてソフトウェア開発を行う 2024/11/26アーキテクチャConference ソフ トウェア開発の複雑さに立ち向かうより抜粋 モノタロウ統合報告書より 競争優位を作り出す手段の一つ モノタロウでは会社の競争優位性を作り出し、ビジネス 価値を生み出すためにソフトウェア開発を行っている
5. 5 本日のテーマ モノタロウではモダナイゼーションと通して、ソフトウェ ア開発をどう会社の競争優位性、ビジネス価値につなげて いるのかを一企業の例として紹介します。 またそれを行うにあたり、何を考えどういうことを行って きたのか、今後何をするのかを説明します。
6. 6 簡単に事業概要説明
7. システムと組織 7 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 コールセンター、商 品 採 用、物 流、 マーケティング、データサイエンス、 IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 事業紹介
8. システムと組織 8 事業紹介 商品点数 2,217万点 ユーザー数 約910万件 売上（連結） 2542億円 グローバルに サービス展開 　※前年比 +12.5%
9. 9 モノタロウのビジネスモデル まずは自社の価値の源泉を理解する
10. わたしたちについて 10 事業成長サイクル 取扱商品 点数拡大 顧客数拡大 在庫点数 拡大 売上・利益 拡大 スケールアップ=利便性アップ •新規顧客獲得増 •ロングテール商品の購入頻度向上 •商品の在庫化が進むことによって 納期短縮、利便性向上 •プライベートブランド化も 推進し利益率向上 •検索ワード数拡大 •ワンストップショッピングの幅拡大 （取扱商品点数2,217万点） •周辺商品の取扱拡大
11. わたしたちについて 11 間接資材の特性 メーカーなどのモノづくり企業が購入する資材の金額は、約80％が 直接資材で20%が間接資材で構成されると言われます。 一方で、品目数は直接資材が20％に対し、間接資材は80％。 そのため、消耗品やたまにしか使わないものなど多種多様な間接資 材を仕入れるには、多くの企業と取引する必要があり、手間が大き くかかってしまう状況でした。 多 少 購 入 量 ・ 全 額 企業の購買品の構成イメージ ヘッド ・購入プロセスの効率化がしやすい ・商品データ登録済 ・有利な条件で購入 ロングテール ・リピート購入がない ・都度購入品 ・拠点別購入品 ・商品データ未登録 ・メンテが困難 ・見える化ができない ヘッド商品とロングテール商品の割合 ［ヘッド］ ［ロングテール］ 80% 20% 20% 20% 80% 80% 買う頻度は 少ないのに 探すのも買うのも 手間…… 手袋 テープ 工具 ナット 例えば… 金額 品目 手間
12. 12 モノタロウのビジネスモデル 事業成長サイクルのも と、商品数、顧客数、注 文数が増加、それにとも なって図の各ネットワー クも拡大していく。 結果、トランザクション 数と複雑性が増す。ドメ インロジックも激増。各 領域毎にスケールできる 状況にしていきたい。
13. わたしたちについて 13 売上・登録口座数推移 売上は順調に増加 その裏でサービス、機 能、顧客の増加により 業務の複雑性も増加 売上2,000億円 突破 2009.12 東証一部変更 2006.12 マザーズ上場 (計画値) （百万円） （千口座）
14. 14 ２つの複雑性 我々が提供しているサービスは高度化していく中で差別化となる必要な業務の複雑性に長 年のビジネス/組織の拡大によって生じた不要な複雑性が付随し、本来取り組むべき課題、 複雑性に集中できなくなっていることが問題。これを取り除き、業務とシステムの可変性 を再び取り戻すことが必要 っっｘ 取り組むべ き課題 不必要な複雑性、 煩雑さ 以前 現状 現状 現状 未来 っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ 不必要な複雑性が増え た結果、本来取り組むべ き課題に集中できない 課題を分割すること、不必要な煩雑さ を減らすことで、本来取り組むべき課 題に向き合える状態になる
15. 15 課題感とやるべきこと • 基幹システムがモノリスアプリケーションであり、拡張とビジネス成長に よって複雑さが増し、変更容易性が失われた • 一方で業務のスケールとそれに付随する「複雑性」はモノタロウの差別化 ポイントでもある • その複雑性をアーキテクチャの構造に落とし込むことで、業務とソフト ウェアの変更容易性を上げていく。 • そのために業務モデリングを徹底的に行い、ドメインを分割することで認 知負荷を下げる。 • 競争優位をもたらす業務の複雑性を明らかにしつつそれが各ドメインで同 時に進化できるようにデザインする。
16. 16 ドメインモデリングを通して共 通のメンタルモデルを整え、 アーキテクチャ、設計に落とし ていくまで
17. まずは顧客フルフィルメント業務全体を広範囲にイベントストーミング。 エンジニア、業務担当者、マネージャーなど総勢30名ほどが参加して全体感を共有。 ただしこれだけでは、システムの設計からはほど遠い。。。。 17 Web注文 キャンセル 受注保留 引当て 出荷指示 調達 出荷 配送 実践① 業務全体をイベントストーミング
18. • 協働的に業務プロセスをモデリングするワークショップの1手法 • 業務側（ドメインエキスパート）とエンジニアが一緒に行う • ワークの結果がソフトウェア設計のインプットになる 18 イベントストーミングとは
19. 1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す 6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 19 イベントストーミングの進め方 より詳細を知りたい方は、 アマゾンウェブサービスジャパン ソリューションアーキテクトの 福井さんの以下の動画がおすすめ 実践！モノリスからマイクロサービス！ Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo
20. • ステークホルダー全員の共通認識のもと分析された業務プロセスが可視化される ◦ ユビキタス言語 → 言葉の統一による共通認識の深化 ◦ 境界づけられたコンテキスト → 同じ文脈で意思疎通可能な(いくつかの)業務領域 ◦ ドメイン → 関心事を分離した業務領域、カプセル化で結合度低下と凝集性向上 • ドメインモデルはシステム設計のインプットになる • 得られるメリット ◦ 業務側・システム側の共通理解がそのままシステムに反映される ◦ 関心事が分離されているので、各システムが独立して変化できる 20 イベントストーミングに期待できること
21. 21 受注/配送ドメイン境界議論 実践② 特定の領域でさらに分析 特に受注/配送ドメイン境界が 曖昧だったため議論を深めた。 この議論を通じて、受注ドメインの 責務について論点出しができた。 受注 引当 在庫 出荷 ※これもあくまで１トピックで 他の境界や業務整理が必要なところに ついて随時、分析を加えています
22. 22 一度に全てを把握することは不可能。 全体から入りつつ、段階的に境界と繋がりを見極めていく必要がある。 抽象度の異なる複数のモデルを往復しながら進めていく手間のかかる作業 全体から入り、段階的に詳細化し分析する ビッグピクチャー （広範な業務全体のプロセスモデル） コンテキストマップ * （区切られた文脈の関係図） プロセスモデル (特定業務領域の詳細なプロセスモデル)
23. 23 「流れ」のプロセスモデルから「構造」のドメインモデルを導き出すには ギャップが大きい。プロセスモデルから集約とコマンドを抜き出し、 集約の構成要素(概念)を見極め、概念の関係性を表すモデルを作成した。 実践③ 流れ から 構造 を導き出す
24. 24 「流れ」のプロセスモデルから「構造」のドメインモデルを導き出すには ギャップが大きい。プロセスモデルから集約とコマンドを抜き出し、 集約の構成要素(概念)を見極め、概念の関係性を表すモデルを作成した。 ③ 流れ から 構造 を導き出す 24 リードモデル ドメインロ ジック 業務イベント
25. 25 ④アーキテクチャと移行計画を考える 在庫ドメインが解決したい課題は以下の通りであった • 在庫状況TBLが周辺業務の密結合点となり、複数の業務の関心事が混在している （業務領域間の結合度を下げる） ◦ 業務領域を基本単位として現モノリスから切り出し、データも独自に管理する ◦ 他 業務領域とは非同期連携とする（EDA） • 業務知識が散在し、在庫状況TBLのデータ構造に依存する業務が多い （業務知識とデータ構造をカプセル化する） ◦ 業務領域ごとにデータを独自管理し、データの操作もひとまとめにする ◦ 業務が扱うデータと、公開するデータのモデルを分ける（CQRS） • 在庫状況TBLは履歴情報を保有できない （変更の履歴を持ち、任意の時点の状態を再現する） ◦ 業務イベント保有し、その積み上げによって最新の状態を得る（Event Sourcing）
26. 26 現行システムからの移行計画 その１ ①EventSourcing＋CQRS環境を構築 ②既存DBの変更をドメインイベントに変換＋新ReadModelDBで業務遂行 ③ドメインアプリが既存DB更新とイベント発行を並行
27. 27 現行システムからの移行計画 その２ ④既存アプリによる既存DB更新と、既存DBの変更検知を廃止 ⑤既存DBへの参照を廃止＋猶予措置として新ReadMoelDBの内容を既存DBに書き戻し
28. 28 説明： 既存DBの変更をDMSが検知し てReadReplicaに書き込み、 AWS Lambdaがドメインイベ ントに変換する。 ドメインイベントはMSKに割 り当てられたトピックに登録 され、さらに後続のドメイン ロジックにより処理されて EventStoreに記録され、 ReadModelにも反映される。 移行ステップ的には②-1の状態 ④システムのアーキテクチャ概要
29. 29 組織的な施策
30. • 仮決めしたドメインにそって組織を再編した（逆コンウェイ戦略） • 既存アプリケーションの各コンポーネントをドメインに割り当てた • ドメインチーム毎にアプリケーションの実行環境分けた 30 ドメイン分割の前にやったこと チームをドメインに従って再編成
31. 31 プラットフォームエンジニアリング部門の組成 31 アプリケーション 開発者 設 計 開 発 テ ス ト リ リ ー ス 顧客提供価値 ビジネスロジックの複 雑性に向き合う 技術的な複雑性に 向き合う プラットフォーム エンジニアリング アプリケー ション （サイト） アプリケー ション （事業） アプリケー ション （基幹） 1. MDIと呼ばれるアプリケーションテ ンプレート 2. コンテナ基盤 3. DOJO（トレーニング機関） 4. 開発生産性向上のためのイネイブリ ング
32. 企業、エンジニア文化 32 MonotaRO DOJO DOJOとは MonotaROで標準的に利用している技術・開発手法の社内 トレーニング機関 ソフトウェア開発における設計・テストの普遍的な考え方を学ぶ開発基礎、KubernetesやReact/Next.JSなどモダ ナイゼーションで使う要素技術と社内での開発ガイドにそった使い方を学ぶもの、アジャイル、チームビルディン グなど開発カルチャーに関わるものがある。 標準開発 スキル カルチャー・ 開発手法 2024年の上半期では12種類以上のワークショップが全部で16回開催され、のべ544人が参加(平均1人3回程度） 開発基礎
33. 33 https://tech-blog.monotaro.com/entry/2023/12/22/090000 https://tech-blog.monotaro.com/entry/2024/02/01/090000 必要なスキルを洗い出した DOJO MenuMapを作成 ドメインモデリング、アーキテクチャ、ソフトウェア開発、アジャイ ル、チームビルディング、リーダーシップなどコース内容は多岐 に渡る 本当に今エンジニアが必要としている「ソフトウェアエンジニアリ ングスキル」とそれを向上させるための取り組みを議論。実際 の業務のコードを元にしたリファクタリングを実践 MonotaRO DOJO
34. • モノタロウが進めるサプライチェーン高 度化の取り組みが進められている。 • 特にサイトでの在庫表示や配送のサービ スレベルアップが進んだ • 現状は商品引き当て、在庫、受注まわり を中心に刷新中。今後は、商品、顧客な ど他業務ドメインにも展開する。 34 これまでの成果と今後の展望
35. • モノタロウでは会社の競争優位性を作り出し、ビジネス価値を生み出す ためにソフトウェア開発を行うと定義した • 数年前の時点では、その目的を達成しづらい状況にあると判断し、シス テムのモダナイゼーションを進めた • 会社のビジネスモデルのスケールと業務の複雑性の包含した形での進化 が重要と認識 • ドメインモデリングを徹底的にすすめ、アーキテクチャとソフトウェア 設計に落とし込み開発を進めている。 35 まとめ