読者です 読者をやめる 読者になる 読者になる

kopug memo

名古屋で働くとあるWebエンジニアの覚書。

その「エンジニア採用」が不幸を生む

開発の現場にいることよりも採用の現場にいることのほうが多くなってきている中で、自戒の念を込めてこの書籍を手に取ってみました。

本書のターゲット

  • 企業経営者
  • 採用人事
  • 転職を考えているエンジニアなど

本書の目次

  • 第1章 経営課題をエンジニア採用で解決しようとする落とし穴
  • 第2章 エンジニアの募集要項が書けない人事
  • 第3章 不幸になる原因はエンジニアサイドにもある
  • 第4章「どんなエンジニアが必要なのか?」「そもそも、エンジニアは必要なのか?」を判断する
  • 第5章 よいエンジニアをみつけ、採用する方法
  • 第6章 エンジニアを惹きつけ、働いてもらえる仕組みを作る

個人的なまとめ

エンジニアの採用に関する経営課題の話しから、エンジニアのキャリアパス、評価制度、組織の作り方と続いていきます。
エンジニアが足りないという声はどの企業でも上がってきますが、「優秀なエンジニア」はどんな企業でも活躍できるのか?というとそうではなく、
エンジニアにも多種多様なタイプが居る中で、本当に必要なエンジニアはどういうエンジニアなのかを見極めないと、結果両者にとって不幸を招きます。
本書の前半は経営者/人事のキーワードが多く、後半はCTOというキーワードが非常に多く出てきます。
事業を推進していく上での課題を、どういう技術/採用戦略が必要なのかを見極め、それを実現する組織を作り、その組織を向上/維持するために、
エンジニアの文化、開発手法、評価制度、教育システムを作り、それを真摯に語り採用活動を実施する必要がある事が分かります。

つまり自分がしないといけない事がここにたくさん書かれているわけですね。はい。

ここから先は、確かになーと思った内容をひとつだけピックアップします。

第4章にある、エンジニアを2つのタイプ x 4つのグループに分けて考える図が面白い。

f:id:kopug:20170218225918p:plain

タイプA の “自由な開発環境"とは主に自社サービスの開発/運営をしている人が当てはまります。新規製品・サービスの開発の経験があり、失敗することを成長の糧と考える。
タイプB の "ガバナンス優先の開発環境"とは、与えられた目標の下、持っている技術と経験で着実に開発をおこなう(失敗は許されない)

将来マネージャになった場合に、上記のタイプAとBではマネージメントスタイルも変わってくるため、2タイプ x 4グループの8セグメントで考えて、 今どのタイプのエンジニアが必要なのかを考えていくと、そこに絞った採用戦略も考えられそうですね。