システム変更を勝手にやったと思われないために。社内共有と説明の進め方

基幹システムの変更は、会社全体の効率化につながることがあります。しかし、使う側から見ると、いつもの画面や手順が変わる出来事です。

目的が正しくても、説明が届いていないと『勝手にやった』『聞いていない』と受け取られることがあります。システム変更では、機能そのものと同じくらい社内共有が重要です。

まず影響する人を洗い出す

システム変更の説明で抜けが出やすいのは、影響範囲の見落としです。主要部署には伝えたけれど、少しだけ使う営業担当には伝わっていなかった。こうしたことが起きると、現場では突然変わったように見えます。

受注、伝票発行、見積、入金処理、請求書発行など、基幹ソフトは複数部署が触ることがあります。変更する画面だけでなく、その前後で関係する人まで洗い出します。

目的を先に伝える

細かい操作説明から入ると、なぜ変更するのかが伝わりにくくなります。まずは、何のために変更するのかを短く伝えます。

入力ミスを減らすためなのか、二重入力をなくすためなのか、警告を出して確認漏れを防ぐためなのか。目的が分かると、多少の変更にも納得しやすくなります。

朝礼、LINE WORKS、個別説明を使い分ける

社内共有は、一つの方法だけでは届ききらないことがあります。朝礼で概要を伝え、LINE WORKSで文章と画面を残し、影響が大きい部署には個別に説明する。複数の入口を用意すると、抜けが減ります。

文章で残すことにも意味があります。後から確認できるので、聞いた人の記憶だけに頼らずに済みます。総務側も、何を説明したか振り返りやすくなります。

共有方法	向いている内容	注意点
朝礼	全体の目的、開始時期	細かい操作までは伝わりにくい
LINE WORKS	画面写真、変更点、FAQ	見ない人がいる前提で補完する
個別説明	影響が大きい部署の不安解消	相手の業務に置き換えて話す
Gemini Notebook	後から確認する資料、質問対応	入れる情報を選ぶ

説明したつもりでも、届いていないことがある

総務側では説明したつもりでも、相手に届いていないことがあります。忙しくて見ていない、関係ないと思って読み飛ばした、前提知識がなくて理解できなかった。理由はいろいろあります。

だからこそ、説明不足と言われたときに、すぐ反発しないことが大切です。どこが届いていなかったのかを確認すれば、次の共有方法を改善できます。

質問は不満ではなく、不安のサインとして受ける

変更後は、『ここはどうなるのか』『前のやり方はできないのか』という質問が出ます。質問が多いと大変ですが、それは不満だけではなく、不安が見えている状態でもあります。

質問を受け止めて、相手の仕事がどう変わるかに置き換えて答えると、理解が進みやすくなります。

Gemini Notebookで説明を補完する

仕様書、変更内容、FAQ、画面説明をGemini Notebookに入れておくと、後から確認できる場所を作れます。全員が必ず使うとは限りませんが、詳しく知りたい人が自分で確認できる入口になります。

ただし、重要な変更をAI任せにするわけではありません。人が説明すべきところは人が説明し、後から確認する場所としてAIを使うのが現実的です。

変更後の問い合わせを次回へ戻す

変更後に出た問い合わせは、次回の説明資料を強くする材料です。同じ質問が出るなら、最初の説明に足りない部分があった可能性があります。

問い合わせ内容、回答、追加した画面説明を残しておくと、次のシステム変更時に使えます。社内共有は一度で完成させるものではなく、使いながら強くしていくものです。

説明対象を部署ごとに分ける

システム変更では、全員に同じ資料を渡しても十分とは限りません。営業、事務、経理、倉庫、管理職では、気になるポイントが違います。

部署ごとに『何が変わるか』『何が変わらないか』『最初に注意すること』を分けると、相手に届きやすくなります。説明は詳しさより、相手の仕事に関係する形に置き換えることが重要です。

変更前、変更直前、変更後で伝える内容を変える

変更前は目的と全体像を伝えます。変更直前は開始日、操作変更、注意点を伝えます。変更後はよくある質問と追加対応を伝えます。時期によって、相手が必要としている情報は変わります。

一度だけ長い説明をするより、短く分けて伝える方が実務では届きやすいです。特に忙しい部署では、今すぐ必要な情報だけを先に伝えた方が読まれます。

画面を見せると不安が下がる

システム変更では、言葉だけで説明すると不安が残りやすいです。新しい画面、変わるボタン、警告が出る条件、今までと同じ部分を見せると、相手は自分の作業を想像しやすくなります。

可能であれば、実際の画面やテスト画面を使って説明します。画面が見えるだけで、『何が変わるか分からない』という不安はかなり下がります。

個別質問への回答も全体へ戻す

個別に受けた質問の中には、他の人も同じ疑問を持つものがあります。その場で答えて終わりにすると、同じ説明を繰り返すことになります。

個人情報や部署固有の事情を除いたうえで、FAQとして全体へ戻します。これにより、次に同じ疑問を持った人が自分で確認でき、総務の対応も軽くなります。

説明不足と言われたときの受け止め方

『聞いていない』『勝手に変わった』と言われると、説明した側はつらく感じます。けれど、相手から見ると本当に届いていなかった可能性があります。

ここで大切なのは、説明したかどうかだけでなく、相手が動ける状態になっていたかを見ることです。伝達の事実より、実務で迷わない状態を作れたかを基準にすると、次の改善点が見えます。

社内共有も改善対象として扱う

システム変更のたびに、社内共有のやり方も見直します。どの部署で質問が多かったか、どの資料が読まれなかったか、どの説明が伝わりやすかったかを残します。

共有方法そのものを改善していくと、次の変更が少し楽になります。システム改修は技術の仕事に見えますが、社内に定着させるところまで含めると、総務の調整力が大きく影響します。

説明資料は一枚で終わらせない

全体向けの説明資料は短くてよいですが、それだけでは足りない場合があります。全体概要、部署別の注意点、よくある質問、変更履歴を分けておくと、必要な人が必要な情報を見つけやすくなります。

一枚に詰め込むと、読む人が疲れてしまいます。最初に見る資料は短く、詳しい資料は後から確認できる場所に置く。この分け方が、社内共有では使いやすいです。

言い忘れた部署を責めずに仕組みで防ぐ

システム変更では、どうしても伝達漏れが起きることがあります。担当者の注意力だけで防ごうとすると、変更が大きくなるほど限界が出ます。

変更前に影響部署リストを作る、関係者チェック欄を作る、説明済みの部署を記録する。こうした仕組みにすると、次回の漏れを減らせます。

社長報告と現場説明は目的が違う

社長には、費用対効果、会社全体の方針、リスクを伝える必要があります。一方、現場には、自分の仕事がどう変わるか、どこに注意するかを伝える必要があります。

同じ変更でも、相手によって必要な情報は違います。総務がその違いを意識して言葉を変えると、情報格差による不満を減らしやすくなります。

共有した証跡を残す

説明した内容だけでなく、いつ、どこで、誰に共有したかも残しておくと安心です。後から問い合わせがあったときに、どの案内を見ればよいかを案内できます。

証跡を残すことは、責任逃れのためではありません。次に同じ変更をするとき、どの共有方法が足りなかったかを確認するためです。社内共有も改善対象として扱うなら、共有履歴そのものが重要な材料になります。

定着までは余白を持つ

変更を出した直後から完璧に回るとは限りません。最初の数日は質問が増えたり、想定外の操作が出たりします。その期間を見込んで、総務側も余白を持っておく必要があります。

社内説明は、公開して終わりではありません。定着するまでの問い合わせ対応、FAQ追加、再説明まで含めて設計すると、現場の不安を下げながら変更を進められます。

特に基幹システムは、日々の仕事に直結します。使う人にとっては、小さな表示変更でも作業のリズムが変わります。その感覚を軽く見ず、最初の数日は質問が出る前提で受け止めると、社内の空気が荒れにくくなります。

総務がすべての説明を抱える必要はありません。部署の管理職、システム会社、Gemini Notebookのような確認場所を組み合わせ、説明の入口を複数持つことで、少人数でも社内共有を回しやすくなります。

変更に対する不安は、説明不足だけで起きるものではありません。今までのやり方が変わること自体に自然な抵抗があります。そこを前提に、説明、質問対応、記録、FAQ化までを一つの流れとして用意しておくと、変更後の混乱を小さくできます。

総務側も、毎回完璧に説明できるわけではありません。だからこそ、説明漏れや質問を責める材料にせず、次の案内を良くする材料として扱います。小さく改善を積み重ねるほど、社内で変更を受け入れる土台ができます。

この積み重ねがあると、次の改修時に『また急に変わる』ではなく、『確認する場所がある』という安心感につながります。

安心感は、システム定着の土台になります。

社内共有のチェックリスト

• 影響する部署、人、作業を洗い出す
• 目的、開始時期、変わる作業を分けて説明する
• 朝礼、チャット、個別説明を使い分ける
• 質問をFAQへ戻す
• 変更履歴を後から確認できる場所に残す

システム変更の説明は、問い合わせ件数で見直す

システム変更を周知したつもりでも、特定部署から同じ質問が来るなら、説明の届き方に課題があります。説明の良し悪しは、資料の量ではなく、変更後に現場が迷わず動けたかで見ます。

見る指標	確認すること	改善策
問い合わせ件数	同じ内容の質問が何件出たか	FAQや画面説明を追加する
未周知部署	影響するのに伝わっていない部署がないか	部署別の説明リストを作る
変更日の混乱	変更直後に業務が止まったか	開始日をずらす、並行期間を作る
説明媒体	朝礼、LINE WORKS、個別説明のどれが効いたか	次回の伝え方を変える

あわせて読みたい関連記事

このテーマに近い実務記事です。必要なところから読み進めてください。

• 一人総務は、ベンダー・現場・社長の情報格差を埋める橋渡し役になる
• システム改修で現場が反発する理由。変化への不安を総務がどう受け止めるか
• ベンダー・現場・社長の情報格差を埋める。一人総務が中に立つ実務
• Gemini Notebookでシステム変更履歴を管理する。基幹ソフト改修を社内FAQ化する方法

よくある質問

まとめ

システム変更を『勝手にやった』と思われないためには、変更内容だけでなく、誰にどう影響するかを先に考える必要があります。

目的を伝え、影響範囲を洗い出し、朝礼やチャット、個別説明を組み合わせる。さらに問い合わせをFAQへ戻すことで、社内共有は少しずつ強くなります。