独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。
今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹介していきます。 技術的な取り組みについて先にご覧になりたい方は、第2章からお読みください。
- 第1章 「資材調達ネットワークの変革」というビジョンを実現するにはシステムの高度化が必須
- 第2章 アーキテクチャの再構築とシステムのモダナイズへの挑戦
- 第3章 挑戦を促すモノタロウのTech組織
- 4章 今後の展望
第1章 「資材調達ネットワークの変革」というビジョンを実現するにはシステムの高度化が必須
モノタロウとしてアーキテクチャの再構築とシステムのモダナイズに取り組む必要があることをご理解いただくために、第1章では、モノタロウのビジネスの構造と目指している世界についてご紹介していきます。
1-1. 2000万SKUを取り扱うB2BのECならではの複雑性
――モノタロウの会社としてのビジョンをお聞かせください。
当社では「資材調達ネットワークを変革する」という企業理念を掲げています。資材のなかでもとりわけ「間接資材」の調達に掛かる工程を減らすことで、あらゆる事業者が本業に集中できるようお客さまの「時間資源」を創出する。これが当社の目指している世界です。
間接資材とは、文具や事務用品、緩衝材・梱包材や作業用の軍手といった消耗品、切削工具や研磨材といった工作用資材など、最終製品になる原材料や部品などの直接資材を除くすべての資材のことを指します。一般的にどの企業でも直接資材に比べ必要となる間接資材のアイテム数は多く、それぞれ調達のタイミングや仕入れ先は異なるため資材調達に膨大な手間がかかります。そこで、モノタロウでは、あらゆる事業者をターゲットに多種多様な資材を取り揃え、ワンストップで調達できる仕組みを提供しています。
――モノタロウのサービスの特徴について伺えますか。
モノタロウは、約2000万SKU(Stock Keeping Unit:在庫管理の最小単位)という規模であらゆる商品の在庫を持ち、ワンストップで商品をお客さまのもとまで届けることができるECサービスです。1つのECサイト上に多数のブランドやショップが出品・出店するモール型ECサイトとは異なり、自社で在庫を保有しているため、商品調達から配送までを担う仕組みを持っている点が特徴です。サプライヤからお客様に商品が届くまでのサプライチェーンを、オペレーションとデータとソフトウェアで最適化しコントロールしようとしているのがモノタロウです。
――モノタロウは他社のECサイトと比べてどのような特徴がありますか。
モノタロウでは、B2B商材をメインに扱っています。B2BはB2Cに比べて商品数が多くなるだけでなく、1つの商品に対して数十~数百単位で発注されるケースがあります。もちろん少量での注文もあるため、注文時の数量のばらつきがB2Bの特徴の一つです。
また、B2Bはニーズが多様で、ロングテール部分の商品数が膨大になります。たとえば「この機械にピッタリと当てはまるネジが欲しい」といった特殊なニーズもあり、商品としては多くの種類を取り揃えておく必要があります。
納期がセンシティブであることもB2Bの特徴です。商品が届かない場合、たとえば工事ができず大規模なプロジェクトが止まってしまうなど、その事業者のビジネスに大きく影響するケースもあります。ECサイトとしては、納品の遅延は最も避けるべき事態です。
つまり、在庫や調達、配送における複雑性の高さがB2B商材を扱うポイントといえます。
1-2. テクノロジーでモノタロウの競争優位性を創出する
―― モノタロウのビジネスの構造について説明をお願いします。
下の図を使って説明します。図の真ん中に商品があります。我々は2000万SKUと膨大な品揃えを構えることでワンストップサービスを実現しています。これが弊社の強みの一つです。この商品群からお客様が如何に簡単に商品を見つけて頂くかが一つ目の重要なポイントです。そして注文頂いた商品を右下の「供給ネットワーク」を通じて商品を調達し、「配送ネットワーク」を駆使してお客様に商品をジャストインタイムで届けることが2つ目の重要なポイントになります。これが資材調達ネットワークです。
――資材調達ネットワークの変革に向けて、課題になっている部分を教えてください。
課題は、事業成長に合わせた形でオペレーションおよびシステムを進化させていく必要があることです。事業としては10年連続で20%近い成長を実現してきました。この成長の過程で業務の複雑性が増していきました。また、資材調達の利便性をさらに向上させるには、顧客接点のパーソナライゼーションとサプライチェーンの高度化が必須となります。こうした課題をどう仕組みに落とし込んで解決していくかが、今まさにモノタロウとして取り組もうとしている挑戦です。
――「挑戦」について詳しく伺えますか。
モノタロウは、手に入らないものはない、必要なタイミングでお届けする方針でこれまでやってきました。こうしたモノタロウの方針には、やはりお客様の時間資源を創出したいというモノタロウのミッションが根底にあります。だからこそ、お客さまにとっては、商品の検索から発注、商品の到着、支払いまで、当社としては、商品を適切な形でお客さまに届けるための施策立案(マーチャンダイジング)からマーケティング・セールス、調達・SCM、オペレーションまですべてをカバーし、実行・改善・再構築・新規設計のサイクルを回すことで、最適化を図っています。
そして複雑な仕組みを実現するには、検索や推薦などのアルゴリズムとソフトウェアが重要な役割を果たします。
――テクノロジーがモノタロウの競争優位性を生み出す一つの鍵になっているわけですね。今後大きなチャレンジとなる部分はありますか。
モノタロウのビジネスを高度化し、競争優位性をより強くするために、さらなるテクノロジーへの投資が必要だと考えています。
2000万SKUの商品を数千からなるサプライヤーさんから調達をし、50万点を超える商品を自社の在庫で保管します。お客様のお届けの場所に応じて、複数ある倉庫から最適な配送ルートでお届けを行います。最近ではサプライヤでの在庫情報と連携することで、自社倉庫以外からも当日の出荷が行うことが可能になり、その資材調達ネットワークが進化しております。
こうした複雑なネットワーク構造となっている仕組みを自社のシステムで効率化することで、垂直的に資材調達ネットワークのコントロールができるようになり、調達、在庫管理、配送などの各工程をスムーズにつなげていくことができるのです。これこそが、モノタロウの競争優位性になっていくと考えています。
また、モノタロウでは、あらゆる業界のニッチな製品を扱っており、ロングテールの商品が多いぶん、お客さまがいかに目的とする商品のページへスムーズにたどり着けるか、サイトの検索性も重要となります。このため、今後はより進んだパーソナライズ化が鍵になると考えています。これに向けても、アルゴリズム、業務オペレーションの進化は必須です。
第2章 アーキテクチャの再構築とシステムのモダナイズへの挑戦
ここまで、モノタロウが目指す世界とそこに向けた課題や挑戦すべきことについて整理してきました。第2章では、システムとして具体的にどのように実現していこうとしているのか、その詳細について紹介していきます。まずは、システムとアーキテクチャの現状から見ていきます。
2-1. 組織の拡大とシステムの複雑化により生じた課題
——現在のシステムにおいてはどのような課題がありますか。
モノタロウはこれまで20年間安定した成長を続けてきている反面、ビジネス成長が十分に進んだことでシステム/組織が拡大し、新規での取り組みに比べて調整コストが増えてしまっている状況です。モノタロウのサービスは高度な機能/仕組みであり、そこに加えてユニークさも備わっているため、年々システムの複雑性も高まっています。
このように組織の拡大とシステムの長年の運用による複雑性が生じている状況で、本来取り組むべき課題に十分リソースを振り向けることが難しくなっていることが課題だと考えています。本来的にはモノタロウのサービスを進化させるためには、システムが経営の戦略・戦術に素早く対応できるよう変更容易性を備えておく必要があります。
2-2. 「分割統治」で複雑性に対処する
——どのような方針でそうした課題を解決しようとしていますか。
そのために取るべき方針が「分割統治」だと考えています。分割統治とは、大きな問題を複数の小さな部分問題に分割し、それぞれの部分問題を個別に解決することで全体の問題を効率的に解決する手法です。
現在課題となっているモノタロウの複雑性は、組織とシステムの規模が大きいがゆえに生じているものです。そのため、それぞれ制御しやすい規模まで問題を分割することで、複雑性への対処が可能になると見込んでいます。さらなる事業のスケールという観点でも、分割統治は効果的です。
システムの話で言うと、モノリスアーキテクチャからマイクロサービスアーキテクチャへと移行すると捉えることもできます。ただ重要なポイントは各ドメインが自律、独立的に経営レベルでの競争優位性を獲得して、サービスを進化させることであり、マイクロサービスはその手段だということです。
またアーキテクチャを変えると同時に開発プラットフォーム、開発プロセスそのものも刷新してきます。また、組織としても開発アジリティが上がる構造に変更をしていく必要があります。アーキテクチャを変えたとしてもそれが十分に活きる組織構造と開発文化が備わっていないと、意図した結果をえることが難しいためです。
2-3. 分割統治を実現するためのドメインモデリングとイベントドリブンアーキテクチャの採用
——具体的にはどのような方針でシステムの分割統治やマイクロサービスアーキテクチャへの移行を実現されていくのでしょうか。
まずシステムの分割の前に、組織の変更から着手しました。逆コンウエイ戦略という言われ方もしますが、大まかなドメインは明確なのでそれに合わせて組織グループの分割を2023年の春に行いました。次にシステムをコンテナで稼働させアプリケーション実行環境をドメイン毎に分割しました。これでまず変更容易性とドメイン毎の独立性をだすのが狙いです。まだ一部の共通ライブラリが共有されているところはありますが、2023年の12月には全てのソースコードの管轄をいずれかのドメインにに整理した上で実行環境の分離が終わっています。このあたりの詳細は別の記事にまとまっております。
並行してドメインモデリングを進めていています。上図のように大まかなドメインの想定はありますが、明確な境界を明らかにしています。そしてドメイン境界にそってデータベースも分割して、他ドメインからアクセスするAPIを提供を順次開発する。またドメイン間をより疎結合にするためイベントドリブンアーキテクチャの導入を進めています。こうした取り組みを各ドメインで同時的に行っていくことで、徐々に狙っていた分割統治が進んでいくと考えています。
——こうしたドメインモデリングはどのように進めていったのでしょうか。
AWSのソリューションアーキテクトの福井さん、金森さんにサポート頂きながらドメインモデリングを愚直に進めていきました。ドメインの役割と境界を決め、現状の業務から集約とイベント抽出し、それがどのドメインがオーナーシップをとるべきかを考えていきます。特に重要視していることは、ビジネス側のメンバーとシステム側のメンバーで同じモデル/コンセプトを共有するということです。従来は、ビジネス側の考え方やモデルを要件という形でシステム側に渡していましたが、システムはソフトウェアのモデルをもとに開発されるため、業務とシステムに乖離が生じるというケースがよく見られました。こうした問題は、ソフトウェアとビジネスで別々のモデルを作り込んでしまっているために起こりえます。
——この課題に対してどういう取り組みを行っていますか?
イベントストーミングの実施です。イベントストーミングとは、システム側、ビジネス側によらず対象となるドメインに関連する人たち同士で協力して業務プロセスを可視化し共通のビジネスモデルとユビキタス言語を獲得する取り組みと我々は考えています。ここで定義されたモデルをシームレスにシステム設計のベースとすることも利点の一つと考えています。これによって今後ビジネス・システムの共通のモデルを元に業務の改善、進化を話し合うことができます。ビジネスの高度な仕組みを素直にそのままシステムに落とし込むことで、ビジネスの進化のアジリティを上げることができると考えています。
図:社内で行ったイベントストーミングの様子
——イベントストーミングのなかで明らかになったことなどはありますか。
発注ドメインの分析でこんなことがありました。発注に当たっては基本的には需要予測に基づいて在庫の東西配置と発注点を決めています。発注点を元に自動発注する際にはサプライヤとの取り決めである最低発注数や発ロットなどの制限、輸入の場合は航路や揚地港、倉庫での在庫体積や入荷工数削減の為の施策、商品の季節性、機会損失など様々な制約事項を加味してサプライヤーに発注する数を算出する必要があります。現状は大まかに行って「発注点の算出」と「サプライヤー発注」アプリケーションの2つに分かれていますが、基幹システム内では発注点を定義する変数が安全在庫数・危険在庫数のみであるため、本来発注で行うべき制御が安全在庫・危険在庫数の計算結果に含まれてしまっています。発注量をコントロールする施策が発生する場合は当然発注側の改修も同期を取って行う必要があります。従って業務変更や新しい施策を行うたびに結果として「発注点の算出」と「サプライヤー発注」どちらにも修正が入ることが多く、変更容易性が確保できていない状況でした。発注ドメインの需要予測から発注までのモデリング作業を進める中で需要予測や在庫配置に基づく計算と発注コントロールに関する集約、ロジック共にオーナーを明確にした上で分離すべきだということがわかりました。様々な制約や業務ロジックも内容に応じて、それぞれ意味合いのアプリケーションに分離させることで変更容易性を上げることができます。
2-4. 業務の複雑性への対応と商品検索体験向上に向けた取り組み
——業務の複雑性にはどのように対応していくのでしょうか。
我々が目指しているのは、「分割統治」、そして分割した各ドメイン毎に個別にアジリティ高い進化できる状況を作ることです。モノタロウの膨大で複雑な業務をドメインモデリングを通じてチームで扱えるサイズに分割していきます。ドメイン間の通信も可能なところは非同期に連携することでより疎結合にしていきます。業務イベントを抽出しその事実情報を他のドメインに伝搬させ、受け取ったドメインが業務チェーンをシステムで表現して処理していくアプローチは合理的で、当社の事業との相性もよいと考えています。特に我々のビジネスは業務ロジックが複雑で分厚いため、業務ロジックを如何に一箇所に閉じ込め、変更容易性を保ち続けるかが肝となってきます。そのためドメインモデリングの後、ヘキサゴナルアーキテクチャの真ん中に閉じて業務ロジックを作り込んでいきます。またドメインに関わるエンジニアが業務ロジックの開発に注力できるようにアプリケーションのベースはテンプレートリポジトリを用意しました。
テンプレートリポジトリにはCI/CDパイプライン、またオブザーバビリティ(ロギング、メトリクス、分散トレース)や他マイクロサービス間の通信用共通ライブラリなどが含まれており、新規開発にまつわるさまざな決め事、タスクを減らし、高速にアプリケーションを立ち上げることができます。同時にスキーマファースト開発や分散トレーシングなどシステム横断で標準で行うと決めた開発のプラクティスを入れ込むことを可能にします。
またアプリケーションが稼働するインフラにおいてはいわゆるクラウドネイティブな技術スタックの採用を進めています。真新しさはありませんが世の中的なベストプラクティスを採用し、我々の状況あわせてカスタマイズすることが大事と考えています。
——パーソナライゼーションによる商品検索体験向上に関する取り組みについてはいかがでしょうか。
特に売れ行きのよい商品をビジュアルにして表示させたり、並び順を工夫したりすることはもちろん大切ですが、単に全文検索エンジンを導入するだけではモノタロウのサービスレベルは実現できません。
商品によっては、商品情報にはない言葉で検索されるケースもあります。たとえば「戸当たりクッション」という商品は、職人の方々のあいだでは「涙目」という通称で呼ばれていますが、商品情報のどこにも涙目という記載はありません。この解決方法として、1つひとつの商品に対して「涙目」という情報を追加していく方法は現実的ではないので、モノタロウでは「涙目」という言葉で検索している人たちが実際に何を購入しようとしているのか、データから解析していくアプローチを取っています。
これを2000万SKUの商品に対して行おうとすると、大変な労力になります。インデックスをつけ直すにも数時間かかるバッチ処理が必要です。また、6〜7億の商品カタログデータから情報を抜き出して各商品の属性データを作成し、比較可能な検索条件に落とし込むための商品情報整備も行っています。この際、言語処理解析を行い、約7割のデータは自動抽出しています。
他にも、「台車」という言葉で検索した場合、約7000件ほどの候補が表示されます。お客さまによって目的としている商品は大きく異なります。そこでモノタロウでは、お客さまが他にどのワードで検索しているのか、過去にどのような商品を購入しているのかなどを加味しながら、その人に合ったカテゴリの商品を上位に表示するよう最適化をしています。
他にも下図のように検索結果画面はコンポーネントを組み合わせて生成していますが、このコンポーネント毎にアルゴリズムによる最適化を行っています。そして日々ABテストを行いその改善を継続的に続けています。
現状のチャレンジは、お客さまが直前に何を閲覧・購入していたのかなど行動まで含めたリアルタイムデータからパーソナライズ化する部分を増やしています。直前の情報を加味することでレコメンドの質は大きく改善できています。
2-5. 組織的にも技術的にも「プロダクト開発」と「プラットフォーム開発」で分ける
――モノタロウにとっては、これまでとは違うテクノロジーの活用を進めることにもなると思います。一方で、エンジニアとしてはドメインの深い理解も求められますよね。
事業の特性上、業務そのものにエンジニアが詳しくなければシステム開発はできません。一方で、マイクロサービス化やイベントドリブンアーキテクチャはモノタロウにとって新しい技術的な挑戦であり、開発者の認知負荷が高まるのも事実です。そこで、アジリティを確保するために、チームトポロジー等で謳われているようなチームタイプを参考にしながら組織再編を行いました。
ストリームアラインドチームである、プロダクト及びドメインチームは業務とサービスの進化に集中する。またそのソフトウェア開発にまつわるテクニカルな複雑性をプラットフォーム組織が引き受け、イネイブリングとプラットフォームの提供を行いながらサポートしていくという構図です。我々のソフトウェア開発をした図のようなAからHの領域にわけ、各領域でのプラクティスを作り込み標準化を進めています。前述のような「テンプレートリポジトリ」なども具体的な内容の一つとなります。
第3章 挑戦を促すモノタロウのTech組織
第2章では、テクノロジーという観点からモノタロウのチャレンジについて整理してきました。第3章では、組織としてどう実現していこうとしているか紹介していきます。
3-1. モダンな開発プラクティスを実践するための組織とカルチャーの醸成の取り組みを開始
――テクノロジー面でのチャレンジに向けては、組織設計も重要になると思います。開発組織が目指すべき「MonotaRO Tech Vision」の策定など、モノタロウのTech組織として新たな取り組みを進められている背景を伺えますか。
組織規模が120名を超えてきた2021年ごろから、メンバーの顔と名前が一致せず、価値観も揃わなくなってきているという課題が顕在化してきました。これに加え、ちょうどコロナ禍で対面の機会が減っていたということもあり、Tech組織として目指すべきビジョンや共通の価値観を整えていく必要性が高まっていました。
また、分割統治という方針を取るに当たって、会社のビジネスとテクノロジーとのつながりがわかりづらくなってしまう懸念もありました。テクノロジーが会社の事業にとってどのような価値を生み出すのか、ビジネスとテクノロジーをしっかり紐づけておくことが求められていました。
そこで、まずはTech Vision、そのための行動規範となるTech Principleを定め、それをもとに組織として目指すべき方向性とそのための具体的なアクションを整理することにしました。
――Tech Visionについて教えてください。
モノタロウ全社で定めている企業理念・行動規範をベースに、「常に事業者に選ばれる世界で唯一の顧客価値を提供するため、データとテクノロジーを徹底的に活用する」と定義しました。前半部分は会社全体のVisionに相当するものですが、テクノロジーは「How」なので、Tech組織としては「データとテクノロジーを徹底的に活用する」という文言を加えているのがポイントです。あらゆるデータを集め、そこから構造、パターンを見出して、判断の基準とする。あらゆる領域において、テクノロジーを活用し問題解決を行っていく。エンジニアリングの手法を用いてスケールさせていく——こうした意思を表しています。
3-2. 5つのTech Principleとその活用法
——Vision実現に向けた行動規範であるTech Principleについて伺えますか。
「守→破→離」「思考を言語化して伝える」「好奇心を育み、成功に導く」「生み出す価値を定義する」「自律と協調の両立」の5つを定めています。
一部を簡単に紹介すると、「守→破→離」は、まず世の中の「型」を学んだうえで、自分たちに合う形で改善していくという、まさに今進めているシステムのモダナイゼーションの方針に近い考え方です。
また組織の拡張に伴い、組織間のコミュニケーションコストが高まるため、「思考を言語化して伝える」ことを重視しています。
他にもマイクロサービス化にあたっては、各自・各チームがオーナーシップを持ち自律的に動くことが必要ですが、その結果は組織全体の最適化につながるものであるべきという方針を「自立と協調の両立」という言葉で表しています。
――Tech Vison、Tech Principleは現在どのように活用されていますか。
主に「アーキテクチャ・開発環境」「採用・育成」「組織構造・チームづくり」「制度・カルチャー」という4つの領域において具体的なアクションを定めるなどして活用を進め、Tech Visonを組織に浸透させる取り組みを行っています。
3-3. スケールしやすい組織にするため「ロール」を設定
――組織構造・チームづくりの具体的な取り組みについて教えてください。
以前は、部門長に権限が集約されていたり、明文化されていない複数の責務を特定のメンバーが暗黙的に担っていたりと、キャパシティを越える責務を抱えたメンバーがいました。また、これがボトルネックとなり、組織としてスケールが難しい状況が各所で発生するようになりました。
そこでまずは、組織マネージャー、テックリード、プロデューサー等など、責務、権限、オーナーシップを明確にした「ロール」を設定し、各メンバーへの適切な権限移譲を行うことにしました。これにより、ボトルネックが解消され、よりスケールする組織体制へと変革していけると考えたためです。また、ロールごとの責務が明文化されれば、誰に、どのような相談をすればよいか判別しやすくなり、よりスムーズなコミュニケーションが行われるようになります。
――代表的なロールについて、具体的に紹介していただけますか。
たとえば、組織マネージャーは、部門長、グループ長、チームリーダーが当てはまり、組織の目標達成が主な職務となります。テックリードは、技術領域におけるチームの開発品質の担保と生産性最大化、担当システムの技術的課題の設定と解決を職務として担います。オーナーシップが求められる範囲は、担当システムにおける実装方針や技術選定、開発プロセスなどの判断・決定などです。一方、ビジネス側のロールの代表例である顧客向けサービスのプロデューサーは、サービスの価値を最大化することが責務として定められており、ニーズ分析や要求管理、サービス価値の説明に対しオーナーシップが求められます。
3-4. コンピテンシーマトリックスやトレーニングプログラムで成長課題を明確化
――採用・育成の観点ではどのような取り組みを行っていますか。
Tech Principleを各職位の行動指針にまで落とし込んだコンピテンシーマトリックスの作成を行っています。人事制度の等級とTech Principleを組み合わせることで、より実践的なレベルで行動指針を示したものがコンピテンシーマトリックスです。たとえば、Tech Principleの「守→破→離」を基幹職のチームに適用した場合を見てみると、「守:インプットした情報を組み合わせ、イレギュラーにも対応します」「破:蓄積された情報をベースとし、部分的な改善点を見出し、改善活動を実施します」といった具合で、より具体的な行動に落とし込まれています。半期に一度の上長との面談では、コンピテンシーマトリックスをもとにして、自身の成長課題などを擦り合わせていきます。
――Tech組織のメンバーに向けたトレーニングプログラムなどは考えられているのでしょうか。
モダナイゼーションのための組織的学習機関「MonotaRO DOJO」を設立しました。前述した通り、我々はシステムのアーキテクチャを変えると同時に、開発プロセス、組織、プラットフォームなど、モダナイゼーションのためにあらゆることに変化を加えました。これを組織に属する200人超える全員が理解し、実践する必要あります。そのためには、例えばモダンなソフトウェア開発のワークショップみたいなものを単発でやっても、全く足りないということに気づき、社内に育成機関を立ち上げることにしました。
まずは必要なスキルを漏れなく洗い出したMenuMapを作りました。そこではドメインモデリング、アーキテクチャ、ソフトウェア開発、アジャイル、チームビルディング、リーダーシップなどコース内容は多岐に渡ります。
2023年の1年で、およそのコースを企画し第一回を実施することができました。現状はそれぞれのコースを必要な人全員に受けてもらうために継続的なコースの開催を計画しています。
2023年11月に行われたソフトウェア開発ワークショップについては、別の記事があがっているので詳しくはこちらをご覧ください。
4章 今後の展望
――最後に、Tech組織としての今後の展望についてお聞かせください。
「資材調達ネットワークを変革する」という企業理念を突き詰めると、やはり在庫管理が重要なポイントになると考えています。時間資源の創出に大いに貢献できる領域ですし、サプライヤとのネットワーク構築にも役立つためです。サプライヤは中小企業が多いため、在庫を電子データで管理していなかったり、電子データがあっても活用しきれていなかったりと、在庫管理業務においてはDXが進んでいない部分がまだまだ残されています。そこまで含めてモノタロウとして支援できるようになれば、事業としての可能性はより広がっていくと考えています。