こんにちは、こんです🦊
今日は、業務のど真ん中に根を張っている「桐」という少々懐かしめなデータベースツールを活用して、在庫調整業務の精度とスピードを改善する対応を行いました。
本当は「脱・桐」を目指したい。でも現場の運用速度や属人化されたフローの中で、全体の再構築に着手するのは難しい。
だからこそ今回は、“今の仕組みを活かしつつも未来への布石を打つ” そんな応急対応です。
実験のきっかけ：属人化と“見た目”在庫のギャップ
こんなこと、起きていませんか？
📦 ECで表示されている在庫数と実際の出荷可能数が一致しない
👁 注文データを目検で確認して、数量を手打ちで差し引いていた
📉 在庫調整が毎回「誰がやるか」「どうやるか」で混乱
このままでは欠品リスクが潜在化し、業務が回らなくなると感じ、「まずは既存フローの中に自動計算の仕組みを組み込む」ことにしました。
作ってみたもの（システムの概要）
今回の主役は桐の3ファイル＋道具箱（マクロ的機能）です：
✅ 新規注文CSV.tbl
→ EC未連携の注文CSVを読み込み、品番ごとの注文数を自動集計✅ 在庫CSV.tbl
→ WMSからダウンロードした在庫データを読み込み、商品コード単位で出荷可能数を自動集計✅ 在庫増減タイプ 新規フォロー在庫読込用.tbl
→ 上記2つを併合し、「出荷可能数－未反映注文数＝本来の在庫反映数」を算出
コードは一切書いていません。桐の道具箱でデータ加工と集計を行いました。
実感したメリット
1. ✂️ 手動カウントからの解放
注文数を目で数えて手入力していた頃と比べて、格段にミスが減り、工数も1/3程度に。
2. 🧠 「在庫の見た目≠実在庫」の違和感がなくなった
今まで曖昧だった“差し引きルール”が明文化され、在庫反映の納得感が生まれました。
3. 🔜 フロー全体の構造理解が深まった
今回の修正を通して、「桐が何をしていて、何が限界か」を整理できたのが最大の収穫かもしれません。
実際の画面イメージ（処理構造）
order.csv（注文CSV）→【新規注文CSV.tbl】→ 品番単位に集計
↓ ↓
在庫状況CSV →【在庫CSV.tbl】→ 商品ID単位に集計
↓ ↓
【在庫増減タイプ.tbl】で併合＋在庫差分算出 → 差分反映CSV出力次回予告：桐に頼らずStreamlitでフローを再現するには？
今回はあくまで「延命的な改善」でしたが、次回はこのフローを桐ではなく Streamlit×Pandas×GAS などで再構成できるかの実験を進めます。
ステップ1：各CSVの構造をPythonで読み込む
ステップ2：order数と在庫の差分を計算するロジックを構築
ステップ3：EC反映用CSVを自動生成しSlack通知
「今後の脱・桐構想」に向けた布石になればと思います。
まとめ：古さは罪ではない。でも「見直す力」は必要だ
今回の改善は、あくまで 現場に合わせた一手。
使い慣れた仕組みを完全に否定するのではなく、「どうすれば移行の準備ができるか」を意識しながらの小さなアップデートでした。
「いつかやろう」ではなく、「いま動く」ことでしか道は開けない。
そんな思いで、今日もひとつ積み重ねました。
それでは、また次の実験で！🦊
#ノーコード #業務改善 #桐 #在庫調整 #ChatGPTで業務効率化 #100日チャレンジ