GAS × 生成AIで在庫会議資料を1クリック作成！経理マン奮闘記

プロローグ：突然の呼び出し

「ちょっと時間ある？」

（この"ちょっと"が、本当にちょっとで済んだ試しはない…）

営業役員が私のデスクにやってきた。普段は伝票や月次決算と向き合う経理マンだが、役員の「改革」スイッチが入ると話は別。案の定、会議室で在庫管理の非効率さを延々と説明される羽目に。

「各課がバラバラに資料作って時間かかりすぎやろ？もっと効率よくできへん？」

カレンダーを見ると、毎月「在庫会議の資料作成」が各課長のスケジュールを4時間ずつ拘束している。本人たちはそれを当たり前だと思っているから、誰も疑問を持たない。

でも、役員の一言で火が点いた。まるで未確認生物を発見したときのTV番組みたいだ。

（さて、今回は何をやらされるんだろうか…）

第一章：謎の資料に隠れた可能性 ― 残業仲間が握っていた"禁断の知識"

「実際の在庫会議の資料、見せてもらえます？」

「ちょっと待って、●●課長を呼ぶわ」 役員が呼び出したのは、
システムに強い営業マンだった。
彼の説明では、どうやら各課でみんな作り方が違うらしい。

そこで、いつも残業している仲間の営業課長にも話を聞いてみた。
「え？うちは基幹システムの販売予定入力画面から必要項目を入力して、Excelに出力してるよ。あとは手作業で複数帳票を結合して…」

（！？）

その瞬間、私の中で何かが閃いた。 販売予定入力画面。
他の営業マンは知らないその機能。
そこに入力された項目は、すべて基幹システムから漏れなく抽出できる。

在庫金額、数量、単価、市況価格、販売予定先、賞味期限…
今まで手作業で集めていた情報が、実はすべてあそこに入っていたんだ。

（これは、行ける…！）

第二章：要件定義は後回し、走りながら考えろ ― プロトタイプ思考のススメ

会議室を出て、自席に戻るや否や、私は早速PCの黒画面（コードエディタ）を立ち上げていた。

「課長、もう作ってるんですか？」
営業マンが驚いた表情で覗き込んでくる。

「いや、まだ試作だよ。まずは動くものを作ってみるのが早いんだ」
私はコーヒーをすすりながら、次々とコードを書き込んでいく。

（要件定義？そんなものは後でいい。まずは形にして、話を前に進めるのが最優先だ）

最初は、基幹システムから出力したExcelファイルをGASで読み込む、というシンプルな目的だった。
だが、そこに「データを自動で加工してほしい」とか、「結果を見やすくまとめてほしい」といった要望が次々に追加され、気づけば試行錯誤の連続に。
必要な機能を片っ端から追加していった結果、コードはどんどん膨れ上がっていった。

そのときの私には、「とりあえず動けばいい」という思いしかなかった。

// 在庫データを取り込む（2週間前のコード。今見ると読みにくいな。）
function importInventoryData() {
  showProgressDialog(); // 進捗ダイアログ

  try {
    updateProgress('最新のExcelファイルを検索中...', 'フォルダを確認しています');
    const folder = DriveApp.getFolderById(SOURCE_FOLDER_ID);
    const xlsFiles = folder.getFilesByType(MimeType.MICROSOFT_EXCEL);

    if (!xlsFiles.hasNext()) {
      throw new Error("Excelファイルが見つかりません。");
    }

    // 最新ファイルを取得（本当にこれで正しい？）
    let latestFile = getLatestFile(xlsFiles); // 名前が曖昧で分かりにくい
    updateProgress('Excelファイルを読み込み中...', latestFile.getName());

    // ここから先は何をやっているかよく分からない処理の塊
    processData();               // データ変換
    updateInventoryStatus();     // ステータス更新
    calculateTotalValues();      // 合計値計算
    createSummarySheets();       // サマリー作成
    markWarningItems();          // 警告アイテム追加
    // ...まだまだ続く（自分でも把握できていない）
  } catch (error) {
    // エラーをそのまま投げっぱなし（後で直すつもりだった）
    console.error('エラー詳細:', error.stack);
    updateProgress('エラーが発生しました', error.message, { isError: true });
  }
}

// 心の声：
// 「何これ、読むだけで疲れる...」
// 「関数名が何をやっているのか伝わらない…」
// 「データ処理もステータス更新も1つの関数に詰め込むのはまずかったな」

私の経験では、AIに相談するときは "具体的" であるほど良い。

• 画面のスクショを説明に添える

• Excelの構造を細かく伝える（列名や期待する行数など）

• エラーメッセージをそのまま貼り付ける

• 最終的に「どういう動作をしてほしいか」ゴールを明確にする

• （今ならわかるけど）途中で機能を整理する

要件定義をすっ飛ばすリスク？もちろんある。だけど、販売予定入力画面という"正解"がわかっているし、「動くもの」を先に作るメリットのほうが大きいと踏んだ。

---

第三章：初のお披露目とプログレスバーの衝撃

― 会議室の空気が変わる瞬間

数日後、営業役員が「次の在庫会議で試しに使ってみようや」と言い出す。
私は密かに作ったツールを持参。基幹システムとExcelデータを掛け合わせ、スプレッドシートに一発でまとめてくれる仕掛けだ。

会議が始まると同時に、「まだ資料できてへんやろ？」と
他の営業課長たちが不安そうにこっちを見ている。
しかし、私はスクリプトをポチッと起動。

すると画面にプログレスバーが現れた。

データを読み込み中... (512件) 
在庫ステータスを判定中...
シートを分割中... 
体裁を整えています...(もうちょっと！)

裏ではコードが列を追加して計算式を仕込み、

• 色を塗って重要在庫をハイライト、

• 列見出しを90度回転させ幅を圧縮し、

• 複数のシートを生成して会議用にまとめ上げ…

• まさにスクリプトが“資料を作っている”様子が目に見えるのだ。

会議室の空気が変わった。
営業役員を含め、みんなが画面に食い入るように見守っている。
「お、いま '在庫ステータスを判定中...'って出てるぞ」
「どんなふうに判定してんだ？」と、
まるでアトラクションの実況が始まったかのようだ。

たった1～2分後、結果が表示される。
「え、もう資料できたの？」
「項目行がスマートに回転してる！」
「重要在庫が黄色で塗られてる…」など、驚きの声が上がる。

私の心の声：
（“進捗表示”って、こんなに人を安心させるんだな…）

---

第四章：要望という名のカスタマイズ地獄

会議が終わると同時に、要望の嵐が吹き荒れた。

• 「賞味期限30日以内は要警告にしてほしい」

• 「今月中に売れそうな在庫は別色で」

• 「回転率が低い在庫を洗い出す機能を」

• 「営業メモが勝手に日付変換されて困る！」

• 「列の順番、やっぱり元に戻して...」

（え、順番？前に「これがいい」って言ったの誰だっけ…）

要件定義をすっ飛ばしたので、そりゃこうなる。
でも、それは”本気で使ってくれるからこそ出る要望”だと私は思っている。

私は自席に戻ると、とりあえず思いつく限りのアイデアをコードに詰め込んでいった。

「さっきの要望、これで動くはず……」

次々と新しい関数を追加し、試行錯誤の末に作り上げたコードは、もはや自分でも把握しきれないほど複雑になっていた。

// （当時の一部コード例。さらに機能を追加していった結果…）
function processInventoryUpdates() {
  try {
    addExpiryWarnings();  // 賞味期限チェック
    highlightSlowMovingStock();  // 回転率低い在庫を強調
    applyCustomSortOrder();  // 列の順番変更
    fixDateConversionIssues();  // 日付の変換問題修正
    colorCodeForecastedSales();  // 売れそうな在庫を色分け
    // ...際限なく増える関数群
  } catch (error) {
    console.error("処理中にエラーが発生しました:", error);
  }
}

「今、何が動いていて何が壊れてるのか、わからない……」

気づけば、進捗バーの動きだけが頼りになっていた。 バーが進むたびに「うん、大丈夫そうだな」と自分に言い聞かせるけれど、その裏側でコードはぐちゃぐちゃに絡まり合っていく。

会議室で見せた「動くもの」は好評だった。
しかし、それと引き換えに、私はコードというブラックボックスを手に入れてしまった。

しかし、この状態で手を止めるわけにはいかなかった。
ツールがただ「動く」だけではなく、「役に立つもの」になるためには、次の一歩を踏み出す必要があったのだ。

---

第五章：在庫ステータス付与がもたらした会議革命

さらに、私が「これは会議時間を短縮できるかも」と目を付けたのが、在庫ステータスの自動付与機能。

「会議資料の作成に時間がかかってる割に、会議の効果が見えにくい」
って、役員のボヤキをそのままAIに入力した結果、提案された機能。

// ステータス付与のための閾値設定
const WARNING_THRESHOLD = {
  保管期間: 8,     // 8期以上は要注意
  賞味期限: {
    生鮮品: 10,   // 10日以内は要警告
    冷凍品: 90     // 90日以内は注意
  }
};

// 問題のある在庫にステータスを付与
function addStatusAndPolicyColumns() {
  // 実際はもっと複雑な条件を組み合わせ...
  const formula = 
    `=IF(AND(NOT(ISBLANK(${colRef(colIndexes.賞味期限)}2))),
      IF(OR(
        AND(
          NOT(ISBLANK(${colRef(colIndexes.期数)}2)), 
          ${colRef(colIndexes.期数)}2 >= ${LONG_TERM_PERIOD}
        ),
        // ...（他の条件も続く）
      ),
      "⚠ 要対応",
      ""),
    "")`;
}

たとえば、賞味期限が近かったり保管期間が長すぎる在庫には「⚠ 要対応」のステータスを自動で付ける。
会議資料に何百行あっても、ステータスが空欄＝問題なしなので飛ばしてOK。
これだけで、説明する行数が激減し、会議時間も30％ほど短縮された。

「お、黄色いマークがあるのはこことここだけ？」
「じゃあ、ここを中心に話そうか」

会議のやり方が変わった。全行をダラダラチェックするのではなく、
"問題在庫"だけを集中的に議論するモードへ移行。
本当に、仕事の流れが変わり始めたのを感じた。

---

第六章：20万円の価値、そして着実な一歩 ― 新たな可能性への入口

2回目の会議はエラーもなく終了。
営業役員や他の課長たちも「これ便利だわ」と口を揃えてくれる。
そんな中、役員がポロッと聞いてきた。

「これ、もし外注して作ったらいくらかかるん？」

私は控えめに答えた。
「20万円くらい、ですかね…」

（でも正直、もっと価値あると思う。会議時間を短縮してストレスも減ったわけだし…）

会社の雰囲気も、なんとなく前より明るくなった気がする。
在庫データが一目でわかると
「やべぇ在庫がある！どうしよう」→「じゃあ今月中にこれ売ろう」と
話が前に進む。
怖がる人もいるけど、一度問題が見えれば意外と動き出せるもんだ。

経理マン、非エンジニアの私がAIと二人三脚で作った在庫管理ツールは、
今日も小さな改善を積み重ねている。
残業時間はまだまだ減らないけど、プログレスバーが少しずつ右へ進んでいくのを見るたびに、こう思うのだ。

（まだあと半分、いや逆にあと半分で終わるじゃないか。大丈夫、きっとなんとかなる。）

そう、未来をちょっとだけ明るくしてくれるツールは、意外とすぐ近くにあるのかもしれない。

---

エピローグ：ツールの成功と、次の一歩

在庫管理ツールは確かに成果を生み出しました。会議資料の作成時間は大幅に短縮され、会議自体も「問題在庫」をピンポイントで議論する効率的なものに。営業役員や課長たちから「これ、めちゃくちゃ便利！」と嬉しい声が続々と上がり、私は内心ガッツポーズを決めました。

けれど、その裏で見て見ぬふりをしていた現実が、徐々に私の中で大きくなっていきました。そう、あの膨れ上がったコードたちです。

（これ、動いてはいるけど……次に機能追加するとき、どうすればいいんだ？）

自分で書いたはずのコードを前に、私はコーヒーをすすりながら頭を抱えました。「とりあえず動けばいい」と思って書き続けた結果、機能を詰め込みすぎて、もはやブラックボックス状態。修正しようにも「これ、どの関数が何をしてるんだっけ？」と画面を睨むばかり。

そこで、ふとAIお姉さんの言葉が頭をよぎります。

『動くものを作るのは素晴らしいこと。でもね、それが"進化できるもの"かどうかは別の話よ？』

……確かにその通りだ。
このツールを本当に「未来につながるもの」にするには、コードを整理して設計を見直す必要がある――そう気づいた瞬間でした。

---

次回予告：コード整理の旅へ

ツールが動くだけではなく、次に繋げられる「進化できるコード」を目指す。その第一歩として、リファクタリングに挑みます！

• 第1回：「RPGに学ぶ設計思想」
  RPGの世界から柔軟で進化しやすい設計のヒントを学びます。

• 第2回：「妄想を形にするクラス設計」
  実際にリファクタリングを進めながら、設計の具体例を解説。

• 第3回：「最強の在庫管理システム誕生」
  整理されたコードが現場でどのように活躍するのかを振り返ります。

果たして私は、この混沌としたコードを整理整頓し、進化できるツールに生まれ変わらせることができるのか――どうぞお楽しみに！

---

まとめ：非エンジニアが在庫管理ツールを作る5つのステップ

• AIとの対話は具体的に

  • 「コードを書いて」ではなく「〇〇の機能のコードを書いて」

  • エラーが出たら、エラーメッセージをそのままAIに見せる

  • コードの動作がおかしい時は、具体的な期待動作を説明する

• プロトタイプ思考を大切に

  • 完璧な要件定義より、まず動くものを

  • 使ってもらってから改善点を聞く

  • 小さな成功体験を積み重ねる

• ユーザー体験にこだわる

  • プログレスバーで安心感を提供

  • 自動色付け・列回転など、見た目を工夫

  • 使う人の立場で考える

• 段階的な機能追加

  • まずは最小限の機能で動くものを

  • 要望が多いほどやりがいがある

  • 無理のない範囲で少しずつ改善

• チーム全体を巻き込む

  • 成功体験を共有

  • 改善要望を歓迎

  • 次のアイデアを一緒に考える

そして、進化するための一歩を踏み出す

このステップを通じて、外注費をかけずに自分たちに最適化されたツールが作れました。しかし、ここで立ち止まるわけにはいきません。

動くコードから進化できるコードへ

――次回は、コードを整理し、未来に向けて強化するリファクタリングの旅にご案内します。

さあ、あなたも始めてみませんか？次回もお楽しみに！