ミドル・シニア向けのエンジニアジョブ紹介をしてきて、最近”年齢制限”
増えてきていないかと感じてきたので、この1年間の傾向を調べてみました。
＊分類の仕方
・弊社に来ている案件のうち、ＣＯＢＯＬ開発案件を対象（汎用機、オープン問わない）
・年齢制限がついてる案件を分類
・40代までの年齢制限記載があるもの
（30代まで、20代までの制限もこちらに含む）
・55歳までの〃
・60歳までの〃
・65歳までの〃
・年齢制限記載がない案件
（年齢不問ということではなく単純に案件に年齢制限記載がない案件）
各月案件数はばらばらですので、比率で表現しています。
この1年間のCOBOL案件の年齢制限の傾向
この1年の傾向を調べると、
①年齢条件のついた案件が増えてきている（50%→80%）
②年齢が低い制限がどんどん増えてきている。
（40代+55歳までが この1年間で30~40%→60%~70%になってきている。
②55歳以上の層が薄くなってきており、案件の中で狭き門になってきている。
（25%→10%に減）
レガシィ言語なのに、年歴制限をデジタルでつける意味はどこにある？
例えば、55歳と56歳、59歳と60歳、61歳、1歳の違いで案件の仕事上にどれだけ影響するのだろうか？
昔みたいにハードなプロジェクトなので、30代、40代の若手ではないと体力上乗り切れませんというならわかりますが
現在は、プロジェクト現場でも『働き方改革の波』が押し寄せて大抵の職場は残業管理に非常に厳しくなってきています。
スキル・能力があれば、対応できるプロジェクトは増えてきているはずです。
では、なぜ年齢制限つける案件が増えているのか？
それはスクリーニングするための一番簡単の方法だからか？
年齢に対してのイメージがあるからか？
本来、案件にマッチする人材を決める際には、スキルと人物で選ぶべきだと思います。
でもそれをスクリーニングするためには、職歴表を読んで、分析しないといけません。
多くの応募者の職歴表を読んで、分析する手間をかけるよりは、年齢でまずスクリーニングをかけたほうが簡単なのではないか。
もしくは、年齢高いと扱いにくいという感覚でとらえれているのかもしれません。
そうだとしても、６０歳までというデジタルナンバーで区切ってしまうのかよくわからない。
せめて
〇〇歳ぐらいまで とか幅を持った言語的表現ができないものだろうか？
あまり日本が『嫌老社会』だとかは断定したくありませんし、やはり、職歴の中で唯一デジタルのものが年齢でそれである意味だれがやってもスクリーニングできる簡単さからではないかと思う
年齢バーによって必要な人材をとりこぼしている
現に弊社でも６０歳過ぎてプロジェクトでコーダとして、バリバリ改修・テストしている人間もいれば、顧客と会話しながら十分要件・設計を決めて行っている人間もいる。
私の経験上、面談まで行くと、ほとんど合格で、途中でスキル合わずに退出する件数も少ない。
役になっていると言われることの方が多い。
しかしこうした入ったらお役に立てそうな人材でも、案件が年齢バーで区切られると提案をあきらめざるを得ない。
年齢バーではなく職歴表を見て内容分析してスクリーニングしよう
プロジェクトの成功要因の8割は人が握っているようだ。
やはり、その人個人の培ってきた経験とスキルそして人間性が”プロジェクトと合うか”が重要なのだ。
経験が豊富な分、経験の差や長さによって個人差が大きくなる。
どんな経験してきたかが職歴表であり、長い職歴表も一定のルールがあれば、プロジェクトとしての簡単なスクリーニングができるはずだ。
例えば
１．必要スキルの年数
２．必要スキルの経験時期
３．従事工程
４．プロジェクトの期間
５．インターバル
年齢で単純にスクリーニングするより、職歴表でスクリーニングしたほうがスキルや環境ニーズとのマッチ度は高くなるはずで、そもそも年齢制限はいらない。
今後、ＡＩ、ＩＯＴと新しい分野でのＩＴ人材のニーズが高まってきている。
レガシィ系の人材は、年代層をミックスしながら継続していかないとＩＴ人材そのものの全体最適は図られないのではないかと思う。
年齢層で区切るのは簡単だけど、対応可能な人材も落としていることに気づくべきだ。年齢を単純な足切りのデジタル数値で考えるのではなく、より幅広く考えれば技術者の補充や、拡張により対応しやすくなるではないか。
次回はより人材不足が深刻な、オープン系での年齢制限の壁を調べてみたい
