信頼を失ったエンジニアはマイクロマネジメントのアリ地獄から抜けられない
仕事をする上で、信頼されることは信頼される側にメリットが大きい。例えば、期待される結果を合意した納期までに決められた完成基準を満たす成果を完成させてくれるエンジニアは、成果物に対して根掘り葉掘りチェックされることはない。一方、期待する結果に足りないとか、納期を毎回オーバーランするとか、完成基準に満たない成果物を作ることがあるとか、そうした実績があるだけで、期待に満たない点を中心にマイクロマネジメントとして介入されることになる。どちらがエンジニアにとって良いかは考える余地はない。前者に決まっている。
具体的な事例で話そう。若手エンジニアにある分析を依頼した。これまで同じような作業をしており、経験に応じた結果が得られるようになった。分析する項目ごとに基準があり、データと基準を照らし合わせ、その評価を記述する。全体の項目が評価が終了したら、総評で締めくくる。
若手エンジニアの作業は、個々の評価は一定の作業レベルになっており、それほど気にするほどではなくなった。評価結果では、ある程度信頼して良いという判断をした。ただし、評価のうち、不良と評価した項目については、判断についてどのように導き出したかは説明を聞き、基準に沿っていることを確認する必要はあった。
総評については、若手エンジニアであるがゆえに、経験知や形式知を生かした記述にはまだまだ足りないと認識しているため、書きっぷりは赤ペン先生をもう少しせざるを得ない状況と判断している。つまり、こちらは信頼が形成されていないということだ。
こうした背景で、ある案件の分析結果のうち、不良と評価した項目の説明してもらったところ、データの確認に抜け漏れがあることがわかった。
こうした抜け漏れは１件であれば、たまたま間違ったとして再分析すれば良いと片付けることができる。しかし、これが数件あると潜在的に他にも分析誤りがあるのではないかと疑念を抱かれ、これまで得ていた信頼を一瞬でパーになりかねない。
この事例からわかることは、信頼自体形のないものだから、日々の小さな、事例では分析する項目の判断誤り、データを見切れていないとか、判断基準に沿っていないとか、そうした積み重ねで信頼をエンジニア自身が失う主体となっていることがわかる。
これが続くとマイクロマネジメントされるのだ。
何の作業をするのか、何を作るのか、完了基準は何か、今日は何をどこまでするのか、昨日の作業は終わったのか、成果は基準を満たしているのか、なぜその工数が掛かっているのか、課題は何か、解決策はどうするのか…。
マイクロマネジメントはする方も御免被りたい。が、せざるを得ない状況を作っているのはエンジニアの日々の作業であることも知っておいた方が良い。
一度、信頼を失うとマイクロマネジメントのアリ地獄からはそうそう抜けられない。
事例の若手エンジニアは、説明をよくよく聞いたら、他は問題がなく、その１項目だけがデータ分析が足らなかったことが確認できたのでそれ以上分析結果をウオークスルーする事態には至らず。よかった。よかった。
