業務改善が嫌われるのは「最初に仕事が増える」から

新しいシステムを導入した。

入力項目も減らした。
画面も見やすくした。
承認経路も整理した。

以前より便利になっているはずなのに、現場からはこんな声が出ます。

「前のやり方の方が楽だった」
「また覚えることが増えた」
「今のままで困っていない」
「余計な仕事を増やさないでほしい」

改善を進めた側からすると、納得しにくい反応かもしれません。

実際に作業時間は短くなる。
入力の手間も減る。
ミスも起こりにくくなる。

それなのに、なぜ現場は嫌がるのでしょうか。

私が業務改善やシステム移行に何度も関わる中で感じているのは、現場が改善そのものを嫌っているとは限らないということです。

現場から見れば、業務改善はまず、

「将来の仕事を減らすために、今の仕事を増やす取り組み」

として始まります。

改善後の「楽になる未来」より先に、

覚える。
試す。
確認する。
質問する。
間違える。
やり直す。

という負担がやってきます。

ここを無視してしまうと、良い仕組みを作ったはずなのに、現場から嫌われる業務改善が生まれます。

改善の効果より先に、移行の負担がやってくる

新しい仕組みを導入すると、利用者には一時的に多くの仕事が発生します。

例えば、

• 新しい操作方法を覚える

• 説明会や研修に参加する

• テストに協力する

• 不具合や使いにくい点を報告する

• 過去のデータを移行する

• 新旧のルールを確認する

• 周囲からの質問に答える

• 今まで無意識にできていた操作を、一つずつ考えながら行う

といった仕事です。

新しいシステムでは入力項目が減っていても、慣れるまでは旧システムより時間がかかることがあります。

旧システムなら、画面をほとんど見なくても操作できていた人が、新しいシステムではボタンを探し、マニュアルを確認し、入力内容が合っているか不安になる。

改善後の完成形だけを見れば、確かに便利です。

しかし、利用者が最初に経験するのは、完成後の便利さではありません。

覚えることが増え、迷うことが増え、確認することが増える期間です。

この状態で、

「新しい方が便利なのだから使ってください」

と言っても、現場には響きません。

改善を設計する側は、完成後に何分削減できるかだけではなく、そこへ移るまでに現場がどれだけ負担するのかまで考える必要があります。

新しい仕事を足したのに、古い仕事をやめていない

そして、業務改善が現場から嫌われる大きな原因の一つが、二重運用です。

新しい申請システムを導入した。

しかし、

念のため、以前のExcelも残す。
上司へのメール報告も続ける。
口頭での確認も継続する。
旧システムもしばらく使えるようにしておく。

こうなると、新しい仕組みを導入しても、現場の仕事は減りません。

むしろ、

• 新システムへの入力

• 旧Excelへの入力

• メールでの連絡

• 新旧データの照合

が必要になり、仕事が増えます。

改善した側は、

「新しいシステムを導入した」

と考えています。

一方、現場から見れば、

「入力先が一つ増えた」

だけです。

この認識の違いはかなり大きいと思っています。

新しい仕事を始めるときには、同時に、

「その代わりに、何をやめるのか」

を決めなければなりません。

新しい報告方法を導入するなら、以前の報告をいつまで続けるのか。

新しいシステムで進捗を確認できるなら、個別の進捗確認メールは本当に必要なのか。

新しいチェック機能を設けるなら、人による二重確認をそのまま残す必要があるのか。

ここを決めずに改善すると、現場にとっては「改善」という名前の追加業務になります。

「前の方が楽だった」は、必ずしも改善への反対ではない

新しい仕組みに対して、

「前の方がよかった」

と言われると、

「変化を嫌っているだけではないか」

と思ってしまうことがあります。

しかし、私はこの言葉をそのまま「抵抗」と判断しない方がいいと思っています。

同じ「前の方が楽だった」でも、中身はまったく違うからです。

本当に新しい仕組みが使いにくい

設計した側が気付いていない問題があるケースです。

入力項目は減っているのに、必要な情報を確認するために別画面を何度も開かなければならない。

承認は早くなったものの、承認後の処理が手作業になっている。

管理部門には便利でも、申請する側の作業は増えている。

業務改善では、全体の工数が減っていても、特定の人だけ負担が増えていることがあります。

この場合は、利用者の声を聞いて設計を修正する必要があります。

説明や研修が不足している

仕組みそのものは悪くなくても、変更理由や使い方が十分に伝わっていないケースです。

操作方法だけでなく、

• なぜ変更するのか

• 旧運用の何が問題だったのか

• 新しい仕組みによって何が変わるのか

• 何がなくなるのか

• 困ったときは誰へ聞けばよいのか

まで伝える必要があります。

特に「何がなくなるのか」は大事です。

新しい仕事だけ説明されても、利用者からすれば、

「結局、今までの仕事にこれが追加されるのでは？」

という不安が残ります。

単純に、まだ慣れていない

旧システムを何年も使っていた人にとって、慣れていること自体が大きな価値です。

新しいシステムの方が客観的には操作数が少なくても、導入初日は旧システムの方が速いことがあります。

これは、新システムが悪いとは限りません。

一定の習熟期間とサポートが必要なだけかもしれません。

古い仕事が残っている

そしてもう一つが、新旧の仕組みが併存し、本当に負担が増えているケースです。

この場合、

「前の方が楽だった」

という現場の反応は、変化への抵抗ではありません。

正当な指摘です。

だから、一つの言葉をすべて同じ問題として扱ってはいけません。

設計の問題なのか。
説明の問題なのか。
習熟の問題なのか。
二重運用の問題なのか。

分けて考える必要があります。

だからといって、現場の意見をすべて採用しても改善は進まない

一方で、現場から不満が出るたびに旧運用へ戻していたら、業務改善は進みません。

利用者は、それぞれ自分の担当業務や日常的な使いやすさを基準に意見を出します。

営業部門は、入力項目をできるだけ減らしたい。

管理部門は、確認項目や証跡を増やしたい。

システム部門は、例外を減らして運用を単純にしたい。

経営側は、統制を維持しながら生産性も高めたい。

どの意見にも、それぞれの立場から見れば理由があります。

問題は、すべての要望を足し合わせた仕組みが、必ずしも良い仕組みにはならないことです。

全員の希望を取り入れた結果、項目が増え、分岐が増え、例外が増え、結局誰にとっても使いにくいシステムになることがあります。

そのため、業務改善では、

現場から聞くことと、
会社として決めること

を分ける必要があります。

操作上の不具合や、実務上処理できない問題は現場から吸い上げる。

一方で、会社として廃止すると決めた旧運用を、「前の方が慣れているから」という理由だけで残さない。

現場の声を聞くことと、現場の要望をすべて採用することは同じではありません。

最終的には、権限のある人が「切り替える」と決める

業務改善を定着させるためには、現場との対話だけでは足りません。

最後には、責任者の意思決定が必要です。

特に利用者が多い仕組みでは、部門長や管理職と事前に合意し、

「この日から、この方法に切り替える」

と明確に決める必要があります。

新旧どちらを使ってもよい状態を長く残せば、多くの人は使い慣れた方へ戻ります。

その結果、新システムの利用率が上がらず、

「やはり現場に合わなかった」

という評価になる。

しかし、実際には新システムが悪かったのではなく、会社が旧運用をやめると決めきれなかっただけかもしれません。

業務改善の責任者には、良い仕組みを設計する力だけではなく、

人と組織を実際に動かすための権限と発言力

も必要です。

IPAの「DX動向2025」でも、日本企業は米国・ドイツと比べて、経営層・IT部門・事業部門の部門間連携が弱いことが指摘されています。DXをシステム部門だけの仕事にせず、経営・IT・業務をまたいで進める必要性が見える結果だと思います。

システム部門だけで進めれば、システムとしての正しさが強くなりすぎることがあります。

業務部門だけで進めれば、現在の運用や個別要望が強くなりすぎることがあります。

経営だけで決めれば、現場で実行できない仕組みになることもあります。

三者が同じ役割を担う必要はありません。

ただ、それぞれが必要な場面で関与する設計は必要です。

並行運用は「安心」ではなく、期間限定のコスト

システム移行では、トラブルを避けるために並行運用を行うことがあります。

一定期間、新旧両方のシステムへ入力し、結果が一致しているか確認する。

重要な業務では必要な場合があります。

ただし、忘れてはいけないのは、

並行運用とは、利用者が二重の負担を引き受けている状態

だということです。

だからこそ、

• 何のために並行運用するのか

• 何を確認できれば終了できるのか

• どの項目を照合するのか

• 誰が確認するのか

• いつ終了するのか

• 終了を誰が判断するのか

を先に決めておく必要があります。

「念のため、しばらく残しておく」

という並行運用は危険です。

「しばらく」が終わらなくなるからです。

特に避けたいのは、

「この申請は旧システム」
「こちらは新システム」
「この条件だけメール」

のように、同じ利用者が日常的に入口を使い分けなければならない状態です。

利用者は本来の業務を考える前に、

「今回はどこから申請するんだっけ？」

を判断しなければならなくなります。

段階移行が必要なら、

「この部署は、この日からすべて新システム」

のように、可能な限り利用者や部署単位で入口を明確にした方が混乱を抑えられます。

研修は「長時間を一度」より「短時間を複数回」

新しいシステムを導入するとき、説明会を一度開催し、マニュアルを配って終わりにすることがあります。

しかし、説明を聞いた直後に、すべての機能を使うとは限りません。

実際にその申請をするのが1か月後なら、その頃には操作方法を忘れているかもしれません。

そのため、私は長時間の研修を一度だけ行うより、

• 利用開始前に変更点と目的を説明する

• 利用開始直前に実際の操作を説明する

• 利用開始後に質問を受ける

• 実際に発生した間違いを共有する

といった形で、短い接点を複数回作る方が定着しやすいと考えています。

また、全員に同じ説明をする必要もありません。

申請者。
承認者。
管理者。
承認後の実務担当者。

必要な情報はそれぞれ違います。

自分に関係のない説明が長く続くと、本当に必要な部分まで聞かれなくなります。

「全員に全部説明する」のではなく、その人が実際にやる仕事に合わせて説明を分けることも大切です。

改善期間中は、一時的に仕事が増えると最初から認める

業務改善を進めるとき、

「新しい仕組みにすれば、すぐ楽になります」

と言いたくなることがあります。

しかし、実際にはすぐには楽になりません。

テストがあります。

研修があります。

移行があります。

問い合わせがあります。

不具合の修正があります。

新しい仕組みが定着するまで、一時的に仕事が増えることがあります。

私は、この事実を隠さない方がいいと思っています。

例えば、

「最初の数週間は負担が増えます。ただし、旧運用はこの日で終了します。その後は、この作業がなくなります」

と最初から伝える。

そうすれば、現場も「いつまでこの状態が続くのか」を理解できます。

必要なら、移行期間中だけ通常業務の期限を調整したり、別の仕事を減らしたりすることも検討します。

今までの仕事をすべてそのまま続けてもらいながら、

「改善活動にも協力してください」

では、業務改善が現場の善意に依存します。

PwC Japanの生成AIに関する調査でも、効果創出には、単なるツール利用ではなく、経営リーダーシップの下で目的設定、推進リソースの確保、業務プロセスやガバナンスの整備まで含めた全社的な改革が重要だと整理されています。

対象が生成AIであっても、この点は通常の業務改善とかなり共通していると感じます。

ツールを入れるだけでは、仕事は変わりません。

仕事のやり方そのものを変えるところまで設計する必要があります。

新しい仕事を始めるなら、「何をいつやめるか」まで決める

ここまで何度も業務改善に関わり、失敗も経験して、今は新しい仕組みを入れるときに「導入するもの」だけを決めないようにしています。

同時に確認するのは、

• 何の仕事をやめるのか

• いつからやめるのか

• 新旧の二重運用はいつまで続けるのか

• 移行期間中の問い合わせを誰が受けるのか

• 何を確認できれば移行完了とするのか

• 新しい仕組みがうまく動かなかった場合、どこまで戻すのか

です。

新しいシステムを公開すること自体は、業務改善ではありません。

新しい仕事を一つ追加しただけで、古い仕事がそのまま残っているなら、現場から見れば仕事が増えただけです。

だから私は、

業務改善は、「何を始めるか」だけでなく、「何をいつやめるか」まで決めて初めて完成する

と考えるようになりました。

「前の方が楽だった」という声が出たときも、すぐに「変化に抵抗している」と捉えない。

その人は新しい仕組みに反対しているのではなく、

古い仕事が残ったまま、新しい仕事だけを追加された状態

に反応しているのかもしれません。

その場合、変えるべきなのは現場の意識ではありません。

移行の設計です。

業務改善は、システムが完成した日には終わらない

良い仕組みを作ることと、その仕組みが現場で使われ続けることは、別の仕事です。

業務改善を定着させるには、システムやフローそのものだけではなく、

• 誰と事前に合意するか

• 何を廃止するか

• いつ廃止するか

• どの単位で切り替えるか

• 一時的な負担をどう吸収するか

• 誰に、いつ、何を説明するか

• 問い合わせをどこで受けるか

• どの時点で定着したと判断するか

まで設計する必要があります。

業務改善が嫌われるのは、現場に改善意識がないからとは限りません。

楽になる未来より先に、覚えること、試すこと、確認することが増えるからです。

そして、古い仕事が残ったままであれば、未来になっても楽にはなりません。

だから業務改善を始めるときは、

「新しく何を始めるか」

だけではなく、

「その代わりに、何をいつやめるか」

をセットで決める。

業務改善の成功は、新しいシステムを公開した日には決まりません。

利用者が新しい方法に慣れ、古い仕事がなくなり、それが特別な「改善活動」ではなく日常業務として自然に回るようになったとき。

そこまで到達して、初めて改善が実現したと言えるのだと思います。

社内申請・承認フローを実際に見直したい方へ

社内申請や承認フローについて、

• 既存申請をどう棚卸しするか

• 何を維持・廃止・統合するか

• 承認権限をどう整理するか

• 代理承認や組織変更へどう対応するか

• 新旧システムをどう移行するか

まで具体的に整理した有料記事も公開しています。

「社内申請をどう見直す？ 既存ワークフローの棚卸し・再設計・システム移行の実務」

数百人規模の新会社立ち上げで実際に使った方法をベースに、既存企業でも使えるワークフローの見直しと移行手順を13章で整理しました。

自社の申請をそのまま棚卸しできる、Excelワークブックの空欄版と記入例版も付属しています。