6. 伊藤忠商事のデータ活用の仕事内容 食品卸の発注を例に、分析から運用までを追う
予測が「明日は17個」と答えても、発注書にはそのまま書けないことがあります。メーカーが受け付けるのはケース単位で、卸の倉庫には昨日の在庫もあるからです。伊藤忠商事と日本アクセスの食品流通の事例では、小売と卸のデータを使って発注の推奨値を計算し、既存の発注システムに渡しました。予測を仕事にするとはどういうことか、現場に渡る成果物から見ていきましょう。
実際に変わったのは、日本アクセスからメーカーへの発注
2021年2月の発表の対象は、消費者が店頭で行う購入でも、小売店が問屋に出す注文でもありません。食品卸の日本アクセスがメーカーに出す注文です。伊藤忠商事、日本アクセス、伊藤忠テクノソリューションズ（CTC）、ブレインパッドが連携した実証では、一部の物流拠点で在庫削減と発注業務の効率化を確認し、対象拠点を広げる方針を公表しました。発表は企業間の取り組みを説明しており、個々の社員の職務分担までは示していません。
以下では、この公表事例を手掛かりに、同種の案件を進めるときに必要になる仕事を順に考えます。誰が注文を決めるのか、どの時点の情報で計算するのか、どんな形で渡すのか。三つの問いに答えていくと、分析、業務設計、システム開発の担当が協力する理由がわかります。
課題整理で作るのは、現場と合意できる判断基準
発注担当者に「何に時間がかかるか」と尋ねるとします。全商品の数を毎日計算し直すのが重い場合と、特売前後の例外だけに時間を取られる場合とでは、効果的な道具は異なります。前者なら日常の発注候補をまとめて示す方法、後者なら注意すべき商品を絞り、理由を説明する方法が考えられます。
この段階の成果物は、現行の手順と変更したい判断を示す一枚の業務図です。「注文を締める時刻」「推奨値を確認する人」「欠品が許されない商品」といった制約も書き込みます。在庫の圧縮を目標にするなら、同時に欠品をどう監視するかを決めます。倉庫担当者や仕入れ担当者と目標を共有して初めて、分析側がどの誤差を小さくすべきかを決められます。
データの整備で作るのは、明日の判断を再現できる表
公表された食品卸の仕組みでは、小売の売上・在庫・発注、卸の入出荷・在庫・商品ごとの発注ロットに、天候やカレンダー情報を組み合わせています。商品が店頭で売れる動きと、物流拠点から出荷される動きは別です。複数のデータを扱う意味は、売れ行きと補充の流れを結び付けられるところにあります。
同種の案件なら、データを管理する部門と「一行の意味」を確認します。たとえば出荷日と納品日は同じ商品でも異なり、箱数と個数の違いもあります。後日訂正された在庫を、当日にわかっていた値として過去の予測に使うと、実際より成績が良く見えます。取得日時と対象日を区別したデータ項目表、欠損や重複を調べた記録が、次の担当者に渡す成果物です。
伊藤忠商事には、コンサルティング、データ収集、蓄積、集計、分析を支える内製組織ITC BICCがあります。この説明から、本体にデータ整備や分析を支援する機能があるとわかります。ただし、食品卸の案件でどの商品コードを誰が統合したかまで、公表された組織説明から割り当てることはできません。
予測・可視化の成果物は、現場が試せる判断材料
最初の比較相手には、現場で使っている発注ルールや先週の実績を置けます。計算した予測と実際の数量を日付順に並べ、よく外す商品群を特定します。全体の平均誤差が下がっても、主力商品で欠品が増えるなら、そのまま採用することは難しいでしょう。評価表には平均値のほか、どの商品に、どちら向きの誤差が出やすいかを残します。
すべての問題に予測が要るわけでもありません。伊藤忠商事が2024年7月にグループ企業向けに提供を始めたサプライチェーン改善支援では、配送時間や倉庫作業の人件費、滞留在庫などを可視化しています。画面を手掛かりに課題を診断し、改善後にも定期的に点検できるサービスです。拠点の違いが見えるだけで、次に調べるべき工程を絞れる場面があります。
たとえば配送が遅い倉庫を見つけたとして、積み込みの順番を変えるべきか、出荷指示が遅れているのかは、時間の合計だけでは判断できません。作業を知る人にグラフを見せて、どの時刻の記録を追加すべきか決めます。利用者の解釈を聞いたうえで指標を直すことも、分析の仕事の一部です。
実装では、予測値と業務の指示を区別する
食品卸の事例では、メーカーが指定するロット単位で発注の推奨値を求め、既存の発注システムに転送しています。モデルが出す需要と、発注システムが受け付ける数量の間には変換があります。発表資料から確認できるのは、この業務上の接続です。人の確認を経ずにすべての注文が確定するかどうかまでは、この記述からは決まりません。
たとえば、推奨数量を別システムに渡す仕事なら、商品コード、納品先、対象日、単位が相手側の仕様に合うかを確かめます。同じ注文を送り直しても二重に処理されないか、締め切り前に計算が終わらない日は担当者が従来の手順に戻れるかも論点です。分析側が計算の前提を、開発側が受け渡し方法を、現場が例外時の判断を持ち寄ると、試験項目が具体的になります。
部門間で受け渡す成果物は、結果のファイルだけではありません。入出力の仕様書、正常な注文と例外注文の見本、現場が確認した受け入れ条件も含まれます。CTCの中途向け開発職の求人では、顧客への提案やアプリケーション開発、品質管理などが実際の業務例として挙がっています。このような職種の説明は、企業のDX事例の中から個人が担いうる仕事を見極める別の手掛かりです。
本体の社員が手掛けた業務アプリの例
伊藤忠商事の採用サイトには、取材当時のIT・デジタル戦略部の社員が、顧客や商談を管理するアプリの開発に携わったと話す記事があります。本人が語っているのは、自社やグループ会社の業務改善と、社内のセキュリティを守りながら開発する難しさです。発注のプロジェクトとは別の、個人の担当が読み取れる例です。
利用者が記録した商談を集計に使うには、入力する側が無理なく続けられることも重要です。たとえば「商談中」と「受注見込み」の境界が人によって違うなら、入力欄を増やす前に営業側と定義を合わせます。アプリの動作と、そこで生まれる記録の品質を一緒に考える仕事があることを理解できます。
運用・改善では、予測の誤差と使われ方の両方を見る
運用後の点検は、記録が届いたか、計算が予定どおり終わったかを確かめるところから始まります。次に、担当者が推奨を採用した割合や、修正の多い商品を見ます。修正が多い日には、現場だけが知る販促や取引条件があったのかもしれません。修正を一律に誤操作と扱うと、有力な改善の手掛かりを失います。
業務効果を報告する際には、作業時間、在庫、欠品を分けて追います。在庫の減少が予測の改善によるものか、品ぞろえの変更や繁忙期によるものかを考え、比較する期間や拠点の条件を合わせます。効果を確認できなかったときにも、入力データ、判断ルール、利用手順のどこを直すかを明確にできれば、次の試行につながります。
引き渡し後に現場が自力で点検するなら、点検結果の保管先と、異常を誰に知らせるかも決めておきます。判断の記録を残すと、次の繁忙期に同じ例外が起きたとき、当時なぜその対応を選んだかを確認できます。
仕事内容を詳しく知りたい人は、募集要項や面談で「最初に受け取るものと、最後に渡すもの」を聞いてみてください。課題の相談から始めて検証計画を渡す仕事、整備済みのデータを受け取り予測を渡す仕事、推奨値を受け取り運用可能な仕組みを渡す仕事では、一日を通して向き合う相手が違います。希望する工程を具体的にすれば、企業の取り組みの中に自分が担いたい仕事を見つけられます。