ベテランエンジニアの雇い方

採用に応募してきたベテランエンジニアの見分け方

## この文章の目的
- エンジニアの中途採用にベテランエンジニアが応募してきたときに、あなたの職場に適する人かどうかの見極め方について、私見を述べる。


### 労働人口の今後
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/446a930a-a1e9-0d02-3b79-b7b88159d697.png)
[引用元](https://www.projectdesign.jp/201901/future-working/005827.php)

15歳から64歳までの人口の比率の推計値だ。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/8551aeeb-0149-2e54-95dd-06480aadbbb5.png)
[引用元]
(https://empowerment.tsuda.ac.jp/detail/9963)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/cdce10ec-f810-6416-a0e4-a03797daf9ea.png)
[引用元]
(https://empowerment.tsuda.ac.jp/detail/9963)


### 労働人口の今後を考えると、40代以上の年齢層の比率が高くなっていく。
- 20代・30代のエンジニアだけを採用することで、開発の分野を担っていくことは難しい（組織も多いだろう）。
- ベテランエンジニアをあなたの事業にすり合わせていこう。
###### その分野ですぐに仕事をできる優秀な新卒は、給与水準が高くなってくる。
- その分野ですぐに仕事をできるそこそこ優秀な新卒も、企業間による奪い合いが高まっていく
- しかし、目的の分野での関連知識の広がりは期待できない。
- 例：新卒の画像認識のエンジニアが、カメラやイメージセンサについて詳しいことは期待しにくい。
　まだ、経験が少ないのだから。
- そういうことを考えたとき、学び続けているベテランエンジニアは価値がある。
　
#### 就職氷河期以前の世代
- 終身雇用前提で、若手が教育されてきた世代だ。
- だから、チャレンジングな課題にもあてがわれることもあったし、今いる人員をなんとか教育して、過去の経験の活かしつつも、新しい分野で結果をだせるようにチャンスが与えられてきた世代だ。
- 使える道具が多いほど、発想が豊かになり、工夫の余地も生まれてくる。
- 職務経歴が長い分だけ、その人の力量を判断しやすくなる。
    - その分野のエンジニアならば誰でもできることをしてきたのか、
    - その分野のエンジニアのうち優秀な方のエンジニアでなければできないことをしてきたのか、
    - その分野で新しい道を切り開いてきたと言えるほどのことをしてきたのか
    それらが、職務経歴でわかることでしょう。
#### 就職氷河期世代
就職氷河期世代は、正社員での雇用が減っています。
そのため、正社員の立場を経験してきたエンジニアの数は不足します。
そのため、企業の中で特定の世代の特定の分野のエンジニアが不足しているのをなんらかの方法で補うことが必要になります。

#### 円安時代の海外からの留学生
- 海外から日本の大学に進み、日本の会社に就職する優秀な人はいる。
- ただ最近は、円安が進んだため、日本でのドルベースの年収は、低い。
- 英語で仕事ができる文化圏では、しかるべき能力のある人への給与水準は高い。
- それらのことから、海外から日本の会社で働く優秀な人の流入は、今後は減っていくという予想が多い。


### エンジニアの能力・チームワークの能力・学び続ける力は、ひとそれぞれだ。


## 適さない場合
- 学び続ける力を持っていない場合
    - 10年以上昔の技術水準のまま止まっている人
- ほしいのは待遇であって、業務ではない場合
    - プロジェクトに問題があっても、放置できる人
- できないことまで、簡単に安請け合いする場合
    - 自分ではできないことに対して、他のメンバーからの協力を求めない人
- 年齢が上ならば、威張っていいと思っている場合
- 口先だけの人
    - 平気で嘘がつける人
    - あるいは、実現性の見通しが立っていない時点で、簡単に「やります」と言い切ってしまう人
- 技術の受け渡しの部分で、必要なドキュメンテーションを書かない人
    - TBD(to be detetermined) が残るのは仕方ない。
- 自分の知っているノウハウは、他のメンバーに教えたくないと思っている場合(少なくともソフトウェアエンジニアの場合)
    - ベテランのエンジニアの場合、あと何年働いてくれるのか、気になることでしょう。
チームに対して、必要なスキルの引き継ぎができないと、事業の将来に関わります。
いままで、どのように技術の引き継ぎをしてきたのか、人材育成をしてきたのか、
聞いてみたくなるでしょう。
- 自分の判断ミスがプロジェクトに及ぼす影響を考えない人
- どのように貢献してくれるかについて仮説を立てているのかを期待しているのに、そうでない場合。
- 妥協ができない人
　設計は、何を選択して何を諦めるかということの塊だ。だから一切の妥協ができない人は設計ができない。

こういった応募者の場合には、採用時に見抜くことが大切だ。
#### 危険な兆候
- 既存技術をボロクソに言うわりに対案を持っていない場合
　既存技術の問題点を指摘することは割と簡単にできる。それじゃあどうするんですかというと、あまりにも大雑把な話しかしない。実は、詳しい対案など持っていないのに、否定することで、否定されている側よりも自分が優秀なのだという演出をしている場合がある。
- 成果物の品質に対してこだわりがない場合
- プロジェクトの１箇所で致命的なトラブルを生じた時に、自分の作業に手抜きをするタイプの場合

#### それぞれの状況について、応募者の状況を確かめるのは比較的簡単だ。
「最近習得した技術はなんですか。また、どのようにして習得しましたか」
のような素直な質問でも、素直な人ならば、状況がわかるだろう。

また職務経歴は、その人がどういうバックグラウンドを持ち、どのように学び続けてきたかを物語っている。
ソフトウェアの分野で重要なことは、実はソフトウェアで実現する内容についての理解だ。
ソフトウェア言語の文法を知っているかどうかは、それほどでもない。
ソフトウェアで実現する内容を知っていることは、その分野のライブラリを知っていることにつながる。

「ほしいものは待遇である場合」
技術的な内容を詳しく議論するときに、いきいきと話しているかどうかで
見極められるだろう。
待遇こそが重要である人は、技術的な内容について最新の動向について
関心を持っていることは考えにくい。

「どのようにあなたの成果物をテストしていますか」
そのコンピュータ言語やフレームワークの中で、標準的なテストのしかたがある。
それをちゃんと実行している人かどうか質問に対する返答で判断しよう。


## 適する場合
- 少しの学習で、目的の業務をこなせる場合
    - その目的を達成するには何が不足しているのかに気付ける人、またそれに対する対策をとれる人
        - 他の人に教えを乞うことができること。
        - 自分でも解決方法を調べて、解決できること。

- 得意分野について深い理解を持って、その前後に関わる周辺知識も持っている場合
    - その分野の技術に対して、入り口と出口に対応する技術の受け渡しの部分も知っている
    例：画像認識エンジニアの場合、カメラについての理解が深い
    例：画像認識エンジニアの場合、学習結果のdeploy先について関心を持っている
    例：機械学習の場合、どうやって学習結果の妥当性・性能を確保していることを示せる
- 若い人が上司であってもなんら問題なく、業務をこなせる人
- 自分の持っているノウハウが有効であれば、惜しげなく他のメンバーに渡すことができる。
- いい結果を出さずにはいられない。
- 自分の今のアプローチが適切であるか疑って、別のアプローチも考えられる人
- [地頭（じあたま）](https://qiita.com/dorarep/items/b9f7f6ff6e1bc344cf0a#%E5%9C%B0%E9%A0%AD%E3%81%AE%E8%89%AF%E3%81%95)がいい人。

- プロジェクト・マネジャーが知るべき97のこと [スキルでなく素質のある人を加えよう](https://xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%82%B9%E3%82%AD%E3%83%AB%E3%81%A7%E3%81%AA%E3%81%8F%E7%B4%A0%E8%B3%AA%E3%81%AE%E3%81%82%E3%82%8B%E4%BA%BA%E3%82%92%E5%8A%A0%E3%81%88%E3%82%88%E3%81%86/)
- [良いエンジニアを採用するための方法論](https://qiita.com/dorarep/items/b9f7f6ff6e1bc344cf0a)

- 学び続けているエンジニアの場合の利点
	- 成功するプロジェクトの共通点を見出している。
	- 成功するプロジェクトの共通点を自分たちのチームに取り込もうとする。
	- 利他的である。
	- 新規の課題を楽しんでいる。

### エンジニア採用の成功率を上げるには
#### 採用する側の立ち位置を明らかにする
##### 場合１：突出型
- 世の中のトップレベルの実装に匹敵する開発を推進できる突出した部分が突出していることを優先する。
学会などでの出会いを求めて探しにいくことが必要です。
応募者がやってくることを待ってはいけません。

##### 場合２：バランス型
- その分野での標準的な実装を、自分たちの分野でも実現することを優先する。
    その分野での標準的なアプローチを、とにかくまねて利用可能にすること。
    その分野での標準的なエンジニアが知っていると期待される内容を網羅的に知っていて
    それを事業に反映できる。
    　その分野のエンジニアが自分一人であっても、適切な方向に事業を持っていけることがのぞましい。
    その分野の初心者に対して、実務上必要なことの成長を助けられるのがのぞましい。

    バランス型を一人で担当させるか、複数人で担当させるのかによって
    候補者に要求したい資質と才能は違ってくる。
    既にその分野の人がいる場合には、複数人で協力してその業務を担当することができる。


##### 場合３：オペレーション型
- すでにビジネスモデルはできていて、それを運用できる人員が欲しい。

    すでに、DevOpsやMLOpsなどのフレームワークの利用手順が立てつけてあって、それを運用するだけになっている場合には、
    新規のメンバーに必須なことは少なくなります。
    すでに立て付けが済んでいるので、新規のメンバーに対する教育も手間ではない。
    だから、人員の採用は比較的楽になるはずです。

これらの求人の違いは、採用側が明確に意識して行動することです。

- 担当させたい業務の内容を明確に書く。
    - その業務の魅力を伝える。
    - その会社の開発力が伝わる技術ブログを多数公開する。
    - 既に、ある程度人がいて加わるだけいでいいのか、その分野を一人で担当しなければならないのかで応募できる範囲は異なってくる。
    - 担当させたい業務で、必須の能力が何であるのか、どの程度深く使いこなせるのが必須なのかを明確に書く。

- 欲しい技術の分野のエンジニアが集まりそうな学会でスポンサーの1社になる。
    　なるべくなら、そこで技術展示をする。
    　その技術展示に引かれて興味を持ってきてくれた人に
    　自分の会社に就職したいと感じさせる。
- 必要な項目に対して優先順序を付ける。
    - いつまでに採用しないと開発スケジュールに影響するのかを検討する。
    - その技術分野の仕事がいつまで続くのか予想を立てる。
    - 技術派遣会社から人を派遣してもらった場合の見積もりも立てる。
###### 必要な項目のうち緊急性が高いのは何か
緊急性が高い要件を満たしている人材は確保するのがよいと考える。

必要とする項目を一人の人間が全てを解決するなんて期待しない。
- トップカンファレンスに発表した経験があって、製品実装の経験があって、マネジメント経験もある
　そんな人っていないよね。
緊急性の高い部分や、容易に身につかない知見をもっていることを重視しよう。
- 供給されやすい部分は、待っていれば自然にでてくる。（待遇さえ十分ならば）

## 同じ分野にもっと頼りになる人がいますか
求人する際に、気にしておきたいのが、その同じ分野にもっと頼りになる人がいるかどうかです。
#### いる場合
- その頼りになる人に指導してもらうやり方ができます。
- 候補者への条件を緩めることができます。
#### いない場合
- その候補者が、採用後にさまざまなタスクをこなしてくれることを期待することになります。
    - そのエンジニアが、ビジネスの中のその分野について学んでいってくれることが大事です。
    - 関連分野のエンジニアに敬意をもって接してくれることが大切です。
    - 必要なことが何かを確認して、学んでいくことができること。
    - そして開発した成果を、引き継いでいくことができるように、コードとドキュメントをバージョン管理してくれる人であることが大事です。
    - 学び続けられているエンジニアであることが大切です。


### 採用後の業務遂行を成功させるには
「プロジェクト・マネジャーが知るべき97のこと」 からいくつかリンクを示す。
- [まずプロジェクトの「目的」を確認せよ](https://xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%81%BE%E3%81%9A%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE-%E7%9B%AE%E7%9A%84-%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%9B%E3%82%88/)

- [成功はビジネス価値で評価される](https://xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E6%88%90%E5%8A%9F%E3%81%AF%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E4%BE%A1%E5%80%A4%E3%81%A7%E8%A9%95%E4%BE%A1%E3%81%95%E3%82%8C%E3%82%8B/)

- [労力ではなく結果を評価する](https://xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E5%8A%B4%E5%8A%9B%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E7%B5%90%E6%9E%9C%E3%82%92%E8%A9%95%E4%BE%A1%E3%81%99%E3%82%8B/)


###### 就職氷河期を経験してきた人の雇い方:提案
- 地頭の良さを重視しよう。
- その分野への適切な指導・教育というチャンスを与えられれば、仕事を遂行できる人を見つけよう。

## 年齢・性別を除外して能力・経歴（近年分）を見てみよう
- [「求人票は年齢不問としながらも、年齢を理由に応募を断ったり、書類選考や面接で年齢を理由に採否を決定する行為は法の規定に反するものです。」](https://www.mhlw.go.jp/content/000708105.pdf)
とある。
しかし、履歴書の書式に、生年月日の記載がある以上、判断に影響してしまうことは避けられない。

年齢を見てから判断すると、思い込みをもって、その人の経歴や能力を判断してしまう。
だから、年齢と性別を見ないで、能力と職務経歴（近年分）を見てみよう。
そうすると、その業務にふさわしい能力を持つ人を見つけやすくなるんじゃないかと考える。

アメリカの求人の場合には、次の要件を満たすことが法律で求められている。
努力事項ではなくて義務となっている。
[全ての人に公平な雇用機会をアメリカ採用の基本「EEO」](https://stscareer.com/eeo/)



----
参考記事
[良いエンジニアを採用するための方法論](https://qiita.com/dorarep/items/b9f7f6ff6e1bc344cf0a)


---
蛇足
##### 統計データの謎
- それぞれのデータでの年齢層の階層が一貫していない。
- 「６５歳以上」ってのは、何歳まで含んでいるんだ。
- 統計の一貫性を損なっているのはどうして？

![Screenshot from 2024-09-09 23-22-51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/0e2f6588-66a0-2df6-475d-18d6a34a928e.png)
[引用元](https://www.mhlw.go.jp/toukei/list/3-20c.html)

国勢調査もあるはずなのに、なぜ、もう少し新しい統計がないのだ。

##### ベテランエンジニアと言った時点で、アメリカでの求人の考え方にそってなさそう。
私は、頭が硬そうだ。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/5ae7e5d7-4ce6-817e-372b-39f0ae1a892e.png)

若い世代が結婚して、子どもをもてるようにするのも忘れないでね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83761/58accd37-52b3-320e-0407-95cec9074d03.png)