4. 伊藤忠商事・CTCのデータ活用を題材に学ぶプログラミング SQLとPythonで発注予測を試す
データ分析のために一つ制作物を作るなら、SQLで正しい集計を作り、Pythonで予測を比べ、翌日も同じ手順で結果を出せるところまで試してみましょう。伊藤忠商事と日本アクセスが公表した発注支援では、予測結果を発注単位に直し、既存システムに渡しています。ここから学べるのは、モデルの手前と後ろにもプログラミングの出番があることです。
企業が公表した技術と、自分が学習に選ぶ道具
伊藤忠商事はデータ統合基盤HANABIや、内製組織による収集・集計・分析支援を公表しています。基盤名から、担当者が使う言語やライブラリまでは特定できません。また、伊藤忠テクノソリューションズ（CTC）の中途求人「開発分野・システムエンジニア（事業グループ不問）」の必須欄は言語を限定せず、設計を含むプログラミング経験を求めています。これは顧客向け開発職の求人です。
ここでSQLを取り上げるのは、複数の表から必要な記録を取り出して集計するのに適しているためです。Pythonは、集計結果の点検、グラフ作成、複数の予測方法の比較を一つの手順にまとめられます。以下は架空の食品店を題材にした自主学習例です。社内のシステム構成や採用試験の内容を再現したものではありません。
練習の出発点は、ファイル三つと業務上の問い一つ
明日一日で何個売れるかを、今日の閉店時に見積もるとします。商品は少数で十分です。「販売明細」には日付・店舗・商品・数量、「店舗別在庫」には日付・店舗・商品・閉店時在庫、「商品台帳」には商品・ケース当たり個数を持たせます。最初に作る成果物は予測値ではなく、各表の一行が何を表しているかを書いた短い説明です。
販売明細では、同じ日に同じ商品が二度売れれば二行になります。閉店時在庫は、同じ日・店舗・商品で原則一行です。台帳の個数は商品ごとに一つと仮定します。この違いを決めておくと、次の集計で売上が二重になったときや、在庫が販売回数分だけ膨らんだときに原因を探せます。
SQLで、結合する前の数を確かめる
まず販売明細を日付・店舗・商品でまとめ、数量を足して日別販売表を作ります。その後で在庫を結び付けます。明細の各行に閉店時在庫を付けてから在庫を合計すると、同じ在庫を何度も数えます。たとえば二回の販売後に棚に三個残っていたなら、閉店時在庫は三個です。合計六個と出る集計には、表の結び方に問題があります。
SQLのGROUP BYは同じキーの行をまとめる操作、JOINは共通の項目で表を結ぶ操作です。どちらも、結果の行数を見るだけでは正しさを確認できません。結合の前後で販売数量の総計が一致すること、在庫側に重複キーがないこと、商品台帳に見つからない商品が一覧に出ることを確かめます。この三つを小さな確認用の問い合わせとして残しましょう。
欠けた行と、販売ゼロの行を区別する
店休日、営業したが一個も売れなかった日、記録の取り込みに失敗した日は、販売明細だけでは同じ空白に見えます。学習用には営業予定表を追加し、取り込み済みの日に限って無販売をゼロにします。在庫切れがわかる日には印を付けます。その日の販売数からは、棚に商品があった場合にいくつ売れたかまではわからないからです。
Pythonで、予測より先に外れ方を見る
日別販売表を読み込み、日付を横軸にして販売数量を描きます。全店合計の線だけでなく、一店舗・一商品の線も見てください。まとめると目立たない欠落が、個別に見ると毎週同じ曜日に生じているかもしれません。点検の結果、店舗コードの変更で系列が分断されていたなら、その修正はモデルを複雑にすることより先です。
予測の一つ目は「先週の同じ曜日と同じ数」とします。二つ目は直近数週間の同曜日の平均にします。学習に使う期間と評価する期間を時間順に分け、予測を出す時点で手元にあった記録だけを使います。明日の実際の天気や当日の閉店時在庫を説明変数に入れると、過去の成績だけが不自然によくなります。
予測値と実績の差の絶対値を平均すれば、平均して何個外したかを示せます。そこからもう一歩進めて、実績より少なく予測した日を数えましょう。誤差の絶対値が同じでも、余らせやすい予測と足りなくなりやすい予測では発注担当者への意味が違います。よく外れた三日をグラフに戻し、欠品や販促の記録と照らして短い考察を添えます。
評価結果は、あとから他の人が検算できる形で保存しましょう。一行に予測日、店舗、商品、二つの方法の予測値、実績値を並べておくと、商品ごとの誤差を再計算できます。加えて、開店直後で過去の同曜日がまだ存在しない店舗を一つ用意してみます。予測が出ない日を黙って除くと成績を良く見せてしまうので、予測できた件数も併記します。現場で使える範囲を評価表から読み取れるようになります。
結果を「何ケース注文するか」に変換する
仮に翌日の予測が17個、手元の使用可能在庫が5個、入荷予定はゼロ、1ケース6個とします。翌日分だけを補う単純な設定では不足は12個で、提案は2ケースです。予測が18個なら不足13個を満たすには3ケース必要です。たった1個の予測差で、仕入れは6個変わります。モデルの誤差だけを見ていると、この段差を見落とします。
この計算例では納期や安全在庫を省略しています。翌日までに届かない商品がある場合は、何日先までの需要を合計するかから決め直します。商品を箱からバラに換算する場所を一カ所にし、在庫が十分ならゼロ、ケース数が欠けている場合は要確認、と期待する動作を書いてテストします。予測と発注ルールを別々に直せる作りにすれば、どちらの変更で結果が変わったか追えます。
再実行して初めてわかる、分析担当と基盤担当の違い
分析担当が見たいのは、同じデータで同じ評価が得られたかです。元の架空データ、分割した日付、使用したライブラリの版、実行手順を残します。Gitのようなバージョン管理を使う場合は、「欠品日の除外」「ケース単位への丸め」と変更理由ごとに記録すると、成績が変化した理由を後から検証できます。
データ基盤の担当を目指すなら、同じ日の処理を二度実行する練習が役立ちます。単純な追記では今日の販売が二重に入るため、日付・店舗・商品の単位で置き換えるなどの対策が要ります。入力が途中で届かなくなった場合にも、完成していない結果を利用者に公開しない方法を考えましょう。行数と最終更新日時を出力するだけでも、翌朝の点検がしやすくなります。
AI開発に関心がある人は、計算結果を受け取る側との取り決めを作ります。商品コード、対象日、予測個数、推奨ケース数、計算日時、例外の理由を出力に含め、画面や別のプログラムが読み取れるようにします。新しいモデルが従来の方法を下回った場合に元へ戻せるかも試せます。小規模な課題なら、手元の環境で更新と復旧を実演するだけでも、運用の考え方を示せます。
動作確認には、答えが手で計算できる一日を使う
架空データの中に一日だけ、正解がわかる記録を入れます。二つの店舗で同じ商品が売れ、片方には在庫が十分あり、もう片方は一ケース補充する設定です。全店の合計は合っていても、店舗コードの取り違えで発注先を逆にする不具合は起こりえます。期待する店舗別の推奨値まで書いておけば、集計方法を変更した後も検出できます。さらに入荷予定を一件追加し、該当店舗だけで推奨が減ることを確かめれば、ルールの依存関係も説明できます。
完成の目安は、別の人が予測を作り直せること
最後に、新しい一日分の販売明細を加え、最初から実行し直します。友人に結果を渡して「なぜこの商品は三ケースなのか」と聞いてもらいましょう。元データ、集計、予測、発注条件のどこからでも答えをたどれれば、学んだ技術が一本の業務につながっています。応募先に合わせて、分析志望なら評価表、基盤志望なら再実行の試験、開発志望なら入出力と例外処理を見せると、自分の得意分野が伝わります。