【前編】経理が作る物流システム！？未完成のプロトタイプが思わぬ化学反応を起こした話

こんにちは！経理部でAI活用を推進しているがっきー課長です。

「課長、物流コストの分析できない？
 運送会社ごとにバラバラで、全然実態が掴めないんだよね...」

物流部長からの突然の依頼。

（えっ、なんで経理？
 ...あ、でも原価計算みたいな感じか。
 確かに経理の仕事といえば経理の仕事...？）

プロトタイプ駆動な経理の流儀

普通のシステム開発なら：
1. 要件定義
2. 基本設計
3. 詳細設計
4. 製造・テスト

でも私がやったのは：
1. 軽い打ち合わせで、ざっくり要件把握
2.とりあえずコードを書く
3. 動くものを見せる
4. 「ここはどうします？」と聞く
5.具体的な要件が見えてくる

（生成AIに手伝ってもらえば、
 コードを書くのは意外と簡単でした）

未完成だからこそ見えてきた課題

例えば、こんなコードを見せたら...

// 未マッチ運賃の内訳を表示
unmatchedSheet.getRange(1, 1, 3, 2).setValues([
  ["総額", totalFreightCost],
  ["マッチング金額", matchedFreightTotal],
  ["残金額", unmatchedAmount]
]);

物流部長「あれ？この残った運賃...」

部長の指摘で判明した問題：
- 倉庫間移動の運賃が混ざってる
- データの粒度が会社ごとに違う
- 重量の丸め方が統一されてない

（これ、事前ヒアリングじゃ絶対出てこなかった...！）

予想外の展開

プロトタイプを見せた結果：

1. 具体的な議論が始まった

// エラーログの例
logMessages.push(`⚠️ 未一致: Row ${i + 1}`);

「このエラー、実は想定内かも」
「でもこっちのパターンは要対応だね」

2. 優先順位が見えてきた
- 倉庫移動は除外→按分の方法を別途検討
- 重量の丸め→0.1kgの誤差まで許容することに
- データ形式→各社と要調整

3. 新機能の種が見つかった

// 着日の補完ロジック
if (currentGroupId) {
  dateCache[currentGroupId] = currentDate;
}

「このロジック、他でも使えそう！」

経理ならではの進め方？

考えてみると、経理の仕事って、
“完璧なものを最初から作る” んじゃなくて
“まず数字をざっくり出して、そこから精度を上げていく” という作業が多い。

例えば、経費精算のルールを決めるときも、
『とりあえずルールを作って試してみる』
→ 『実際に運用してみたら例外が発生する』
→ 『その都度調整する』 の繰り返し。

これって、今回のプロトタイプ開発と同じじゃない？

最初から完全な仕様を決めるんじゃなく、
とりあえず作ってみて、そこから調整する。
…経理とシステム開発、実は同じ発想で動いてるのかも？」

その後...

物流部との打ち合わせを重ねて：
- 倉庫移動用のフラグを追加
- データ形式の違いに対応
- 重量の丸め処理を統一

「課長、他のシステムも
 この進め方でやってみない？」

（えっ、また増えるの...？）

次回予告

「経理なのに社内SE!? "便利な人"扱いを回避する防衛術」

「課長、次のシステムも作ってもらえない？」
営業役員の言葉は軽かった—
だが、そこには深い闇が隠されていた。

効率化しても、なぜか仕事が増える。
スキルが上がっても、評価は変わらない。
月次決算を抱える経理マンは、
いつの間にか全社の便利屋に...？

次回、効率化する人が報われる世界を目指して、
ある防衛戦略を実行する。

次回「AIスキルの代償」編、お楽しみに！

#経理で情シス #業務効率化 #知らんけどDX