古参社員を説得する、システム刷新の説明会の準備と進め方
導入 ― 説明会前夜、後継社長が感じる胃の重さ
会議室の予約は取れている。プロジェクターの動作確認も済ませた。配布資料は昨夜遅くまで手直しして、ようやく形になった。それでも後継社長は、明日の説明会が終わったあとの空気を想像すると、どうしても気が重くなる。
先代から会社を引き継いで二年目。先代が現場に出ていた頃から使い続けている受発注の台帳、電話とファックスで完結する発注フロー、社員それぞれの手元にある「自分専用のExcel」。これらを新しい基幹システムに置き換える計画を、経営会議では役員全員の賛成で決めた。取引先からの見積もり回答も取った。予算も確保した。あとは現場に説明して、稼働開始の日程を決めるだけ、のはずだった。
ところが、経理を三十年近く担当してきたベテラン社員の顔が、資料を渡した瞬間から曇っていたのを後継社長は覚えている。「今のやり方で何か問題があったんですか」と静かに聞かれ、返す言葉が見つからなかった。問題がなかったわけではない。だが、それを面と向かって「あなたの仕事のやり方が古い」と言うつもりはなかったし、そう伝わってしまうことを何より恐れていた。
現場の主任からは「導入してくれるのは結構だけど、忙しい月末にトラブルが起きたら誰が対応してくれるんですか」と釘を刺された。倉庫の責任者は何も言わず、ただ資料を折りたたんでポケットにしまっただけだった。その沈黙が、賛成よりもずっと重く後継社長の胸に残っている。
後継社長は先代の葬儀の後、慌ただしく社長印を受け取った日のことを思い出す。あのとき古参社員たちは口々に「先代がいなくなって寂しいですが、これからもよろしくお願いします」と頭を下げてくれた。あの頭を下げる姿勢と、システム刷新の説明会での曇った表情とは、明らかに温度が違う。経営を継ぐことと、経営のやり方を変えることは、社員にとって全く別の重みを持つ出来事なのだと、後継社長はこのとき初めて実感した。事業を引き継ぐことは受け入れられても、先代が作った仕事のやり方に手を入れることは、まるで先代自身を否定するかのように受け止められてしまう。この温度差を理解しないまま説明会に臨んだことが、そもそもの準備不足だったのかもしれない、と後継社長は今になって思う。
説明会の資料を作っている間、後継社長は開発会社の担当者と何度もやり取りを重ねた。画面のモックアップは何度も修正を重ね、導入スケジュールも現実的な線に調整した。しかし、資料の完成度を高めることに時間を使うほど、後継社長の頭の中では「これだけ丁寧に作ったのだから、きっと納得してもらえるはずだ」という期待が膨らんでいった。その期待こそが、実は説明会当日の落胆を大きくする原因になることに、当時の後継社長はまだ気づいていなかった。資料の完成度と、現場の納得感とは、必ずしも比例しないのである。
システム刷新そのものは、経営判断としては間違っていない。取引先からの受注件数は先代の時代の一・五倍に増え、手作業での処理はすでに限界に近づいている。若手社員を採用しても、独自ルールだらけの旧システムの使い方を覚えるだけで半年かかってしまい、定着率にも影響している。数字で見れば、刷新しない理由はない。
しかし数字だけでは、二十年、三十年とその仕事のやり方を守ってきた古参社員の気持ちは動かない。後継社長がこれから開こうとしている説明会は、単なる導入スケジュールの伝達会ではない。先代の時代の仕事の仕方を否定せずに、新しい仕組みへ心理的に橋を架ける場である。その場の設計を誤れば、システムは導入されても現場は動かず、表面上は稼働していても実際には古いやり方が裏で生き続ける、という状態に陥る。逆にこの場を丁寧に設計できれば、古参社員こそが新システムの一番の推進者になってくれることもある。本稿では、なぜ古参社員の説得がこれほど難しいのかという構造から、実際の説明会の準備と進め方、よくある失敗パターン、そして後継社長がこの場を経営の転換点として活かすための実務対応までを、具体的に整理する。
なぜ古参社員の説得が難しいのか ― 構造的な理由
承継直後という時期そのものが持つ不利な条件
システム刷新の説明が難しくなる最大の理由は、後継社長が「承継直後」というタイミングでこの話を持ち出さざるを得ないことにある。先代が現役だった頃であれば、古参社員はその判断を「社長がずっと会社を見てきた末の決断だ」として、多少の疑問を持ちながらも受け入れてきた。しかし後継社長の場合、まだ経営者としての実績も信頼も積み上げている最中であり、古参社員から見れば「まだこの会社の現場を知らない人が、いきなり長年のやり方を変えようとしている」という構図に映ってしまう。
これは能力の問題ではなく、時間の問題である。信頼は説明の巧拙よりも、積み重ねた時間と実績によって築かれる部分が大きい。だからこそ、承継直後のシステム刷新は、内容がどれだけ合理的でも「なぜ今、この人が」という感情的な壁を最初に越えなければならない。この壁の高さを軽視して、資料の完成度だけを上げてしまうのが、後継社長が最初に陥りやすい落とし穴である。
「システムを変える」が「自分を否定される」に変換される心理
古参社員にとって、長年使ってきた業務のやり方は単なる作業手順ではなく、自分がこの会社に積み上げてきた専門性そのものである。台帳の書き方、電話でのやり取りの順番、独自の略語、トラブルが起きたときの対処の仕方。これらはマニュアルに書かれていないことが多く、その人だけが持っている暗黙知になっている。この暗黙知こそが、その社員が長年会社に必要とされてきた根拠でもある。
システム刷新の説明会で「このやり方を新しいシステムに置き換えます」と言われた瞬間、古参社員の頭の中では「自分がこれまで培ってきた専門性は、もう会社にとって価値がないと言われている」という変換が起きる。経営側は業務プロセスの効率化を語っているつもりでも、聞いている側は自分自身の存在価値を評価されているように感じてしまう。この変換が起きることを前提に説明会を設計しないと、どれだけ論理的な資料を用意しても、聞く側の耳はすでに閉じてしまっている。
さらに厄介なのは、この心理的な反応は本人にも自覚しにくいという点である。古参社員自身も「自分は感情的に反対しているわけではない、業務上の合理的な懸念を述べているだけだ」と思っていることが多い。だからこそ表面上の反対理由（「トラブル対応が心配だ」「今のやり方で回っている」)と、根底にある感情(「自分の存在価値を否定された」)がずれてしまい、後継社長がいくら表面上の懸念に答えても、納得感が生まれないという事態が起きる。
開発会社との三者関係が生む距離感
もう一つの構造的な難しさは、システム刷新の説明会には多くの場合、開発会社の担当者が同席するか、あるいは開発会社が作った資料を後継社長が代弁する形になることである。古参社員からすると、話しているのは「会社の外の人が作った、会社の外の人の言葉」であり、そこに自分たちの現場の実情が本当に理解されているのか、という疑念が生まれやすい。
開発会社の担当者は業務フローを図で説明することは得意でも、その会社の現場に流れる空気や、なぜ今のやり方がこうなっているのかという経緯までは、短い打ち合わせだけでは理解しきれないことが多い。その結果、説明会の場で「実際はそう単純じゃないんですよ」という現場からの反論が出たとき、開発会社の担当者がその場で納得のいく返答をできず、古参社員の不信感がさらに強まってしまう場面は少なくない。
この三者関係を後継社長がどう設計するかは、説明会の成否を大きく左右する。開発会社に説明を任せきりにしてしまうと、古参社員は「社長は外部の人に丸投げして、自分たちの現場を見ていない」と感じる。逆に後継社長が前面に立ちすぎて開発会社の専門性を活かせないと、技術的な質問に的確に答えられず、説明会そのものの信頼性を損なう。後継社長には、開発会社と現場の間に立って両者の言葉を翻訳する役割が求められる。
この翻訳者としての役割を果たすためには、後継社長自身が開発会社の説明内容を、説明会の前に自分の言葉で一度言い換えられるかどうかを確認しておく必要がある。専門用語をそのまま使った説明を鵜呑みにして説明会に臨むと、現場から突っ込んだ質問が出た瞬間に、後継社長自身も答えられず、開発会社に丸投げする場面が生まれてしまう。この場面が一度でも起きると、現場は「結局この人も内容を分かっていない」という印象を持ち、以後の説明にも信頼を置きにくくなる。逆に、後継社長が現場の言葉で技術的な内容を語れる場面が一つでもあると、それだけで「自分たちの現場を理解しようとしてくれている」という安心感につながる。
「変わることで失うもの」が具体的に見えている恐怖
新しいシステムが入ることで会社全体の効率が上がるという話は抽象的で、多くの古参社員にとって実感を持ちにくい。一方で、自分が失うかもしれないものは非常に具体的に想像できる。長年の経験で身につけた操作の速さが、新しいシステムでは一年生と同じレベルからのスタートになる。自分だけが分かっていた業務の抜け道や工夫が、システム化によって誰でも同じようにできるようになり、自分の重要性が薄れる。あるいは、新システムの操作に慣れないまま定年やパートへの切り替えの時期を迎え、「最後は肩身が狭いまま会社を去ることになるのではないか」という恐怖すら抱く社員もいる。
こうした「失うものの具体性」と「得られるものの抽象性」の非対称が、古参社員の説得を難しくしている本質的な原因である。説明会で語られる言葉が「業務効率化」「生産性向上」といった抽象的な表現に留まっている限り、この非対称は解消されない。得られるものの側も、その社員個人にとって具体的に何が変わるのかまで踏み込んで語る必要がある。
世代間のITリテラシー差という現実
構造的な要因の最後として、単純なITリテラシーの差も無視できない。長年紙とファックスで業務を回してきた社員にとって、タブレットやクラウドの画面操作そのものが未知の領域であり、「使いこなせるかどうか分からない」という不安は、業務内容の是非とは別のレイヤーで存在している。この不安を「業務上の反対意見」だと後継社長が誤読してしまうと、的外れな説明を重ねることになる。操作研修の充実や、慣れるまでの移行期間の設計といった、業務論とは別次元の安心材料を用意する必要がある。
「社内政治」としての説明会という側面
後継社長がもう一つ見落としがちなのは、システム刷新の説明会が、社内における力関係の変化を暗示する場としても受け取られてしまうという点である。古参社員の中には、これまで自分が独占的に持っていた情報や手続きの知識によって、社内での立場を保っていた人がいる。新システムが導入され、業務プロセスが可視化・標準化されると、その独占的な知識の価値が薄れ、結果として社内での自分の立場が弱くなるのではないかという懸念を持つことがある。
この懸念は本人の口からはまず語られない。「情報を独占して立場を守っている」ということを、本人が公の場で認めるはずがないからである。表向きには「新システムは現場の実情に合わない」という業務上の理由が語られるが、その裏には社内の力関係への影響という、もう一段深い懸念が存在している場合がある。こうした「今のままでいい」という表面上の理由の裏側にある心理構造は、古参社員の「今のままでいい」が招く停滞と、向き合い方の最低ラインでも取り上げている。後継社長がこの構造に気づかず、業務上の理由だけに反応して説明を重ねても、核心には届かない。個別ヒアリングの際に、業務内容だけでなく「この変化によって、あなたの社内での役割や立場がどう変わると感じているか」という点まで、間接的にでも聞き取る姿勢が求められる。
承継後の複数の変化が同時に押し寄せることへの疲労
システム刷新は、多くの場合、承継後に後継社長が手をつける最初の大きな変化の一つに過ぎない。取引先との条件見直し、評価制度の改定、就業規則の変更など、承継後の数年間は様々な変化が短期間に連続して起こることが多い。古参社員からすれば、そのたびに「先代の時代とは違うやり方」への適応を求められ、変化そのものに対する疲労が積み重なっている場合がある。
この疲労の蓄積を後継社長が把握していないと、「なぜこの程度の変化にこれほど強く反発するのか」と困惑することになる。実際には、システム刷新という単発の出来事への反発ではなく、承継後に積み重なった変化の総量への反発である可能性がある。説明会の準備をする際には、その社員が直近でどのような変化にすでに対応してきたかを振り返り、変化への耐性がどの程度残っているかを考慮に入れる必要がある。変化の総量を管理する視点を持たないまま次々と新しい施策を打ち出すと、個々の施策の合理性とは無関係に、現場の抵抗は強くなっていく。
具体例・ケーススタディ
ケース1 ― 受発注システム刷新で経理担当のベテランと衝突した金属加工業の事例
従業員四十名ほどの金属加工業を営むある後継社長は、先代の時代からファックスと電話で受けていた受発注を、クラウド型の受発注システムに切り替える計画を立てた。取引先の数は先代の時代の二倍近くに増えており、ファックスの受注内容を経理担当のベテラン社員が一件ずつ手入力する体制はすでに限界に近づいていた。ミスも増え、月末には毎回残業が発生していた。
後継社長は経営会議で刷新を決定し、開発会社が作成したシステム構成図と導入スケジュールをそのまま説明会の資料として使った。説明会当日、経理担当のベテラン社員は資料を一通り眺めたあと、「今のやり方でミスが出ているのは分かっています。でも、それは人を増やせば済む話じゃないんですか」と発言した。後継社長はその場で「人を増やすコストの方が高い」と即答してしまい、経理担当は「自分の仕事が高くつくコストとしてしか見られていない」と受け取った。空気は一気に硬くなり、説明会はその後、質疑応答が一切出ないまま終了した。
後日、後継社長はこの反応の背景を個別に聞きに行った。経理担当が本当に伝えたかったのは「私がこれまで工夫してきたやり方を、誰にも聞かれずに切り替えられるのが悔しい」という点だった。後継社長はそこで初めて、説明会前に個別ヒアリングを行わずに全体説明だけで進めたことが失敗の根本原因だったと気づいた。二度目の説明会では、経理担当に新システムの入力ルール設計に意見を出してもらう場を先に設け、「あなたの工夫の一部は新システムの標準機能として引き継ぐ」という説明を加えたことで、態度は大きく軟化した。最終的に経理担当は稼働後、若手社員への新システムの使い方指導役を自ら引き受けるまでになった。
ケース2 ― 倉庫管理システム導入で現場責任者の沈黙が示したもの
食品卸売業を営む後継社長は、紙の在庫台帳とハンディターミナルの一部運用を組み合わせていた倉庫管理を、バーコードとタブレットを使ったシステムに一本化する計画を進めた。倉庫責任者は入社から二十五年、先代の右腕として現場を切り盛りしてきた人物だった。説明会では特に反対意見も出さず、資料にも目を通し、質問もほとんどしなかった。後継社長は「特に反対もないようだから、順調に進みそうだ」と判断し、そのまま導入準備を進めてしまった。
ところが導入直前になって、倉庫責任者から「体調が良くないので少し現場を離れたい」という申し出があった。表面上は健康上の理由だったが、後になって他の社員から「責任者は新システムの説明会のあと、家でずいぶん悩んでいたようだ」という話が伝わってきた。倉庫責任者にとって、説明会での沈黙は同意ではなく、その場で反対を口にすることへの遠慮だった。二十五年の経験を否定するようなことを、新しく社長になった人の前で言うわけにはいかない、という思いがあったという。
後継社長はこの一件から、説明会での「発言がないこと」を安心材料として受け取ってはいけないという教訓を得た。以後、説明会の後には必ず一対一の個別面談の時間を設け、その場では言えなかった懸念を吸い上げる仕組みを取り入れた。倉庫責任者とも改めて面談し、新システム導入後も現場の判断は責任者に委ねること、システムはあくまで記録と共有を助ける道具であって、現場を管理する道具ではないことを丁寧に伝えた結果、責任者は復帰し、導入プロジェクトの現場側リーダーとして最後まで関わることになった。
ケース3 ― 説明会を段階分けしたことで合意形成に成功した印刷業の事例
創業五十年の印刷業を継いだ後継社長は、受注管理から生産管理までを一括で扱う統合システムの導入を計画した際、前任の後継社長仲間からの助言もあり、説明会を一回で終わらせず、三段階に分けて実施した。一回目は「なぜ今このシステムが必要なのか」という背景と危機感の共有だけに絞り、具体的な操作画面や導入スケジュールには一切触れなかった。この段階では反対意見も出たが、後継社長は「今日は方向性の共有だけで、細かいやり方はこれから一緒に決めていきたい」と繰り返し、結論を急がなかった。
二回目の説明会では、現場から選出した数名の社員と一緒に、開発会社を交えて実際の操作画面のデモを見る場を設けた。ここで初めて、ベテランの生産管理担当から「この画面のここが、今の台帳の書き方と全然違って戸惑う」という具体的な指摘が出た。開発会社はその場で画面のカスタマイズが可能であることを説明し、後継社長は「今の台帳のやり方に近づけられる部分は積極的に反映する」と明言した。
三回目の説明会でようやく導入スケジュールと研修計画を提示したが、この時点では現場からの反対はほとんど出なかった。後継社長は振り返って、「一回で全部を説明しようとしていたら、絶対に一回目の反発で心が折れていたと思う。段階を分けたことで、現場が『決定を一方的に伝えられた』ではなく『一緒に作り上げた』と感じられる時間を確保できたのが大きかった」と語っている。
この印刷業のケースでは、もう一つ工夫があった。二回目の説明会の前に、後継社長は生産管理担当のベテラン社員に「デモを見る前に、今の台帳のやり方で一番大事にしているポイントを三つ挙げてほしい」と個別に依頼していた。当日のデモの場で、その三つのポイントが新システムのどこに反映されているか、あるいは反映されていない場合はなぜ反映が難しいのかを、開発会社の担当者がその場で一つずつ説明する構成にした。この段取りがあったことで、ベテラン社員は「自分の意見が扱われずに終わる」という不安を持たずにデモに参加でき、結果として当日の空気が対立的にならなかったという。後継社長は、事前に「発言してもらう論点」を用意しておくこと自体が、説明会の空気を大きく左右すると振り返っている。
ケース4 ― 説明会後の個別フォローを怠り、稼働直後に離職者を出した建設資材業の事例
建設資材の販売業を営む後継社長は、受注から配送指示までを一括管理するシステムの導入を決め、説明会も一度きちんと開催した。説明会自体は大きな反対もなく終わり、後継社長は「特に問題なく理解してもらえた」と判断して、そのまま稼働に向けた準備を進めた。個別のフォロー面談は特に設けず、稼働開始の一週間前に操作研修を一回行っただけだった。
稼働開始後、配送担当のベテラン社員から新システムの入力項目についてたびたび質問が上がったが、現場は忙しく、後継社長もその都度簡単に答えるだけで済ませてしまった。稼働から一ヶ月ほどが経った頃、その配送担当社員から突然退職の申し出があった。理由を尋ねると、「新しいやり方に自分がついていけていないと感じ、周りに迷惑をかけるのが申し訳なかった」という言葉が返ってきた。後継社長は引き留めようとしたが、本人の意思は固く、結局その社員は退職してしまった。
後継社長は後になって、この社員が稼働直後の質問の裏に「本当は不安で仕方がないが、忙しい中で何度も聞くのが申し訳ない」という気持ちを抱えていたことに気づいた。もし稼働直後の数週間に、個別のフォロー面談や、質問を気軽にできる窓口を設けていれば、この社員の不安をもっと早く解消できたはずだった。このケースは、説明会自体の出来が良くても、稼働後のフォローを怠れば、それまでの合意形成の努力が水の泡になり得るという教訓を示している。特にベテラン社員ほど、忙しい現場で何度も質問することへの心理的な負担を強く感じる傾向があり、そこを見越したフォロー体制の設計が欠かせない。
実務対応 ― 説明会の準備と進め方チェックリスト
準備フェーズ
個別ヒアリングを説明会の前に必ず行う。 全体説明会の場で初めて意見を求めるのではなく、影響の大きい古参社員には最低でも一人十五分から三十分程度の個別ヒアリングの時間を事前に設ける。ここでの目的は説得ではなく、その人がどの部分に一番強い思い入れを持っているかを知ることに絞る。事前に懸念を把握しておくことで、説明会当日の想定質問への準備ができるだけでなく、「事前に自分の意見を聞いてくれた」という事実自体が、当日の心理的なハードルを下げる効果を持つ。承継したばかりの時期にどこまで現場に踏み込んでヒアリングしてよいかで迷う場合は、従業員承継で1年目、前社長より先に現場の判断を仰いでいいタイミングも参考になる。
説明会は一回で終わらせず、段階分けを検討する。 背景共有、デモ・体験、スケジュール確定という三段階に分けるだけで、現場が意思決定に参加している感覚を持てるようになる。特に最初の段階では、具体的な仕様やスケジュールの話に踏み込まず、なぜ変える必要があるのかという危機感の共有だけに徹する方が、後の合意形成がスムーズになる。
開発会社との役割分担を事前に打ち合わせておく。 開発会社の担当者に説明会で何を話してもらい、何を後継社長自身が話すのかを明確に分ける。技術的な質問への回答は開発会社に委ねるとしても、「なぜこの会社にとってこの刷新が必要なのか」という経営的な文脈は、必ず後継社長自身の言葉で語る。外部の人間の言葉だけで進めると、現場は「自分たちの現場を知らない人に決められた」という印象を強く持ってしまう。この役割分担を含め、発注前に社内で固めておくべき論点は発注前に社内で決めておく3つのことにも整理している。
資料は業務フロー図だけでなく、個人の作業がどう変わるかまで具体化する。 システム構成図や導入スケジュールといった全体像の資料に加えて、「この作業は、今はこうしているが、導入後はこうなる」という個人視点の変化を示すページを用意する。特に長年同じ作業を担当してきた社員がいる場合は、その人の作業内容を匿名化せず具体的に取り上げ、変化後の姿を描くことで、抽象的な効率化の話から自分事の話に変換できる。
失われる専門性の扱いを事前に決めておく。 古参社員の暗黙知やノウハウの一部は、新システムでは自動化され表面上は不要になる。しかし、その知識そのものは今後も例外対応やトラブル時の判断に必要になる場面が多い。説明会前に「この人の知識は今後どういう役割で活かしてもらうか」を具体的に決めておき、説明会の場でその役割を明言できるようにしておく。役割が消えるのではなく変わるのだという伝え方ができるかどうかが、納得感を大きく左右する。
トラブル時の対応体制を明文化しておく。 現場からの反対理由の多くは「導入直後にトラブルが起きたときに誰が対応するのか」という不安に集約される。開発会社のサポート窓口、社内の一次対応担当、稼働直後の一定期間の並行運用の有無など、トラブル発生時の対応フローを説明会の資料に明記する。曖昧なまま「大丈夫です」と伝えるだけでは、現場の不安は解消されない。
説明会に誰を呼ぶかを慎重に決める。 全社員を一度に集める形式が必ずしも最適とは限らない。部署ごとに影響の度合いが異なる場合は、まず影響が大きい部署だけを集めた小規模な説明会を先に行い、そこで出た懸念を反映したうえで全体説明会に進むという二段構えも有効である。特に発言力のある古参社員が複数いる場合、その全員を最初の大人数の場に一度に集めると、反対意見が相互に強め合ってしまうことがある。小規模な場を先に設けることで、一人ひとりの懸念を丁寧に拾いながら進められる。
社内政治的な懸念にも配慮した資料設計を行う。 前述の通り、システム刷新は社内の力関係にも影響を及ぼす場合がある。情報の可視化によって影響を受ける立場の社員がいる場合は、その社員の役割を「情報を管理する人」から「可視化された情報をもとに判断する人」へと格上げするような資料設計を検討する。単なる業務効率化の話に終始せず、社内での役割そのものがどう位置づけられるかまで踏み込んで準備することが望ましい。
変化の総量を振り返り、実施タイミングを再検討する。 承継後に他の制度変更が既に進行中である場合、そのタイミングとシステム刷新の説明会が重ならないように調整する。同時期に複数の変化が押し寄せると、現場の抵抗が本来の合理性以上に強くなることがある。可能であれば、他の変更が一定程度落ち着いた時期を見極めてから説明会を開く方が、合意形成はスムーズに進みやすい。
説明会当日の進め方
冒頭で「今のやり方を否定するものではない」と明言する。 説明会の最初の一分で、この刷新が過去の仕事のやり方を否定するものではなく、会社の成長に合わせて仕組みを追加するものだという立ち位置を明確に伝える。この一言があるかないかで、聞き手の受け止め方が大きく変わる。特に先代の時代からのやり方に自分自身のアイデンティティを重ねている社員がいる場では、この一言を省略してはいけない。
危機感の共有を先に、解決策の提示を後にする。 現場が「なぜ今変える必要があるのか」を自分事として理解する前に、いきなり新システムの機能説明に入ってしまうと、単なる「新しい道具の使い方講座」に聞こえてしまい、必要性への納得が置き去りになる。受注件数の増加、ミスの発生状況、若手の定着への影響など、具体的な数字や事実を先に共有し、「このままでは立ち行かなくなる」という危機感を共有したうえで解決策としてシステムを提示する順序を守る。
質疑応答の時間を十分に確保し、即答できない質問は持ち帰る。 説明会の時間配分で最も削られやすいのが質疑応答だが、ここを削ってしまうと現場の懸念は解消されないまま残る。その場で答えられない質問に無理に答えようとして曖昧な返答をするより、「持ち帰って確認し、いつまでに回答する」と明言する方が信頼を損なわない。
反対意見が出たら、その場で論破しようとしない。 古参社員から反対意見や懸念が出たとき、後継社長がその場で完璧に論破してしまうと、その社員は面前で恥をかいたと感じ、その後の協力を得にくくなる。「その視点は重要なので、持ち帰って検討する」「その懸念にはこういう対応を考えているが、他にも心配な点があれば教えてほしい」というように、意見を受け止める姿勢を優先する。
説明会の場で結論を急がない。 その日のうちに全員の賛同を得ようとせず、「今日は方向性を共有する場」「次回は実際の画面を見てもらう場」というように、次のステップを明示して終える。合意形成には時間がかかるという前提を持つこと自体が、焦りから来る強引な進め方を避ける助けになる。
発言の少ない社員にも意図的に声をかける。 説明会の場では、声の大きい社員の意見ばかりが目立ち、静かに座っている社員の反応が見過ごされやすい。後継社長自身が「〇〇さんは長年この業務を見てきたと思いますが、率直にどう感じますか」というように、名前を挙げて意図的に発言の機会を作ることで、沈黙のまま終わらせてしまうリスクを減らせる。ただし、名前を挙げる際は本人が公の場で発言することへの抵抗がないかを事前のヒアリングで確認しておく必要がある。
先代の名前を安易に持ち出さない。 「先代もこの必要性は分かっていたはずだ」といった発言は、一見説得力を持ちそうに見えるが、先代がすでに退いている以上、その言葉の真偽を確認できる人はいない。古参社員によっては、先代の名前を都合よく持ち出されることに強い違和感を覚える場合がある。説明の根拠は、先代の意向ではなく、現在の会社が置かれている状況と数字に基づいて語る方が誠実であり、結果的に納得感も得やすい。
説明会後のフォロー
個別面談で説明会では言えなかった懸念を吸い上げる。 説明会という公の場では発言しづらい懸念があることを前提に、説明会後には必ず一対一で話す時間を設ける。特に発言が少なかった社員には優先的に声をかける。沈黙は同意ではなく、遠慮であることが多い。
移行期間中の並行運用や研修計画を具体的に示す。 いきなり旧システムを廃止するのではなく、一定期間は旧来のやり方と新システムを並行して運用する期間を設けることで、現場の不安を大きく減らせる。研修についても、集合研修一回だけで終わらせず、稼働後にも質問できる窓口を用意しておく。
新システムでの役割変化を人事評価や業務分担に反映する。 古参社員の役割が「入力作業の担当者」から「例外対応やトラブル判断の担当者」に変わるのであれば、その変化を評価制度や業務分担表にも反映し、単なる口約束で終わらせない。役割の変化が処遇にも一貫して反映されることで、説明会での言葉に実質的な裏付けが生まれる。
稼働後の小さな成功を早めに共有する。 稼働開始から数週間の間に、たとえ小さくても「新システムのおかげでこの作業が早くなった」という具体的な成功例が出てきたら、社内で早めに共有する。特に懐疑的だった古参社員が新システムの利便性を実感した発言をしてくれた場合は、本人の了承を得たうえで他の社員にも共有すると、社内全体の空気が変わりやすい。
質問しやすい窓口を明示し、忙しさを理由に質問が埋もれないようにする。 稼働直後は現場が最も忙しい時期でもあり、疑問があってもその場で聞けずに抱え込んでしまう社員が出やすい。誰に、どの手段で質問すればよいのかを稼働前から明示し、稼働後の一定期間は後継社長自身が定期的に「困っていることはないか」と現場に足を運んで確認する姿勢を持つ。質問の少なさを安心材料と捉えず、むしろ質問が出ていないことこそ注意すべき兆候だという意識を持つことが重要である。
古参社員の協力を公の場で評価する。 説明会や稼働準備の過程で協力的な姿勢を見せてくれた古参社員がいれば、その協力を社内の朝礼や会議など公の場で具体的に評価し、感謝を伝える。抵抗していた社員が態度を変えて協力してくれるようになった過程は、他の社員にとっても「変化に協力することは評価される」という前向きなメッセージになる。評価を怠ると、協力した社員だけが変化のコストを一方的に負担したという印象が残ってしまう。
よくある失敗パターン
失敗パターン1 ― 開発会社の資料をそのまま使ってしまう
開発会社が作成する導入資料は、システムの機能や構成を説明することには優れているが、その会社特有の歴史や人間関係までは反映されていない。後継社長がこの資料をそのまま説明会で使ってしまうと、現場からは「外部の会社が作った、うちの実情を知らない資料」という印象を持たれやすい。特に長年の暗黙知に強い自信を持つ古参社員ほど、この印象を強く持つ傾向がある。資料の骨格は開発会社の力を借りつつも、個人の作業がどう変わるかという部分や、失われる専門性の扱いといった部分は、後継社長自身の言葉で書き加える必要がある。この作業を省略すると、説明会全体が「他人事の発表会」のように受け取られ、現場の当事者意識を引き出せないまま終わってしまう。
失敗パターン2 ― 反対意見への回答を数字と効率化の話に終始させる
古参社員から懸念や反対意見が出たとき、後継社長がつい陥りやすいのが「これだけ効率化できます」「これだけコストが下がります」という数字での説得に終始してしまうことである。しかし前述の通り、古参社員の反対の根底には、自分の専門性や存在価値が否定されるという感情的な反応がある場合が多く、数字による説得はその感情には届かない。数字の話をするのであれば、その効率化によって浮いた時間や労力を、その社員自身がどういう役割に使えるようになるのかという個人の未来像まで語る必要がある。数字だけの説得を繰り返すと、現場は「結局この人は数字でしか会社を見ていない」という印象を持ち、承継直後の信頼構築にとってむしろ逆効果になることがある。
失敗パターン3 ― 説明会を一度で終わらせ、稼働まで一直線に進めてしまう
経営会議での決定から稼働開始までのスケジュールが決まっていると、後継社長はどうしても効率を優先し、説明会を一度で終わらせて一直線に導入まで進めたくなる。しかし合意形成には現場側の心理的な時間が必要であり、一度の説明会だけで全員の納得を得ようとすると、表面上は反対意見が出なかったとしても、実際には納得していない社員が多く残ってしまう。この状態で稼働を迎えると、稼働直後に些細なトラブルが起きた瞬間に、それまで抑え込まれていた不満が一気に噴出し、「やっぱり無理な導入だった」という空気が社内に広がりやすい。段階を分けて時間をかけること自体が、結果的に稼働後のトラブル対応コストを下げるという投資であることを、後継社長は理解しておく必要がある。
失敗パターン4 ― 説明会の成功を「反対意見が出なかったこと」で測ってしまう
説明会が終わったあと、後継社長がつい陥りやすいのが、「特に強い反対が出なかったから、今回の説明会は成功だった」という評価をしてしまうことである。しかしケース2や失敗パターン3で見た通り、反対意見が出ないことと、現場が本当に納得していることの間には、大きな差がある場合がある。説明会の成功を測る基準を「反対意見の有無」ではなく、「個別ヒアリングで具体的な懸念がどれだけ拾えたか」「稼働後のフォロー体制がどれだけ具体的に用意できているか」といった、より実質的な指標に置き換える必要がある。この評価基準の置き換えができていないと、後継社長は説明会の場では安心し、稼働直後に予期しない離職や強い反発に遭って初めて問題の深刻さに気づく、という後手の対応に陥りやすい。
よくある質問
古参社員が説明会で何も発言しない場合、賛成と受け取ってよいのでしょうか。
いいえ、沈黙は同意のサインではなく、多くの場合は公の場で意見を言うことへの遠慮の表れです。特に承継直後で後継社長との関係がまだ固まっていない時期には、面前での反対発言を避ける社員が少なくありません。説明会後に必ず一対一の面談の時間を設け、その場では言えなかった懸念を個別に確認する仕組みを持つことが重要です。
開発会社の担当者に説明会に同席してもらうべきでしょうか。
技術的な質問に的確に答えられるという意味で同席は有効ですが、説明会全体を開発会社に任せきりにするのは避けるべきです。なぜ今この会社にとって刷新が必要なのかという経営的な文脈は、後継社長自身の言葉で語る必要があります。事前に役割分担を打ち合わせ、技術面は開発会社、経営判断の背景と現場への配慮は後継社長、という形で分担するのが望ましい進め方です。
説明会を段階分けすると、導入スケジュールが延びてしまうのではないでしょうか。
初期段階では確かにスケジュールに余裕が必要になりますが、一度の説明会で強引に合意を得ようとした場合、稼働後に現場の不満が噴出してトラブル対応や再説明に時間を取られるリスクの方が大きくなります。段階を分けて丁寧に合意形成を進めることは、稼働後の安定運用までを含めた全体のスケジュールで見れば、むしろ手戻りを減らす選択になることが多いです。
説明会での懸念表明が業務上の理由なのか、社内の立場への懸念なのかをどう見分ければよいでしょうか。
一つの目安は、その懸念が新システムの機能や仕様に具体的に結びついているかどうかです。「この画面のこの項目が今の業務と合わない」といった具体的な指摘であれば、業務上の懸念である可能性が高く、システムの調整で解消できる余地があります。一方で、懸念の理由が説明会のたびに変わり、明確な業務上の根拠が見えにくい場合は、社内での立場や役割への不安が根底にある可能性を考え、個別の面談でその社員の今後の役割について改めて時間をかけて話し合うことが有効です。
なお、丁寧に段階を踏んで説明会を重ねても、それでも古参社員から「デジタル化するなら辞める」という強い言葉が出てしまう場面はゼロにはできない。そのときにどう向き合うべきかは、「デジタル化するなら辞める」と言われたら。刷新と離職リスクの向き合い方で、離職コストの試算や労務面の注意点まで含めて具体的に整理している。
説明会で具体的な費用感を問われることも多い。先代の紙台帳をそのままWebシステム化するといくらかかる？を事前に確認しておくと答えやすい。
まとめ
古参社員を説得するシステム刷新の説明会は、資料の完成度や説明の巧拙だけで結果が決まるものではない。承継直後という時期そのものが持つ信頼の薄さ、業務の変更が自分の存在価値の否定として受け取られてしまう心理構造、開発会社という外部の存在が生む距離感、そして失うものの具体性と得られるものの抽象性の非対称。これらの構造を理解せずに説明会を開くと、どれだけ論理的な資料を用意しても現場の心は動かない。
逆にこの構造を理解したうえで、個別ヒアリングによる事前の懸念把握、段階を分けた説明会の設計、失われる専門性の新たな役割への転換、そして説明会後の丁寧なフォローという実務対応を積み重ねれば、古参社員は単なる抵抗勢力ではなく、新システムの現場側の推進者に変わり得る。後継社長にとってこの説明会は、システムを刷新する場であると同時に、先代の時代からの信頼を自分自身への信頼へと引き継いでいくための、承継そのものの一部である。焦らず、一つずつ段階を踏んで進めることが、結果的に最も確実で速い道になる。
冒頭で描いた説明会前夜の胃の重さは、多くの後継社長が一度は経験する感覚である。しかしその重さの正体は、資料の不備への不安ではなく、これから自分が古参社員の何を変え、何を守るのかという問いに、まだ自分自身の答えが定まっていないことへの不安であることが多い。説明会の準備を進める過程で、後継社長自身がこの問いに一度きちんと向き合い、失われるものと守られるものを言葉にできるようになったとき、説明会はようやく単なる伝達の場ではなく、古参社員との新しい関係を築き直す場に変わる。システム刷新という一つのプロジェクトを通じて、後継社長自身の経営者としての言葉も、少しずつ鍛えられていく。その積み重ねこそが、承継後の数年間で最も価値のある資産になっていく。
