現場データを“設計資産”に変える ─ 現場保守情報のフィードバック構造（Closed-loop）
「現場で得られた膨大なデータが、設計や製品開発に活かされない」─ FSM（Field Service Management）を導入した企業の多くが、同じ悩みに直面しています。
サービス部門は、MTTRやFTFRなど保守効率や応答時間をKPIに追い、設計部門はコスト削減や開発スピードを指標にする。 両者の評価軸が異なる限り、現場データは“修理の記録”で終わり、企業の知として還流することができません。
FSM導入は、現場の可視化を可能にしました。しかし次の壁は、“フィールド（現場）データをどう設計資産に変えるか”です。
この壁を越える鍵が、クローズドループ構造（Closed-loop）─ 現場 → 設計 → 現場 が連続的に循環する仕組みです。
なぜ、現場データは“生ゴミ”と化すのか？
現場データは毎日生成されています。 修理履歴、交換部品、環境条件、顧客要望─。
それらはすべて貴重な設計知見の源泉であるにもかかわらず、ほとんどが「報告書」という静的な形で保存されるだけなのが現実です。
問題の本質は、データの“文脈”が断絶していることにあります。
サービス部門は「症状」や「部位」で情報を語り、設計部門は「図面番号」や「設変通知番号」で考える。
両者の言語体系（プロトコル）が異なるため、現場データをそのまま渡しても設計側には“意味”として届かないのです。
構造化されていない情報は、どれほど量があっても「ゴミ屑」同然のノイズでしかありません。
クローズドループの構造と、「As-Maintained BOM」による翻訳
クローズドループを構築するための基本構造は、以下の3ステップで整理できます。
1️⃣ データ採取：FSMやIoTにより、現場で発生した作業履歴や交換部品情報を収集する。
2️⃣ 分析と翻訳：サービス部門が、現場の定性データを設計が理解できる構造化データに変換する。
3️⃣ フィードバック：翻訳された情報を設計・品質部門に戻し、設計変更や改善の根拠として活用する。
この「②分析と翻訳」が、多くの企業で抜け落ちています。
単に作業データを共有するだけでは、設計はそれを解釈することはできません。
ここで必要になるのが、As-Maintained BOM（AM-BOM）という翻訳の基盤です。
AM-BOMが「翻訳の辞書」として機能する仕組み
AM-BOMは、個体ごとの“今日現在の構成”を正確に保持する唯一のデータ構造です。
ここに、FSMが収集した交換履歴を紐づけることで、次のような翻訳が可能になります。
S-BOM（本社側理想構成）との差分を自動算出できる → 設計部門は「何が想定外だったか」を瞬時に特定できる
故障モードと“構成の組み合わせ”を結びつけられる → A部品 × 使用環境 × 稼働時間 のように因果推論が可能
交換頻度と部品寿命を構造的に比較できる → 消耗性の再定義や材料見直しの根拠になる
たとえば、
“同じ故障でも、Aモデルは2000時間で発生、Bモデルは4500時間で発生している”
という差分は、AM-BOMを使って初めて “構造の問題なのか、使用環境なのか” を分解できるのです。
つまり AM-BOM＝現場データを設計が読める言語に翻訳する座標系 です。
これにより、設計部門は具体的な根拠に基づく設計変更や部品改善を行うことが可能になります。
クローズドループを阻む「構造的な二重の壁」
ループが閉じない、つまり現場データが設計に戻らないのは、システムの問題ではありません。 「品質と構造の壁」、そして「動機と制度の壁」という二重の構造が存在するのです。
壁1：データの品質と構造の壁
まず、現場データには「分析」と「構造化」が欠けてしまっています。
一部の業界・業態を除けば、RCA（根本原因分析）は殆ど行われず、現場データが単なる「不具合レポート」に留まってしまっています。
また、フィードバックは紙・メール・口頭補足など非構造的な手段で行われることが常で、構成・症状・発生条件が、機器・装置の構成と統合されていません。
その結果、設計部門は「なぜ故障が発生したのか（原因）」ではなく「故障があったこと（結果）しか分からない」状態に陥いるのです。
データが“構造”を持たない限り、原因は追跡困難となり、改善は偶発的に終わってしまいます。
壁2：組織と制度の「動機」の壁
仮に高品質なデータがあっても、それを使う動機がなければループは閉じません。
設計とサービスが異なるKPIで動く限り、現場データの活用は「自部門の評価」とは、無関係になります。
また、現場で収集したデータが設計に届いたとしても、「設計変更コスト増加」と見なされてしまえば、組織は動きません。
二重の壁を超える鍵 ─ “翻訳担当者（アーキテクト）”
この二つの壁を越えるためには、 AM-BOMを理解し、現場と設計双方の言語を翻訳できる「アーキテクト」 が不可欠です。
具体的には次のような役割を担います。
AM-BOM × 交換履歴 × 稼働条件を統合した「故障モード解析シート」を毎月更新
設計・品質・サービスが参加する“Closed-loopレビュー会議”を主催 （議題：差分の分析、改善要求、設計反映の優先順位）
S-BOMとAM-BOMの差分をダッシュボード化し、設計部門が使える形に整形
設計変更・品質改善プロセスに、現場データを必ず紐づける運用ルールを作成
つまりアーキテクトは
データに“構造”を与え、組織に“動機”を与える唯一の役割
設計とサービスの間で言語（プロトコル）を変換し、データを制度へと結びつける
─それがクローズドループ・アーキテクトの役割なのです。
現場データは未来の製品品質への投資である
クローズドループが完成すると、現場で得られた知見が設計を変え、 その設計変更が次の現場効率を高める─学習が循環する構造が生まれます。
その循環構造が生まれると、現場データは、もはや“保守記録”ではなく、未来の製品品質への投資となるのです。
最初の一歩は、壮大なシステム連携である必要はありません。
頻出故障モードを構造化し、AM-BOM上でS-BOMとの差分として設計部門に戻すだけでもよいのです。
その行為が、「情報を戻す」という組織文化の始まりになります。
現場データは、未来の製品品質への投資である。 企業の学習速度は、情報を“戻す速度”で決まる。
👉次回予告：情報循環の実装（Vol.11＆12の実例）：Volvo Construction Equipment事例解説
世界の先進企業では、As-Maintained BOMを静的な台帳ではなく、動的な「ツイン」として活用し始めています。 たとえばVolvo Construction Equipment（ボルボ建機）は、PLM（PTC Windchill）を中核に、製造後も更新され続けるAs-Maintained BOMとIoTデータを連携させ、機器ごとの「デジタルツイン」を形成しています。 各機械の稼働データから残存寿命や最適メンテナンス時期を算出し、Equipment-as-a-Service（EaaS）へと発展させる先進的な取り組みです。
次回（Vol.13）では、As-Maintained BOMがどのように実装され、どんな効果を出すかを掘り下げます。
YMGアドバイザリーは、勝率95％を実現してきた「勝ち筋設計」を軸に、提案戦略・デモシナリオ構築・ROI算定をご支援しています。
FSM/アフターサービス提案のシナリオ（勝ち筋）設計に悩まれている方は、ぜひ一度ご相談ください。