ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

採用とか退職とか評価に関するよもやま話

こんにちは。@ryuzeeです。

以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。

採用に関するメトリクスを取ろう

採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。

  • 総応募者数
  • 採用媒体別応募者数
  • エージェント別紹介者数
  • 社員の紹介によって応募が来た数
  • 自社の採用サイトから応募が来た数
  • 各属性で書類選考を通った数
  • 各属性で一次面接を通った数
  • 各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)
  • 各属性で最終面接を通った数 (同上)
  • プロセスの途中で辞退した数
  • オファーを出した数
  • オファーを受けた数
  • オファーを辞退した数
  • 各採用媒体やエージェントに支払った金額
  • 採用イベントに使った金額
  • 応募からオファーまでのリードタイム(所要時間)
  • 採用活動に関わった社員の時間
  • 社員別の面接の回数やそこでの判断

つまり応募者の数から実際に採用した数、かかったお金、かかった時間のようなものを対象にすると良いでしょう。

採用に関連するメトリクスをとる最大の理由は、当然のことながら「採用活動の質」をカイゼンするためです。なんとなくうまく行っていないと思っていても実際に見えていないものはカイゼンできません。

また実際に時間や費用を測定してみると、想像以上に時間も費用もかかっていることが分かります。 つまり社員が辞めてしまうことは仕方がないにせよ、それを補充するために採用にお金や時間を使うくらいであれば、事前にそのお金を社内のカイゼンに使うという選択肢が存在することが分かるでしょう。

社員の退職理由に関する情報を集めよう

トム・デマルコのピープルウェアでは以下のように言っています。

大部分の企業は、退職の統計さえ取っていない。実際問題として、熟練スタッフが辞めた場合、比重にどれぐらいのコストがかかるかは誰にもわからない。その結果生産性を議論するとき、退職はありえない、あるいは、退職してもタダ同然で補充がきくとの前提で話を進める。

しかし採用で書いた話の流れを踏まえれば、社員がなぜ退職するのかストレートな理由を収集することは重要です。もちろんストレートな理由を収集するには一定以上の信頼関係が必要ではあるのですが、そこで得られた答えが組織のカイゼンに繋がる可能性は多いにあります。

なお、さまざまなWebサイトで退職の理由の統計などが出ていますが、アメリカ海軍に学ぶ「最強チーム」の作り方という本によれば、以下の順番だそうです。

  • 第一の理由は「上司から大切に扱ってもらえないこと」
  • 第二の理由は「積極的な行動を抑えこまれること」
  • 第三の理由は「意見に耳を貸してもらえないこと」
  • 第四の理由は「責任範囲を拡大してもらえないこと」
  • 第五の理由は「給与」

もちろん、人にはそれぞれ違う理由があると思いますが、その理由が組織の機能不全に関わる問題なのであれば、このような形で情報を収集し続けてカイゼンすれば良いことになります。すなわち組織運営のフィードバックサイクルをまわす上での材料になるということです。

ちなみに上記の理由の上から4つ目までは、その人の上司のふるまいに関するものであることが分かります。つまり退職の分析をしてみると、特定のマネージャーの部下だけがたくさん退職しているというケースもあり得るということです。このような兆候があるのであれば、情報収集のやり方を変える必要があるかもしれません。

きちんと評価されないことは不満に繋がる

上記の理由には出ていませんでしたが、自分に対する評価が妥当だと思えない場合は、当然ながら不満が募ります。 もちろん自分に対しては甘くなってしまうのが人情なので仕方ないところなのです。 しかし、この不満が組織構造に関連している場合もあるので注意が必要です。

たとえば、「期初にゴールの数字を決めて、半年とか一年後に数字だけで評価する」ようなやり方をしていて、途中のビジネスの変化によってその数字の意味がなくなった(やる必要がなくなった)場合を考えてみましょう。 期初のゴールだけを見れば単純に未達になってしまいますが、それだけで評価されれば当然不満になります。一方で評価を下げたくないので、意味のない数字を達成しようとする、というのは今度は会社にとってのムダになります。

つまりゴールがあったとしても、ゴールがいつ正しくないものに変わるかが分からず、新しい適切なゴールが出てくるとも限らない、というのを認める。すなわちMoving Targetであることを共有する必要があるわけです。そして状況の変化に対応しながらゴールを変えていくためには、従業員とマネージャーの間で定期的なコミュニケーションが必要です。これも3か月や半年といった単位ではなく、毎週・隔週・月一回くらいのペースで行われなければいけません。つまりゴールや進捗状況についても、フィードバックサイクルを回すということになります。(評価ミーティングで、まずあなたの仕事を説明してください、みたいなことを言うマネージャーが世の中にはいるらしい…。上司だけの判断で正しく人を評価できるなんてはずはないのです。)

お前は何をいってるんだ?

要は、製品を作るときだけフィードバックサイクルをガンガン回すんじゃなくて、組織運営でも短いフィードバックサイクルを回せ、という話です。

それでは!!

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 RACIマトリクスを使ってスクラムでの責任分担を見える化する
次の記事 【資料公開】強いチームの作り方(デブサミ2016版)

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World