orangeitems’s diary

クラウド専任の40代インフラエンジニアが書くブログ。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。

結論だけ伝えると、部下は育たない

 

何か、作業を行っていたら問題が発生したとします。問題は複雑で調査が必要です。パッと見、原因まではすぐにわからないので、ここで部下から私に問題がエスカレーションされてきます。私は上級者の位置づけです。

この後私が調査していくのですが、原因の当たりをつけていく作業が始まります。いろんなログを見たり問題発生時の周辺の状況を確認したりしていきます。試行錯誤感は強くいろんな無駄もあります。ただ答えがわからない以上は、全ての可能性を一個一個見ていく必要があります。自分の中の思い込みもあるので、決めつけないようにしていかなければいけません。

これらを散々やった挙句、やっと結論にたどり着きます。全体のストーリーを整え、問題が発生したメカニズムを誰にでも理解可能なように整えます。原因への対策を行い、再発防止策を実装したら、一旦問題は解決です。

どうやって、問題を解決したのか、部下にもフィードバックします。この地点に問題が起こる原因が隠れていて、そのエビデンスがここにあった。だからこういう対応をすると良くなるんだよ、と。部下は「なるほど、わかりました」と良い返事をします。何かわからない点はある?と聞くも「ありません」と言います。

少し前までは、これで指導の仕方としては問題ないと思っていましたが、最近はこれではいけないかもしれないと思うようになりました。

結論から考えて、問題を語ると一直線に見えるのです。

この教え方だと、同じ問題が起こった場合は対処できますが、ちょっとでもひねられると対応してくれません。

問題が起こった時は、さまざまな原因が考えられ、結論は見えないのでどこに行っていいかわからないのです。それを、この教え方では伝授することができません。

問題が発生し部下が私にエスカレーションするのはいいことです。問題を解決することを部下の経験より優先させないといけません。教育的な観点で、問題を放っておくのはカスタマーファーストではありませんから。

必要なのは、私が問題を解決する姿、どんな無駄な調査をしていくかも、部下に公開しないといけないということです。問題解決は一本道ではないよ、と。どんな無駄なことをしないと解決までの道が見えないかまで、その戦いの一部始終を公開しなければいけない、ということです。

なぜ、これを指導役がサボり、部下に結論だけを教えたがるかというと、私個人の感想としては「かっこをつけたい」からです。問題解決について、上級者はすぐさま原因を見抜き、華麗に解決する、という演出をしたいためです。結論だけ伝える姿勢というのは、泥臭い問題解決のプロセスを隠しますから。

しかし、これでは部下は育たないのだな、と。上級者は、問題と相対したときに、どういう思考をして問題を解きほぐし、調査し、結論を得るか、そのプロセスを公開しないといけない。

これ、結構、かっこ悪いところも見せないといけないので、勇気はいるんですけどね。しかし、やっぱり部下には育ってほしい。部下も、「結論だけ教えてくれればいいのに」「解放されたいな」って思うかもしれませんが、指導役がオープンにする姿勢は重要なのだと思います。

実際に出来る人、出来るように演出したい人は、どうしても手品のように結果を出したいのですが、ぐっとこらえて能動的に種明かししていかないと、なかなか部下は育ちません。