最終日までに書いてもらえればいいので！
担当者に「辞めます」と言われた翌日にやることはたいてい決まっていて、最終出社日までに引き継ぎ書を書いてもらう段取りを組みます。
その前に、確かめることが1つあります。その人に集まっていたのが、作業なのか仕組みなのかです。仕組みだった場合、引き継ぎ書を何枚書いてもらっても、その人が辞めた翌月に止まります。
この見分け方は、社内のkintone開発を一任されたまま辞めた私が、思いつくものを全部渡したあとに何が残ったかから作りました。渡したつもりで渡っていなかったものが、1つだけあります。
それが何かは本文で書くとして、この記事を読み終えると次の3つが決められます。
- 引き継ぎ書で止血できる属人化と、できない属人化の見分け方
- 本人が全部渡したつもりでも、渡らないものの正体
- 辞めると言われる前に、隣で1回やらせておく修正の選び方
辞めますと言われた日に、引き継ぎ書より先に確かめること
その人に集まっていたのが作業なのか、仕組みなのか。引き継ぎ書を頼む前に確かめるのは、ここだけです。
辞意を聞いた翌日、管理職の多くは引き継ぎ書のフォーマットを渡します。本人は最終出社日までに、担当している作業の手順を順番に書き出していくわけです。「最終日までに全部書いてもらえれば、なんとかなる」と周りも思っていて、私は書いた側なので、その空気は分かります。
作業が集まっていたのならこの見立てで合っています。手順は書き写せるので、次の人が手順書を見ながら回せば、速度は落ちても止まりません。作業か仕組みかは、辞意を聞いた日にこの3つで見分けがつきます。
- その人が休んだ日に止まったのは、1つの作業か、複数の部署の業務か
- その人が作った画面や自動処理に、他の人の仕事が乗っていないか
- その人が直したあとで動くようになったものが、社内に残っていないか
2つ目か3つ目に当たるなら、手順書を全部書いてもらっても回らない業務が出てきます。その人に集まっていたのが作業ではなく、仕組みだったからです。では、作業と仕組みは何が違うのか。
業務の属人化とシステムの属人化で、止まるものの違い
属人化とは、社内の特定の人がいないと業務が回らない状態を指します。ここにもう1つ、区別を足します。その人に集まっていたのが作業なのか、仕組みなのかです。
業務の属人化で止まるのがその人のやっていた作業なのに対して、システムの属人化で止まるのは、その人が作った仕組みに乗っていた業務の全部です。止まる範囲がまったく違うのに、辞意を聞いた側からは同じ「あの人しか分からない」に見えます。
社内でkintoneやRPAを作った会社を思い浮かべてください。作ったのは1人で、その人が辞めた翌月には、アプリの設定を操作できる人も、月末の集計がどこで動いているかを知る人もいなくなります。期日で飛んでいた通知、他部署が毎日入力していた画面。どれもその人の作業ではありませんが、その人の仕組みです。
2つの違いを、表にしました。
| 業務の属人化 | システムの属人化 | |
|---|---|---|
| 依存しているもの | その人の手順と判断 | その人が作った仕組み |
| 止まるもの | その人がやっていた作業 | その仕組みに乗っていた業務すべて |
| 引き継ぎ書の効き目 | 効く。手順は書き写せる | 使い方までは効く。直し方には効かない |
| 復旧に要るもの | 手順を読める人 | 仕組みを直せる人 |
| 起きやすい会社 | どこでも | 内製化した会社 |
外の会社に頼まず社内の人が仕組みを作ることを内製化と呼び、内製化した会社ほど右の列を抱えています。しかも作った本人が、自分が「仕組み」の側にいると気づいていないことがあります。私がそうでした。
一任されていた側が、辞めるときに渡せなかったもの
気づいていなかった私が、辞めるときに何を渡せて、何を渡せなかったか。順に書きます。
2年間、社内のkintoneアプリの開発と改修を1人で引き受けていました。なぜ辞めたかは別の記事に書いたので、ここでは辞めると決めてからの数週間の話です。引継書を書き、開発まわりのマニュアルを書き、決まっていないことの一覧と進めている途中の施策の経過まで並べて、思いつくものは全部渡したつもりでした。
- 引継書
- 開発まわりのマニュアル
- 決まっていないことの一覧
- 進めている途中の施策の経過
渡せなかったものは、いまでも1つしか挙げられません。私が気付いていないことです。自分が何を知っているかは、自分では全部は分からないので、引き継ぎ書には書く側が自覚しているものしか載りません。いちばん引き継ぎたいものほど、そこに無い可能性があります。
渡す側が気付いていないものは、引き継ぎ書に書けない。
そして辞めたあと、そのアプリがどうなったかを、私は知りません。社外の人間になった時点で、知る手段がなくなります。渡したものが足りていたのかどうかを、渡した側はもう確かめられません。仕組みを作った人が抜けると、それを確かめられる人は社内にも社外にもいなくなります。これが、辞めた側から見たシステムの属人化です。
本人が気付いていないものは、本人には書けません。では、誰が、どうやって表に出すのか。
引き継ぎ書では渡らないものを、辞める前に表に出す方法
本人に書かせる代わりに、本人以外の人に直させます。本人は隣で見ているだけです。
気付いていないことは、書こうとしても出てきません。出てくるのは、他の人が触って詰まった瞬間です。「そこは月末だけ別の処理が走るから」「その項目は消すと通知が止まる」。本人が思わず口に出したその一言が、引き継ぎ書に書けなかったものの正体です。
次の修正依頼が来たら本人が手を動かすのをいったんやめて、隣の席の人に設定画面を開かせ、本人は画面を見ながら口だけ出してみてください。修正には時間がかかりますが、その時間の中に、本人が自覚していなかった判断が全部入っています。やることは4つです。
- いま止まると困る仕組みを、1つ選ぶ
- 次の修正を、本人以外の1人にやらせる
- 本人は隣で見て、詰まったところだけ口を出す
- 口に出した中身を、その場でメモに残す
これは、担当者をもう1人採用する話ではありません。触れる範囲を分ける考え方は関連記事に書きましたが、そこで言った「設定を変えられるもう1人」は、採用では生まれません。本人が辞めると言い出す前に、隣で1回直させたかどうかで決まります。
まとめ：仕組みを直せる人の数を、いま数える
社内で動いている仕組みを1つ書き出して、それを直せる人が何人いるかを数えてください。1人なら、その人が次に直すとき、隣にもう1人置きます。それだけです。
「辞めます」と言われてからではこの1回が作れず、言われる前の何でもない修正依頼のときにしか作れないので、次に依頼が来た日がその日です。私も、これを1回やっていれば渡せたものがあったと考えています。