ビジネスを駆動するアーキテクチャへ～AI-Agentという新しいアクター

by MonotaRO

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 本日お話しすること ● MonotaROと基幹システム ● これまでの軌跡 ● 何を変えたいのか ● AI-Agentという新しいアクター ● 組織とアーキテクチャの再編成 ● 混沌とチャレンジ ● これからのモノタロウ

Slide 3

Slide 3 text

3 2023年11月モノタロウ入社。 IT職歴の大半を事業会社のIT部門で過ごし、biz/sysの関係構築や要件定義などの超上流工程に取り組んできたが、質とスピードという言葉に出会ってからは品質←保守性に目を開く。関心事の分離とカプセル化をあらゆる粒度に適用すべく、ビジネスアナリシスにおける概念モデルの活用DOJOを開催したり、 AI-Agentと業務システムの関係性に頭を悩ませたりしています。尾髙敏之株式会社MonotaRO シニアアーキテクト (10月からEM業も再開しました)

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 モノタロウとは https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=4

Slide 6

Slide 6 text

6 モノタロウとは https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=7

Slide 7

Slide 7 text

7 モノタロウが提供する価値 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=17

Slide 8

Slide 8 text

8 モノタロウが提供する価値 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=18

Slide 9

Slide 9 text

9 モノタロウが提供する価値 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=19

Slide 10

Slide 10 text

10 モノタロウにおける基幹システムの役割 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=3

Slide 11

Slide 11 text

11 モノタロウにおける基幹システムの役割 https://www.monotaro.com/topic/fulfillment/

Slide 12

Slide 12 text

12 変革の必然性 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=8

Slide 13

Slide 13 text

13 変革の必然性 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=27

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 これまでの取り組み① ドメイン仮説と新たな発見 https://speakerdeck.com/monotaro/bizinesunogou-zao-woakitekutiyaniluo-tosiip-misohutoueanike-bian-xing-wozhu-ru-suru?slide=15

Slide 16

Slide 16 text

16 これまでの取り組み① ドメイン仮説と新たな発見 https://speakerdeck.com/monotaro/bizinesunogou-zao-woakitekutiyaniluo-tosiip-misohutoueanike-bian-xing-wozhu-ru-suru?slide=16

Slide 17

Slide 17 text

17 これまでの取り組み① ドメイン仮説と新たな発見 https://speakerdeck.com/monotaro/bizinesunogou-zao-woakitekutiyaniluo-tosiip-misohutoueanike-bian-xing-wozhu-ru-suru?slide=24

Slide 18

Slide 18 text

18 これまでの取り組み② 業務理解の深化と実践 https://speakerdeck.com/monotaro/ye-wu-li-jie-noshen-hua-toshi-jian-domeinmoderingudeji-gan-sisutemuwozhuo-eru?slide=18

Slide 19

Slide 19 text

19 これまでの取り組み② 業務理解の深化と実践 https://speakerdeck.com/monotaro/ye-wu-li-jie-noshen-hua-toshi-jian-domeinmoderingudeji-gan-sisutemuwozhuo-eru?slide=27

Slide 20

Slide 20 text

20 これまでの取り組み② 業務理解の深化と実践 https://speakerdeck.com/monotaro/ye-wu-li-jie-noshen-hua-toshi-jian-domeinmoderingudeji-gan-sisutemuwozhuo-eru?slide=33

Slide 21

Slide 21 text

21 ここまでの成果 ● 逆コンウェイ戦略に則った組織変更 ● 新たなドメイン仮説: 在庫ドメイン ● EDA+ES+CQRS の PoC → 本番投入 ● 在庫状況管理の中核テーブル更新をイベント化 ● 基幹システム全体のToBeモデルを描く ● ドメイン分割の仮説を刷新

Slide 22

Slide 22 text

22 ここまでの成果でも、足りない。まだまだ足りない。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 モノタロウが変えたい３つのこと ● 組織とアーキテクチャ ● 文化 ● 開発手法

Slide 25

Slide 25 text

25 モノタロウが変えたい３つのこと 3つの要素は独立したものではなく、絡み合いながら進化する ● ビジネスを駆動するアーキテクチャ ○ アーキテクチャと表裏一体の組織 ○ 変わることが当たり前な文化 (人) ○ アーキテクチャを具体的に変えていく開発手法 (技術)

Slide 26

Slide 26 text

26 モノタロウが変えたい３つのこと : 開発手法 (技術) オンプレ + 全部盛り巨大DB + テーブル駆動設計 + スクリプト的実装クラウドシフト + ドメイン別DB + スキーマ駆動開発 + 業務に則したデータ型変えていきたい重要なのは概念設計あらゆる粒度で関心事の分離・カプセル化 DOJO エンジニア育成プログラム実践を通じた学び MDI*エコシステム MonotaROの開発者がプラットフォームの機能にアクセスする際のインターフェース * MonotaRO Developer Interface

Slide 27

Slide 27 text

27 モノタロウが変えたい３つのこと : 文化 (人)

Slide 28

Slide 28 text

アプローチ: ひとりひとりにスポットを当てる（「変わりたい」気持ちを「変わる」行動へ） 28 モノタロウが変えたい３つのこと : 文化 (人)

Slide 29

Slide 29 text

29 モノタロウが変えたい３つのこと : 組織とアーキテクチャ表裏一体の構造変革 ● データとテクノロジーを徹底的に活用する構造を獲得する ➡ その前にまず...

Slide 30

Slide 30 text

Slide 31

Slide 31 text

31 Tech Vision: データとテクノロジーを徹底活用 https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=33

Slide 32

Slide 32 text

32 Tech Vision: データとテクノロジーを徹底活用 https://speakerdeck.com/monotaro/monotaro-ai-conference-autumn-2025

Slide 33

Slide 33 text

33 カスタマサポート向けAI-Agentの開発 ● 今年の早い段階から着手 → 10月に部分的に本番導入

Slide 34

Slide 34 text

34 ヒトとAI-Agentの協業モデルを模索する

Slide 35

Slide 35 text

35 「とりあえずMVP」の結果、思うこと学び: ドキュメントが陳腐化するのはどこも一緒 ● ルールベースな業務 = マニュアルが整備されているはず ○ 業務マニュアルをもとに業務フローを分析 ○ 業務判断が可能なAI-Agentを開発 ○ テストデータによる評価で精度を確保 ○ さあ本番で試用だ！ ... 暗黙知が爆発 🤯

Slide 36

Slide 36 text

36 「とりあえずMVP」の結果、思うこと目指すべきは、利用部門による利用部門のための自働化 ● AI-Agent開発、フィードバック反映、評価、配置まで利用部門で完結 ● それって Agentic Autonomous Platform 的なもの？ ● (非常に野心的だが) モノタロウはこの世界線を目指したい ○ となると、やはりマニュアルは重要　過剰品質なんじゃ？ ● 「なんでも解ける汎用Agent」は非現実的だろう。 ● 業務ごとにAgentを開発する必要。 ● 業務あたりの改善効果はそう大きくない。 ● 業務ごとにエンジニアを投入してはROIが... 　➡ プラットフォーム化が必要

Slide 37

Slide 37 text

そもそも「業務」は無数のアレコレで構成されている ● 業務例「〇〇という商品の在庫配置を、東西で70:30にする」 ○ 倉庫の場所を確保 ○ 輸送を手配 ○ サプライヤに相談 ○ 自動発注設定を見直し … 37 「とりあえずMVP」の結果、思うこと

Slide 38

Slide 38 text

38 「とりあえずMVP」の結果、思うことマニュアルに書かれているのはこの「アレコレ」 ● アレコレ is 何 ○ 目的を達成するための手順、システムの使い方、連絡方法... ○ システムの使い方ではなく、スプシでのアレコレかも？ ○ さらには「誰々に聞く」とか、念のため、とか... e.g. 倉庫の場所を確保 : ① A画面で〇〇の数量を確認する ② B画面で直近の出荷状況を確認する ③ AからＢを減じた値をC画面の△△に登録する ④ 登録結果をＣ画面で確認したら、××部門の担当者にメンションする

Slide 39

Slide 39 text

39 「とりあえずMVP」の結果、思うことこのアレコレはヒトのための手順これをもとに AI-Agentの振る舞いを決めるのは辛いまずはその手続き的なマニュアルを抽象化して宣言的に書き換えそのための情報や操作を明示したい

Slide 40

Slide 40 text

40 「とりあえずMVP」の結果、思うことこのアレコレはヒトのための手順これをもとに AI-Agentの振る舞いを決めるのは辛いまずはその手続き的なマニュアルを抽象化して宣言的に書き換えそのための情報や操作を明示したい

Slide 41

Slide 41 text

41 必要なのは IT化だった󰷻 業務の複雑性をシステムに隠ぺい → それはスペシャリストの仕事 ● エンジニアが知識を蓄え、トレーニングにより得たケイパビリティ ○ 要するにビジネスアナリシス ○ つまりIT化のスペシャリストの仕事 ● 利用部門の方々は、業務のスペシャリストであっても、 IT化のスペシャリストではない

Slide 42

Slide 42 text

42 必要なのは IT化だった󰷻 󰷻IT化のマニュアルが必要ということ？󰷻 ● 手順を抽象化し「宣言的に業務を行う」を言い換えると ○ 業務の目的を達成するための手順を再構築するということ (煩雑なアレコレ → シュッとさせる) ■ これまではIT化のスペシャリストがやってきたこれからはAI-Agentがやる...のか？ ○ マニュアルとして必要なのは、与えられた目的を構成する要素(状態)に分解し、その状態に至る必要な情報, 操作, パラメータを決める手順？ (少なくとも画面の操作方法やスプシの値コピペ手順ではなさそう)

Slide 43

Slide 43 text

43 必要なのは IT化だった󰷻 ヒトは意思決定する ● 実現したいこととパラメータを決め、その理由を探求する ○ 在庫の東西配置を変えたい。変更後の東西比率を示す。 ○ 理由は、関東で需要が高まっており、配送費を抑えるため。 Agentは実現する ● 目的を状態（場所確保、輸送手配...)に分解し、操作とパラメータを決定 ● ツールを組み合わせて状態を実現し、総合する能力が必要 󰷻どうすればこの世界線に到達できるのか󰷻

Slide 44

Slide 44 text

Slide 45

Slide 45 text

45 基幹システムとして必要なこと AI-Agent開発から見えた必要なこと ● 既存システムを目的で分ける ○ これまでモノタロウでは「基幹システム」が指す対象をはっきりと意識できていなかった ■ 所定の業務ルールに従って自動的にI/P/Oするシステム ■ 上記システムの振る舞いを監視・変更するシステム

Slide 46

Slide 46 text

46 基幹システムとして必要なこと所定の業務ルールに従って自動的にI/P/Oするシステム ● 基幹システム: Systems of Activities (SoA) ○ プロセスに沿って粛々と I/P/O する ○ 情報(R)と操作(CUD)、およびその仕様を適切に公開 ○ (権限のある)誰もが容易に使える状況に https://gihyo.jp/book/2024/978-4-297-14010-6

Slide 47

Slide 47 text

47 基幹システムとして必要なこと SoA の振る舞いを監視・変更するシステム ● 業務システム: Systems of Controls (SoC) ○ SoAへの指示・介入を目的とする ■ パラメータを変更したり、新たなルールを設定する ○ SoAが公開する情報と操作の仕様に精通して、プロセス(=業務)を構築する

Slide 48

Slide 48 text

48 基幹システムとして必要なこと Systems of Record を細分化（基幹システム）

Slide 49

Slide 49 text

49 基幹システムとして必要なこと受注No.xxxx はキャンセル受注No.xxxx の出荷状況は？優先倉庫のパラメータ変える当日出荷締め切り前倒し新しいプロセスを定義業務プロセスA 業務プロセスB 業務プロセスC 業務機能群 (ドメイン群)

Slide 50

Slide 50 text

50 基幹システムとして必要なこと AI-Agentによる業務の代行・自働化を実現するには ● 十分にプリミティブな機能(インタフェース)が公開されている（SoA） ● SoAの機能を組み合わせてワークフローを定義できる（SoC） ● 業務目的を構成する状態に適したワークフローを選定する（Agent）いずれは AI-Agent が、未定義の業務目的に対して自らワークフローを定義することも期待する。（きっと当社DS部門が）

Slide 51

Slide 51 text

受注No.xxxx はキャンセル受注No.xxxx の出荷状況は？当日出荷締め切り前倒し新しいプロセスを定義業務プロセスA 業務プロセスB 業務プロセスC 業務機能群 (ドメイン群) 51 基幹システムとAI-Agentの関係優先倉庫のパラメータ変える

Slide 52

Slide 52 text

52 最新のドメイン理解左図は受注～調達～出荷に至るまでのコンテキストマップ。これまでの「受発注配送」というドメイン境界の仮説に比べ、さらに細分化する道が見えてきた。このドメイン理解に基づいて、SoA/SoCを区別していきたい。

Slide 53

Slide 53 text

53 SoC/SoAモデル（案） 🤖

Slide 54

Slide 54 text

Slide 55

Slide 55 text

55 モダナイゼーションのこれから本番はこれから ● 組織変更と本格的なリアーキテクチャの推進はこれから ○ 現状はこれまでご紹介した通り、一部の試験的な導入による学びで進む先が見通せるようになってきた程度 ○ ダニングクルーガー効果おそるべし ● 取り組みによる定量的なビジネスインパクトもまだ測れていない

Slide 56

Slide 56 text

56 モダナイゼーションのこれから見えてきたもの: 技術 ← p.26 ● 開発手法は部分的に刷新された ○ DOJO, MDIなどの取り組みにより変わりつつある ● DDD+EDA+ES+CQRSの本番投入 ○ 後に続く案件もある ○ ドメイングループごとの取り組みも始まった

Slide 57

Slide 57 text

57 モダナイゼーションのこれから見えてきたもの: 人 ← p.27-28 ● 個人の行動変容を支援する仕組み ○ DOJOコンテンツによる学びをフォローアップする場 ○ 部門ごとチームごとの勉強会をつなぐHUBとして期待 ● 文化醸成のアプローチが見えてきた...？ ○ 正直わからん ○ 地道に続けることでしか成し得ないと思ってる

Slide 58

Slide 58 text

58 モダナイゼーションのこれから見えてきたもの: アーキテクチャと組織 ● AI-Agentという新しいアクターへの対応 ○ 突き詰めれば使われる側である既存アプリケーションの整備が重要 ○ RPAやBrowser-useで画面に依存するのは急場しのぎか ● 目指すべきアーキテクチャの姿が明確に ○ 目的に沿ったレイヤリング (SoA,SoC + Agent) ○ きっと開発メンバのケイパビリティも異なるはず ● 組織の姿も ○ 必要なケイパビリティをチームに凝集し、適度な結合度を目指す

Slide 59

Slide 59 text

Slide 60

Slide 60 text

60 これからのモノタロウこれから我々が目指すパラダイムただシステムを小さく分割するだけではない

Slide 61

Slide 61 text

61 これからのモノタロウ業務プロセスを蒸留・洗練する不要な複雑性をシステムに閉じ込めることで、より大きなビジネスインパクトを生み出せる状況それはつまり、より「データとテクノロジーを徹底的に活用」できる状況

Slide 62

Slide 62 text

62 これからのモノタロウ AI時代の再挑戦モノタロウは、インターネット時代にデータとテクノロジーで資材調達ネットワークを変革してきた来るべきAI時代においても変わらず成長を続ける MonotaROは、常に事業者に選ばれる世界で唯一の顧客価値を提供するため、データとテクノロジーを徹底的に活用する https://speakerdeck.com/monotaro/monotaro-cai-yong-shao-jie-zi-liao-for-engineers?slide=33