ノウハウ継承に失敗した話（そうではないことを願って）

身を引くにあたって、ノウハウの継承にはかなり力を入れたつもりだった。ドキュメントを整理し、口頭でも説明した。「このタスクは毎月X日にやらないと本当にマズい」「この書類はここに気をつけて、こう書く」といったことを、ひとつずつ伝えてきた。

結果としては、結構難しかったというのが現時点での評価だ。

正直、がっかりしており残念である。ただ、何がうまくいかなかったのか、自分の側の反省も含めて整理しておきたい。

この文章は、経験者が持っている「状況を見て次に何をするか」という判断能力を、どうやって別の人間に移植するかということがテーマで、結局、私は情報はそれなりに移植できた自覚があるが、判断能力は思ったほど移植できなかった、そこが自分の限界だったという話である。

伝えたかったこと

私が教えたかったのは「俺のやり方をそのままやれ」ではない。むしろ逆で、自分で考えて回せる力を身につけてほしかった。具体的には、次のような考え方の切り替えだ。

ところが、反応はほぼ左側ばかりになる。

言われたことだけをやり、明示された期限しか期限と認識せず、判断は責任を避ける方向に寄る。その結果、期限は延びるか守られない。

たとえば、外部から月末締めの作業があるとする。本当は、その前に確認や差し戻しの時間が必要なので、自分たちとしては月の半ばには着手していないと危ない。ところが実際には、月末が近づいてから動き出し、確認で問題が見つかって間に合わない。あるいは、判断に迷う場面で自分で決めずに確認待ちにして、その間に期限が過ぎる。

わざわざ自分たちからそれを選びに行っていることに、愕然とする。保身のための選択が、かえって全体のリスクを増やしていることが伝わらなかったことは残念である。

反省と分析

現象を分析してみる。

1. 判断力は説明では渡らない

手順や知識はドキュメントで渡せる。でも「このタスクを落とすとマズい」という感覚や、逆算して動く習慣は、説明を聞いただけでは身につかない。

自分がその感覚を持てるようになったのは、過去に実際に危ない目に遭ったり、ギリギリで回避したり、逆に先回りしたおかげで楽に済んだりした経験があるからだ。つまり、自分の「感覚」の正体は、積み重なった経験の要約にすぎない。

「経験がないと理解しにくいだろうが、ずいぶん後になってしまうから、事実を受け入れてほしい」と口酸っぱく言ったが、それを言葉にしたところで、経験そのものは伝わらない。要約だけ渡しても、元の経験がない人にとっては、ただの注意書き以上の解釈はしない。

2. 「感覚を身につけなさい」は指示になっていなかった

自分の伝え方には「感覚」「意識」といった言葉がまず率先して出る。受け手からすると、何をすればいいのか分からないのはそうだろう。

そこで、「何日に何をするか」まで落とし込んだ。ところが、それでも伝わりきらなかった。手順に落とすと、今度は「手順に書いてあることだけやればいい」になる。手順に書いていない事態、たとえば前工程が遅れた、必要な情報が揃っていない、といった状況になった瞬間に止まってしまう。

手順主義の畑で育った人材の場合、この先がかなり弱い傾向にある。例えば、基本の和声理論を知ったピアニストなら、キーを変えて新たな組み合わせの別の音楽を奏でることができる訳だが、基礎を抑えずHowを求めすぎてる傾向があるので、そこに辿り着ける人が限られる。

「感覚」のままでは行動にならず、「手順」にすると判断が抜け落ちる。その間を埋める何かが必要だった。

3. 「分かった」と「できる」の間には距離がある

ドキュメントを渡し、説明し、私が横にいる間に実際に回してもらい、詰まったところや間違えたところを指摘した。それでも同じことが繰り返されてしまう。

説明を聞いて頷くことと、一人になったときに「今何をすべきか」が出てくることは別の能力だと考えている。これは相手が嘘をついているわけではないだろう。知識として理解することと、状況に応じて取り出して使うことが違う、というだけの話だ。私も別に折々の際には、後者まで想像・理解できなくても、とりあえず「ハイ、分かりました」と言っておく。

もう一つ足りなかったのは、私が横にいる間の「実施」は、本当の意味での実施ではなかったということだ。困れば私に聞ける。間違えれば私が止める。その状態でうまくできても、一人で回せる証明にはまだなっていない。

願わくば、「一人で回せるようになったか」を判定するところまでやり切りたいところだった。「説明した」「やってもらった」ではなく、「こちらがいなくても、予定を立て、判断し、問題を発見し、必要なら相談できる」ことを完了条件にしたかった。そこまでいかないと、やはり組織は前進しないと今はより確信を強めている。

4. 個人の問題だけではない

主体性には個人差がある。ただ、それだけで説明するのも違う。

自分で判断して失敗すると詰められる。指示通りにやって問題が起きても「指示通りやりました」と言える。そういう環境なら、後者を選ぶ人が増えるのはある意味自然で、そこには私も同情できる。

私が教えようとしていたのは「全体を見て、先回りして、合理的に判断する」という仕事の仕方だった。一方で同じ組織から返ってくるメッセージが、

• 勝手なことをするな
• 問題を起こすな
• 自分の担当範囲を守れ
• 判断に困ったら上に確認しろ

だとしたら、両者は一致しない。その状態で「主体的になれ」と言っても難しい。受け手からすれば、私の言うことと組織の言うことのどちらに従うかという話になり、残る側の組織に合わせるのは当然だ。

主体性を求めるなら、主体的に判断した人が損をしないことは、必要条件になる。 ここは自分一人ではどうにもできなかった。

次にどうするか

手順ではなく「判断の構造」を渡す

「毎月X日にやってください」だけでは、X日という数字しか残らない。渡すべきなのは、その日付が決まっている理由と、崩れたときの動き方なのだが、そこが口頭ではなく、深く言語化できていることは1つ重要な点だろう。

次のようなものだ。

月次処理A（毎月X日）

• なぜX日か：この処理の結果を使ってY（X+3日）が動き、その結果がZ（月末の外部期限）に提出されるため。X日を落とすと、後続すべてが連鎖的に遅れる
• 内部期限：X−2日までに事前確認を終える。ここで不足があれば差し戻しの時間が取れる
• 危険信号：X−2日の時点で必要な情報が揃っていない / 前工程の担当から連絡がない
• 危険信号が出たら：その日のうちに〇〇に状況を共有し、X日に間に合うかどうかの見込みを伝える
• 落としたらどうなるか：Zの提出が遅れ、外部から問い合わせが来る。影響は自チームだけでは済まない

ここまで書いてあれば、本人が逆算しなくても「いつ危ないのか」「危ないときに何をするか」が分かる。手順書というより、判断の地図に近い。とはいえ読まなければそもそも学ぶこともないので、難しいものだが。

作業ではなく判断させる

作業を正しくこなせても、手順にない事態で止まるなら、やはり継承はまだ終わっていない。よって作業そのものではなく、判断を問題として与える。

たとえば、こんなケース問題を出す。

• 「今日はX−3日。前工程から来るはずの情報がまだ届いていない。あなたは今日、何をしますか？」
• 「X日当日、作業中に想定外のエラーが出た。自分で対処できるか分からない。誰に、何を、どう伝えますか？」
• 「来月、X日が連休にかかる。いつ作業しますか？ それを誰と調整しますか？」

答えが出なければ、その場で教える。答えが出たら「なぜそう判断したか」を聞く。正解を当てることより、判断の筋道が通っているかを見る。

そして、説明 → 実施 → 判断 → フィードバック → 再実施 のループを何度か回す。士気が高いとは言えない集団である条件の場合、10回で身につくことも期待しない方がいい。

段階的に手を離す

横で見ている状態から、いきなりゼロにしない。段階を決めて、少しずつ手を離す。

段階3と4が一番大事で、ここで「言われる前に動けたか」「自分から相談できたか」を見る。ここのループが構築しにくかった。

仕組みで判断を引き出す

人の考え方をすぐに変えるのは難しい。よって、考え方が変わらなくても事故が起きにくい展開をゴリゴリに出す。

• タスクを「作業」ではなく「期限から逆算したイベント」として管理する
• 内部期限をカレンダーに登録し、外部期限と同じように「外から見える期限」にしてしまう
• 各タスクについて「なぜこの日なのか」「落とすと何が起きるか」を明示する
• 期限に間に合わないと分かったときの初動と、相談先を決めておく
• 判断が必要になる典型例を、ケースとして残しておく
• 「何をしたか」だけでなく「なぜそう判断したか」を確認する
• 残っているリスクは、上長に書面で共有しておく

とはいえ、そもそも日常タスクで満稼働すぎる状況だと、各々が働き方改革をゴリゴリに出すのは難しい。最後に余裕が出来たので、私は溜め込んでいた「オレだったらこうする」案を大量にモデル成果物として提示したが、結局受け取り側も満稼働なので、ノイズのように受け取られ、あまり関心はないようだった。これらのモデルは経験の蓄積の集合体なのだが、ちょっと残念だ。浸透力というのは私には非常に弱い。

ともかく「分からなければ聞く」だけでなく、「分からないことを自分で発見する」ところまで求めなければなるまい。「聞いてくれれば答える」という状態は、聞くべきことに気づける人にしか機能しない。

失敗をどう評価するか

やったことを全部否定する必要はないと思っている。ドキュメントを整理し、説明し、実際にやってもらい、間違いを指摘し、重要な期限は繰り返し伝えた。それでも十分には継承できないこともある。

ノウハウには、文書化できる部分と、経験によってしか形成されない部分がある。後者については、経験する機会を意図的に設計する必要がある。今回は時間的な制約の中で、それを十分に積ませられなかった。これは自分の反省点だ。

本来目指すべきなのは「自分がいないと困る状態」ではなく、「自分がいなくても、同じように考えて判断できる状態」である。この点はより方向性が間違っていないと実証されたと思う。私が残したかったのは、

• なぜそうするのか
• 何を見て判断するのか
• どこからが危険か
• 異常をどうやって早く検知するのか
• 間に合わないときにどう動くのか

という判断モデルである。

お気持ち

引き継ぎとは、本来、今行っている案件の情報だとか、作業の手順を残すだけではあってはならない。ノウハウ継承も責務として行うべきで、情報を渡すことではなく、「判断できる人」を作ることだと、むしろ確信は深めている。

一方で、うまくいかなかったときに、すべて教える側の責任ではないなと開き直って思ってる部分は正直にある。

• 教える側には、伝え方や仕組みを改善する責任がある
• 受ける側には、自分で考え、試し、失敗し、分からないことを発見する責任がある
• 組織には、主体的に動いた人が損をしない環境を作り、継承に必要な時間を見積もる責任がある

この三つが揃わなければ、本当の意味でのノウハウ継承はなかなか成立しない。これを揃えるスキルフルな人間になるにはどうすればよいのだろうか。その難しさを身をもって経験した。

次に同じ機会があるなら、更に早い段階から、判断を渡すことを前提に設計したいかな。