MonotaROと基幹システム

尾髙：モノタロウは、間接資材、つまり工場の原材料以外によく使われるもの、ネジやドライバー、掃除用具といったものを扱うEC事業者です。基本的には自前主義でして、ECサイトから基幹システム、実際の倉庫ネットワークまで、おおよそ自前でやっています。

事業規模としては、売上2,761億円、ユーザー1,000万人超というところですが、これは2024年の実績です。直近では取扱点数が2,830万点まで育っており、当日出荷点数も74万点を超えるなど、順調に大きくなってきています。

私たちがどのような価値を提供して商売をしているかというと、間接資材業界はサプライヤーの構造が複雑で、仲卸が入った多重構造になっています。そのため、お客様からすると、どこから買うかによって微妙に価格が違ったり、発注してから届くまでのリードタイムが違ったりします。ここにモノタロウが入ってシンプルにすることで、お客様は同じものを同じ値段で常に買えるようになります。

尾髙：また、実際に購買される会社様の中にも購買部があって、そこを通さないと買い物ができないケースが工場系の現場では多いのですが、私たちがワンストップで巻き取ることで、資材調達にかかる時間を節約できます。つまり、お客様の時間価値を高めて、本業に集中できるようにするお手伝いをしています。

今日お話しするのは主に基幹システムについてです。モノタロウにおける基幹システムの役割は、ECサイトというデジタルの世界から、実際に物が届くというリアルの世界へのつなぎ目になっているところで、非常に重要なミッションを担っています。

システムの構造をご紹介すると、お客様のタッチポイントを介してデータが入ってきて、顧客ドメイン、受注ドメイン、商品ドメイン、発注ドメイン、配送ドメインといった基幹システムのサブシステムで処理されます。これらを複数の業務要件に基づいてそれぞれ進化させていきたいのですが、現在それが難しくなってきています。

尾髙：おかげさまで25周年を迎え、コードを継ぎ足し継ぎ足しでシステム開発をしてきた結果、いわゆるモノリシックアプリケーション、一つの巨大なデータベースと一つの巨大なアプリケーションという状態になっており、複雑性が限界に達しています。これ以上放置するとビジネスの足を引っ張りかねない状況なので、これをモダナイズするという標語のもと、いろいろな施策を進めています。

これまでの軌跡

尾髙：まず私たちはモノリシックな状況をどうにか分けていきたい。けれど、どうアプローチしたらいいかわからないという課題がありました。そこで何をやったかというと、EC事業者であれば、受注や商品、配送といった当たり前のドメインはきっとあるだろうという仮説を立てました。

この仮説に基づいて、組織も一気に分割しました。当時のモノリシックアプリケーションは何をやるにもアプリケーション丸ごとデプロイし直さなければならない状態でしたが、ドメインごとに実行環境だけ変えて、同じアプリケーションのコピーをいくつか並べることで、少なくともドメインごとにデプロイできる状況に持っていきました。

尾髙：その後、受注から配送までのひととおりの業務プロセスを、関係部門の主要な人物を集めて、総勢30人超でイベントストーミングという手法を使って分析しました。付箋をペタペタ貼りながら、ここでは何が起きている、こっちでは何が起きているというのを時系列で整理していきました。

こうしてプロセスを読み解いていく中で、ある違和感に気づきました。当時の構成では、発注ドメイン（入荷を担当）と配送ドメイン（出荷を担当）の関心事が単一のテーブルに集中していて、非常に変更しにくい状況にありました。そこで、このテーブルから「今、在庫がいくつあるのか」「あといくつ出荷できるのか」を管理する責務を「在庫ドメイン」として切り出した方がよいのではないかという仮説を立てました。

尾髙：続いて、この仮説が正しいかどうかを机上で検証していきました。まずビッグピクチャーのイベントストーミングで大きいレベルの絵を描き、そこで見つけた境界コンテキスト間の関係を線で繋いで整理していきます。その中で、在庫ドメインがどこに位置するのか、誰と会話するのかを見極めました。次に、在庫ドメインに限定して、メソッド単位ぐらいのレベルまで落とし込んだイベントストーミングを行い、プロセスを詳細に理解していきました。その結果、「どうやらこの仮説はありそうだ」ということがわかりました。

尾髙：そこで、モダンなアプリケーションスタックで実装を進めました。既存のデータベースの変更を検知してイベントを発火するアーキテクチャを採用し、データベースの変化を在庫ドメインの業務的なイベントに変換します。それをイベントソーシングとして蓄積し、独自のリードモデルを提供するという仕組みを、今本番で動かしています。

尾髙：この手法がうまくいきそうな感触を得たので、改めて基幹システム全体の再分析に入り、全体のコンテキストマップを書きながら、コンテキスト間の通信の関係性も分析していきました。

一旦おさらいすると、まず逆コンウェイ戦略に則って組織変更を行いました。新たなドメインの仮説として在庫ドメインを得て、これを検証しつつモダンなアプリケーションスタックで本番投入ができました。既存の巨大テーブルの変更ユースケースを一つずつ業務上の意味のあるイベントに切り出して、新しいシステムが動いています。

ただ、これで十分かというと、全然足りていません。もっともっと変えていかなければならないところがたくさんあります。

何を変えたいのか

尾髙：モノタロウが変えていきたいことは、大きく3つあります。組織とアーキテクチャ、文化、そして開発手法です。組織とアーキテクチャは表裏一体なので、これを一つと捉えています。

なぜこの3つなのかというと、私たちがフォローしていきたいのはビジネスです。ビジネスをうまく回すためのアーキテクチャを作りたいと考えているので、アーキテクチャと表裏一体の組織は変えていきます。組織は結局人で構成されているので、マインドセットを変えて、それを文化として当たり前のことにしていきたい。さらに、アプリケーションを構成するのは技術であり、技術は人に根ざします。この組織・人・技術という3つの観点で考えています。

技術面では、現在オンプレで全部盛りの巨大DB、テーブル駆動設計、スクリプト的な実装というパラダイムで動いています。これをクラウドシフトし、ドメイン別DBに分け、スキーマ駆動開発や業務に即したデータ型を採用していきたいと考えています。

尾髙：ただ、左と右にはかなりのギャップがあるので、「やるぞ」と言ってもすぐにはできません。それをやれるようにするために、DOJOというエンジニア育成プログラムで新しいパラダイムについての実践的な学びを提供しています。また、MDI（MonotaRO Developer Interface）エコシステムという開発しやすいフレームワークを用意して、ゴールデンパスに沿えば1〜2週間でAPIが作れるという環境を整えています。

一方、技術を皆さんに積極的に使っていただくには、マインドセットを変えていかなければなりません。ただ、人それぞれ変わりにくい事情があります。この個々の事情にスポットライトを当てて、どうすれば変われるのかを個別具体的に積み上げていかないと、文化には至りません。号令するだけではなく、チームごと・個人ごとのつらみにフォーカスしながら解決していきたいと考えています。

AI-Agentという新しいアクター

尾髙：組織とアーキテクチャの話に入る前に、昨今、AIエージェントという新しいアクターが出現しました。みなさんコーディングや設計の段階ではよく使っていると思いますが、これをエンジニアだけではなく業務部門の方々にも使ってほしい。そうすると、基幹システムや業務システムとどう組み合わせていこうかという話になります。

私たちはテックビジョンとして「データとテクノロジーを徹底的に活用する」ということを掲げています。常に事業者に選ばれる世界で唯一の顧客価値を提供したい、そのためにデータとテクノロジーを徹底的に活用するという考え方です。

エンジニア組織ではエージェンティックコーディングなどの取り組みが広まってきていますが、業務部門の方々はまだそうでもありません。そこで、業務システムにAIエージェントを組み込んでいきたいということで、今年の3月頃からプロジェクトを発足させ、先月ようやく部分的に、1ユースケースだけMVPとして本番投入することができました。

尾髙：これはプロジェクトの発足当初に描いた構想図です。いろいろな会社さんがエージェントをシステムに組み込むならこうだという情報を公開してくださっているので、それを参考に当社でやるとしたらこんな感じかなと無邪気に描いてみたものです。

左側にユーザーがいて、「こういうことをしたい」という内容を、右上のエージェントコントロールで文脈判断します。このユーザーはキャンセルがしたいのか、商品の問い合わせがしたいのかといった判断をして、必要なツールを実行しながら回答を生成します。そして、まずい回答をしていないかをガードレールでチェックしてからお客様に提供するという流れです。

また、右下には社内の管理者がいて、1日にどういう回答をしてどんな感じで働いてくれたのかを俯瞰しながら、修正すべきマニュアルを更新していくというフィードバックループも回せるようにと考えていました。

尾髙：MVPの構成としては、バックエンドコンテナがエージェントの核心部分で、ここにプロンプトと周囲のツールを選択的に使っていくコードで構成されています。その右側に業務担当者が使うフロントエンドの画面があり、バックエンドの下側には基幹システムから提供されているAPIがツールとして並んでいます。エージェントのコア部分と基幹システムが密結合するのは避けたかったので、中間にラップAPIという層を設けて分離しています。

本取り組みではいろいろな学びがありました。そして今、この構成はあまりよろしくないと思い始めています。次の機会には新しいモデルに変わっていそうな気がしています。

MVPをやってみて思うことがあります。ドキュメントが陳腐化するのはエンジニア組織だけではなく業務側でも同じだということです。

尾髙：MVPのユースケースとして選んだのはルールベースな業務でした。エージェントは抽象的な判断をさせるべきだという話もありますが、むしろマニュアルが整備されていた方がフロー分析やロジック構築が楽だろうと思って、あえてそちらを選びました。マニュアルがたくさんあって、それを元に業務フローを分析して、エージェントとして実装して、テストデータを作って、100%の回答精度が出て最高だと思いました。

ところが実際にお客様の問い合わせに利用してもらったら、「それはマニュアルに載せてないけどこうなんですよね」とか「これは本当はこうなんです」とか、しかもスタッフさんによって言っていることが違うという、かなりの暗黙知が爆発しまして、どうしようという状況に今陥っています。

私たちが目指したいのは、利用部門による利用部門のための自働化です。エージェント開発からフィードバック反映、評価、デプロイまでを利用部門だけで完結したいのです。これはAgentic Autonomous Platform的なもので、非常に野心的ですが、モノタロウはこの世界線を目指していきたいと考えています。

尾髙：なぜそこまで必要かというと、ひとつのエージェントですべての問題を解くのは現実的ではないので、ユースケースごとに小さいエージェントを作ることになりますが、暗黙知の爆発でいろいろな調整が必要になります。そこにエンジニアやデータサイエンティストをそれぞれ貼り付けてカスタマイズできるほど、ユースケース1本のビジネスインパクトは大きくありません。やればやるほど赤字になる可能性があるので、プラットフォームとして保守開発していくことで、社内に広くユースケースを適用してもらい、ROIを取っていきたいと考えています。

業務が実際はどのように構成されているのかを見ていくと、例えば「ある商品の在庫配置を東西で70:30にする」という業務があった場合、倉庫の場所を確保する、輸送を手配する、サプライヤーに相談する、自動発注設定を見直すなど、いろいろなアレコレがあります。マニュアルにはこういった目標を達成するための手順、システムの使い方、連絡方法などが書いてあります。

このアレコレは人のための手順です。曖昧で手続き的な記述が多く、これをもとにAIエージェントの振る舞いを決めるのはつらみが大きすぎます。そこで、その手続き的なマニュアルを抽象化して宣言的に書き換え、そのために必要な情報や操作を構造化したいと考えています。

抽象化して宣言的に書き換える行為は、私たちが普段やっている業務のシステム化、IT化そのものなんですよね。業務の複雑性をシステムに隠蔽するということです。私たちエンジニアがこれをできるのは、いろいろなところで勉強して知識を蓄え、OJTや実務で得たケイパビリティがあるからです。これを業務の人に「さあやってください」と言っても、なかなか難しいです。

尾髙：そもそもの話に戻ると、人は意思決定に全振りしたいんです。実現したいことと、そのために必要なパラメータを決めて、その「なぜならば」を裏打ちする。例えば、在庫の東西配置を変えたい、具体的には70:30にしたい、なぜなら関東で需要が高まっていて関東を厚めにした方が配送費が抑えられるから、というところは人の領域だと思っています。

一方で、在庫配置を変えたいという目的を、場所を確保しました、輸送を手配しましたといういくつかの状態に分解して、それを達成するための操作とパラメータを決め、ツールを組み合わせて実現していくのはエージェント側にカプセル化したい。やりたいことはそうなのですが、どうやったらこの世界線に到達できるのかは、まだよくわかっていません。

組織とアーキテクチャの再編成

尾髙：AIエージェント開発の文脈から見ると、既存のシステムをきちんと目的で分けて、適切なインターフェースを公開していくことが必要です。例えば、この受注はどういう受注なんでしたかという情報を返してくれる、あるいは引き当て条件を変更するといった形で、目的に分けて適切なインターフェースを公開していきたいと考えたときに、どうも2つに分かれそうな気がします。

一つは、お客様の注文を所定の業務ルールに従って自動的に入出力処理していく、粛々と受注から出荷までを回すシステム。もう一つは、このシステムに対してちゃんと動いていますかとか、その受注をこう変えてくださいといった監視・変更をするシステムです。

ここで杉本啓さんの著作『データモデリングでドメインを駆動する』という書籍を参照しています。この本ではSystems of Activities（SoA）として基幹システムを表現しています。プロセスに沿って粛々と入出力処理するシステムで、情報と操作（CRUD）およびその仕様を適切に公開して、権限のある誰もが容易に使える状況にする。これを整えるのがSoAの責務です。

尾髙：もう一つの振る舞いを監視・変更する側のシステムを、私たちはSystems of Controls（SoC）と呼んでいます。書籍ではSystems of Managementと呼ばれていますが、複数の責務が多層的に説明されていて混乱しがちだったので、造語を作りました。SoCはSoAへの指示・介入を目的としていて、パラメータを変更したり新しいルールを設定したりします。SoAが公開する情報と操作の仕様を理解しながら、新しい業務プロセスを構築していく役割です。

尾髙：従来、基幹システムのことをSoR（Systems of Record）と呼んでいました。このSoRを分解してSoAとSoCと呼んでいるわけです。

SoAとSoCの関係を図で説明すると、オレンジ色のSoAには受注、引き当て、調達、入出荷、会計といった業務機能があって、いくつかの業務プロセスがこれらの機能を使います。すべての機能を使うプロセスもあれば、一部だけ使うプロセスもある。これを既定のルールに沿って粛々とやるのがSoAです。そのSoAに対して、新しいプロセスを定義したとか、あの受注どうなったとか、あれキャンセルねといった外からやいのやいの言ってくるのがSoCという関係性です。

尾髙：AIエージェントによる業務の代行・自働化を実現するには、3つのことが必要です。まず、十分にプリミティブな機能（インターフェース）が公開されていること（SoA）。次に、SoAの機能を組み合わせてワークフローを定義できること（SoC）。そして、業務目的を構成する状態に適したワークフローを選定すること（Agent）です。

いずれはAIエージェントが未定義の業務目的に対して自らワークフローを定義することも期待していますが、それはきっと当社のデータサイエンス部門がやってくれると思っています。SoCがやっている仕事を、AIエージェントが代行というか同じようなことを、しかも高速で24時間休まずできる状況になってくると考えています。

尾髙：前段でお話しした通り、基幹システムがどうあるべきかという分析を進めてきて、ドメインの細分化についてはある程度見えてきました。ただ、SoAとSoCを区別して、どこにエージェントを使うのかというところも含めて、改めてコンテキストマップを書き直す必要があると感じています。

今考えているモデルでは、右側が基幹システムでSoA、左側が業務システムでSoCという構成です。受注、引き当て、調達、入出荷、会計といった自動的に流すプロセスは基幹システム側に置きます。一方、そこに対していろいろな介入をしてくる業務システムがあります。例えば、お客様の要望で注文をキャンセルしたり、在庫を引き当てする倉庫を変えたり、仕入れたけど返品するといったイレギュラーケースを扱うシステムです。エージェントはこの業務システムと同じような役割で動くことになるだろうと考えています。

尾髙：これとは別に、マスターのメンテナンスやCRUDだけのシステムは、レイヤードアーキテクチャをやるまでもなく、普通にマスターの読み書きをするシステムとして別で分けておきます。SaaSやパッケージも一定ありますが、この文脈に当てはめると複雑になるので、一旦外にあるものとして連携対象として考えています。このモデルをベースに、今後のシステム構築を進めていこうと思っています。

混沌とチャレンジ

尾髙：実際の変更の本番はこれからです。現状はこれまでお話しした通りで、試験的な導入でいくつか学びが得られ、進む方向性はなんとなく見えてきた程度です。当初、マニュアルに沿って業務フローを書いて「よしこれで完璧」と思ったら全然違いましたという経験があり、ダニングクルーガー効果って本当なんだなと実感しています。これによって創出されるビジネスインパクトもきちんと見ていかなければなりません。

技術面では、DOJOやMDIなどの取り組みによって新しい開発手法は取り入れつつあります。DDD+EDA+ES+CQRSの本番投入もでき、後に続く案件もいくつか出てきています。

人の面では、個人の行動変容を支援する仕組みとして、DOJOコンテンツによる学びをフォローアップする場を用意しています。部門ごとチームごとの勉強会をつなぐHUBとして期待しています。文化醸成のアプローチが見えてきたかというと、正直わかりません。地道に続けることでしか成し得ないと思っています。

アーキテクチャと組織の面では、AIエージェントという新しいアクターへの対応として、突き詰めれば使われる側である既存アプリケーションの整備が重要です。RPAやBrowser-useで画面に依存するのは急場しのぎであり、基本的にはAPIベースの連携を目指していきたいと思っています。

SoA、SoCプラスエージェントというレイヤリングも見えてきましたし、そうすると開発チームのケイパビリティも変わるはずです。その辺を踏まえて、新しい組織をどう分けていったらいいのか、チームごとに過剰な結合がないように、かといってサイロ化しないいい塩梅で設計していきたいと考えています。

これからのモノタロウ

尾髙：私たちがこれから目指すパラダイムは、ただシステムを小さく分割するだけではありません。業務プロセスを蒸留・洗練し、不要な複雑性をシステムに閉じ込めることで、より大きなビジネスインパクトを生み出せる状況を作っていきたい。それはつまり、より「データとテクノロジーを徹底的に活用」できる状況です。

モノタロウは、インターネット時代にデータとテクノロジーで資材調達ネットワークを変革してきたという自負があります。来るべきAI時代においても成長を続けるために、常に事業者に選ばれる世界で唯一の顧客価値を提供するため、データとテクノロジーを徹底的に活用していきたいと思っています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。