【リーダー考察】チームワークを阻害する一番たちの悪いメンバーは?

エンジニアネタ

ブログを読んで頂いてるみなさんは仕事で指示を受ける立場だろうか?それとも指示を送る立場だろうか?そんな私は指示を送る立場です。

 

リーダー職になることは何が正しい選択か常に判断を任されるという意味だ。

 

時には優秀な部下たちに囲まれてプロジェクトを運営することもあるだろう、逆に優秀ではないメンバーと組むことになる場合もあるだろう。

今回はそんな時にメンバーで一番たちが悪いのは誰だ!という観点で見ていきたいと思います。

 

一番たちが悪いメンバーとは?

どんなメンバーと組んでもプロジェクトは回さなければいけません、スキルの低い新人が入る場合もあればスキルの高いベテランと組む時もあると思います。

でも私はたちの悪いメンバーはとはそういうことで分類されるものではないと考えております。

たちの悪いメンバーというのは周りのことを考えずに自己中心的に仕事をしてしまうメンバーを指すことと定義しています。スキルが低いから使えないというのは上司や先輩の責任だと思います。

「働く」という言葉の由来として「はたが楽をする、できる」ということが言われています。

この表現は言いえて妙です。この言葉を基準に考えたときに私はチームのメンバーが本当に「働いている」「働いていない」を分別することができました。

みなさんもこの基準をもとに周りのメンバーを見てもらえれば判断できるのではないでしょうか?

働かない、「はたが楽できない」メンバーの行動

例えばプログラマが働かない場合はどういうケースがあるか見てみましょう。

コーディングの可読性が極端に低い

今後のメンテンナンスやレビューを実施する際に困惑するパターンです。動けばいいだろう、試験さえ問題なければいいでしょうと無理にコーディングしたりコメント量が極端に低かったり自分だけが理解しているが何を書いているのかわからないという内容のもの。

これは正直短納期でできたとしてものちのちに「はたが楽=はた楽」ができません。故障が発生して開発した本人が存在しない場合は目も当てれません。

 

設計者が働かない場合を見てみましょう。

設計に意図や経緯が記されていない

たまに設計書ができました!と満を持して作成する人がいますが「なぜそうなったのか?」「なぜそうしたいのか?」という『仕様』そのものの存在理由が書かれていないため誰もがあとで確認したときに「なんで?」となるケース多いこれも「はた楽」にはなっていないと思います。

 

今度はリーダー層で働かない場合を見てみましょう。

進捗管理表はメンテンナスするが進捗管理ができていない

リーダー層の仕事を進捗管理表のメンテナンスに絞りこんでいる人がたまにいます。

要するに「今日の進捗は?」っと朝会または夕会で聞いたっきり何も考慮をしないなどの場合もダメだと思います。聞くだけ聞いてあとはなんとかしてよ!では通用しませんよね、周りが楽できるように環境調整をするなり仕様の齟齬を取るようにきちんとレビューをするなどやれることはたくさんあります。

 

まとめ

どうでしたでしょうか?一例づつ取り上げているのでまだまだ「働かない」というたちの悪いメンバーがどこにでもどのフェーズにも存在していることは確かだと思います。

個人プレイでプロジェクトを済ませることも可能でしょうがチームが結成されているわけは効率よく仕事を進めてプロジェクトを安定的に終わらせることが大事だと考えます。

私の個人的な意見ですが自分の仕事をこなして他者の作業はまったく無視というやり方については成果主義の場合に仕事が進まない方が悪いと判断されるわけです。でも同じ会社の人間と考えてスキルが低いメンバーの底上げに協力するという姿勢で臨めばいつかは自分に別の形で返ってくるという思考を持つべきだと思います。

フリーランスとなれば成果や納期の時間にシビアになっていくのはわかりますがサラリーマンの方はいろいろと考えなおすことをおすすめします。

コメント