Vol.14：FSMソリューション導入直後に現場が抱く3つの不満と、これを乗り越えるための業務再設計の構造
FSM（Field Service Management）ソリューションを導入した直後、多くの企業で似たような不満が聞かれます。
「入力が増えて仕事が増えた」
「デモで見たように最適化されない」
「結局、紙や電話に戻ってしまう」
一見すると“現場がITを嫌がっているだけ”のように見えますが、実際には何が問題なのでしょうか？
イントロ：現場がシステムを「拒絶」する構造的理由
現場の不満は、FSMというツールそのものに対してではなく、新しいツールが既存の業務慣行と摩擦を起こしている構造に起因しています。
長年の現場では、「誰がどう情報を持ち寄り、どの順番で判断を行うか」という暗黙の流れが確立されています。
FSMはその“流れ”に直接干渉するため、現場の判断モデルとシステムの判断モデルが衝突しやすいのです。
つまり── 現場が拒絶しているのは「システム」ではなく、“業務構造が再設計されていない状態”なのです。
今回は、この構造的摩擦を3つに整理し、そこから導かれる3つの業務再設計フレームワークを提示します。
1️⃣ FSM導入直後に現場が抱く「3つの不満」の構造化
■ 不満1：入力負荷─「入力項目が増えた」
FSM導入初期に最も多く聞かれる不満がこれです。
しかし、この不満の本質は「面倒だから嫌だ」ではありません。
🔍 真のニーズ：入力作業の自動化・最小化
現場の本質的ニーズは次の通りです。
本当に必要な項目だけを入力したい
入力が“次の作業を助ける”と実感できるようにしたい
写真や位置情報などは自動で取得してほしい
現場に出ているので、キーボード入力は極力勘弁してほしい
つまり、入力が「ただの報告義務」と化していることこそ抵抗の原因であり、
入力が次の作業を容易にする構造へ転換されていないことが最大の問題なのです。
■ 不満2：最適化の不一致 ─「デモで見たようには動かない」
次に出てくるのが、最適化結果への不満です。
「期待していたほど賢くない」
「現場感覚と違う」
という声が多く聞かれます。
しかし、この不満の深層には、さらに構造的な課題があります。
🔍 真のニーズ：目的関数と制約条件が明確に定義された“最適化ルールの設計”
最適化エンジンは魔法の箱ではありません。
何を最大化するのか（目的関数）
現場の何を守るのか（制約条件）
これらを設計しなければ、最適化が正しく機能することはありません。
多くのケースでは、こうした前提設計を曖昧にし、“デモで見た最適化”をそのまま期待してしまうことで 「デモと違う」という失望が生まれているに過ぎません。
よくあるのが、最適化結果は”推奨案”として、現場の作業者に”微調整権限”を持たせてはどうか、という要望です。
しかし、それはスケジュール全体に破綻をもたらすだけでなく、”最適化”の目的そのものも壊してしまうことになります。
本シリーズVol.10で論じたように、サービス組織のKPIは部分最適ではなくスループット（全体最適）で捉えるべきです。
現場への一律の「微調整権限委譲」は、現場個別の判断が累積し、作業計画の全体最適を破綻させる危険性があります。
FSM最適化の目的は、
「人に作業を割り当てる」
ではなく
「作業に人を割り当てる」
構造そのものを動かすことである点を改めて強調しておきます。
■ 不満3：情報チャネルの散在──「結局、紙や電話に戻った」
FSMを導入しても、現場が再び紙や電話に戻ってしまう─これもよく聞く現象です。
しかし、現場は“アナログが好きだから”戻っているわけではありません。
🔍 真のニーズ：現場が必要な情報のシームレスな統合
必要な情報がFSMに集約されていなければ、 現場は最も速くて確実な手段（電話・口頭・紙）に戻ります。
顧客情報
過去の履歴
As-Maintained BOM（AM-BOM：現場の真の構成）
図面・マニュアル
部品在庫
移動情報
これらが1つの画面で見られない限り、FSMは“単なる電子入力装置”止まりなのです。
2️⃣ 不満を乗り越えるための「業務再設計の構造」
ここからは上記3つの不満に対応する再設計フレームワークを提示します。
■ フレームワーク1：インプットの構造化
「入力作業を、次の作業を容易にする行為に再定義する」
入力負荷を解決するには、次の4点が必要です。
入力項目の棚卸し（本当に必要な項目だけにする）
自動取得できる項目の自動化（写真・位置情報・タイムスタンプ）
プルダウンで選択できるよう、入力項目の定型化
入力が次の作業計画に反映される因果関係を可視化する
入力は“作業効率化のための投資”であり、 入力→データ→次の作業が楽になるという構造を示すことで現場の協力を得やすくなります。
■ フレームワーク2：最適化ルールの明確化と「緩衝の設計」
最適化に対する不満は、最適化エンジンではなく、 最適化ルール（目的関数×制約条件）の設計不足が原因です。
最適化は“魔法”ではなく“設計作業”である
目的関数を決めずに「最適化してほしい」と言うことは、 「何を最適にしたいかを言わずに、数学者に答えを求める」ようなものです。
そのため、導入初期は以下を徹底すべきです。
目的関数を明確化する（例：完了件数最大化／稼働率最大化／移動時間最小化）
制約条件を定義する（優先顧客／スキル条件／予約時間枠）
無理に詰め込まない“緩衝のパラメーター設計”を行う
現場には「計画通りに行かなくても、システムがすぐ再計算するので、目の前の作業に集中すればいい」安心感を与える
繰り返しになりますが、現場の判断は重要ですが、リアルタイムな調整権限委譲を現場に行うと、目的関数が乱れ、全体最適が崩れてしまう、ということです。
現場の感覚と計画指示が異なった場合は、そのフィードバックを詳細にもらい、パラメーター設計の見直しに活用する対応が必要です。
重要なのは、 全体最適（組織のスループット）を崩さない、調整可能な緩衝設計 をルールの下、行うことです。
■ フレームワーク3：情報のシームレスな統合
FSMを「現場の判断を支援するプラットフォーム」へ
現場がFSMを手放さなくなるための条件はただひとつです。
「必要な情報がすべてFSMに揃っていること」
AM-BOM（現場の実構成）
履歴
マニュアル
在庫情報
顧客情報
これらが“バラバラのシステムを探し回らずに済む”状態をつくることが、 最も強力な現場支援になります。
FSMは入力のためのシステムではなく、 判断のための“情報インターフェース”として設計すべきです。
3️⃣ 結論：業務再設計は「システムと現場の翻訳」である
FSM導入の成功を決めるのは、機能の多さではありません。
鍵は、現場の慣行をシステムの構造へ翻訳できるかどうかです。
入力、最適化、情報統合という3つの不満は、 すべて「業務構造の再設計」が必要であることを示すシグナルです。
適切に再設計が行われれば、 不満は単なる“抵抗”ではなく、 持続的な改善サイクルを生む“実行可能な教訓”へと変わります。
FSM定着の本質は、ツール導入ではなく、構造を再設計し、
現場とシステムを翻訳することにある。
👉次回予告：次回は、現場DXに立ちはだかる最難関の壁、導入企業側における制度との接続について解説します。
Vol.15：制度との接続：「現場DXの効果を最大化する評価・報酬制度との接続構造」
YMGアドバイザリーは、勝率95％を実現してきた「勝ち筋設計」を軸に、提案戦略・デモシナリオ構築・ROI算定をご支援しています。
FSM/アフターサービス提案のシナリオ（勝ち筋）設計に悩まれている方は、ぜひ一度ご相談ください。