在庫という結節点から始めた再設計
モノタロウがPoC（概念実証）の対象として選んだのは、基幹業務の中でも特に複雑な結節点となっていた「在庫数管理業務」だった。
従来のシステムでは、在庫情報は共用DBの1テーブルに集約されており、「オーダー（受注）」「パーチェス（発注）」「デリバー（配送）」といった複数の業務ドメインが、それぞれの都合で同じ在庫データにアクセスする構造だった。尾髙氏はこれを「在庫が“モテモテ”状態」と表現し、笑いを交えてその課題を語る。しかし実際には、この構造が業務間の密結合を生み、変更や拡張を難しくする大きな障壁となっていた。
こうした状況を打開すべくPoCでは、在庫の定義を「業務領域ごとの責務と関心事」に応じて再構築し、以下3つの設計方針を採用した。
- イベント駆動による非同期連携：共用DBから脱却し、各業務ドメインがデータを独自管理。他ドメインとはメッセージベースで連携。
- CQRSアーキテクチャの導入：内部で扱うコマンドモデルと、外部に公開するリードモデルを明確に分離。
- イベントソーシングの適用：「1個入荷」「1個出荷」といった在庫変動を履歴として記録し、任意時点の状態を再現可能に。
PoCの構築は完了し、アーキテクチャとしての妥当性も確認できたが、尾髙氏は「本当の試練はここから」と語る。PoCを現行システムと接続し、段階的に新アーキテクチャへ移行する必要があるからだ。
移行は「ストラングラーフィグ・パターン」に則って進められている。これは、既存システムを段階的に新システムへ置き換えていく方式で、全体を一気に刷新するリスクを避けられるのが特徴だ。
モノタロウではまず、既存DBの変更を検知してPoC環境に流し込む橋渡し部分（赤色の領域）を構築。そのうえで、ユースケースを1つずつ新環境（紫色）に切り出していった。4月には、そのうちの1つが本番稼働を開始予定であり、ここからが本格的な移行フェーズとなる。
すべてのユースケースの移行が完了すれば、既存システムは段階的に廃止される。まず既存DBへの書き込みを止め、次に新環境からの書き戻しを除いて既存DBの活用を停止。最終的には、新しいリードモデルからの書き戻しも終了し、旧システムから完全に切り離される見込みだ。
一見すると計画的に見えるこの移行だが、尾髙氏いわく「非常に骨の折れる作業」だという。モノリスと共有DBという旧来の設計を、イベント駆動やデータメッシュといったモダンな構造へ移し替えるには、ドメインロジックの再整理、インフラ整備、エンジニア教育まで含めた“総力戦”が求められるためだ。
それでもこの挑戦は、業務の密結合をほどき、将来的にスケーラブルな構造を実現するための重要な一歩でもある。在庫という複雑性の中核にあえて踏み込んだ今回のPoCは、モノタロウが掲げる「良い構造をつくる」という意志の体現にほかならないのだ。
構造を描き、整えるための視点の往復
在庫数管理の分離を突破口に、モノタロウでは周辺業務でもモダナイズの機運が高まってきた。ここで言うモダナイズとは、単なる技術刷新ではなく、各業務領域に最適な構造へと見直していく取り組みを指す。だが、各ドメインがボトムアップで進めていた結果、全体としての整合性には欠け、個別最適の域を出ていなかった。
「このままではモダナイズがうまく進まない。いわゆるトップダウン的な取り組みにはなりますが、改めて全体視点から領域間の関係を整理し、“私たちが目指す基幹システムの全体像”を描き出す必要があると考えた」と尾髙氏は語る。組織全体で目線を揃えることに、大きな意味があると判断したのだ。
こうして2024年10月、尾髙氏は全体構造の可視化に乗り出した。業務領域の境界を引き直し、集約や連携の関係を概念レベルで整理していく。その成果は、関係者の中にあった“なんとなくの前提”を可視化し、次にどう進めるかの議論を生む土台となった。
この取り組みを通じて、手が回らなかったドメインにもモダナイズの波が及び、個別と全体の整合を図る「視点の上下運動」へとつながっていった。全体を描きながら、足元を見つめ直す。その繰り返しこそが、強くしなやかな基幹システムを育てていく。
モノリスの限界を感じている。共有DBの複雑さにうんざりしている。けれど、それでも変えていきたい気持ちが湧き起こったなら──モノタロウのように、まずは自分たちの業務を言語化し、構造を見直すところから始めてみてはどうだろうか。
