勉強履歴(と雑記)

プログラミング初心者のメモ書きです

エンジニアリングマネージャーのしごと

アウトプットの習慣を戻すと言っておきながら、前回から1ヶ月弱空いてしまいました…
この1ヶ月具体的に何していたかというと、RubyRailsの復習および就活をしていました。
正直、今までやってきたことの振り返りが中心で新しく学習することは少なかったので、
ブログに書く必要あるのかなってしまって放置してしまいました。
技術的な話だけに絞ってしまうと更新が難しくなってしまうので、
もうちょっと関係ない話や雑記的な内容でもOKにして、取り敢えず更新を続けることを目標にしていきたいと思います。

最近は、8月末にオライリーから発売された「エンジニアリングマネージャーのしごと」をRUNTEQ内の輪読会で 読み進めています。
1週間に2章のペースで進めて、章ごとに担当者を決めてFigjamに整理した後に発表するという形でやっています。
私が担当したのは8章で、人が辞める時・人を辞めさせる時の対処法について書いてありました。
今回はそのまとめを文章化していきたいと思います。

1.人が去るのは普通

自分の人生やキャリアをよりよいものにするため人は会社を去るものです。
2018年のアメリカのテック業界での離職率は13.2%とのこと(ちなみに日本の2020年の離職率は14.2%、情報通信業は9.2% )。

https://www.mhlw.go.jp/content/11652000/000845829.pdf

辞めるパターンは自主退社と会社都合による退社の2つあります。

2.スタッフが去るとき(自主退社)

この本では、労働者の都合で辞める場合を良い退職理由、 会社・マネージャーとの関係に起因する退社を悪い退職理由としています。

良い退職理由は新しい仕事の機会・家族の都合・よりよい報酬があります。
良い退職理由の場合、マネージャーができることは以下の通りで、基本的には円満に送り出そうと言っています。

  • お互いに都合の良い退職日を決めよう。
  • リファレンスが必要かどうか確認。
  • 引き継ぎ。
  • 後任の採用。
  • 祝福して送り出す。


悪い退職理由は給料に不満があって辞める、同僚(チームメンバー)との関係が悪い、昇進の機会がない、新しい挑戦や仕 事をやる機会がないなどが挙げられています。
このような事態になってしまうのは、スタッフとマネージャー間で信頼関係が築かれていないためであり、未然に防ぐためにも普段の1on1で以下の内容について話をしておくべきだとしています。

  • キャリアアップ
  • マズローの欲求階層(スタッフ自身の自己実現についての話)
  • イライラすること

3.うまく戦う(残留について)

自主退社するスタッフに残留依頼をかける場合について書いてありました。
退職届が出された時点で転職活動済みの場合が多く、そうでなくても精神的には別の会社にいる場合が殆どなので、基本的には退職を受け入れて送り出すのがベターです。

ただ、そのスタッフがハイパフォーマーであり、会社に残ってもらうために生じる不均衡(賃上げや移動の埋め合わせなど)を受け入れられる場合は、残留依頼をかけてみても良いかもしれません。
まず、退職の理由を会話の中で特定し、解決できる問題かどうか検討します。
概ね、以下の理由が考えられます。

  • お金
  • キャリアアップ
  • 仕事の種類
  • フラストレーション


解決できそうであれば、上司・HR・部門内の他のマネージャーに協力を求めてカウンターオファーを作成します。
カウンターオファーを出して、スタッフが残留してくれればめでたし、気が変わらなくても最善を尽くしたとして気を病まないようにしようとのことです。

4.スタッフを辞めさせる(会社都合の退職)

会社都合でスタッフを辞めさせる場合の話です。
パフォーマンスが低く、仕事をこなせない人への対処としてPIP(業績改善計画)が挙げられています。
外資系でもない限り日本だと馴染みがない印象ですが、以下の点がまとめられているドキュメントのことを指します。

  • 現在の職務内容の概要
  • パフォーマンスや振る舞いの問題
  • PIPを通過するためのゴール
  • PIPの期間(1~3ヶ月が妥当)
  • マネージャーからのサポート


PIPが達成できなければ解雇ということになるので、脅しのような形では使うのではなく、他の方法でパフォーマンスを改善させようとしたけど失敗した場合に限り使うべきとのことです。
実際、PIPを悪用している会社もあるようでアメリカでは社会問題にもなっており、PIPで調べたら日本の外資系の企業で不誠実な使い方がされていると告発しているサイトが見つかりました(気になる人は自分で調べて)。

PIPを作成する場合は以下の点を検討する必要があります。

  • パフォーマンスの問題が根拠のあるもので、過去に本人へ伝えたか
  • 設定したゴールは達成可能で、期間内に終わるものか
  • ゴールの達成に必要なスキルが不足しているか、不足している場合は理由とサポートの方法を検討
  • 個人的な問題によるものかどうか


PIPが完成したら予めスタッフと共有したうえでミーティングを行い、調整を加えつつ相手の合意を得られたらPIP期間に入ります。
毎週進捗を確認し、スタッフの方に改善が見られた場合は晴れてPIPを通過、何事も起こらないパターンです。
逆に改善が見られなかった場合も、すぐ解雇はせずに正式な警告を出すのが妥当とのことです。
PIPに反したことを示すドキュメントを提示し、これが最後の機会であると伝えます。
これでもPIPに反するようであれば、その時が解雇となります。

解雇(リストラ)

上記の解雇はスタッフ側に問題がある場合ですが、何も問題がなくても解雇する時もあります。
リストラという名の業績悪化による人員削減です。

この場合の課題は次が挙げられています。

  • 解雇される側に何ら非がない。
  • 解雇される側にとって不意打ちになる。
  • マネージャーとしてもスタッフには去ってほしくない。


解雇を告げる際は怒りやイライラをぶつけられる可能性が高いですが、落ち着いてやるべき事をやりましょう。
告げる側も辛いものですが、一番辛いのは解雇されるスタッフの方なので乗り越えましょうとのことです。


以上が8章の要約になります。
すごく世知辛い話でした。
いつかは人を辞めさせる側に立つ日が来るかもしれないので、 その時は上記の内容を思い出して、離職がお互いにとってよい結果になるようにしたいですね。

解雇について日本は厳しいとよく聞くのでちょっと調べてみたんですが、次の記事によると欧州に比べたら実はそれほど厳しくないとのこと。

shuchi.php.co.jp

解雇のさせやすさはアメリカ>日本>欧米らしいです。
リストラをさせるのは日本より欧米の方が難しく、雇用者有利な制度となっているそうで。
ただ、日本の雇用形態はメンバーシップ雇用で総合職として雇用するため、ジョブ型のように仕事がなくなったからクビとは言えず、何かしら仕事を任せられるようであればクビにできないのが噂の実態とのことです。

折しもTwitterで連載されている「100話後に心が折れるスタートアップ」という漫画がそろそろ完結しそうなのですが、 それを見たのも合わせて人を雇うのも辞めさせるのも大変なんだなって思います。
今回は以上です。