BOM変更の後追いがツラい人へ — 基板の「いつ・なぜ・何が変わった」を機械的に残す
中規模以上の基板プロジェクトを長く回していると、BOM変更が累積数十回は当たり前。気付くと：
- 「あれ、このR12って前は4.7kだったよね？いつ10kに変わった？」
- 「先月のレビューで指摘した部品、誰がいつ差し替えたか分からない」
- 「Excelの BOM_v3_final_最終.xlsx と _v3_final_revised_2.xlsx、どっちが本番？」
…という状況、心当たりありませんか？
この記事では、BOM変更を**「機械的に証跡として残す」**ための運用方法を、ScoutCheckerのコミット機能を使って解説します。Excel/Confluence/Jiraだけで頑張ってるチームには、移行の一案として参考になるはずです。
なぜBOM変更追跡は壊れるのか
ありがちな失敗モードは3つあります。
1. ファイル名で版管理してしまう
BOM_rev1.xlsx → BOM_rev1_2.xlsx → BOM_final.xlsx → BOM_final_v2.xlsx。誰もが通る道で、誰もが後悔します。最大の問題は 「どれが現行か」「何が変わったか」が機械的に分からないこと。
2. 変更理由が散らばる
「LDOを TPS7A47 → TPS7A4901 に変更」という事実だけはわかっても、なぜ変えたか（コスト？性能？在庫？指摘事項？）は別のメール / Slack / Confluence / 議事録に散在。半年後に思い出せない。
3. 解析結果との紐付けが無い
BOMを変えたなら、当然回路解析（電源系チェック、設計ルール照合）を再実行するはず。でも「この BOM 版に対する解析結果はこれ」という対応関係が残っていないと、後から「変更前後でどう挙動が変わったか」を追跡できません。
ScoutCheckerでの解決ワークフロー
ScoutCheckerは Git の commit と同じ感覚で、プロジェクト状態（ファイル群 + 解析結果）のスナップショットを残す機能を持っています。BOM変更前後で commit を打っておけば、後から自動 diff 可能になります。
ステップ1：節目ごとに commit を打つ
Project › Commits から「Commit」ボタンを押し、メッセージを書きます。これだけ。何が記録されるか：
- 全ファイル（ネットリスト、BOM、設定ファイル等）のスナップショット
- 直前の commit からの変更タイプ（追加 / 修正 / 未変更 / 削除）
- 直近の解析結果（processing_run）のID参照
- コミット時刻、コミットしたユーザー
メッセージは Git と同じ感覚で：
LDOをTPS7A47→TPS7A4901へ変更（在庫切れ対応、データシート上はピン互換）
これがそのまま後追い時のコンテキストになります。「なぜ変えたか」を必ず書くのが運用上のキモ。
ステップ2：BOMを変更して、再解析後にもう一度 commit
ファイル管理画面でBOM (.csv) を新版でアップロード → 解析を回して完了 → 再度 commit：
TPS7A4901で再解析。VIN/VOUTピン構成は同等、cVOLT指摘なし。
ステップ3：差分を見る
Project › Commits の一覧で、過去の commit と現状を比較できます。Compare 機能で2つの commit を選ぶと、以下が出ます：
- ファイル単位の diff — どのファイルが変更されたか（BOM のどの行が変わったか含む）
- ユニット (IC/抵抗/コンデンサ) の追加/削除/属性変更
- ネット構成の差分 — どのネットにどのピンが追加 or 除去されたか
- 解析結果の差分 — 新規発生した警告、解消した警告
つまり「BOM が変わった結果、解析上どう影響したか」が一画面で見られます。設計レビューの効率が体感で5倍くらい違います。
実例：抵抗を 4.7kΩ → 10kΩ に変更
仮に R12 = 4.7kΩ → 10kΩ という変更を加えてコミットしたとします。比較画面では：
=== File diff ===
modified: bom.csv
R12: 4.7k → 10k
=== Unit attribute changes ===
TOP.R12: VALUE = "4.7k" → "10k"
=== Findings ===
[NEW] DR-021 R12: pull-up resistance higher than recommended for I2C @ 100kHz
[RESOLVED] DR-009 R12: pull-up resistance below typical
抵抗値の変更で I2C プルアップの設計ルール判定が変わったことが、ファイル変更とリンクして表示されます。
これを Excel 運用でやると：
- 旧BOM と新BOM を WinMerge で比較
- 旧版の解析結果を発掘
- 新版で解析を回す
- 警告一覧を目視で diff する
…というコースで、最低でも10〜30分。コミット運用なら数秒。
運用のコツ3点
1. メッセージを必ず書く
Git の git commit -m "fix" と同じで、意味のないメッセージは未来の自分を泣かせます。最低限「何を / なぜ」を1行で：
- ❌
BOM update - ❌
修正 - ✅
R12を10kに変更（I2Cプルアップ規格対応） - ✅
LDOを4901へ変更（旧品在庫終息、ピン互換確認済み）
2. レビュー直後にコミット
設計レビューや指摘修正の直後にコミットを打つ習慣にすると、「指摘 → 対応 → 確認」のセットがコミットとして自動的に残ります。後日の監査でもそのまま使えます。
3. ロット切替や代替品適用も記録
製造側からの「この型番、サフィックス変わって RBHR から RBHT に切り替わります」みたいなロット情報も、コミットに残しておくと後で追跡可能。ピン互換であってもコミットを残すこと自体が証跡になります。
まとめ：BOM 履歴を「製品設計の議論ログ」にする
BOM変更追跡は、単なるデータ管理の話ではなく、**「設計判断の理由を組織に残す活動」**です。10年後の同じ失敗を避けるための、いちばん安価な投資。
ScoutCheckerでは：
- ✅ プロジェクト状態のスナップショット
- ✅ コミット間の自動 diff（ファイル/ユニット/ネット/解析結果）
- ✅ レビュー指摘との紐付け（設計ルール違反の解消履歴）
- ✅ 任意時点へのリストア
を全部組み込んでいます。Excel管理から脱出したいチームには、試してもらう価値があると思います。
ScoutChecker無料登録 で実際に動かしてみてください。既存プロジェクトのインポートも可能です。