システム改修で現場が嫌がるとき、それは単なる抵抗とは限りません。今までの仕事のやり方が変わること、自分の作業にどう影響するか分からないこと、説明が自分ごととして届いていないこと。こうした不安が重なると、「使いにくい」「勝手に変わった」「前の方がよかった」という反応になります。
総務や管理部門の側から見ると、システム改修は効率化のために進めていることが多いはずです。電話やFAXの受注を減らす。手入力を減らす。ミスを減らす。伝票発行や請求処理をスムーズにする。目的は前向きです。
この記事の要点
- 現場の反発は、仕事の品質や慣れた手順を守りたい気持ちとして受け止めます。
- 会社の目的と本人の仕事の変化を分けて説明し、進捗と画面を早めに見せます。
- 強い意見も質問として記録し、説明不足と仕様上の問題を切り分けます。

現場の抵抗を不安として読み解く
現場が嫌がる理由を否定せず、仕事の品質を守りたい不安として受け止める視点を整理します。
- 現場の反応を抵抗ではなく不安として見る
- 目的、画面、変更前後を使って説明する
- LINE WORKSやGemini Notebookを説明補助として使う
しかし、現場からすると、短期的には慣れた作業が変わります。長期的に良くなるとしても、明日の入力、今日の伝票、今の確認作業が変わるなら、それはストレスになります。ここを軽く見ると、システムは動いているのに社内で定着しにくくなります。
中小企業のシステム導入ガイド
現場・社長・ベンダーをつなぐ流れをまとめています。 このテーマ全体を見る
現場・社長・ベンダーの間で、総務が橋渡しする実務を順番に整理しています。
- 全体像 中小企業のシステム導入ガイド
- 1 システム導入で橋渡し役になる理由
- 2 システム改修で現場が嫌がる理由
- 3 現場ヒアリングを要件にする方法
- 4 全部叶えるより落とし所を作る
- 5 勝手にやったと思われない共有
現場が嫌がる理由は、わがままではない
説明前の確認
読むときは、正しいかどうかだけでなく「相手の仕事がどこで変わるか」を一つ書き出してみます。
システム改修に対する現場の反応を「抵抗」とだけ捉えると、説明が雑になります。「便利になるのだから使ってください」で済ませたくなります。しかし、現場の不安には理由があります。
特に基幹ソフトや販売管理のように、受注、伝票発行、見積、請求、入金処理などに関わるシステムは、多くの社員が少しずつ違う使い方をしています。事務職は毎日触ります。営業は一部の画面だけ見ます。経理は請求や入金に関わる部分を見ます。管理職は結果の数字を見ます。
同じシステムでも、見ている場所が違うため、変更の受け止め方も違います。主要部署には説明したつもりでも、少しだけ使う部署に伝わっていないことがあります。そこから「聞いていない」「勝手に変わった」という印象が生まれます。
「説明不足」に見える背景には情報格差がある

総務側は、システム会社との打ち合わせ、仕様書、テスト、エラー対応、費用、運用開始日など、多くの情報を持っています。一方、現場は日々の作業をしながら、変更後に自分の操作がどう変わるのかを知りたいだけです。
この情報量の差があるまま、「こう変わります」とだけ伝えると、現場には必要な情報が届きません。総務からすると説明したつもりでも、現場からすると自分の仕事に関係する説明になっていないことがあります。
| 現場の反応 | 裏側にある不安 | 総務が説明すること |
|---|---|---|
| 前の方がよかった | 慣れた操作が変わる不安 | 変わる操作と、変わらない操作を分ける |
| 勝手に変わった | 自分の仕事への影響が見えない | 部署別に影響範囲を伝える |
| ミスしそうで怖い | 確認ポイントが分からない | 人が見る場所と警告の意味を伝える |
| 結局誰に聞けばいいのか | 質問の入口が不明 | チャット、担当者、FAQを用意する |
| なぜ今やるのか分からない | 目的が共有されていない | 効率化、ミス防止、将来のための理由を伝える |
大きな変更ほど、部署ごとに説明を変える
情報差を見る
相手が知らない前提情報は何か、逆に自分が現場から聞けていない情報は何かを分けます。
小さな見た目の変更であれば、社内への影響は限られます。しかし、受注データを自動で取り込む、手入力を減らす、受注から売上入力へつなげる、警告を出して人の確認に回す、といった変更は影響範囲が広くなります。
この場合、全員に同じ説明をしても届きにくいです。事務担当者には日々の操作が重要です。営業にはお客様への説明や問い合わせ対応が重要です。経理には売上、請求、入金への影響が重要です。社長や管理職には費用対効果とリスクが重要です。
総務ができることは、同じ改修内容を相手の仕事に合わせて翻訳することです。これは手間ですが、システムを定着させるための大事な作業です。
説明は「機能紹介」ではなく「仕事の変化」で伝える

システム改修の説明でありがちなのは、機能を説明してしまうことです。「自動連携します」「警告が出ます」「このボタンで登録します」といった説明です。もちろん必要ですが、それだけでは現場の不安は減りません。
現場が知りたいのは、「自分の仕事がどう変わるのか」です。今まで手入力していたものがどう減るのか。どこで確認すればよいのか。エラーが出たらどうすればよいのか。今まで通りでよい作業は何か。ここまで具体化して初めて、説明として届きます。
説明文に入れたい5つの要素
- この変更は何のために行うのか
- 誰の、どの作業が変わるのか
- 逆に、今まで通りでよい作業は何か
- エラーや警告が出たときにどうするか
- 困ったときに誰へ、どこへ聞けばよいか
受注システム化のような変更は、短期ストレスが出やすい
運用に落とす条件
仕様の話に入る前に、画面、発生条件、影響範囲、例外時の連絡先をそろえると止まりにくくなります。
たとえば、電話やFAXで受けていた注文を、Web上の受注システムへ移していくような変更があります。会社側から見ると、電話対応、手入力、読み間違い、確認の手間が減ります。お客様側にも、営業時間に縛られず注文できるメリットがあります。
一方で、社内の現場では新しい確認作業が発生します。取り込まれたデータが正しいか、警告が出ていないか、例外商品は人の目で見る必要があるか。最初は慣れるまで手間に見えます。
ここで「自動化したのだから楽になるはず」とだけ言うと、現場の感覚とずれます。最初は確認しながら運用する。警告を見て、人が判断する部分を残す。問い合わせが出たらルールを見直す。こうした導入初期の負担も含めて説明する必要があります。
人が見る場所を残すと、現場は安心しやすい
システム改修では、何でも自動化すればよいわけではありません。受注数量が普段と大きく違う、荷姿が前回と違う、特定の商品が含まれる、備考欄に注意すべき文字がある。こうしたものは警告として出し、人が確認する設計にした方が安全なことがあります。
現場にとっても、「全部システム任せ」より「ここはシステムが拾ってくれる。最後は人が見る」の方が受け入れやすい場合があります。総務は、この人が見る場所を説明に入れます。
自動化の説明では、できることだけでなく、あえて人に残す部分を伝えることが重要です。これは現場の不安を減らし、ミス防止にもつながります。
現場の全部を叶えることが成功ではない
現場から強い意見が出ることは、悪いことではありません。それだけ今の仕事を良くしたい、変えたいという気持ちがあるからです。ただし、現場の要望をすべてそのままシステムに入れることが成功とは限りません。
すべてを現場の今のやり方に合わせると、システムが複雑になりすぎることがあります。費用も増え、保守も難しくなります。一方で、システム側に寄せすぎると、現場の負担が大きくなります。
大切なのは、人が変える部分と、システムが合わせる部分の中間を探すことです。総務は、現場とベンダーの間でこの落とし所を作る役割を担います。
説明の流れを先に決めておく

システム改修は、作ってから説明を考えると遅くなります。説明は後始末ではなく、設計の一部として考える方がうまくいきます。
特に大きな改修では、最初に「誰へ、どの順番で、何を伝えるか」を決めておくと安心です。主要部署だけでなく、少しだけ使う部署も洗い出します。
説明不足を防ぐための影響範囲リスト
説明漏れを防ぐには、影響範囲をリスト化するのが有効です。システム改修では、直接作業する部署だけでなく、帳票を見る部署、問い合わせを受ける部署、数字を確認する部署にも影響が出ることがあります。
| 確認項目 | 見る内容 | 説明先の例 |
|---|---|---|
| 画面 | 入力画面、確認画面、検索画面 | 事務、営業、管理職 |
| 帳票 | 納品書、請求書、一覧表、チェック表 | 事務、経理、現場管理者 |
| データ連携 | 受注、売上、入金、請求へのつながり | 経理、総務、管理職 |
| 例外処理 | 警告、エラー、手入力、確認待ち | 直接担当者、問い合わせ窓口 |
| お客様対応 | 注文方法、問い合わせ、誤入力時の対応 | 営業、事務、管理職 |
朝礼、社内チャット、FAQを組み合わせる
一度の説明会だけで全員に伝えるのは難しいです。そもそも参加できない人もいますし、説明会の場では理解できても、実際に操作するときには忘れていることもあります。
そのため、複数の入口を作ります。朝礼で変更の概要を伝える。社内チャットに説明文とリンクを載せる。よくある質問をFAQにする。必要に応じて部署別に補足する。重要な変更では、口頭と文章の両方を使います。
文章で残しておくと、後から見返せます。総務側も同じ説明を何度も繰り返さずに済みます。口頭で伝えた内容も、要点だけチャットに残すと、誤解を減らせます。
Gemini Notebookのような資料参照AIも説明補助になる
変更内容、仕様メモ、FAQ、問い合わせ履歴、画面説明などを資料参照型AIに入れておくと、社内からの質問に答えやすくなります。全員が使うかどうかは別として、「ここに聞ける入口がある」と示すだけでも意味があります。
ただし、入れる情報には注意が必要です。個人情報、給与情報、秘匿性の高い情報は入れません。全社に共有して問題ない説明資料、仕様の概要、操作案内、FAQなどに絞ります。
AIは、説明を人の代わりに全部やるものではありません。人が説明し、AIが補足し、FAQが残る。こう考えると、一人総務でも共有の負担を下げやすくなります。
問い合わせは、面倒なものではなく改善材料
システム改修後には、必ず問い合わせが出ます。これは失敗ではありません。むしろ、説明が足りなかった場所、使いにくい場所、例外処理が分かりにくい場所が見えたということです。
問い合わせを受けたら、その場で答えて終わりにせず、FAQやマニュアルへ戻します。同じ質問が出るなら、説明が足りないというサインです。操作ミスが続くなら、画面や警告の出し方を見直す材料になります。
現場への説明テンプレート
実際に社内へ流す説明は、長すぎると読まれません。最初は短く、必要な人が深掘りできる形が使いやすいです。
| 項目 | 書くこと | 例の方向性 |
|---|---|---|
| 目的 | なぜ変更するのか | 手入力を減らし、確認漏れを防ぐため |
| 対象 | 誰に関係するか | 受注入力、伝票発行、請求確認に関わる方 |
| 変更点 | 何が変わるか | 注文データが自動で取り込まれる |
| 確認点 | 人が見る場所 | 警告が出た注文は登録前に確認する |
| 問い合わせ | どこへ聞くか | 社内チャット、担当者、FAQリンク |
総務自身が説明を諦めない
一人総務では、システム開発や改修そのものに時間を使いたくなります。説明に時間をかけるより、早く作った方が会社にとって良いと感じることもあります。
しかし、現場に伝わらなければ、せっかくの改修が「よく分からないもの」になってしまいます。説明は単なる付属作業ではなく、定着させるための本体に近い仕事です。
「これは言っても分からないかもしれない」と思って省くと、後から説明不足として返ってくることがあります。専門用語を減らし、相手の仕事に合わせて、短く何度も伝える。ここを諦めないことが、社内調整ではとても大切です。
AI時代は、説明資料を作りやすくなっている
以前は、説明資料、FAQ、マニュアル、部署別案内を作るだけでも大きな負担でした。今はAIを使えば、メールや仕様メモから要点を抜き出し、説明文のたたき台を作れます。
たとえば、ベンダーから届いた仕様説明を現場向けに言い換える。問い合わせ履歴からFAQを作る。部署別に「あなたの作業ではここが変わります」という文章を作る。こうした作業は、AIと相性が良いです。
ただし、最後に確認するのは人です。社内の空気、相手の理解度、どこまで言うべきか、誰に先に説明するか。ここは総務が握るべき判断です。
システム改修後に見るチェックリスト
| 確認項目 | 見るポイント | 次の対応 |
|---|---|---|
| 問い合わせ数 | 同じ質問が繰り返されていないか | FAQを追加する |
| 操作ミス | 特定の画面や警告で止まっていないか | 説明文、画面、ルールを見直す |
| 部署差 | ある部署だけ困っていないか | 部署別に補足説明する |
| 例外処理 | 人の確認が必要な場所が多すぎないか | 自動化範囲と確認範囲を調整する |
| 記録 | 質問と回答が残っているか | 次回改修の資料にする |
現場が嫌がるのは、仕事の品質を守りたいからでもある
システム改修は、結果的には良くなるとしても、一時的には不安定さや仕事の変更を伴います。現場が不安に思うのは自然です。特に、真面目に仕事をしている人ほど、「この変更で品質が下がるのではないか」「自分が大切にしてきたやり方が崩れるのではないか」と感じます。
だから、現場の反応を単なる抵抗として見ないことが大切です。不信感は、仕事に真面目だからこそ出る場合もあります。総務はその不安を否定せず、収められる言葉で説明する役割を持ちます。
最初に伝えるべきは、機能より目的である
後から「言っておけばよかった」と感じやすいのは、変更の目的です。会社として何を目指しているのか、なぜ今この変更をするのかを、なるべく多くの人に伝えておく必要があります。
人によって、正確性を重視したい人、効率性を重視したい人など仕事の価値観は違います。全員が同じように賛成するとは限りません。それでも、会社としてどの方向へ進みたいのかを先に示しておくと、説明の土台ができます。
現場に伝わるのは、自分の仕事がどう変わるかである
会社全体のゴールは必要ですが、現場の人にとって一番気になるのは、自分の作業がどう変わるかです。明日から困らないか、今までできていた確認は残るのか、画面はどう変わるのか。ここが見えないと不安は残ります。
説明では、完成後の画面、変更前後、進捗状況を見せることが有効です。LINE WORKSで記録に残す、Gemini Notebookで変更内容の説明やFAQを補完することもできます。ただし、ITリテラシーが高くない人には、文章やAIだけでは足りません。言葉で説明し、質問に丁寧に答える場面も必要です。
強い意見は、相手の立場から一度分析する
システム改修中は、「そこはどうなの」「これは困る」と強い意見が出ることがあります。そのとき、なぜその批判が出たのかを相手の立場から冷静に分析することが理想です。なんで分かってくれないのかと思うと、話は発展しません。
相手が勘違いしているなら、責めるのではなく、足りない情報を補って説明する。精神的に厳しいこともありますが、システム改修では技術面以上に、社内調整でどれだけ我慢強く答えられるかが重要になる場面があります。
よくある質問
- Q現場が反対する場合、どこまで聞くべきですか?
- A
まずはしっかり聞くべきです。ただし、すべてをそのまま実装する必要はありません。困っている理由を整理し、実装する部分、人が運用で吸収する部分、今回は見送る部分に分けます。
- Q説明会を開けば十分ですか?
- A
説明会だけでは足りないことが多いです。参加できない人、聞いても忘れる人、実際に操作して初めて疑問が出る人がいます。社内チャット、FAQ、マニュアル、個別補足を組み合わせる方が安全です。
- Qシステム会社の説明をそのまま共有してもよいですか?
- A
そのままだと専門的すぎることがあります。総務が現場の仕事に合わせて言い換えると伝わりやすくなります。仕様ではなく、操作と影響を中心に説明します。
- QAIで社内説明を作るときの注意点はありますか?
- A
個人情報や秘匿情報を入れないこと、AIの文章をそのまま出さず人が確認することです。AIは整理とたたき台作成に使い、最終的な言い方や順番は総務が決めます。
まとめ
システム改修で現場が嫌がるのは、変化そのものが嫌だからとは限りません。自分の仕事にどう影響するのか分からない、説明が自分ごととして届いていない、ミスしたときの対応が見えない。こうした不安が反応として出ていることがあります。
総務ができることは、改修内容を現場の仕事に翻訳することです。目的を伝え、影響範囲を洗い出し、変わる操作と変わらない操作を分け、質問の入口を作る。そして、問い合わせを次のFAQや改善に戻す。
説明は、システム改修の後始末ではありません。現場に定着させるための設計そのものです。一人総務・少人数総務だからこそ、実務とシステムの両方を見ながら、会社で使える形に落とし込む価値があります。


コメント