【キッコーマン、海外事業で収益力向上へ】「経験と勘」に頼る業務をデータで判断できるシステムに変える方法
システム化のゴールは「入力」ではなく「判断できること」
2026-09-19

企業の現場では、「この商品は売れそうだ」「この顧客にはこの提案がよい」「この時期には在庫を多めに確保したほうがよい」といった判断が、担当者の経験や勘によって行われていることがあります。
経験豊富な担当者が持つ知識は企業にとって重要な財産です。しかし、判断の根拠が個人の頭の中にしかない状態では、その担当者が異動・退職した際にノウハウが失われたり、担当者によって判断が変わったりする問題が生じます。
日本経済新聞は2026年8月26日、キッコーマンが海外の食品卸事業で倉庫管理の新システムを各国へ順次導入し、商品ごとの採算を把握しやすくすることで、経験や勘に頼った営業からの転換を進めていると報じました。すでに導入した米国では、利益率が約2ポイント向上したとしています。
ここで重要なのは、単に倉庫業務をデジタル化したという点ではありません。システムによって必要なデータを蓄積・整理し、現場の判断そのものを変えようとしている点です。
本コラムでは、経験と勘に頼っている業務をどのようにシステム化し、データに基づいて判断できる業務へ変えていけばよいのか、システム開発を検討している事業会社の担当者向けに解説します。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
目次
【記事要約】キッコーマン、倉庫管理システムで商品別採算を可視化し「経験と勘」の営業から脱却
キッコーマンは、海外で展開する食品卸事業の収益性向上に向け、倉庫管理の新システムを各国へ順次導入している。同事業では日本・東アジアの食品を中心に1万点以上の商品を扱っており、多様な需要への対応と収益管理の高度化が課題となる。新システムの活用によって商品ごとの採算を把握しやすくし、担当者の経験や勘を中心とした営業から、データに基づいて販売方針を判断する営業への転換を進める。すでに導入している米国では、利益率が約2ポイント向上したとしている。多品種の商品を扱う事業において、システムによる採算の可視化を収益改善につなげる取り組みが進んでいる。
出典:日本経済新聞「キッコーマン、現金収入1000億円視野 海外で価格支配力高く 株主還元の拡大、市場注視」2026年8月26日付朝刊
ポイントをひとことで
システム化で大切なのは、人の経験や勘をなくすことではなく、優秀な担当者が何を見て判断しているのかを明らかにすることです。売上や在庫を記録するだけでは、現場の判断は変わりません。「どの商品を売るべきか」「どこまで値引きできるか」「どれだけ仕入れるべきか」といった判断に必要なデータをすぐ確認できてこそ、システムへの投資が業務改善や利益向上につながります。機能を考える前に、現場で行われている判断を整理することが、使われるシステムを作る第一歩です。
「経験と勘」で回っている業務は多くの企業に存在する
経験や勘に依存した業務というと、特殊な職人仕事をイメージするかもしれません。しかし、実際には一般的な企業活動のさまざまな場面に存在します。
例えば営業担当者が過去の経験から値引き額を決める、仕入れ担当者が感覚的に発注数量を調整する、在庫担当者が繁忙期を予想して在庫を積み増す、といった業務です。
ほかにも、
・どの商品を重点的に販売するか
・どの顧客を優先して営業するか
・どの商品をどれだけ仕入れるか
・どの案件を受注するか
・どこまで値引きを許容するか
・どの商品を継続して扱うか
といった判断が、担当者の経験に委ねられている企業は少なくありません。
経験自体が悪いわけではありません。問題なのは「なぜその判断をしたのか」を他の人が確認できない状態になっていることです。
優秀な担当者ほど、さまざまな情報を無意識に組み合わせて判断しています。その結果だけをシステムに入力している場合、会社には結果のデータは残っても、判断に必要だった情報や考え方は残りません。
これが業務の属人化につながります。
システム化の目的は「人の判断をなくすこと」ではない
経験や勘に依存した業務をシステム化すると聞くと、「システムがすべて自動的に判断する状態」を目指すものと思われがちです。
しかし、必ずしもそこまで自動化する必要はありません。
まず目指すべきなのは、人が適切な判断をするために必要な情報を、必要なタイミングで確認できる状態です。
例えば営業担当者がある商品を顧客へ提案するとします。
従来は「この商品はよく売れている」という経験だけで提案していたとしても、システム上で、
・商品の売上
・仕入価格
・物流費
・値引額
・返品率
・在庫回転率
・顧客別の購入履歴
などを確認できれば、判断は変わります。
売上が大きくても物流費や値引きが多く、実際には利益がほとんど残っていない商品かもしれません。
反対に販売数量は少なくても、利益率が高く継続購入されている商品もあります。
人の判断をシステムに置き換えるのではなく、「判断に必要な材料をシステムが提供する」という考え方が重要です。
売上だけでは「本当に儲かっている商品」は分からない
商品やサービスを多数扱う企業では、売上データだけで業績を判断してしまうことがあります。
しかし、売上が大きい商品が必ずしも利益を生み出しているとは限りません。
例えば商品Aと商品Bがそれぞれ100万円売れていたとしても、仕入原価、物流費、保管費、販売手数料、値引きなどを差し引けば、最終的に残る利益は大きく異なる可能性があります。
そのため、商品ごとの採算を把握するには、売上情報だけではなく複数のデータを組み合わせる必要があります。
問題になるのが、これらの情報が別々のシステムやExcelに分散しているケースです。
売上は販売管理システム、仕入れは基幹システム、在庫は倉庫管理システム、営業活動は営業管理ツール、物流費はExcelといった状態では、商品単位の利益を確認するためにデータを集めて加工しなければなりません。
集計に時間がかかれば、現場では結局「そこまで調べるより経験で判断したほうが早い」となってしまいます。
経験や勘から脱却するには、データを蓄積するだけではなく、業務上の判断に使える形でデータをつなげることが重要です。
「何を見れば判断できるのか」を先に整理する
データ活用を目的としたシステム開発では、「どんな画面を作るか」「どんな機能を搭載するか」から考え始めるケースがあります。
しかし、その前に整理したいのが「現場では何を基準に判断しているのか」です。
例えば商品別の採算を把握したいのであれば、「商品ごとの利益をどのように計算するのか」を決める必要があります。
売上から仕入原価だけを差し引くのか、物流費まで含めるのか、倉庫保管費をどう配賦するのか、値引きや返品をどのように扱うのかによって数字は変わります。
さらに営業判断に利用するのであれば、「利益率が何%以下なら販売方法を見直す」「在庫回転率が一定水準を下回ったら仕入れを調整する」など、数字をどのような行動につなげるかも考える必要があります。
つまり、システム開発の前に、
「現在、人は何を見て判断しているのか」
「本来は何を見て判断すべきなのか」
「その情報はどこに存在しているのか」
を整理する必要があります。
ここが曖昧なままでは、データを大量に集めても現場で使われないシステムになりかねません。
データは「蓄積する」だけでは意味がない
企業ではシステム導入によって大量のデータが蓄積されています。
ところが、そのデータが十分に活用されていないケースもあります。
典型的なのが、業務システムが「入力するためのシステム」になっている状態です。
営業担当者が受注情報を入力する。在庫担当者が入出庫情報を入力する。経理担当者が売上や原価を入力する。それぞれの業務はデジタル化されていますが、そのデータが次の判断に活用されていません。
これでは紙やExcelをシステムに置き換えただけです。
データ活用を前提とした業務システムでは、
入力する
↓
蓄積する
↓
組み合わせる
↓
可視化する
↓
判断する
↓
行動する
という一連の流れを考える必要があります。
例えば商品別利益率を一覧表示し、利益率の低い商品をすぐ確認できれば、営業担当者は販売価格や値引き、仕入れ条件などを見直せます。
在庫回転率と利益率を組み合わせれば、「売れているが利益が少ない商品」「販売量は少ないが利益率が高い商品」なども把握できます。
データを業務改善につなげるには、「集めた後にどう使うか」まで考えたシステム設計が必要です。
現場の経験はシステム化するための重要な材料になる
経験や勘から脱却するからといって、ベテラン担当者の経験を否定する必要はありません。
むしろ、その経験こそシステムを作るための重要な材料になります。
例えば優秀な営業担当者に「なぜこの商品を提案したのですか」と聞いても、最初は「経験です」と答えるかもしれません。
しかし詳しく確認すると、
「この業種ではこの時期に需要が増える」
「この顧客は価格より納期を重視する」
「この商品は返品が少ない」
「この組み合わせで販売すると利益が残りやすい」
といった判断基準が見えてくることがあります。
こうした暗黙の判断基準を一つずつ整理し、必要なデータを特定していくことで、個人のノウハウを会社全体で利用できるようになります。
重要なのは「経験を排除すること」ではなく、「経験の中にある判断材料を見えるようにすること」です。
フルスクラッチが向いているのは「自社独自の判断」が多い業務
データを活用するシステムは、必ずしもフルスクラッチで開発する必要はありません。
一般的な販売管理、在庫管理、会計管理などであれば、パッケージやSaaSで十分対応できるケースもあります。
一方、自社独自の業務ルールや判断基準が競争力になっている企業では、既製システムに業務を合わせることが難しい場合があります。
例えば、
・独自の商品分類がある
・特殊な価格決定ルールがある
・顧客ごとに原価計算方法が異なる
・複数拠点の在庫を独自ルールで配分している
・営業担当者独自の判断基準をシステムに反映したい
・複数システムのデータを組み合わせて採算を算出したい
といったケースです。
こうした業務では、「一般的な業務を効率化するシステム」ではなく、「自社がどのように判断しているか」を反映したシステムが必要になります。
フルスクラッチであれば、自社の業務フローやデータ、判断基準に合わせて必要な機能を設計できます。
ただし、最初からすべてをシステム化する必要はありません。
まずは商品別採算の可視化、次に営業判断への活用、その後に発注や在庫管理との連携というように、効果を確認しながら対象範囲を広げていく方法もあります。
システム開発会社には「何を作るか」だけを伝えない
経験や勘に頼った業務をシステム化する場合、システム開発会社への伝え方も重要です。
「商品別の利益を表示する画面がほしい」
「在庫を一覧表示したい」
「ダッシュボードを作りたい」
という機能だけを伝えると、本来解決したかった業務課題が十分に共有されない可能性があります。
それよりも、
「営業担当者によって販売する商品が変わっている」
「売上は把握できるが商品ごとの利益が分からない」
「毎月Excelでデータを集計しないと採算が分からない」
「ベテラン担当者しか適正在庫を判断できない」
といった現場の困りごとを伝えることが大切です。
システム開発では、機能を決める前に「なぜその機能が必要なのか」を明確にすることで、より実務に合った設計ができます。
特にフルスクラッチ開発では、既存製品の機能に業務を合わせるのではなく、業務課題から必要な仕組みを考えられることが大きな特徴です。
まとめ
経験や勘による判断は、長年の業務で蓄積された貴重なノウハウです。一方で、その判断が特定の担当者にしかできない状態では、属人化や判断のばらつきにつながります。
重要なのは、人の経験をすべてシステムに置き換えることではありません。
まず「何を基準に判断しているのか」を明らかにし、その判断に必要なデータを蓄積・整理し、必要なタイミングで確認できるようにすることです。
売上、原価、在庫、物流費、顧客情報などを組み合わせれば、これまで感覚的に行っていた判断を数字で確認できるようになります。
さらに、商品別採算や在庫回転率などを日々の営業・仕入れ・在庫管理に活用できれば、業務システムは単なる記録のための道具ではなく、利益を生み出すための判断基盤になります。
「担当者がいないと判断できない」「Excelを集計しなければ採算が分からない」「売上は分かるが何が本当に儲かっているのか分からない」といった課題がある場合は、機能を考える前に、現在どのような情報をもとに人が判断しているのかを整理することが、システム化の第一歩です。
さいごに
経験や勘に頼っている業務をシステム化するためには、単に既存の作業をデジタルに置き換えるだけでは十分ではありません。「担当者は何を見て判断しているのか」「どのデータがあれば、より適切な判断ができるのか」を整理し、実際の業務に合ったシステムへ落とし込むことが重要です。
特に、商品ごとの採算管理や独自の営業判断、在庫・仕入れのルールなどは企業によって異なります。一般的なパッケージやSaaSでは自社の業務に合わせにくい場合、フルスクラッチ(オーダーメイド)でシステムを開発することで、自社独自の業務や判断基準をそのまま活かした仕組みを実現できます。
当社フレシット株式会社では、フルスクラッチのシステム開発を専門とし、お客さまのご要望をそのまま機能にするのではなく、現在の業務や課題、システム化によって実現したいことを整理したうえで、必要な機能をご提案しています。
「ベテラン担当者しか判断できない業務を見直したい」「Excelや複数のシステムに分散したデータを活用したい」「自社独自の判断基準に合ったシステムを作りたい」とお考えの場合は、ぜひ当社フレシット株式会社へご相談ください。自社の強みや現場のノウハウを活かしながら、データに基づいて判断できる業務システムの実現を支援いたします。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
著者プロフィール
フレシット株式会社 代表取締役 増田順一
柔軟な発想でシステム開発を通して、お客さまのビジネスを大きく前進させていくパートナー。さまざまな業界・業種・企業規模のお客さまの業務システムからWEBサービスまで、多岐にわたるシステムの開発を手がける。一からのシステム開発だけでは無く、炎上案件や引継ぎ案件の経験も豊富。システム開発の最後の砦、殿(しんがり)。システム開発の敗戦処理のエキスパート。

公式Xアカウントはこちら