タスクのパフォーマンスを1/3しか期待できないエンジニアの4つの特徴


チームを組めば一人ひとりのエンジニアの性格、特徴などタレント性は様々です。いつもにこやかに接してくれる人もいれば、つっけんどんで言葉少ない人もいます。こちらが思う以上に気を使ってくれたり、とっても心配性だったりと、もう、それは一つとして同じ人はいません。


タレント性が違うから、チームを組むことで補完関係を期待できるチームを編成したいとか、新人の育成で手間がかかる(けれど、育成に掛かる手間は必要コスト)のをカバーできるように少しだけ手厚いメンバ構成にしたいとか、組み合わせには四苦八苦しながらもチーミングするのも実は少し楽しいんです。


勿論、「こんな風にチーミングしたいなぁ。」と思っても思ったようにはいくはずもなく、スキルの観点で不足するとこがそのプロジェクトに参加する際に担うだろうロールが少し背伸びをするような経験を積めることが期待できそうなら、日々のプロジェクトで起きるリスクの予兆を探すことの注視を他のプロジェクトよりやろうと腹を括ってアサイメイントすることも少なくないです。


とは言え、そうしたチームに参画させるメンバも1を期待して得られる結果はチームのメンババラバラであったとしても、トータルの予測はチームとしては±0くらいを期待したいんですが、エンジニアの経験年数から期待してもいいだろう期待値を得ることが出来ない人もいるんです。今時の学生さんですから勉強はできて社会人になったのだろうけれど、仕事ではその勉強する能力が活躍していない、みたいな。


そうした人もプロジェクトマネージャとしては大切なリソースなので使わないわけにはいかないし、じゃあと言って外すと運営が回らないので外すわけにもいかない。


経験値ですが、エンジニアの経験年数から期待するところって、暗黙だし定性的だけれどあると思うんです。そうした経験値からの期待を得られないエンジニアには共通の特性があるんです。

  • タスクを説明してもメモは取っているが理解していない。
  • 取ったメモを自分の頭で理解していない。メモを取っただけで見返さない。
  • 自分でタスクの解決策を考えずダメ出しされるとすぐに答えを聞く。
  • 予定完了日に終わらせないといけないと言いながら終わらすことが出来る段取りを組めない。


何となく、1つ目の特徴を書いていておもったことは、その場で理解しようとしていないのではないか、後でメモを見てやればいいや、と「思っているんじゃないのかなぁ。」なんて思当たってみたりします。その場で、タスクのアサイメントの場で、自分の頭の中でタスクのゴールの、アウトプットのイメージができていないんだろうなぁ、と。


そうした期待するアウトプットのパフォーマンスが1/3も出ない人はそのパフォーマンスを初めて知ったわけではなくているもそうなのですから、それの対策をするわけですが。タスクを説明した後に本人に理解した内容を説明してもらったり、とか、ことあるごとに進行情況を聞いてみたりとか。それでも、変わらないのは生まれ持った性格を根源とするところにあるんでしょうかなぁ、と。


なので、そうした人のタスクは1/3のアウトプットしか計画を割り当てないし、間違ってもクリティカルパスになるタスクをアサインしたりしないようにして予防しましょう。