和田近年では外国人労働者の姿が見られることからも、物流業界の人手不足がうかがえます。また、華奢な女性がダンボールを重そうに運ぶ姿を見たこともあります。そうした状況を見ると、この業界は現場の努力によってギリギリの状態で何とか仕事が回っていることを実感します。

我々が取り組むDX事業なら、こうしたロジスティクスの課題を解決できますし、社会的意義も高い。そんな想いから、この課題解決に懸けようと心を決めました。

和田私が過去に携わっていた金融業界では、例えば融資する桁が変わったところで、従業員の作業工数にはさほど影響がありません。極端な話、500万円を貸すのと、5,000万円を貸すのとで我々の事務的な手間は、極端に言うとほとんど変わらないわけです。しかし、物流業界では取り扱う物量が増えると、文字通りそのための業務量は、物量が増えた分だけ増えます。

和田それはサプライチェーンのなかで用いられる、荷物の量や配送先といった情報を含むデータの仕様に共通の規格がなく、すべて現場の手作業によって振り分けが行われているという点です。

まず整理すると、BtoBにおける物流とは、工場から物流センター、物流センターから卸売会社の配送拠点へと荷物が渡っていきます。そして我々が、現在支援している物流センターのポジションは、メーカーと卸の間に入り、荷物を振り分ける”ディストリビューター”と位置付けることができます。

その流れのなかで用いられる発注データは各社バラバラの仕様。これが現場の長時間労働を引き起こしている要因のひとつなんです。

極端な話、物流企業が30社のメーカーと取引をしている場合、30種類のフォーマットでデータが送られてくるということです。バラバラのフォーマットで発注データを受け取った物流センターは、まずデータを統一されたフォーマットに加工しなければなりません。具体的に言うと、積荷の配送先、荷量、品目、荷姿（梱包された荷物の外見や形状）などの表記や単位を全社分、統一するということです。

物流のコア業務はあくまで配送にあると思いますが、その前段となる配送手続きに驚くほど手間が掛かっているという状況ですね。

和田荷主である各メーカーと物流センターとでは、どうしても発注側であるメーカーの方がイニシアティブを持ちます。

「業務フロー変更などの影響範囲が大きいから」というものや「昔からやっている業務を変えたくない」など、様々な理由によって、物流の現場側がメーカーの意見を受け入れながら手作業で最適化しているわけです。

データの発生側を変えることはできない。だったら物流現場が手作業で行っている業務をシマント独自のデータベースで自動化。業務効率を促進しようというのが我々の狙いです。

和田我々が取り組む物流における配車業務の効率化領域は、一般に”割り付け”と呼ばれる「運んでほしい荷物と運ぶための車両の組み合わせ」を考えるところです。

ゲームのテトリスをイメージしていただけるとわかりやすいかもしれません。要は、どのメーカーのどの荷物をどの車両に何個積めば効率よく収まるのか、パズルを解くように考えていくわけです。

和田ここもこれまで人が担ってきたアナログ業務なのですが、我々の開発したシステムを使えば、荷物と車両の組み分けを自動生成することができます。

また、配車を組み合わせた後でも物流の現場では荷主のオーダーや在庫状況に応じて状況が変化するため、配車割り付けの組み直しや微修正を配車マンの判断により修正できる仕組みも備えています。

和田企業規模が大きくなればなるほど、現場に入り込んで個々の現場の事情に照らし合わせながらプロジェクト対応していかなければ難しいと思っています。現場の人たちにも正解がわからないケースは多々ありますから、現場業務と照らし合わせながら調整していくようなイメージですね。

和田IT業界は建設業界と同じく多重下請け構造になっています。ピラミッドの頂点に立つのは大手SIerで、大きいプロジェクトになれば、一般的には複数の下請け構造で総勢数十名～数百名、プロジェクトによっては数千名が開発に関わっているようなケースも多いです。

そのなかでシマントはアジャイル型の開発スタイルを取りつつ、クライアントとシマントで階層構造を少なくしたプロジェクトを担うため、スピード感と柔軟性を発揮できていると思っています。

一般的に多く採用されているウォーターフォール型は、家の建築に例えると、ユーザにとっては「家ができて初めて全体像がわかる」ことだとイメージしていただけるとわかりやすいでしょうか。構造となる柱を立ててしまった後には、途中で大幅な設計の変更は不可能です。

これに対し、我々のプロジェクトの進め方のイメージは3Dモデリングでプロトタイプを作り、全体イメージを掴んでからつくり始めるようなスタイルです。まず、実際のデータから顧客の要求に従って最初のバージョンを作って顧客に見せます。この場合、クライアントも完成品のイメージがつくし、プロトタイプの段階で「ここを変えてほしい」といった要望も出しやすく、柔軟性に富んでいます。

和田メーカー側の担当者、物流現場の担当者、卸売の担当者と、複数社をまたぐ形で仕事を進めていくのがこの業界です。

メーカーの要求Nに対して卸の要求Nがあり、それらの板挟みにあいながら帳尻を合わせてきたのが物流の現場です。だからこそ、開発においてもスタート時の要件定義ですべての仕様を固めるのではなく、プロトタイプを用いてクライアントと協議しながら、最適な解を見出していけるアジャイル型が適しています。

和田そこを実現できるのは、シマント最大の強みでもある『マルチバリューデータベース』という技術を駆使しているからですね。この技術をベースとした開発ツールを持っているため、顧客の要望の追加や変更にも多大なリソースをかけずに対応していくことができるのです。

和田シマントでは、この『マルチバリューデータベース』を活かしてサービスを展開しています。先ほども述べたように、メーカーから届く発注データは仕様がバラバラですが、シマントのDWH側でエクセルの非構造データやCSVなどデータフォーマットが異なっていても統合してデータベース化します。

もちろん、データベース化した情報の中から欲しい情報だけをピックアップして抽出する検索機能も優れています。つまり、データベースに投入される際には整理されていない情報でも我々のツールに取り込めば、すべて整理整頓された状態で取り出せるということです。

和田たとえば、ある人が預金・投資信託・保険という別の商品を運用していたとします。この預金管理システムには管理コードが「1、2、3」と振られており、投資信託管理システムでは「A、B、C」、保険管理システムには「甲、乙、丙」とそれぞれ違う管理コードが振られているという問題が当時はありました。

また、集計期間の尺度も日次・週次・四半期と商品によって異なる状態。このように前提のルールが整っていなければデータとして有効に使えないわけです。そして、このルールを揃えるデータ加工工程が30〜40もあったというのが、私が当時直面した課題です。高い給料をもらって企画を立てなければいけない人間がこうした事務作業に大半の業務時間を割いているのは、企業として経済合理性に欠けるなと思っていました。

ただ、こうした仕事をしているのは各部署で1～2人程度。社内的にその人たちの仕事ぶりは目に見えにくく、また、根本のコード体系の改修やシステム改修をしようとすると莫大なコストがかかるので、改善の手が入りづらい。しかし、必須の仕事であることは間違いない。

「このような縁の下の力持ちを悩ませる非効率業務を改善したい」と思って調べていたところ、『マルチバリューデータベース』の存在を知りました。その後、この技術を日本に持ち込んだ立役者の一人、データベーススペシャリストの渡邉 繁樹氏をCTOに参画してもらい、起業しました。

和田銀行内でデータの統合にまつわる仕事をやりたいとも思ったのですが、社内でやるにはリソース的に時間が足りない。また、今さら営業からシステムに異動するのも難しいだろうと。そう考えると、起業という選択肢が最も課題解決のためのショートカットになると思ったのです。

たしかに銀行出身者が畑違いのITで起業したことには驚かされます。当時の私は熱に浮かされてといいますか、課題感が先行し、正直「失敗してもいいからチャレンジしたい…！」と思っていました。そのチャレンジによって一人のビジネスパーソンとしての戦闘力は上がりますし、何かしらの経験値は得られるだろうと。

和田また、業界未経験ということだけでなく、30代後半という年齢での起業も珍しがられました。ただ僕としては、「これ以上、年齢が上がると役職もついて年収はどんどん増えていく。そうなると保身が働いて絶対にやめられなくなるな」と思い、そこを振り切るべく完全見切り発車したんです。

若気の至りというか、今だったらやらないかもしれませんね（笑）。やっぱり苦労しましたから。資金繰りの不安とか、実際に起業してみなければわからない辛さはありますよね。

和田1つ挙げるとすると、我々が現在の主力としてサービスを提供しているのは、大きな組織のお客様が中心です。過去の大組織の一員だった経験から、組織の力学を理解し、バランスを図りながらプロジェクトが進められる点です。業界を俯瞰してみると、DXの多くはトップダウンで行われており、現場の声が置いていかれがちな印象を受けます。

一方で、私はいわゆる大手企業と呼ばれる組織に十数年に渡って身を置いてきました。また、営業担当者として色々な法人のお客さまを見ることができました。そこから感じることは、「日本はとにかく現場が強い」。そうすると何が起こるかというと、総論としては賛成、各論としては反対といった状況に陥りがちです。

トップ側においては、法人営業として数多くの経営者、幹部の方々と接することで、そうしたレイヤーの方々にしか見えない世界や事情があることを学びました。また、現場という意味においては、まさにデータ分析の業務において自分にしか分からない苦労や事情がありました。

大組織の中で大きなプロジェクトを推進していく際には、ステークホルダー（トップと現場）それぞれの事情を鑑みて調和を取りながら物事を推進していく”作法”の必要性を身に染みてわかっているつもりです。

こうした経験から、トップダウンとは真逆の「現場起点でのDX」を行いながら、同時にトップも納得させるプロジェクト推進を行える点が私の強みだと考えています。ベンチャー/スタートアップの世界に身を置いていると、よく「現状の非効率な世の中を革新的に変えようぜ」というメッセージを目にしますが、現場の人間も好きで非効率な仕事をしているわけではないはずです。施策の導入よりも、まずその気持ちを理解して寄り添うことの方が重要で。「無駄を省いて効率的にしようぜ！」と意気込みだけでは、決して現場は付いてこないと信じています。

和田そこには、「物流の総量が増えているにも関わらず、人が足りていません。このままだと完全にパンクしてしまいます。アナログでやっている配車作業を、なんとかデジタル化できないか…助けてほしい」と書かれていました。これが2019年の終わり、コロナ禍が始まった直後のことです。

未曾有の事態のなか、この先は金融ですらどうなるかわからない。しかし、物流を含むエッセンシャルワーカーの仕事はなくならないだろうと思い、物流業界へのシフトを決めました。

ですので、物流に完全にピボットできたのはコロナ禍とこの1通のメールがあったからです。そうでなければ、金融から脱却できず、中途半端に事業を続けていたかもしれません。そういう意味では我々にチャンスをくれたこの物流業界に感謝していますし、少しでも恩返ししていければと思って日々クライアントに向き合っています。

和田現状のシステム構築に課題感を持っている人、レガシーが残る領域において業務フローや業界構造そのものを変えていきたいと思っている人ですね。SIerのSEやPM、ITコンサルで活躍しているような人たちをイメージしています。

プロジェクトの構築やステークホルダー間の調整に奔走し、その苦労をわかっている人がたくさんいるでしょう。

また、国内の大手SIerの下請けで切磋琢磨しているような人たちも同様に興味を持って頂けたらと思っています。つまり現場の苦闘を知っていて、そこで奮闘している人たちにジョインしてほしいです。

和田その他、パッケージ販売をしてきたなかで、課題感や物足りなさを感じている人もウェルカムです。パッケージ販売は、クライアントに対し、こちら側の仕様ややり方に合わせてもらうことであり、いわばテックタッチな関わり方になると思います。

その点、シマントではハイタッチに顧客接点を持っているので、クライアントに無理強いさせていることに違和感を抱いている人には、やりがいを感じてもらえる仕事だと思っています。企業に深く向き合い、システム開発しながら業界の課題を把握する。そこからパッケージやプロダクトの開発につなげるといった、事業開発の醍醐味を味わうことができます。

和田大企業とシマントでの課題解決に取り組むという意味では、仕事内容は本質的には同じはずです。一方で、我々の方がよりクライアントの課題解決にフォーカスする時間があるところは違うかもしれません。

大企業での仕事は、その組織構造や規模感ゆえ、どうしても内外含めた説明コストがかかっているところがあると思います。業務時間のうち、クライアントの課題解決に直結する仕事の割合はどうしても少なくなってしまうでしょう。

その点、シマントは顧客の課題にフルコミットすることができます。また、二次請けや三次請けだとクライアントと直接コミュニケーションを取る機会を与えてもらえないケースも多いですが、我々は直接顧客とやりとりしますので、提供価値への反応もダイレクトに感じることができます。

クライアント様との距離が近く、相手の不満を上手く吸収しながらプロジェクトを進められる人にジョインしていただきたいと思います。

このように必要なイシューにだけフォーカスできるところが、スタートアップの環境に身をおいてこそ、だと思いますね。