6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

前回の記事

連載の構成

  • この記事は、マネジメントについて一人で考える Advent Calendar 2022の連載記事です
    • 1記事目から読んでいただいても良いですし、気になる記事から読んでいただいても問題ありません
  • 全25回分の構成は、次の通りです
    • 第1〜6回:ドラッカーの『マネジメント』を中心に解説します
    • 第7〜13回:『図解人材マネジメント入門』を中心に解説します
    • 第14〜22回:『エンジニアのためのマネジメントキャリアパス』を中心に解説します
    • 第23〜25回:私の経験談を中心に、まとめに入ります

有害な社員

ブリリアントジャーク

  • エンジニアとしては有能だけれど、自己中心的な存在が『ブリリアントジャーク』として解説されています

「有害な社員」の第1のバリエーションは「ブリリアントジャーク」です。先述のとおり、エンジニアとしては非常に有能なのですが、ひどく自己中心的で、周囲の人全員に恐れと嫌悪の入り混じった気持ちを抱かせると言っても過言ではありません。
(中略)
管理者がチームのためにできる最良のブリリアントジャーク対策は「好ましくない言動は、断固、公然と拒否する」です。(中略)「仲間にそんな反し方をしないでください。失礼です。」
引用:エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

  • 今回の連載で特に触れていなかったのですが、マネージャーのコミュニケーションの基本として
    • 褒める時はみんなの前で
    • 指摘する時は1対1で
  • があります
    • 称賛は周囲に共有することが大事です
    • 逆に、指摘を公然とされるとプライドを大きく傷つけてしまいます
  • ブリリアントジャークに対して"公然と拒否する"ことは、この本においても"数少ない例外"であるとして紹介されています

秘密主義者

  • 理由は多々あれ、秘密主義者も注意が必要です

ブリリアントジャークと同様によくいるチームの問題児が「秘密主義者」、つまり、管理者やチームメイト、プロダクトマネージャーに隠し事をする人です。具体的には、自分が企画した「すばらしい」プロジェクトを秘密裏に進め、完成したところで披露する、チームメイトが手を加えたコードを無断で元の状態に戻してしまう、仲間の作業を横取りして完成させてしまう、コードをレビューされるのをいやがる、大きなプロジェクトのデザインを引き受けておきながらそのレビューを頼まない、といった行動をします。
(中略)
可能であれば、情報隠しという行動の根っこにどんな理由があるのかを探ってみてください。
引用:エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

  • 自分の書いたコードが"絶対的な正しさ"を持っていると感じてしまっていたり、中途半端な状態や失敗した姿を隠したいと考えていることも、秘密主義者になってしまう原因の1つでしょう
  • ブリリアントジャークと異なり、秘密主義者はまだ改善の余地があるのではないでしょうか
    • そもそも「失敗を見せたくない」「恥ずかしいところを隠したい」のは個人の特性に限らず、チームとして心理的安全性が担保されていない可能性があります
  • 対話を重ねて理由がわかったら、それをチームで解決する方法を探すと良いでしょう

無礼者

  • ブリリアントジャークと近い気もしますが、最後の1つは無礼者です

第3の「有害な社員」は無礼者、つまり管理者やチームメイトに敬意を払おうとしない人です。(中略)管理者は自分やチームメイトに敬意を払おうとしない部下を放置するべきではありません。こんなふうに上司に敬意を払わなくても許されるのか、と他のメンバーが首を傾げるようになり、チームの結束が徐々に乱れてくる恐れもあります。好ましくない芽は早く摘み取れば摘み取るほど、悪影響も小さく抑えられます。
引用:エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

  • チームや会社として、『そのような態度を許さない』と毅然と振る舞う勇気が必要です

結局はHRTの欠如

  • これら3種類の有害な社員ですが、共通するのはHRTの欠如でしょう
  • 連載第4回で触れましたが、再度引用します
  • 自身のあり方を謙虚に見つめ、チームメンバーに尊敬と信頼を持てていれば、今回挙げた有害な社員になることは防げるでしょう
  • 逆に言えば、このHRTはITエンジニアとして生きていく上で根本的なところにあります
    • HRTに共感できず言動で欠如が見える場合、会社の雰囲気や社風の不一致ではなく、ITエンジニアとして働くことは困難が伴います
    • その点も念頭に置きつつ、自身がそういった存在にならないよう気をつけると共に、指導すべき時はしっかり伝える必要があります

そもそもいちばん重要なのは、有害な社員を最初から雇わないこと

  • 今回の参考図書でも書かれていますが、何より重要なのは「初めからそういう人は雇わない」ことです
  • もう1個それを裏付ける参考に、世界的な名著『ビジョナリー・カンパニー』シリーズでも語られている部分を引用します

偉大な企業への飛躍を指導したリーダーは、まずはじめに新しいビジョンと戦略を設定したのだろうとわれわれは予想していた。事実はそうではなかった。最初に適切な人をバスに乗せ、不適切な人をバスから降ろし、適切な人がそれぞれにふさわしい席に坐ってから、どこに向かうべきかを決めている。
引用:ビジョナリー・カンパニー2 飛躍の法則

  • なので、何よりまず最初に重要なのは"誰を雇うか"です
  • 『エンジニアのためのマネジメントキャリアパス』や『ビジョナリー・カンパニー2』は海外の本なので、日本より解雇に対する規制が緩い点にも注目です
    • 解雇の規制が緩い文化においても「最初から雇わない」ことが強調されています
    • 日本においては、解雇のハードルはさらに高いです

終わりに

  • 今回は有害な社員について解説しました
  • 次回は引き続き有害な社員の1つ、テクハラについて触れていきます

次の記事

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?