※この記事は、特定の会社・部署・個人を指すものではありません。職場で起きがちな構造を、具体的な内容が分からないように抽象化して整理したものです。
はじめに：改善活動が「めんどくさいもの」になる瞬間
職場改善という言葉は、聞こえはいい。
作業しやすくする。ミスを減らす。情報を見やすくする。進捗を共有しやすくする。現場の負担を減らす。
どれも本来は、会社にとっても働く人にとってもプラスのはずです。
しかし実際の職場では、改善活動をした人ほど疲れていくことがあります。
なぜか。
改善そのものが悪いのではなく、改善後に発生する「後出しの指摘」「責任の押し戻し」「個別サポート」「感情的な確認」が重すぎるからです。
ある改善施策を進めたとします。申請ルートを通し、所属長や関係者の承認も得て、手順どおりに対応する。ところが対応後に、別の方向から「なぜそんなことにお金を使ったのか」「本当に必要だったのか」と言われる。
こうなると、改善担当者は思います。
「承認を取った意味は何だったのか」
「ルートを通したのに、なぜ自分が責められるのか」
「次からは何もしない方が安全なのではないか」
この瞬間、改善活動は前向きな仕事ではなく、防衛が必要なリスク業務になります。
問題は費用ではなく、承認フローの安全性
改善にお金がかかること自体は、別におかしいことではありません。
備品、システム、ツール、教育、資料整備、環境改善。どれも一定の費用や時間を使います。
問題は、費用が発生したことではありません。
問題は、承認済みの対応に対して、後から別の人が感情的に文句を言える構造です。
本来、確認すべきなのは次のようなことです。
- 誰の承認があれば実施してよいのか
- いくらまでなら現場判断でよいのか
- どのような目的なら費用を使ってよいのか
- 費用対効果は何を基準に判断するのか
- 後から指摘する人は、最初の承認フローに入っていたのか
ここが曖昧なまま改善を進めると、担当者は常に後出しで殴られる可能性を抱えます。
その結果、会社全体がこうなります。
「改善したいけど、やると面倒が増える」
「提案した人が最後まで面倒を見ることになる」
「承認を取っても安全ではない」
「なら、黙って現状維持の方がいい」
これは、改善が苦手な会社というより、改善した人を守る設計がない会社です。
「サポートセンター化」する改善担当者
改善活動のもう一つの落とし穴は、導入後に担当者がサポートセンター化することです。
たとえば、何か便利な環境や仕組みを導入したとします。
本来の目的は、現場が自分で使いやすくなることです。
しかし運用設計が曖昧だと、導入した人のもとに次々と質問が来ます。
「これはどう使うの？」
「どこを見ればいいの？」
「設定はどうするの？」
「うまく動かない気がする」
もちろん、本当の不具合やシステム上の問題なら担当部署が対応すべきです。
でも、基本的な使い方や自己確認で解決できることまで全部受けると、改善担当者は疲弊します。
ここは切り分けが必要です。
- 承認に関する話：承認済みの申請に基づく対応です
- 基本的な使い方：各自で確認してください
- 不具合や接続不良：状況を添えて連絡してください
- ルール変更：申請ルールや費用基準を明確化してください
この線引きがないと、改善担当者は「便利にした人」ではなく、「便利にした後のすべてを背負う人」になります。
それでは、次の改善をやりたくなくなるのは当然です。
リーダーシップを人格と気合に寄せすぎると重い
職場ではよく、リーダーシップが人格論で語られます。
明るく巻き込む。
熱意を持って伝える。
周囲を動かす。
信頼関係を作る。
もちろん、それらが不要という話ではありません。
ただし、それだけに寄せすぎると危険です。
なぜなら、リーダーシップが「人格」「気合」「巻き込み力」だけで語られると、権限も報酬も明確な責任範囲もない人に、感情労働だけが乗るからです。
相手が動かなかったときに、こう言われることがあります。
「もっと巻き込めていればよかった」
「伝え方が足りなかった」
「周囲を納得させる力が必要」
しかし、本当に必要なのは人格の強さでしょうか。
むしろ必要なのは、次のような設計です。
- 目的を明確にする
- 役割を分ける
- 期限を決める
- 判断基準を置く
- 依頼内容を記録する
- 進捗確認の場を決める
- 対応漏れをリスト化する
リーダーシップとは、気合で人を動かすことではありません。
人が動きやすい状態を設計することです。
「自分はマイクロマネジメントしていない」のズレ
マイクロマネジメントの厄介なところは、やっている本人ほど自覚しにくいことです。
本人の中では、こう見えています。
「確認しているだけ」
「品質を見ているだけ」
「教育しているだけ」
「ちゃんと進めてほしいだけ」
「責任があるから見ているだけ」
しかし、受ける側はこう感じることがあります。
「任されていない」
「途中で詰められる」
「正解が後出しになる」
「判断する余地がない」
「態度や納得感まで管理されている」
ここに大きなズレがあります。
マイクロマネジメントかどうかは、本人の自己認識だけでは決まりません。
大事なのは、受ける側に判断余地が残っているかどうかです。
目的と期限と基準だけを示して任せているのか。
それとも、やり方、進め方、態度、納得感、空気まで握りに行っているのか。
後者なら、本人がどう思っていても、受け手にとってはかなり重い管理になります。
「前回共有済みです」だけでよい場面もある
進捗確認や教育の場では、「前回言ったかどうか」が問題になることがあります。
そのとき、感情戦に入ると消耗します。
「言いましたよね」
「聞いていません」
「どういうつもりですか」
「みんなそれで納得しているんですか」
こうなると、論点がどんどんずれていきます。
本来の論点は、誰が悪いかではありません。
共有事項が反映されていないなら、次から漏れないようにする仕組みが必要なだけです。
だから、まずは事実だけ返す。
「前回共有済みです」
そのうえで、必要ならリストにする。
- 共有日
- 共有内容
- 反映先
- 担当
- 期限
- 状態
- 備考
これで、「言った・聞いてない」の空中戦を避けられます。
口頭の記憶勝負ではなく、台帳で確認する。
これだけで、かなり消耗が減ります。
改善活動に必要なのは、やる気ではなく防衛設計
改善活動が続く職場には、共通点があります。
改善した人が損をしにくい構造があることです。
逆に、改善が止まる職場には、次のような特徴があります。
- 承認ルートが曖昧
- 後出しで文句を言える
- 改善した人が運用まで全部背負う
- 基本操作の質問まで担当者に集まる
- 責任範囲が広がる一方で権限はない
- 失敗や不満だけが可視化される
- 「巻き込み力」「熱意」「納得感」で片付けられる
この状態で「もっと主体的に改善しよう」と言われても、人は動きません。
なぜなら、改善した先に待っているのが報酬ではなく、追加負担と後出し指摘だからです。
必要なのは、気合ではありません。
改善担当者を守る仕組みです。
実務で使える返し方
後出しで「なぜ対応したのか」と聞かれた場合は、反省文にしない方がいいです。
使える表現はこれです。
本件は、所属長承認済みの申請に基づいて対応しています。
今後、費用基準や対象範囲を変更する場合は、申請ルール側で明確化いただければ、その基準に沿って対応します。
これなら、担当者の勝手判断ではないことを示せます。
基本操作の問い合わせには、こう切り分けます。
基本的な使い方や表示設定については、各自で確認をお願いします。
設定上の不具合や接続不良がある場合は、状況を添えてご連絡ください。
これで、自己確認範囲と本来対応すべき不具合を分けられます。
進捗共有の反映漏れには、こうします。
前回共有事項の反映漏れ防止用に、確認リストを作成しました。
今後はこちらに「共有内容・反映先・担当・期限・状態」を記載して、次回確認します。
これは、誰かを責めるためのリストではありません。
感情戦を避けるための防衛結界です。
まとめ：人格論に逃げず、設計に落とす
職場の問題は、すぐ人格論にされがちです。
巻き込み力が足りない。
熱意が足りない。
責任感が足りない。
確認が甘い。
主体性が足りない。
しかし、本当に見るべきなのは構造です。
承認済みなのに後から文句を言われるなら、承認フローが弱い。
改善後に質問が集中するなら、運用設計が弱い。
進捗共有が反映されないなら、共有事項の台帳がない。
マイクロマネジメントが多いなら、任せ方と判断基準が曖昧。
リーダーシップが重いなら、人格ではなく仕組みに落とせていない。
改善活動を続けるために必要なのは、強い人格ではありません。
目的、役割、期限、承認、記録、対応範囲を明確にすることです。
人を気合で動かすのではなく、人が動ける状態を作る。
それが本当の意味で、職場を少し楽にする改善です。
