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

20241217 競争力強化とビジネス価値創出への挑戦:モノタロウのシステムモダナイズ、開発組...

Avatar for MonotaRO MonotaRO
December 22, 2024

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

Avatar for MonotaRO

MonotaRO

December 22, 2024
Tweet

More Decks by MonotaRO

Other Decks in Programming

Transcript

  1. 普川泰如 (ふかわ たいすけ) 株式会社 MonotaRO CTO taipuka0 慶応義塾大学環境情報学部卒業、 SIer企業を経て2009年にオイシックス・ラ・大地 に入社、2016年同システム副本部長。 2019年にモノタロウに参画。

    2021年1月に ECシステムエンジニアリング部門長、 2022年4月に執行役CTO/VPoEに就任。 顧 客体験の向上をアジリティ高く行うべくシステム全体のモダナイゼーションと組織作 りを推進中。 趣 味 ランニング マラソン PB3時間56分 トレラン  高尾山、奥多摩周辺の山が多い キャンプ  なぜか焚き火台3台所有、ほぼ焚き火をしている 2 自己紹介
  2. システムと組織 7 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 コールセンター、商 品 採 用、物

    流、 マーケティング、データサイエンス、 IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 事業紹介
  3. わたしたちについて 10 事業成長サイクル 取扱商品 点数拡大 顧客数拡大 在庫点数 拡大 売上・利益 拡大

    スケールアップ=利便性アップ •新規顧客獲得増 •ロングテール商品の購入頻度向上 •商品の在庫化が進むことによって 納期短縮、利便性向上 •プライベートブランド化も 推進し利益率向上 •検索ワード数拡大 •ワンストップショッピングの幅拡大 (取扱商品点数2,217万点) •周辺商品の取扱拡大
  4. わたしたちについて 11 間接資材の特性 メーカーなどのモノづくり企業が購入する資材の金額は、約80%が 直接資材で20%が間接資材で構成されると言われます。 一方で、品目数は直接資材が20%に対し、間接資材は80%。 そのため、消耗品やたまにしか使わないものなど多種多様な間接資 材を仕入れるには、多くの企業と取引する必要があり、手間が大き くかかってしまう状況でした。 多

    少 購 入 量 ・ 全 額 企業の購買品の構成イメージ ヘッド ・購入プロセスの効率化がしやすい ・商品データ登録済 ・有利な条件で購入 ロングテール ・リピート購入がない ・都度購入品 ・拠点別購入品 ・商品データ未登録 ・メンテが困難 ・見える化ができない ヘッド商品とロングテール商品の割合 [ヘッド] [ロングテール] 80% 20% 20% 20% 80% 80% 買う頻度は 少ないのに 探すのも買うのも 手間…… 手袋 テープ 工具 ナット 例えば… 金額 品目 手間
  5. 14 2つの複雑性 我々が提供しているサービスは高度化していく中で差別化となる必要な業務の複雑性に長 年のビジネス/組織の拡大によって生じた不要な複雑性が付随し、本来取り組むべき課題、 複雑性に集中できなくなっていることが問題。これを取り除き、業務とシステムの可変性 を再び取り戻すことが必要 っっx 取り組むべ き課題 不必要な複雑性、

    煩雑さ 以前 現状 現状 現状 未来 っっ x っっ x っっ x っっ x っっ x っっ x 不必要な複雑性が増え た結果、本来取り組むべ き課題に集中できない 課題を分割すること、不必要な煩雑さ を減らすことで、本来取り組むべき課 題に向き合える状態になる
  6. 15 課題感とやるべきこと • 基幹システムがモノリスアプリケーションであり、拡張とビジネス成長に よって複雑さが増し、変更容易性が失われた • 一方で業務のスケールとそれに付随する「複雑性」はモノタロウの差別化 ポイントでもある • その複雑性をアーキテクチャの構造に落とし込むことで、業務とソフト

    ウェアの変更容易性を上げていく。 • そのために業務モデリングを徹底的に行い、ドメインを分割することで認 知負荷を下げる。 • 競争優位をもたらす業務の複雑性を明らかにしつつそれが各ドメインで同 時に進化できるようにデザインする。
  7. 1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す

    6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 19 イベントストーミングの進め方 より詳細を知りたい方は、 アマゾンウェブサービスジャパン ソリューションアーキテクトの 福井さんの以下の動画がおすすめ 実践!モノリスからマイクロサービス! Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo
  8. • ステークホルダー全員の共通認識のもと分析された業務プロセスが可視化される ◦ ユビキタス言語 → 言葉の統一による共通認識の深化 ◦ 境界づけられたコンテキスト → 同じ文脈で意思疎通可能な(いくつかの)業務領域

    ◦ ドメイン → 関心事を分離した業務領域、カプセル化で結合度低下と凝集性向上 • ドメインモデルはシステム設計のインプットになる • 得られるメリット ◦ 業務側・システム側の共通理解がそのままシステムに反映される ◦ 関心事が分離されているので、各システムが独立して変化できる 20 イベントストーミングに期待できること
  9. 25 ④アーキテクチャと移行計画を考える 在庫ドメインが解決したい課題は以下の通りであった • 在庫状況TBLが周辺業務の密結合点となり、複数の業務の関心事が混在している (業務領域間の結合度を下げる) ◦ 業務領域を基本単位として現モノリスから切り出し、データも独自に管理する ◦ 他

    業務領域とは非同期連携とする(EDA) • 業務知識が散在し、在庫状況TBLのデータ構造に依存する業務が多い (業務知識とデータ構造をカプセル化する) ◦ 業務領域ごとにデータを独自管理し、データの操作もひとまとめにする ◦ 業務が扱うデータと、公開するデータのモデルを分ける(CQRS) • 在庫状況TBLは履歴情報を保有できない (変更の履歴を持ち、任意の時点の状態を再現する) ◦ 業務イベント保有し、その積み上げによって最新の状態を得る(Event Sourcing)
  10. 28 説明: 既存DBの変更をDMSが検知し てReadReplicaに書き込み、 AWS Lambdaがドメインイベ ントに変換する。 ドメインイベントはMSKに割 り当てられたトピックに登録 され、さらに後続のドメイン

    ロジックにより処理されて EventStoreに記録され、 ReadModelにも反映される。 移行ステップ的には②-1の状態 ④システムのアーキテクチャ概要
  11. 31 プラットフォームエンジニアリング部門の組成 31 アプリケーション 開発者 設 計 開 発 テ

    ス ト リ リ ー ス 顧客提供価値 ビジネスロジックの複 雑性に向き合う 技術的な複雑性に 向き合う プラットフォーム エンジニアリング アプリケー ション (サイト) アプリケー ション (事業) アプリケー ション (基幹) 1. MDIと呼ばれるアプリケーションテ ンプレート 2. コンテナ基盤 3. DOJO(トレーニング機関) 4. 開発生産性向上のためのイネイブリ ング