導入：見ていないのに、辞める時だけ理由を聞く
職場では、普段その人の仕事をきちんと見ていないのに、辞めようとした瞬間だけこう聞かれることがある。
なんで辞めるの？
もったいないよ
価値ある仕事なんだから続けてよ
みんな助かってるのに
頼られてるんだから
もう少し協力してよ
一見、引き止めの言葉に見える。
しかし、そこには大きな違和感がある。
普段は見ていない。
負荷も測っていない。
仕事も減らしていない。
担当範囲も決めていない。
教育後の窓口も決めていない。
自動化で作った余力に、さらに仕事を積んでいる。
それなのに、辞める時だけ「なんで？」と聞く。
これは、本人にだけ説明責任を求めているように見える。
本来、会社側も考えるべきである。
なぜその人に仕事が集まったのか
なぜその人が軽く見えていたのか
なぜ自動化で作った余力を追加業務で埋めたのか
なぜ価値ある仕事なのに正式業務にしなかったのか
なぜ後任・評価・工数・優先順位を設計しなかったのか
この記事では、辞めようとした時に発生する「なんで辞めるの？」問題を、離職理由の説明責任ロンダリングとして整理する。
結論から言う。
価値があるなら、善意でやらせるな。業務設計にしろ。
1. 「なんで辞めるの？」は、時に説明責任の転嫁になる
もちろん、退職理由を聞くこと自体が悪いわけではない。
会社が改善のために理由を聞くことはある。
本人が話したい範囲で共有することもある。
建設的な退職面談なら意味がある。
しかし、問題は次のような場合である。
普段は見ていない
負荷を測っていない
相談を拾っていない
業務量を減らしていない
本人が作った仕組みにさらに仕事を積む
辞める時だけ理由を聞く
この場合、「なんで辞めるの？」は、改善の問いではなく、本人への説明責任の押し戻しになる。
つまり、
会社が見ていなかった
↓
構造を放置した
↓
本人が限界になる
↓
辞めようとする
↓
会社が「なんで？」と聞く
↓
本人が理由説明を求められる
これは、離職理由の説明責任ロンダリングである。
本来、会社側にも観察責任がある。
なぜ人が辞めるまで分からなかったのか。
なぜ辞めるまで負荷を見なかったのか。
なぜ辞めるまで正式な業務設計にしなかったのか。
そこを見るべきである。
2. 「価値があるからやって」は危険な言葉である
辞めようとした時や、業務を手放そうとした時に、こう言われることがある。
それは価値がある仕事だから
みんな助かってるから
会社に必要だから
あなたにしかできないから
続けてほしい
この言葉は、一見すると承認に見える。
しかし、危険でもある。
なぜなら、価値があることと、その人が個人で持ち続けることは別だからである。
本当に価値があるなら、会社がやるべきことはこうである。
正式業務にする
担当範囲を決める
必要工数を見積もる
既存業務を減らす
優先順位を決める
後任を作る
評価・対価に反映する
標準書・台本・チェックリストにする
ところが悪い職場では、こうなる。
価値がある
↓
だから善意でやって
↓
だから辞めないで
↓
だから説明して
↓
だからあなたが続けて
これは設計ではない。
価値を理由に、個人依存を継続しているだけである。
3. 自動化で軽く見える人ほど危ない
RPA、VBA、テンプレート、標準書、台本、チェックリストを作れる人は、仕事が軽く見えることがある。
なぜなら、その人は仕事を根性で処理していないからである。
毎回手作業しない
毎回考えない
毎回同じ説明をしない
毎回同じ確認をしない
自動化・標準化・台本化で軽くしている
つまり、その人が軽く見えるのは、暇だからではない。
仕事を軽くする設計をしているからである。
しかし、周囲がそれを理解していないと、こうなる。
あの人は余裕がありそう
あの人は早い
あの人ならできる
じゃあこれもお願い
これは危険である。
その人がRPAやVBAで作った余力は、無限の空き時間ではない。
業務改善によって作った安全余白である。
その余白を、また未定義タスクで埋めてしまうと、改善した意味がなくなる。
外向きにはこう言えばよい。
現在の業務が軽く見える部分は、RPA・VBA・標準化で手作業を減らしているためです。
追加で業務を載せる場合は、その分どの業務を下げるか、優先順位と対応範囲を確認させてください。
短く言うなら、
自動化で工数を下げているだけなので、余力として無限に追加できるわけではありません。
4. 仕事を増やす前に、減らす仕事を決める
業務設計で最も重要なのは、これである。
仕事を増やす前に、減らす仕事を決める。
新しい仕事を渡すなら、同時に次を決める必要がある。
代わりに何を減らすか
何をやめるか
何を後回しにするか
どの優先順位を下げるか
例外時は誰が判断するか
いつ見直すか
これがない職場では、仕事は増える一方である。
悪い例はこうである。
新しい仕事を渡す
↓
頑張って
↓
周りを見て
↓
協力して
↓
人の気持ちを汲んで
↓
できていないなら指導
↓
疲れたら本人の問題
これは仕事を渡しているのではない。
負荷を積んでいるだけである。
追加業務への返しは、これでよい。
対応自体は確認します。
ただ、追加で対応する場合、代わりに何を下げるか、優先順位と対応範囲を確認させてください。
もっと短く言えば、
追加するなら、減らすものも決めてください。
5. 教育者を永久サポート窓口にしない
高レベルな教育者がいても、組織側が「受け取っても安全」を作らなければ、技術は伝播しない。
教育者が潰れる職場では、次のようなことが起きる。
この研修もあなた
あの研修もあなた
教えたんだから今後もあなた
新人が分からないならあなた
例外が出たらあなた
次の教育もあなた
困ったらあなた
これは教育ではない。
教育者の永久サポート窓口化である。
本来、教育は次のように分ける必要がある。
教育者：
初期理解、資料作成、台本化、つまずきポイントの標準化
運用担当：
日常運用、通常質問、実務処理
上長：
正式担当化、範囲決定、優先順位、既存業務の削減、失敗時の責任
教育開始時点で、出口条件を置く必要がある。
本教育の目的は、初期理解と標準手順の共有です。
教育後の通常運用・日常質問・例外判断・正式担当化については、担当部署および上長判断でお願いします。
教育者が恒常的な問い合わせ窓口になる前提ではありません。
短く言うなら、
研修実施と、以後の業務責任・問い合わせ窓口になることは別だと認識しています。
教えた人を一生聞いていい人にすると、高レベル教育者から順番に燃え尽きる。
6. 受け取っても安全な構造を作る
人が新しい技術や業務を受け取りたがらない時、単にやる気がないとは限らない。
むしろ、防衛している場合がある。
分かると言ったら担当にされる
できると言ったら全部渡される
質問したら自分の仕事になる
失敗したら詰められる
前任者は外れるのに権限は来ない
通常業務は減らないのに新しい責任だけ増える
この状態では、教育しても伝播しない。
受け手はこう言うしかない。
まだ分からないです
ちょっと難しいです
自分には無理です
そこまでは持てません
これは能力不足ではなく、防衛反応であることがある。
対策は、技術移転の前に責任移転を設計することだ。
理解と担当化を分ける
見る→一緒にやる→一部だけやる→監督付きでやる→正式担当化
仕事を増やす前に減らす仕事を決める
通常処理と例外判断を分ける
失敗時の扱いを先に決める
教育者を永久窓口にしない
受け取っても戻せるルートを作る
評価に反映する
一言で言えば、
教育とは、できる人の技術を渡すことではなく、受け取る人が防衛しなくていい構造を作ること。
7. 「みんなで協力しようね」は、設計がなければ次の犠牲者探しになる
人が抜けたり、仕事が増えたりした時、職場ではよくこう言われる。
みんなで協力しよう
残った人で頑張ろう
困っている人を助けよう
お互い様だから
もちろん、協力自体は悪くない。
しかし、設計がない協力は危険である。
なぜなら、実際には「みんな」ではなく、言いやすい人に流れるからである。
正式担当は決めない
仕事も減らさない
ルールも作らない
でも困った人がいたら助けてね
助けやすい人に寄る
これは協力ではない。
負荷の自然流下である。
本当の協力には設計が必要である。
誰が何を持つか
誰が判断するか
何を減らすか
どこまでやるか
例外時は誰に戻すか
いつ見直すか
これが決まっていないなら、「みんなで協力しよう」は、次の人間インフラを探す言葉になりやすい。
返しはこうでよい。
協力自体は必要だと思います。
ただ、誰が何をどこまで持つのか、判断者・優先順位・減らす業務を決めないと、特定の人に負荷が寄るだけになると思います。
短く言えば、
協力するためにも、まず役割と範囲を決めた方がいいと思います。
8. 「あなたの特性」の問題にしてはいけない
業務設計ができる人、RPAやVBAで手作業を減らす人、会議前に台本を作る人、善意ロンダリングを受け取らない人は、職場によっては「特性が強い」「協調性がない」「考え方が独特」と見られることがある。
しかし、それは本当に問題なのか。
その人がやっていることは、実はかなり組織に必要な動きである。
未定義を見つける
担当範囲を切る
判断者を確認する
仕事を減らす
台本化する
標準化する
自動化する
教育を仕組みにする
責任を正しい場所に戻す
善意で穴を塞がない
これは、人格の問題ではない。
むしろ、業務設計が弱い組織に必要な能力である。
悪い職場では、この能力を「扱いづらい特性」として見る。
しかし、本来は逆である。
そういう特性の人を増やすべきである。
あるべき姿で動ける人とは、何でも善意で吸う人ではない。
未定義を見つけ、範囲を切り、仕組みに戻せる人である。
もし管理者がその人の特性や人格を否定するなら、こう言い換えるべきだ。
それは個人の性格問題ではなく、業務設計・役割定義・運用ルールの問題として整理したいです。
もっと短く言うなら、
特性の問題ではなく、担当範囲と判断者の整理の問題だと認識しています。
組織が必要としているのは、空気で動く人ではない。
未定義を未定義として扱える人である。
9. 部長クラスの離職は、組織設計の強いシグナルである
部長クラスが辞めることは、一般社員の離職とは少し重みが違う。
部長クラスには、通常、
年収
立場
社内人脈
裁量
情報
影響力
がある。
それでも辞めるなら、そこには強いシグナルがある。
特に、その人が、
頼れる人
現場から重い話が来る人
教育できる人
マネジメントできる人
帰りが遅い人
みんなに相談される人
だった場合、単なる個人都合だけでなく、構造負荷を疑う必要がある。
重い判断が一人に集中していなかったか
課長層や代理判断者が薄くなかったか
係長層がすでに便利屋化していなかったか
部長不在後の判断ルートが未定義ではなかったか
「ちょっと分かる？」が周辺に漏れ始めていなかったか
人が抜けたことだけを見てはいけない。
その人が抜けたら崩れる構造だったことを見るべきである。
10. 「なんでだろうねー」で終わる職場は、次の善意ロンダリングを継承する
部長やキーパーソンが辞めた時、周囲がこう言うだけで終わることがある。
なんで辞めるんだろうね
残念だね
急だね
後任どうしようね
みんなで協力しようね
これで終わると、組織は学習しない。
本来は問うべきである。
なぜその人に重い話が集中していたのか
なぜその人がいないと判断が止まるのか
なぜ後任が育たなかったのか
なぜ教育者が永久窓口化していたのか
なぜRPAやVBAで作った余力に追加業務を乗せたのか
なぜ価値ある仕事を正式業務にしなかったのか
これを問わないまま「なんでだろうねー」で終わると、次は別の言いやすい人に負荷が流れる。
つまり、善意ロンダリングが継承される。
11. 辞める人に説明責任を押しつけない
退職する人に理由を聞くなら、会社側も自分たちの観察不足を見なければならない。
辞めるまで負荷に気づかなかったのはなぜか
価値ある仕事を正式業務にしなかったのはなぜか
自動化で作った余白を追加業務で埋めたのはなぜか
教育者を永久窓口にしたのはなぜか
みんなで協力という言葉で役割設計を避けたのはなぜか
個人の特性や人格の問題にして、業務設計の問題を見落としていないか
退職理由を本人だけに説明させるのではなく、組織側も構造を説明する必要がある。
そうでなければ、また同じことが起きる。
12. 防衛テンプレート集
12-1. 「価値があるからやって」と言われた時
価値がある業務だとは認識しています。
ただ、継続するには担当範囲・工数・優先順位・引継ぎ体制を会社として整理する必要があると思います。
私個人の善意や自動化で吸収し続ける形では、長期的な運用は難しい認識です。
短く。
価値があるからこそ、個人依存ではなく正式な業務設計が必要だと思います。
12-2. 追加業務を頼まれた時
対応自体は確認します。
ただ、追加で対応する場合、代わりに何を下げるか、優先順位と対応範囲を確認させてください。
12-3. 自動化で余裕があると思われた時
現在の業務が軽く見える部分は、RPA・VBA・標準化で手作業を減らしているためです。
追加で業務を載せる場合は、その分どの業務を下げるか、優先順位と対応範囲を確認させてください。
12-4. 研修後も窓口にされそうな時
研修実施と、以後の業務責任・問い合わせ窓口になることは別だと認識しています。
教育後の通常運用・日常質問・例外判断については、担当者または上長側で整理をお願いします。
12-5. みんなで協力と言われた時
協力自体は必要だと思います。
ただ、誰が何をどこまで持つのか、判断者・優先順位・減らす業務を決めないと、特定の人に負荷が寄るだけになると思います。
12-6. 特性や人格の話にされた時
それは個人の性格問題ではなく、業務設計・役割定義・運用ルールの問題として整理したいです。
短く。
特性の問題ではなく、担当範囲と判断者の整理の問題だと認識しています。
12-7. 辞める理由を深掘りされた時
価値ある業務があることは認識しています。
一方で、継続的に行うには業務量・役割範囲・優先順位・引継ぎ体制を会社として設計する必要があると感じています。
個人依存の形では長期的な継続が難しいと判断しました。
13. まとめ：価値があるなら、個人依存にするな
この記事の結論はシンプルである。
価値があるなら、正式業務にする。
正式業務にするなら、範囲を決める。
範囲を決めるなら、工数を見積もる。
工数を見積もるなら、減らす仕事を決める。
続けたいなら、後任を作る。
教育するなら、教育者を永久窓口にしない。
協力するなら、役割と判断者を決める。
自動化で軽くなったなら、その余白を未定義タスクで潰さない。
特性の問題にする前に、業務設計の問題として見る。
辞める人にだけ「なんで？」と聞いても遅い。
本当に聞くべきなのは、
なぜ辞めるまで見なかったのか
なぜ価値ある仕事を設計しなかったのか
なぜ善意で回していたのか
なぜ仕事を増やす前に減らす仕事を決めなかったのか
なぜ業務設計できる人を、扱いづらい人として見てしまったのか
である。
最後に、この記事の一文を置く。
価値がある仕事ほど、善意で持たせてはいけない。設計にしなければならない。
