問題児エンジニアは指導しないで本人が成果を出したように仕向ける
問題児エンジニアを預かっていたとき、あれこれと指導したり指図したりせずに、まるで本人が成果を出したように仕向けたことがある。問題児なエンジニアとは、組織の中でのエンジニアのバンドで要求するパフォーマンスが出ていないという意味での問題児である。程度はあるにしても、そこそこの割合でどこにでもいるのではないか。
問題児であろうがなかろうが、そんなことは自分には関係ないし、問題児なエンジニアの出せるパフォーマンスを出してくれればそれはそれで良い。問題児なエンジニアのパフォーマンスを知っていれば、自分の問題児に対する期待値をマネジメントをしておけばいいので気にならない。
アジャイル開発で最初にスプリント0をやってチームのベロシティを知っておこう、というようなものである。たとえスケジュールに到底間に合わないようなパフォーマンスであっても、無理矢理急かしても碌なパフォーマンスは出ないのはその辺に歩いているエンジニアも同じである。だからペースは問題児なエンジニアに合わせる。
期待するパフォーマンスの出ないエンジニアは、いきなりそうなったり、そう評価され始めたわけではなく、仕事をしている中でそう言った烙印を押され続けているから事故に対する評価も低いことが多い。それを踏まえておかないとダメ押しをしてしまいかねないのでそれはしないように配慮しなければならない。
どう配慮するかというと、指示や指導的な物言いをしないということである。大前提にマイクロマネジメントをしない、ということがある。
では、実際にどうやったかというと、まず、自分の姿勢はこんな感じでのぞむ。
- 笑顔で話す
- 話を全部聞く
- 肯定（理解・同意）する
- 考えの違いはお互いに理解できるまで話し、違いを認識する
これをベースに、
- 任せたいタスクをやるか意思を確認する（問題児はそのエンジニアなりに必死なのでやるという）
- 一緒にゴールの状態をイメージ合わせする（基本はどう思うか考えを引き出す）
- 一緒にタスクを分解して手続き（手順・構成要素）を具体化する（これも引き出したり、ここはどうするかとヒントを出す）
- 具体化した手続きの１つだけをやってみるかと尋ねる（やるという）
- 問題児のエンジニアのスケジュールの空き時間でどこでやれるかを聞いてみる
- こちらが思う2−3倍の時間か日にち単位を設定する
- 始める前に準備ができたら一緒に見ようかという
- 結果に抜け漏れを見つけたら、このケースはどうしようかと相談するように聞いてみる
何をここまで手をかけて、と思うかもしれないが、サラリーを払っているので働いてもらわなければならない。対価に見合っているかどうかは本人が一番わかっているので、そこを追い詰めても何も生産的なことに結びつかない。
だから、手間を掛けても、やってもらうのであるし、そうした結果は自分は実作業をしていないのだから、問題児のエンジニアの手柄に仕向ける。そのエンジニア自身も自分1人でやったことではないことは重々わかっているが、こちらとしてはあなたがやった成果だ、としか言わない。
自分は問題児エンジニアが成果を出せるようにしたというだけでいい。
