業務改革に反対されたら？現場の不安を実施条件へ変える進め方

「そのやり方では現場が回らない」「前にも変えて失敗した」。業務改革の提案に反対が続くと、説明が足りないのか、相手に変わる気がないのかと悩むことがあります。改善したい側にも、日々の仕事を止めたくない側にも、守りたいものがあります。

反対されたときは、賛成に変えることを急がず、「何が起きると困るのか」「何が整えば試せるか」を具体化します。特に部署をまたぐ業務では、ある部署の効率化が別の部署の負担増になることもあります。懸念を試行の条件に変え、対応する人と判定日まで決めることが必要です。

この記事では、業務再設計の案ができた後、現場との調整から移行を決めるまでを扱います。変化一般への向き合い方は、変化に適応する力と仕事での対応方法を参照してください。

最初に、決定済みのことと変更できることを分ける

「自由に意見をください」と言いながら、実際には開始日も手順も決まっていると、意見を聞かれた側は何を話せばよいか分かりません。目的、期限、対象範囲、方法のうち、どこを変えられるかを最初に伝えます。

たとえば「申請の進捗を共有できる状態にすることは決定済み。ただし、入力項目、確認担当、例外の扱い、段階的に移す順番はこれから決める」と説明します。期限が動かせないなら、その根拠も示し、対象を絞る、支援要員を増やすなど、他に調整できる条件を用意します。

現場への相談は、責任を現場へ渡す手段ではありません。部門間の負担配分や規程の変更は、権限を持つ責任者が判断します。デジタル庁の窓口BPRアドバイザー派遣事業でも、支援前に横断的な推進体制を構築することを要件にしています。行政向けの事業条件ですが、関係部署を含む体制を先に置く参考になります。出典：デジタル庁「窓口BPRアドバイザー派遣事業」

「反対」を、確認できる困りごとに言い換える

「抵抗勢力」「古いやり方に固執している」と名づけると、その人が知っている例外処理や過去の失敗が出てこなくなります。一方で、反対意見をすべて正しいものとして受け入れる必要もありません。事実、予測、不明点を分けて確かめます。

「忙しい」は、試行の必要性を否定しているとは限りません。通常業務に試行を上乗せする設計への反対かもしれません。説明会を増やす前に、実際に減らせる仕事と、追加対応を引き受ける人を決めてください。

懸念を、担当と期限のある実施条件に変える

聞いた意見は議事録に残すだけでなく、「解決しなければ開始しない条件」「試行で確かめる条件」「今回の範囲から外す条件」に分けます。担当と確認日がない項目は、対応する約束ができているとはいえません。

これは架空の記入例です。すべての業務で同じ条件を採用するのではなく、自部署の権限、情報管理、顧客影響に合わせて変えてください。懸念への回答が「慣れれば大丈夫」だけなら、まだ具体化が足りません。

当事者は各部署の代表者だけでなく、日常的に処理する人、例外を引き受ける人、後工程で結果を使う人を含めます。会議で言いにくい不安は個別にも聞き、提案者にその場で説明を求めすぎないことが大切です。心理的安全性を高める管理職の実践例も役立ちます。

架空の会話：説得から、試せる条件の合意へ変える

次は、営業から購買への申請を変える場面の架空例です。

購買担当：「この項目だけだと、急ぎの発注で毎回営業へ確認が必要になります」

推進担当：「急ぎの案件では、何が分からず止まりますか」

購買担当：「必要な納期と、遅れてもよい代替品の範囲です。通常案件と同じ欄では区別できません」

推進担当：「では初回は通常案件だけを対象にして、急ぎは現在の相談経路を残しましょう。営業側で区別できる条件を作り、受付時に迷った件数も記録します。急ぎの経路は購買と営業で別途確認し、担当と回答期限を決める形でどうでしょうか」

この会話で受け入れたのは「改革をやめる」という結論ではありません。通常と急ぎで必要情報が異なるという指摘です。例外の負担を誰かの善意に残さず、対象範囲と別経路を具体化しています。

部門間で合意できない場合は、現場同士で話し続けるより、選べる案と影響を権限者に示します。「通常案件だけ先行」「追加要員を置いて全体移行」「開始日を遅らせる」のように、何を選ぶと何が変わるかを並べます。詳しくは他部署との優先順位・責任分担の調整方法を参照してください。

試行では、成果と現場の負担を同時に記録する

試す人には「自由に使って感想をください」ではなく、対象、期間、記録する項目、問い合わせ先、止める条件を伝えます。開始前に通常の一件を最後まで通し、例外がどこへ流れるかも確認します。

たとえば通常案件を2週間試す場合でも、2週間経てば必ず移行するとは決めません。これは期間の例であり、処理件数や業務の周期によって必要な長さは変わります。十分な案件がなければ、期限を理由に安全や効果を確認済みとしないでください。

• 利用者の結果：完了までの時間、差し戻し、問い合わせ、困った場面。
• 各部署の負担：入力、確認、照合、例外対応、問い合わせ対応にかかった時間。
• 守る条件：必要な承認・記録の欠落、誤処理、閲覧権限の問題。
• 移行特有の負担：練習や一時的な二重作業。定着後も残る作業と分ける。

平均時間が短くても、一部の案件だけ長く止まっていないかを見ます。また、自部署の入力が減った分、後工程で照会が増えたなら、それも変更の結果として記録します。「現場が慣れていない」で片づけず、手順の問題と学習不足を分けて判断しましょう。

移行を決める会議では、未解決の懸念から確認する

移行判定では、最初に集めた懸念の一覧をもう一度使います。それぞれに、試行結果、残る影響、対応、決定者を記します。意見が出た件数の多さではなく、重要な懸念が処理できたかを見ます。

戻す場合は、途中の案件の担当、正しい記録、重複処理の防止を確認します。新方式を止めても、既に顧客へ送った連絡や発注は元に戻りません。対外的な処理がある業務は、実行を許可する条件と、問題発生時に対応する責任者を試行前に決めておきます。

ツールを伴う変更で、使われない理由や継続判断を整理したい場合は、MAツール導入が失敗する原因と立て直し方も参考になります。

反対意見への回答を、現場に返す

最終決定では、「意見を受けて変えた点」「変えなかった点と理由」「残る問題の担当と期限」を伝えます。全員が望む案になるとは限りませんが、出した懸念がどの判断に使われたかは分かるようにします。

改善案に反対されたら、次の説明資料を作る前に、直近の反対意見を一つ選び、「具体的に困る場面」「開始前に必要な条件」「試して確かめること」の3つに書き換えてみてください。現場と確認する対象がそろえば、賛否の押し問答から、仕事を回せる条件を決める話へ進められます。