ドメインモデリングで全システムの設計をゼロからやり直す。リアーキテクチャに挑む2年間の全貌【モノタロウCTO普川】

多くの企業で、10年以上前に開発されたシステムが、事業拡大に伴い続々と限界を迎え、リアーキテクチャに取り組み始めています。

間接資材のネット販売ビジネスを展開するモノタロウ社もその1つです。約20年前の創業期から内製で開発してきたモノリシックなシステムは、事業成長とともに度重なる機能追加を経て、2015年頃にはコードの変更すら容易にできない状態に。一度はパッケージシステムの導入も試みますが、2022年頃から、再度内製開発による抜本的なリアーキテクチャに取り組んでいます。

今回のリアーキテクチャでは、現在のシステムの課題を解決し、複雑な業務を処理できて、かつ変更容易性の高いシステムをつくり維持するために、業務ドメインの分割統治とマイクロサービス化を選びました。CTOの普川さんは「注目されているドメイン駆動設計も参考に進めているが、やっていることは至って地道。2年かかっているがまだ終わりは見えない」と語ります。

リアーキテクチャを決意してから、どんな順番で何をしてきたのか？　2年間やってみた今、一番難しいと感じることとは？　詳しく聞きました。

• keyboard_arrow_down リアーキテクチャの下準備は「丁寧な合意形成」から
• keyboard_arrow_down 逆コンウェイ戦略に沿い、着手前に組織を変更。精鋭たちの異動には2年をかけた
• keyboard_arrow_down まずはイベントストーミング。関係者全員で、業務の流れを明確に言語化
• keyboard_arrow_down ドメインの境界線を可視化し「コンテキストマップ」を作成
• keyboard_arrow_down 最も難しいのは「どのプロセスをどう端折るか」の見極め
• keyboard_arrow_down リアーキテクチャに向き合う日々は、終わりが見えない不安との闘い

――今回のリアーキテクチャは、ドメインモデリングを綿密に行った上で実施しているそうですが、そもそもなぜドメインモデリングに力を入れているのか、改めて教えてください。

普川：事業構造の複雑性が非常に高く、これをシステムに落とし込むには、ドメインモデリングが最も効果的だろうと考えたからです。

実は、システム刷新自体は2015年ごろから構想していて、一度はパッケージシステムの導入も試しました。しかしモノタロウの事業上、システムに求める要件はとても複雑です。膨大な商品数を扱い、個人も企業も顧客になりえて、各業界ならではの用語にも対応しなくてはならないし、商品の納期も非常に厳しい。この事業の流れを、既存のシステムとパッケージシステムを組み合わせて表現しきることはなかなか難しく、あまりうまくいきませんでした。

やはり当社の事業に資するシステムをつくるためには、既存の製品を組み合わせるよりも、内製でまるごとつくり直した方がよいのではないか。そう考えるようになり、様々な手法を検討しました。

今回のリアーキテクチャの目的は、複雑な事業構造をシンプルかつ的確にシステムに落とし込み、当社の競争優位性を生み出すこと。これを実現するには、現状の業務の分析を丹念に行い、事業構造の整理とシステムの設計をすべてやり直すほかない。こうして「業務ドメインのモデリングと分割統治、モノリスアーキテクチャからマイクロサービスアーキテクチャへ移行する」という方針に決めたのです。

――これまでの流れを、順を追ってお聞きしたいです。まず、リアーキテクチャに着手する前には、どんな準備をしましたか。

普川：経営レイヤーと合意した後に、エンジニア全員に「リアーキテクチャを本気でやります」と共有しました。

今回のリアーキテクチャを無事完遂させるためには、丁寧な合意形成が不可欠です。

ドメインモデリングを初めて実践する組織で、複雑な事業やビジネスの流れを全て整理し直してシステムに反映するには、膨大な時間やコストがかかります。正直いつ終わるのかの見通しもつきません。これを行うという意思決定は、経営レイヤーにとって「先が見えず効果を想像しづらい取り組みに、長期間投資し続けること」を意味します。それに、エンジニアにとっても、ドメインモデリングは今まさに注目されている取り組みですから「流行っているからやってみたいという意味なのか」と誤解を招くおそれもありました。

だからこそ、どんなに時間がかかっても投げ出さないでやりきるために、誤解なくスタートラインを揃える、つまり関係者全員がリアーキテクチャの意義を理解し、方針に合意している状態をつくる必要があったのです。

幸いなことに、当社の経営レイヤーは技術への理解があったため、スムーズに合意形成を進められました。エンジニアへの説明のためには、リアーキテクチャの意義を理解するための下地として、開発組織の行動基準として大切にしてきた価値観を改めて言語化して「テックプリンシプル」を設定しました。その上で「この取り組みはシステムを大幅な刷新を行うし、新しい開発手法や技術要素も取り入れていく。そのため短期間では成果がでない。ある程度長期にわたった取り組みになる」と繰り返し説明しました。

エンジニアに対して綿密に、丁寧に説明したのは、逆コンウェイ戦略（※1）に沿って、リアーキテクチャを始める前に組織変更をしたかったからです。組織変更は現場に大きな負荷がかかるからこそ、丁寧に説明し、リアーキテクチャの意義を理解して協力してもらう必要があったのです。

（※1）逆コンウェイ戦略： 「アーキテクチャは組織構造に依存する」と示したコンウェイの法則を逆手に取り、「理想とするアーキテクチャを見越して、それに合わせてあらかじめ組織構造をつくっておく」こと。サービス単位の組織構造をつくることで、チーム同士のコミュニケーションコスト削減や、システム変更のコスト削減が見込めるとされている。

――組織変更は、どのように行いましたか？

普川：今回のモダナイズに際しては、CTO直下でリアーキテクチャを専任で主導する「CTOオフィス」というグループと、既存業務と兼務しながら進めるグループをつくることにしました。そして各グループの中には、大まかなドメインの分かれ目を「受注」「配送」「発注」「顧客」「商品」「会計」「物流」として、これに応じて7つのチームを組成していきました。

この組織変更のポイントは、あえて既存業務とリアーキテクチャを兼務するグループをつくったことです。

目的は、既存システムの機能開発を担う人と、リアーキテクチャ専任チームのコミュニケーションコストを抑えること。それぞれがすっぱり分かれた組織構造だと、情報の受け渡しが重くなってしまいます。両者のコミュニケーションがうまく取れないまま開発を進めると、新しいアプリケーションが既存システムの状況に全く配慮しないものになってしまう可能性があります。そうした状況を避けるために兼務グループをつくっていて、たとえばあるチームでは、6名中4名が兼務するといったように、各チーム内の半分以上のメンバーは兼務としています。

――「CTOオフィス」のメンバーはどのように選んだのでしょうか。

普川：社内でも、業務についての理解が深い人、新しいアーキテクチャに造詣が深い人、新しい開発手法に慣れている人など、取り組みを進める上で十分なスキルをもった方に入ってもらいました。中途で入っていただいた方も何名かいます。ただ一番重要視したことは新しい取り組みを一緒に楽しんでもらえるかという点です。

もちろんこうしたメンバーは、元々いたチームからも深く頼りにされているので、すぐに異動してもらおうとすると、元のチームに多大な影響を与えてしまう場合があります。そのため、今の体制になるまで2年をかけて、地道に調整していきました。

今、CTOオフィスには6つのチームがありますが、皆それぞれ、最初に異動を提案してから実際に異動するまで、約半年程度かけています。短期間で懸命に交渉するのではなくて、腰を据えて着実に拡大していったのです。

――組織変更が完了し、本格的にリアーキテクチャを始められるようになってからは、どんな流れで進めていったのでしょうか。

普川：今回のリアーキテクチャにおいては、システムの上で行われている業務を理解するところから、実際にシステムの設計ができる状態に至るまでに、いくつものステップがあります。

最初に、システムを介して行うあらゆる業務を理解するために、ビジネス側とエンジニアが一緒に、業務の流れを言語化していきます。これを、イベントストーミングといいます。ビジネス全体の流れを整理するためのイベントストーミングが終わったら、これを図に起こして「ビッグピクチャー」を作成します。その後、業務領域を細かく区切ってイベントストーミングをして、ドメインの分かれ目（ドメイン境界）を明確にしていき、ドメイン同士の相関関係と、それぞれの業務の目的や流れを可視化した「コンテキストマップ」を作成します。その後、それぞれの業務の流れを整理した「プロセスモデル」をつくります。さらに業務プロセスを一定の構造に落とし込んだ構造分析図を作成します。これがソフトウェアの設計のベースとなります。

この一連の流れが「ドメインモデリング」です。これを経てドメインモデルが明確になってから、やっとソフトウェアの設計に着手できます。1つのドメインモデルが明確になるまで、約3～4カ月かかります。

――設計を始められるまでに、数カ月を要するんですね。最初に行う「イベントストーミング」は、どのように進めたのですか。

普川：まずは誰に参加してもらうのかを決め、声をかけます。

最初に行った、業務全体を俯瞰したビッグピクチャーをつくるためのイベントストーミングの際は、その後特定領域に絞っていったときに礎となる共通認識をつくるために、関係者全員に幅広く声をかけました。システム側はCTOオフィスのメンバー全員、ビジネス側は、各業務のマネージャーを全員集めました。

業務領域を絞ったイベントストーミングを行うようになってからは、そのとき議題に上る業務の関係者を集めていました。ビッグピクチャーをつくる会にいた人の中から、その業務の関係者に声をかけたうえで、エンジニアもビジネスサイドも、より現場に近いメンバーを集めるイメージです。

1回の参加者数は20～30人ぐらい。完全オフラインで丸一日、長い時には2～3日かかりました。

ワークでは、付箋の色で意味の違いを表しながら、業務の流れを整理していきます。オレンジが「注文を受けた」「不正チェックをした」というような「業務」を示します。水色は「アクター」といって人間が何かをするということを示し、ピンクは何らかのアプリケーションを指しています。

こうして付箋に書き出していくと、この画像のようにまとまりがあるのがわかってきます。これが「ドメイン」です。

普川：ドメインが明確になったら、次はこれらを時系列に並べていきます。

その際、ドメインの境界線をはっきりさせるために、一度実行すると後戻りできない「ピボタルイベント」を探します。たとえばモノタロウの場合「出荷する」という業務は、一度実行すると、出荷した商品に変更を加えることはできなくなるため、後戻りができないピボタルイベントであると言えます。また、並行処理を見つけたり、関係者や外部システムを洗い出したりもします。議論を進める中で現在の業務の流れの課題に気づいたら、黄色の付箋を使って書きとめます。

こうして、現状の課題を洗い出しつつ、業務の流れも可視化するわけです。このようにモノタロウの業務全体を網羅したイベントストーミングを通じてできあがったものを「ビッグピクチャー」と呼びます。

普川：そして、このビッグピクチャーで可視化された「Web注文」や「キャンセル」などといった業務領域ごとにもイベントストーミングをして、各業務の細かな流れを整理した「プロセスモデル」をつくっていきます。

――イベントストーミングをスムーズに進めていくために、どんなことに気をつけていましたか？

普川：議論がうまく噛み合わないときには「1つの言葉が複数の意味を持っていないか」と話し合ってみるようにしていました。

組織の中では、1つの言葉が複数の違った意味で使われている場合がよくあります。実際にあった場面を例に挙げると、「在庫の引き当て」という言葉です。これは狭い意味では「ある受注に対して、どの倉庫のどの在庫を使うかを決めること」を指しています。しかし、うまく話が噛み合わない。そこで「“在庫の引き当て”というと、具体的にどういった業務までを指していますか？」と確認したところ、相手は狭義の意味に加えて「どの配送会社を使うかを特定すること」までを「在庫の引き当て」だと考えていました。

イベントストーミングで、担当業務も、持っている知識も異なる30人近くが集まると「なんだか噛み合わない」という瞬間はかなり頻繁に訪れます。そんなときは、議論の中で頻出している言葉の定義に立ち返ると、途端に議論がうまく進むようになる場合が多いです。こうして言葉の定義を合わせていくことで、ドメイン駆動設計でいうところの「ユビキタス言語（同じ言葉）」が生まれていきます。

でも、これだけ時間をかけて丁寧にイベントストーミングをしても、それだけでは何も変わらないんですよね。システムに落とし込むまでには、ここからさらに長い工程を経なければなりません。

――イベントストーミングで、ビッグピクチャーやプロセスモデルをつくってからは、どのように進めていくのでしょうか？

普川：ビッグピクチャーで業務全体の流れを、プロセスモデルで特定業務の流れを整理していくと、ドメインの分かれ目や関係性、また、ドメインにどんな要素が内包されているのかがなんとなくわかってきます。そのため次は、これらを可視化する「コンテキストマップ」をつくります。

たとえば先ほど申し上げた「在庫の引き当て」であれば、在庫ドメインの中に「引き当て」があり、その中にどういう業務があるのかを細かく洗い出します。そして、他の「受注ドメイン」「配送ドメイン」などと、どんな関係があるのかを洗い出していきます。受注すると「引き当て指示」が出て、「引き当て指示」を受け取った担当者が、「出荷割り当て」と「在庫引き当て」を別の担当者に依頼する…というように整理していくと、「在庫の引き当て」において「在庫ドメイン」が「受注ドメイン」「配送ドメイン」とどのように関わっていくのかが見えてきます。

これがコンテキストマップによって可視化されて、ようやく、ソフトウェア設計の手前の「各ドメイン毎のドメインモデリング」に着手できるようになります。

――ドメインモデリングは、具体的にどのように行うのでしょうか？

普川：私たちが最初につくったドメインモデルである「在庫ドメイン」を例にお話します。

ビッグピクチャーをつくった時点では「在庫ドメイン」の役割は曖昧でした。しかしプロセスモデルをつくるうちに「在庫ドメインは他のあらゆるドメインと関係を持っている。となると、このドメインを整理しないことには、他を決めることができない」とわかってきて、最初にドメインモデリングをすることになりました。

「在庫」という言葉は、受注や配送、発注や倉庫など、ビッグピクチャーで示した業務全体の流れの中に、ほとんどずっと介在しています。しかし、それらが示す概念は業務ごとに全く異なる。

たとえば「在庫数」という言葉でも、受注においては「現在在庫数」、配送においては「引き当て可能数」、倉庫においては、今倉庫に置いてある在庫のうち、移動や出荷の予定がなく自由に扱える在庫数を「出庫余力」…というように。どの概念の「在庫数」を参照したいのかは、業務やユースケースによって異なり、算出するためのロジックも違います。既存システムでは、このロジックがあらゆる業務に紐づいて点在していて、管理も変更も容易にできなくなっていました。

そこで「在庫ドメイン」のドメインモデリングとして、在庫ドメインと他ドメインとの関係性を構造化していきました。様々なドメインで発生する在庫の移動を「今出るか／未来に出るか、今入るか／未来に入るか」の4象限に分けたり、「出荷・仕入れ・返品」と分けていたのを抽象化して「在庫の移動」を示す1つの処理に集約したり。このドメインを処理するソフトウェアを設計できるように、ドメイン内の構造を構造分析図に整理していきました。

また、ドメインモデルとは別に、既存システムを止めないように移行していく方法も考えなくてはなりません。参照する場所はどこなのか。物理的にシステムをどう配置するのか、というようなことをこまごまと決めていきます。

――かなり長い段取りを踏む必要があるのですね。

普川：ただモダンな技術スタックに入れ替えるだけだったら、こんなに多くのプロセスを踏まなくても、できるかもしれません。しかし、既存システムでうまくいっていないアーキテクチャから脱出できないままでは、変更に強く競争優位性に直結するようなシステムはつくれません。

今動いている業務を、今後どうしたいかを考え、そこから逆算して業務の構造をシステムで正しく表現したいと考えると、だいたいこれぐらいのことをしなければならないんですよね。

――この一連の流れで、最も難しいのはどのあたりでしょうか？

普川：時間がかかるといってもできるだけコストは抑えたい。しかしリアーキテクチャに必要な情報を明らかにするプロセスの中で、どこをどう端折れるのかを見極めるのが、ものすごく難しいです。

これまでに話したドメインモデリングの流れを上から下まで教科書的に、この順番にやればきれいにできるというように思われがちですが、実際にやってみると、そんなことは全然ありません。

そもそもモノタロウにはドメインモデリングを実践した経験がある人がそんなにいないから、AWSさんの支援を受けながらずっと手探りで進めています。教科書通りに進めていても「ここから先を明らかにするには、まずあのドメインの議論をしなくちゃ」と、手順を行ったり来たりする場面が少なくない。

では最短で、今回目指しているアーキテクチャをつくるために必要十分な情報整理を行うためには、何を端折ればいいのか。コストをかけてもアウトプットが変わらないところはどこなのか。その見極めが難しいのです。

――どのように「端折るところ」「端折らずやるところ」を決めていますか？

普川：現状では、業務の特徴を踏まえて、特に複雑性が高いところは端折らず慎重に、そうでないところはある程度端折ってもいいだろう、といったように判断しています。

前者の例としては、先ほどの「在庫ドメイン」が挙げられます。「在庫ドメイン」の特徴は出入りが非常に多くてユースケースがたくさんあること。まずは考えられるユースケースを全部洗い出しました。そして「結局在庫のドメインがやるべきことは何なのか？」を決めるためにユースケースごとに、どのデータ・カラムを更新しているのかを確認して、データから分析していく、というように、丁寧に進めていきました。

一方「受注ドメイン」の場合は、データからの分析をざっくりと端折っています。というのも、最も複雑性の高い「個別の受注のイレギュラー」は、過去にオペレーターが対応してきた事例が蓄積されていたので、この事例の分析から取り掛かっています。ここが明らかにできさえすればデータの分析は必要ないだろう、として、行っていません。

端折るというのも、結果的に端折っているだけで、その場の状況によって、「これを理解したのであれば、次はここを理解したい」だとか、「これがわかるのであれば次はこの手法でこの領域をやろうか」と判断している、と言った方が実態に近いと思います。この見極めの精度は、私自身も、組織としても、まだ明確なプラクティスができあがっていないのが実情です。

――これまでお話にあったプロセスを、全ての業務について実施して、システムを刷新していくとなると、お話を聞いている立場でも気が遠くなります…。

普川：そうですよね。業務の複雑性が高いからこそ、思い通りスムーズに進められるわけではありませんし、いつまでかかるかもわからないし。

そもそもイベントストーミングすらも、最初は全然うまくできませんでした。流れもやるべきことも理解しているはずなのに、これで前に進めているのだろうかという所在なさがありました。これまで話してきたように、ドメインモデリングに沿ったプロセスごとの目的を言語化できるようになってきたのも、ここ最近のことです。現状、イベントストーミングだけでも10回以上は実施してきましたが、まだまだかかりそうですね。

そして当然ですが、メンバーからも「この仕事に意味はあるんだろうか」「本当にリアーキテクチャはできるんだろうか」といった不安の声が聞こえてきます。その気持ちも痛いほどわかります。

――「今回のやり方では厳しいのではないか。とりあえず技術スタックの刷新だけ先に行おう」など、方向転換を考えたりはしないのでしょうか。

普川：それは絶対にありません。我々がやりたいことは「システムの変更容易性の獲得と、当社の競争優位性の確立」です。技術スタックの刷新だけではそれはなし得ないからです。

私自身「このリアーキテクチャは本当に完遂できるのか」「完遂できたとして、競争優位性の向上に資する設計ができるのか」と不安を感じるときもあります。取り組んでいる内容は簡単ではありませんし、今まで我々が慣れ親しんだやり方や考え方を変える必要もある。しかし、今の方針でやりきってみないことには、現在のシステムにある不確実性を下げることはできません。

リアーキテクチャ成功の可能性を高めるために、開発組織の価値観を示すテックプリンシプルと、今回のリアーキテクチャを強く結びつけました。モノタロウの開発組織とシステムが一丸となって、当社の成長のためにこの取り組みを進めていく。この説明責任、実行責任を果たし続けることこそが、意思決定者であるCTOの責務だと、私は思います。

先はまだまだ長いけれど、モノタロウの事業をきっと大きく前進させてくれるこのリアーキテクチャを完走できるよう、たゆまず進んでいきます。

取材：鹿野 恵子、光松 瞳
執筆：鹿野 恵子
編集：光松 瞳
撮影：赤松 洋太