"BOKU"のITな日常

BOKUが勉強したり、考えたことを頭の整理を兼ねてまとめてます。

「問題はありません。」としか報告しない部下ほど恐ろしいものはない

f:id:arakan_no_boku:20190203133001j:plain

メンバーの多いプロジェクトに多少の問題社員が混じりこむのは仕方ありません。

問題社員への対処もマネージャ・リーダーの仕事です。

この問題社員には、ざっくり分けると2つのタイプがいます。 

それは

  • あからさまに問題を起こしそうで、やらかしてしまう人
  • 問題を起こしそうになくて、やらかしてしまう人

です。

一般に認知されているのは「前者」です。

前者は「めんどくさい」ですけど、問題が目に見えるので、手をうつことはできます。

いよいよとなれば、メンバーから外してしまうとか(笑)、やりようがあります。 

だけど「後者」はやっかいです。 

後者の「問題を起こしそうになくて、やらかしてしまう人」がやっかいな理由は、仕事全体を一気に破綻させるような巨大地雷になる可能性が高いことです。

なぜ、そうなるのかというと、破綻する一瞬前までは、問題ない人だからです。  

 

自分が話を聞いた具体例です。 

その人は外注(社外の人間)の開発者でした。

その人に20本程度のプログラム開発を割り振っていたと思ってください。 

見た目も真面目で、言動もまとも。

進捗報告は常に「問題なし」。 

JUNITでの自動テストで、指示したケースのテスト結果も合格。

疑う理由もありません。

順調に開発・単体テストフェーズが終わったのですが、次のテストフェーズで、突然問題が発生しました。。

テスト担当者からあがってくるバグ報告に「マスタを変更しても結果が変わらない」とか「テストデータを入れ替えたのに、前のテストデータの時と同じ結果がでる」等不可解な内容のものが大量にあがってきたことです。

しかも、その対象のプログラムの開発者はすべて同じ人間。

真面目で問題がなかった開発者です。

原因を調査してみると。

なんと!!

プログラムが単体テストケースでのみ合格になるように作られた、いわゆる「ハリボテプログラム」で全く使い物にならないことがわかったのです。 

あわてて、同じ担当者が開発したプログラムソースを洗い直したら、全てが同じで、JUNITの自動テストのケースだけしか、ロジックを書いていないわけです。

まさに「やられた・・」って感じです。

その当人は既にプロジェクトを離れており、当然のごとく、携帯電話はつながらず、住所を聞き出していってみても引っ越した後。

あとの祭りです。

仕方なく、20本程度のプログラムは全部作り直したそうです。

約5ケ月弱くらいの作業量で、残ったメンバーが地獄を見たのは言うまでもないです。 

 

ただ、この話も「できるプロジェクトリーダー」の方によれば、リーダーが悪いよ・・と一言で切り捨てられましたけど。 

途中経過をちゃんと現物でチェックしておくのは当たり前で、あいつを信じてるから・・などと、それをしないリーダーは

嫌われることを恐れて、本来の仕事をしていない駄目なやつ

でしかないということです。

リーダーが、こまめに声をかけて、自分の眼でモノを見て状況を把握する。

これが基本。

会議やメールとかで報告される内容だけを信じて、それをしないのは単なる手抜きでしかないんだから、失敗するリスクがあがって当たり前。

そういうことみたいです。

勉強になりました。