第1回から第4回で、1つの班（パン班）ぶんの発注ツールが「正しく動く」ところまで来ました。でも、本当の現場は1班では終わりません。生産管理の担当者は、全部のラインの発注を、1人でまとめて見ている。しかもその計画データは、班ごとにバラバラのExcelで作られていて、決してきれいではない。今回は、そこへ広げます。
1. 修正点の概要
今回の仮想事例では、パン班・洋菓子班・和菓子班という3つの製造ラインがあり、製造計画は班ごとに独立して管理されています。そして現実の計画は、いつも全部の情報がきれいに埋まっているとは限りません。仮にすべて埋まっていても、誤った計画がそのまま提出されれば、在庫管理は簡単に破綻します。だからこそ、「この計画はどこかおかしくないか？」と気づくきっかけがあれば、在庫を適正に保てる可能性が上がります。
変えたいのは、この3つです。
- 多チーム対応… 全ラインの製造計画を、1つの計画としてまとめて扱う。
- データ整合チェック… 班ごとに汚れた入力でも止まらず、不整合を見える化する。
- 製造計画の可視化… どの日・どの製品が混むかをひと目で分かるようにして、考えるきっかけをつくる。
前提として、コアの計算は、一行も変えません。同じ材料を複数の製品が使うときの「合算」は、第2回ですでに実装済みです。製造計画のteam列も、最初から入れてありました。だから多チーム化は、計算を作り直すのではなく、計画の行が増えるだけです。
2. 修正計画：データチェック機能と製造計画の可視化
何をどう変えるかを、先に仕様として固めます（今回配る変更仕様書にまとめました）。コアを触る大きめの変更なので、Claude CodeにはPlanモードで「コアは変えず、その上に乗せる」段取りを確認してから実装に入ります。
入力：全ラインを1つの計画に
全ラインの計画を1つの計画として読みます（team列で班を識別）。班ごとの計画ファイルが分かれていても、同じ形式なら結合して読み込む。特別な臨時計画も、同じ形式で足すだけです。
整合チェック：止める／報告して続行
ここがこの回の肝です。汚いデータへの対応を、2段に分けます。構造の異常（必須カラムが無い・ファイルが読めない）は止める。一方、紐づけの不整合（計画にあるが配合表に無い製品、配合表にあるが在庫に無い材料、欠損、日付の異常、表記ゆれで結合できないIDなど）は、報告して続行します。
- 原材料IDのカラムがない → 止まる。
- 日付の形式が異なる → 報告して進める。
といった形で進めていきます。
可視化：候補からヒートマップを選ぶ
実際にプログラムを書く前に、イメージだけ固めておきたかった。そこでWeb Claudeに「全ラインの計画を可視化して、混雑状況の理解の助けになる表示例を出して」と相談し、図を作ってもらいました。候補は3つです。
(A) 製品×日付のヒートマップ
(B) 日別の総ロット数＋能力ライン
(C) チーム別の積み上げ棒
採用は(A)ヒートマップにしました。理由は、チームと品目の情報が落ちず、「どの製品が・どの日に混むか」が分かるから。(B)(C)は総量や班の負荷は見えても品目が潰れてしまい、「急ぐべきか緩めていいか」の判断材料としては弱い、と考えました。
MATSUプログラムの実装する前に、Web Claudeを活用して図を作ってもらうのが時短になります。
作成した変更仕様書
作成した変更仕様書は以下の通りになります。
3. 実装：Planモードで実装し、動作を確認する
Planモードによる実装
変更仕様書をClaude Codeに渡し、Planモードで実装させます。返ってきた計画が「既存のコアプログラムを変更せず、実装する」段取りになっているかを、まず確認する。もしコアを書き換える計画になっていたら、そこで止めて指示し直します。この一手間が、動いている土台を壊さないための保険です。確認できたら、実装に進みます。
動かすデモデータ：わざと3か所、汚しておく
動作確認には、3班ぶんのデモデータを用意しました（在庫・全ラインの製造計画・配合表の3ファイル）。A＝パン班、B＝洋菓子班、C＝和菓子班で、砂糖や卵といった共通材料は班をまたいで使われます。だから合算が効いて、共有材料ほど早く減る──多チーム化の効きどころが見える構成です。
ただし、きれいなデータだけでは整合チェックが働く様子を見られないため、わざと3か所だけ、汚してあります。
① ロット数の欠損：製造計画のロットの1行を空にした（→ その行は除外して報告）。図は次のセクション参照。
② 配合表に無い製品：計画にだけ「抹茶ロール」を入れた（→ 計上せず報告）。
③ IDの表記ゆれ：在庫は BTR-01、配合表の1か所だけ BTR_01（→ 表記ゆれの疑いとして報告）。
動作確認：不整合における表示
コードの実装が完了しました。「製造計画ヒートマップを見る」「整合チェック報告」のボタンが追加されています。
3つのCSV（在庫・全ラインの製造計画・配合表）を入れて動かします。全ラインの計画を読み込み、共通材料は班をまたいで合算される。そして、データに不整合があれば、処理を止めずに報告が出ます。
想定した項目である3つの項目
- ロットデータの欠損
- 抹茶ロールが配合表にない
- 表記のゆれ
これらに由来するデータの不整合は検出されました。また、メタ的な話をしますが、製造計画の日付について、作業をしているうちにデモデータの日付が過去のものになってしまい、計算対象外になりました。想定していない不整合でしたが、これも検出できるように設計してくれていたみたいです。
動作確認：ヒートマップで混雑の可視化
そして、「製造計画ヒートマップを見る」を押したら採用したヒートマップが出てきます。縦が製品（班つき）、横が日付、色が濃いほどその日に多く作る、という見方です。色の濃い帯を追うだけで、どの製品がいつ混むか、どこが空くかが、ひと目で分かります。製造をしない日や過密なスケジュールなど、通常運転と異なる部分がひと目で分かります。
4. 評価：pytestによるテスト作業
ここまでで「動いた」ことは確認できました。でも第4回でやったとおり、「動いた」と「正しい」は別です。だから評価は、第4回のテストにそのまま観点を足して、もう一度 pytest を回します。
pytestによる検証項目
今回の変更に合わせて足すのは、この4つの観点です。
- 多チームで、共通材料が班をまたいで正しく合算されるか
- 未登録製品や在庫に無い材料が、（止まらず）報告されるか
- 欠損がポップアップで通知され、該当行が除外されるか
- 表記ゆれのIDが、注意として拾われるか
これらを足して、全件が緑（PASSED）になって初めて、多チーム対応も「正しく動く」と言えます。実装で終わりにせず、ここまでやって一区切りです。
検証結果
検証項目に対する検証結果は以下の結果になりました。
| 確認項目 | 結果 | 検証内容 |
|---|---|---|
| ① 多チームで共通材料が班をまたいで合算 | ✅ | バターの平均使用量が単一班より大きいことを確認（A班 BRD-01/02 ＋ B班 CAK-02 等を合算） |
| ② 未登録製品・在庫に無い材料が止まらず報告 | ✅ | report.ok=True（停止しない）かつ MTR-01（紐づけ①）・BTR_01（紐づけ②）が報告される |
| ③ 欠損が通知され該当行が除外 | ✅ | WAG-02 06-10（空lots）が計画から除外され、「13行目：ロット数が空です」が報告される |
| ④ 表記ゆれIDが注意として検出 | ✅ | BTR_01 ↔ BTR-01 がnear-miss（注意）で検出。全角・区切り・前ゼロの正規化も確認 |
全ての項目において、passedになりました。これで変更の完了です。
5. まとめ
- 多チーム化はコアを変えず、計画の行が増えるだけ（team列を最初から持たせた設計が効く）
- 汚いデータは2段で対応：構造の異常は止める、紐づけの不整合は報告して続行
- 「黙って無視」をやめ、欠損はポップアップで具体的に通知
- 可視化はヒートマップを採用。情報を増やさず、混雑を目で見つけられる形に
- 実装（動いた）と評価（正しい）は分けて確認する
次回は第6回。道具としては形になりましたが、まだ「毎回やり直し」が残っています。緊急度のしきい値も、選んだファイルも、起動するたびに最初から。前回の設定を外部ファイルに覚えさせて、起動時に戻せるようにします。あわせて、.batなどで自分以外のPCにも配れる形にして、この道具を「人に渡せる」ところまで仕上げます。
使用しているデータ・製品名・取引先名はすべて架空のものです。コードは解説用の実装例で、各ツールの仕様・料金は記事公開時点のものです。
コメント