2026-08-09
稟議より先に、1部署を帰らせる——改善が「伝染」する条件の整え方
Argora編集部
全社を説得しようとするほど、改善は止まりやすい。効いたのは、隣の部署が先に定時で帰る場面を作ること。1部署の成功が問いかけを生み、改善はじわじわと広がっていく。伝染の条件を整える考え方。
全社を動かそうとして、逆に止まる
全社への説得を先行させると、逆に改善が止まりやすい。
組織に業務改善を広げるとき、多くの担当者が最初に考えるのは「全社への説得」だ。経営層への提案、部門長会議でのプレゼン、稟議書の作成。丁寧に進めようとすればするほど、改善は「承認を待つもの」になっていく。
承認フローが長くなる弊害については「承認を増やすほど現場が止まる」でも触れたが、改善の普及においても同じ構造が起きやすい。全員の合意を先に取ろうとすることで、誰かの反対が理由で止まり、担当者だけが消耗していく。
合意形成の正攻法が、逆に前進を妨げているケースがある。
隣の部署が先に帰る、その絵の力
改善を広げた決め手は、資料でも稟議でもなく、隣の部署が先に帰る場面を作ったことだった。
業務改善を最初の1部署で試した。その部署が定時で帰れるようになった。すると数週間後、隣の部署から「何をやったの?」と声がかかった。説明会を開いたわけでも、展開計画を立てたわけでもない。ただ、隣の部署の様子が「見えた」だけだ。
「押し切ったという感覚はない。なんとなく広がっていって、気づけば社内の仕組みの7割がこれになっていた」
この言葉が示すのは、説得ではなく伝染という広がり方だ。
人は、説明された未来より、目の前の現実の方に動かされる。改善の効果を資料で見せるより、「あの部署が今日も定時に帰っている」という光景の方が、動機づけとして強く機能する。稟議を通すエネルギーを、1部署を先に動かすことに使う。それだけで、後の展開がまるで違ってくる。
伝染を起こすための3つの条件
改善を「伝染しやすい形」にするには、可視性・距離感・タイミングの3点を整える必要がある。
うまくいった現場を振り返ると、共通する条件が浮かんでくる。
- 変化が「見えやすい」部署から始める
定時退社、処理時間の短縮、問い合わせ対応の減少。数字より「見た目の変化」が大切だ。隣の部署が変わったことを、資料ではなく場面として感じ取れる状況を先に作る。
- 最初の部署を「ノウハウ提供係」にしない
成功した部署が「教える役」に回ると負担が増え、意欲が落ちる。「見たければ見に来てください」くらいの距離感が、伝染のサイクルを持続させる。
- 問いかけが来るまで待つ
「うちもやりたい」という声を待ってから動く。声が来てから説明するのが、自発的な広がりを生む順番だ。頼まれる前に展開しようとすると、「押しつけ」と受け取られやすい。
こうした進め方は、DXの文脈でいう「小さく始める」とも重なる。失敗の記憶を持つ組織への提案の通し方でも触れているように、過去に一斉導入で痛い目を見た組織ほど「全社同時」の提案を警戒しやすい。1部署の成功体験を積み上げることが、その記憶を少しずつ塗り替えていく。
また、どの部署から始めるかを絞り込む作業自体が、改善全体の設計に関わる。DX伴走支援「しぼる」では、優先順位の整理から最初の一手の設計まで、一緒に考える支援をしている。
改善の種が育つ組織には、共通して「見せる場所」がある。全社説得ではなく、1部署の成功を可視化すること。それが、誰も頼んでいないのに改善が広がる、最初の条件だ。
FAQ
よくある質問
社内改善を全社に広げるにはどうすれば良いですか
全社説得より、まず1部署で成功させて「見える形」にすることが有効です。隣の部署が成果を目撃することで「うちもやりたい」と動き始める伝染の流れが、組織全体を動かします。
稟議が通らないとき業務改善はどう進めればいいですか
稟議を通す前に、小さな範囲で先に動かすことを検討してください。1部署の成功が可視化されると、周囲の問いかけが後押しとなり、自然に合意形成が進むケースがあります。
DX推進を社内に浸透させるコツは何ですか
「説得する」より「見せる」が基本です。隣の部署が先に定時で帰る絵を作ること。体験していない人への説明より、体験した人の様子を目撃する方が動機づけになります。
Related
Argo:デジタルの、ほかの読みもの
2026-08-11
自動化は業務フローを固定する——AIエージェントを乗せる前に確かめること
AIエージェントを業務に組み込む前に、問うべきことがある。自動化はフローを固定する技術であり、整っていないものを乗せれば、誰も読めない仕組みが生まれる。
2026-08-10
「非効率」と呼ぶ前に受け取るべきもの——現場の経験を失わないDXの進め方
アナログな業務を「非効率」と断じてデジタル化を進めると、現場が培った判断力と責任感ごと失いかねない。経験を受け取ってから設計することが、DXを根付かせる起点になる。
2026-08-10
ベンダーを動かすのは仕様書ではない——事業者が磨くべき「課題を語る力」
システム開発の失敗の多くは、技術ではなく「課題の伝わらなさ」から起きる。事業者がITを学ぶとはコードを書くことではなく、問いを立てる力を身につけることだ。