• 03-6869ー4694
  • info@market-interface.co.jp

年別アーカイブ 2019

ベテランエンジニアはPMOとして活躍できるのか

ミドル・シニアエンジニアのスキルを活かす選択肢のひとつとして多くの人が考えているのはPMOといった役割ではないでしょうか。PG、SE、PL、PMとエンジニアとしての役割が管理・調整へと経験・年齢を重ねるごとにポジションが変わっていき、管理がメインとなったベテランがPMOとしてそのスキル活かせないかと考えるのはごく自然だと思います。
現場でバリバリ開発は難しいし、新しい技術への適応は自信ない。でも多くの経験を活かしながら、PMOとして若い人たちが苦労しているプロジェクトを支援し役に立てるのではないか。多くのシニアのエンジニアがそう考えていると思います。多分プロジェクトも、自分のスキルニーズを求めているのではないかと。
私もミドル・シニアのエンジニアの紹介事業をし始めた当初はそう思っていました。
PMO案件の年齢ハードル
しかしながら、これはシニア側からの見方で、現実の案件状況はすこし違っているようです。
PMO案件にも年齢ハードルがかなりあります。
もちろん、PMOといっても、役割はピンキリです。議事録作成だけのもあれば、ベンダーコントロールや顧客社員の役割としてPMとしての動きを求められている案件もあります。
すべて一緒くたにして調べるのもどうかと思いますが、案件量が限られていますので今回、弊社に来ているPMO案件で、どういう年齢制限がついているのか調べてみました。
対象:弊社に来ているPMO案件(2018年11月~2019年10月)全体として900件強です。
調査方法:案件についている年齢制限を年代別に分類しました。
30代は、30代までの他、それ未満の制限のもの(20代まで)や若手希望といったものも含まれています。
集計を見ると、6割以上は、40代まで、55歳までで含めると、76%にまでなります。
55歳以上、60歳以上も提案OKという案件は全体の6%しかありません。
(もちろん年齢制限あっても、誤差範囲であれば、提案できる案件があるかと思いますが、年齢高い分を超えるプラスαのスキルが必要になってくると考えたほうがいいでしょう。)
昨年の11月からの推移を見ても、山谷あれど、1年通して同じような傾向のように見えます。しかもCOBOL案件より狭い。
(COBOLは約10%)
55歳を超えたエンジニアにとって、PMOとしてプロジェクト支援したいという気持ちの広さほどには窓口が開かれていないのが現状のようです
どうしてPMOに年齢制限が付くのか
PMは若手なんだから、経験豊富なPMOが支援していく。これこそ理想的な姿に見えるのだが、なぜ年齢制限がつくのでしょうか?
(PMOは、本来的には組織内でプロジェクトを横断的に見る組織のことを指すが、)
ほとんどの案件は、プロジェクト内でPM補佐、ないしは支援をする内容となります。作業内容もプロジェクトにかかわる種々雑多な作業を手伝ってPMの負荷を下げたり、代替する役割となります。
PMOの求められる役割としては、過去経験をもとにアドバイスをしてくれることではなく、PMと一緒にプロジェクトを担ってほしいということなのかと思います。
PMが30代だとすると、60歳のPMOに仕事を依頼するのは心理的ハードルが高い。(と考える人が多い)
必然的にPMと同世代のPMOということになってくるということです。
PMOに求められるのは、まずはPMの手足になれるかということ。そこにさらに経験が付いていれば良しの順位づけなのかも知れません。
シニアOKのPMO案件に求められるもの
逆に55歳以上でもOKなPMO案件で求められているスキルはなんでしょうか。求められるスキルはひとつではないでしょうが、プロジェクトごとの重要度を見て振り分けしてみました。
ここには50代後半、60代、年齢記載ないものを含めています。
調べてみると業務スキル、技術スキル条件がついているものが6割となります。
PMOとして調整業務とか進捗管理とかのスキルは当然のこととして顧客業務やプロジェクト技術等+αが合わないとPMOとして参加できないのが現実です。
あなたのPMOスキルを知っている人が一番の顧客になりうる
そんな技術スキルあれば、技術で売っています、と言われる方もいらっしゃると思います。
多くのプロジェクトで経験を積んでいるし、調整能力にも若い人とも上手くやれるという自信がある方は
自分のスキルをよく知っている人を通してPMOに入る方法もあるでしょう。
正攻法で臨めば、スキルや経験ベースでの競争になります。どう調整能力をアピールしてもプロジェクト固有の経験となり、新しいプロジェクトに適用できるものが何かを語らないといけなくなります。それは現実には難しいでしょう。資格もその一つになりえますが、経験には勝りません。
競争を避けるにはPMOとして役に立つだろうと思われているリレーション・コネクションを多く持ち、プロジェクトに呼んでもらう必要があるということではないでしょうか。
PMO案件・人数規模は開発案件と比較して少ない。
PMOは開発者ニーズに比較して求められる案件・人数は少なくなります。例えば100名開発者が必要なプロジェクトにPMOは何人必要でしょうか。
PMOもまずは社内から充当していくでしょう。(自社にスキルがない、専門家がない、人がいない(いなくなった)トラブっている等々)の条件がないと案件化しないでしょう。
その少ないPMOの案件をメインターゲットで仕事を得るには、スキルに+αが必要だと思います。
決して、消去法(技術がないからとかアプリできないから)でPMOを選択すべき状況ではないと思います。
あくまでもエンジニアのスキルのひとつとしてPMOスキルがあるぐらいで臨んでいかないと難しいのではないでしょうか。
ベテランエンジニアはPMOとして活躍できないのか
私は今でもベテランエンジニアがプロジェクトに入れば、現実的にプロジェクトの役に立てると思っています。
しかしながら、現状はウエルカムの状況にはなっていません。
55歳以上のエンジニアが増えている今、PMOとして活躍できないか考えられているエンジニアも多いはずです。
是非、PMOを考える際にPMOとしてのそのもの経験だけではなく、どんな技術や、業務バックグラウンド等があり、PMOとして何を差別化できるのか深堀したり、PMOとしての自分の能力を高く評価してくれそうな関係先はないか洗い出しながら選択していってほしいと思います。

人材不足の激しいJava案件に年齢の壁はあるのか?

前回、COBOLの案件で、年齢の壁がすこしづつ高くなりつつあることを案件内容をもとに分類してみました。
ただCOBOL開発のマーケット自体が広がる市場ではないので、大規模な統合や開発が終わった現在、
人材が余っている競争状況の中で、年齢壁が高くなっているという結論かも知れません。
実際来ているJavaの案件を調べてみた
そこで今回は成長著しいオープン系案件に年齢の壁があるのかについて調べてみたいと思います。
オープン系での開発といっても種類も沢山ありますので、今回は、その中でも最もポピュラーなJava系の開発案件を中心に調べてみました。
分類の仕方
弊社に来ている案件のうち、Java開発案件を対象(Javaスキル要件があるもの含む)とします。
その中に提案にあたって、年齢制限がついてる案件を分類
・30代までの年齢制限記載があるもの
・40代までの〃
・50代までの〃
・年齢不問と記載があるもの〃
・年齢制限記載がない案件
各月案件数はばらばらですので、比率で表現しています。
期間は、2019年1月から9月末までに弊社に来た案件としています。
Java案件の年齢条件の傾向,COBOLとの比較
Java案件の傾向を調べると、
①30代、40代までの案件がで5割、6割占める。
②年齢記載ない案件比率はすこしづつであるが減る傾向にある。
③年齢不問と記載あるものは全体の5%。
④50代+年齢不問で10%弱の比率となっている。
さらに前月のCOBOLでの案件のグラフと比較してみます。
COBOLでも55歳以上は比率として10%弱であったがJavaにおいても50歳以上が10%弱となっている。
COBOL同様50歳過ぎると案件数が少なくなります。
年齢の壁はCOBOLもJavaも同じ?
否、COBOLは55歳以上が10%あるのに対し、Javaは、50歳以上可が10%となっています。
数字的には、(案件数や人材ニーズが多い)Javaのほうが年齢制限が厳しいのかということになります。
人材ニーズが高いJavaの方が年齢の壁が大きい?
そこで50歳代の案件を少し細かく見てみました。
Javaで50歳代OK案件の全ての案件がなんと55歳未満の年齢指定での案件でした。
さらに60歳もOKと積極的に記載あるものは、全体で3000件ある中でたった1件でした。

実は案件数が圧倒的に多いJavaの世界でも55歳超えると提案の壁が高くなってくるのである。
30代までの層が20%以上ある分、COBOL市場より中高年のJava技術者に狭き門となっていると言えます。
現状では、55歳以上でJavaバリバリという方は比較的少ないので(中高年のJavaバリバリの開発者の方、すいません)
年齢制限つけている影響はそんなにないかも知れません。(良心的に解釈すれば、対象人口が少ないから年齢条件ついているかも?)ただ、5年後、10年後Java経験者の中高年エンジニアが増えてくる状況になったときにどういう傾向になっていくのかということだ。
人材ニーズが高いから年齢条件は緩いというわけではない。
少なくとも現状では人材不足=スキルあるシニアにもチャンスが増える という状況になっていないということだ。
年齢の壁は(人が余っていて)競争がもたらしているものではないということだろう。
若年人口がだんだん減っていく中で、逆に若年人口を求める案件が増えている人材不足と言われていても、スキルがあってもシニア活用が進んでいない現実がここにある。
スキルがある人もいるのに誠にモッタイナイ話です。
この傾向がこのままつづくのかどうか今後も注視していきたい。

最近のCOBOL案件の年齢の壁:どんどん高くなる

ミドル・シニア向けのエンジニアジョブ紹介をしてきて、最近”年齢制限”
増えてきていないかと感じてきたので、この1年間の傾向を調べてみました。
*分類の仕方
・弊社に来ている案件のうち、COBOL開発案件を対象(汎用機、オープン問わない)
・年齢制限がついてる案件を分類
  ・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代の若手ではないと体力上乗り切れませんというならわかりますが
現在は、プロジェクト現場でも『働き方改革の波』が押し寄せて大抵の職場は残業管理に非常に厳しくなってきています。
スキル・能力があれば、対応できるプロジェクトは増えてきているはずです。
では、なぜ年齢制限つける案件が増えているのか?
それはスクリーニングするための一番簡単の方法だからか?
年齢に対してのイメージがあるからか?
本来、案件にマッチする人材を決める際には、スキルと人物で選ぶべきだと思います。
でもそれをスクリーニングするためには、職歴表を読んで、分析しないといけません。
多くの応募者の職歴表を読んで、分析する手間をかけるよりは、年齢でまずスクリーニングをかけたほうが簡単なのではないか。
もしくは、年齢高いと扱いにくいという感覚でとらえれているのかもしれません。
そうだとしても、60歳までというデジタルナンバーで区切ってしまうのかよくわからない。
せめて
〇〇歳ぐらいまで とか幅を持った言語的表現ができないものだろうか?
あまり日本が『嫌老社会』だとかは断定したくありませんし、やはり、職歴の中で唯一デジタルのものが年齢でそれである意味だれがやってもスクリーニングできる簡単さからではないかと思う
年齢バーによって必要な人材をとりこぼしている
現に弊社でも60歳過ぎてプロジェクトでコーダとして、バリバリ改修・テストしている人間もいれば、顧客と会話しながら十分要件・設計を決めて行っている人間もいる。
私の経験上、面談まで行くと、ほとんど合格で、途中でスキル合わずに退出する件数も少ない。
役になっていると言われることの方が多い。
しかしこうした入ったらお役に立てそうな人材でも、案件が年齢バーで区切られると提案をあきらめざるを得ない。
年齢バーではなく職歴表を見て内容分析してスクリーニングしよう
プロジェクトの成功要因の8割は人が握っているようだ。
やはり、その人個人の培ってきた経験とスキルそして人間性が”プロジェクトと合うか”が重要なのだ。
経験が豊富な分、経験の差や長さによって個人差が大きくなる。
どんな経験してきたかが職歴表であり、長い職歴表も一定のルールがあれば、プロジェクトとしての簡単なスクリーニングができるはずだ。
例えば
1.必要スキルの年数
2.必要スキルの経験時期
3.従事工程
4.プロジェクトの期間
5.インターバル
年齢で単純にスクリーニングするより、職歴表でスクリーニングしたほうがスキルや環境ニーズとのマッチ度は高くなるはずで、そもそも年齢制限はいらない。
今後、AI、IOTと新しい分野でのIT人材のニーズが高まってきている。
レガシィ系の人材は、年代層をミックスしながら継続していかないとIT人材そのものの全体最適は図られないのではないかと思う。
年齢層で区切るのは簡単だけど、対応可能な人材も落としていることに気づくべきだ。年齢を単純な足切りのデジタル数値で考えるのではなく、より幅広く考えれば技術者の補充や、拡張により対応しやすくなるではないか。
次回はより人材不足が深刻な、オープン系での年齢制限の壁を調べてみたい

「人生100年時代のライフプランニング」とは

先日、HR関係のセミナーに参加して
「人生100年時代のキャリアプランニング」と題してある企業の取り組みの発表があった。
その企業は、長く働いていくためのスキルアップのモチベーションを向上させていく、
そのためにスキルポイント制を導入しながら年功序列からスキル重視へと転換させていく
取組をしているという発表であった。
企業としての取り組みとしては画期的なのであろう。
でも「人生100年時代のキャリアプランニング」といったときに、
何か重要な視点が忘れ去られていないのか感じぜずにいなかった。
人生100年時代になり、労働できる(しないといけない?)年数は増えてきている。
弊社も60歳超えたIT人材を紹介していく事業をしているが、
60歳、65歳を超えてもシステム現場でバリバリこなせる方もいらっしゃる。
仕事をしたいというシニアのエンジニアが多い中、まだ仕事を提供できる場が増えていないのが現実だ。
政府は、65歳定年制の推進や、70歳までの雇用を努力義務としていくという動きがあるが、
一方で企業側は終身雇用の放棄を宣言し、それどころか40代からの早期退職募集を行う
企業が増えてきているのも事実だ。
キャリアを同じ会社にて続けていこうにも、企業はそれはダメよといいつつある。
「キャリアプランニング」どこで作る?
キャリアプランとは、人生において、将来的にどのようになりたいかという目標を持ち、
計画を立てることであり、人生設計の中の、働くことに関するプランニングである。
本来は、自分自身の人生のためにあるものなのである。
でも実際、我々が「キャリアプラン」として作る場面は、学校であったり、企業の中だ。
会社で作る「キャリアプラン」は、自分の所属する会社でどうスキルアップするかを作ることが目的となっている。
右図は、キャリアプラン作成の説明時によく用いられる図だ。自分のキャリア像と企業の目標、求めるもの
とのすり合わせが重要になってくる。
もちろん人生のキャリアを積み重ねる場として企業の果たす役割は大きい。
だからこそ、企業の求めるものと個人のキャリアとのすり合わせが必要なのだ。
人生100年時代のキャリアプランとは
しかし、人生が長くなり、今終身雇用がなくなりつつあり、人生でのキャリアも複数ステージとなってきている。
企業の中だけで「キャリアプラン」を作るだけでは「自分のライフキャリア」は築けなくなってきているのだ。
複数ステージでのキャリアプランニングでは、ベースに「個人としてのライフキャリア」があり、
それに合わせて、各ステージごとに、どこで、どうキャリアを積んでいくのか考えながら、”選択”
していくことが求められる。
すり合わせも、キャリアを積み重ねる場として企業があり、自分のキャリアを
形成していくためのすり合わせであり、個人のライフキャリアの重きが出てくるであろう。

選択はリスク、でも選択してきた方のほうが…..

自分のキャリアをステージごとに見直しながら、企業との関係も定期的に見直してみる。
もし違うのであれば、”違う選択”をしないといけない場合が出てくるであろう。
自分で選択をしていくこと、終身雇用で生きてきた世代からすると、リスクでしかない。
でも、多くのシニアに仕事を紹介している立場からすると、過去
”選択してきた方”のほうが1社で全うされた方より、圧倒的に”スキルも立っており”
仕事も紹介しやすいく、顧客にアピールもしやすい。
選択を勇気をもって行っていくこと、これが100年時代には重要になっていく。
ライフキャリアはなるべく早めに考えたほうがいい。
60歳、65歳定年を迎えて、さて私のこれからのキャリアは・・・と考えても
すでに遅い。あなたの積み重ねてきたキャリアで勝負するしかない。
本来は、仕事も任され、自分の周りも理解できるようになる30代、40代から自分の将来
キャリアをどうするか考え始めたほうがいいのかも知れない。
今までのスキル・経験をもとに将来に渡ってどこで、どうキャリアを延ばしていくのか。
もちろんプランどおりに進むわけではないので、見直しや修正、方向転換も必要になるだろう。
ただ、自分のライフキャリアを会社まかせにしないということが重要なのだ。
もちろん 「あなたのライフキャリア」はあなた自身のものだから。

自分の職歴の”とがった”部分を見つけよう

60歳周辺のエンジニアの方と面談して”どんなお仕事希望しているんですか”と聞くと、
自分が過去経験のあるスキル全部を希望対象として挙げてこられる方がいる。
例えば
20年も30年もブランクのあるスキルだったり、
30年も職歴あるのに、1,2年しかしていないスキルであったり
プロジェクト調整役だったらみたいなスキル
をもととして”お仕事つければ”とお話される方もいる。
当然プロジェクトで経験されたスキルであるから、いれば”なんらかのお役”に立つ可能性はあるのだろうが、
相手の具体的なニーズに答えられなければ(少なくとも答えられそうでなければ)、
応募したところで、選ばれないだろう。(ほとんど職歴表出しても面談には通らない。)
若い人材ならともかく、あくまでも、即戦力で対応できる人材として求められていると認識すべきだ。
自分はどうやった分野で競争できるのか、自分の長い経験を見ながら
とがった部分を明確にして、そこにフォーカスしていくことが必要だ。
自分の職歴の”とがった部分”を見つけて行こう。
そんなことを言っても、私にはとがった分野なんて思いつかないという方には、
次の方法をおすすめしたい。
自分の経験・スキルを要素分解して、
・掛け算する
・深さを足す
・逆に幅を狭めてみる
こうして、自分の職歴上での特徴ある分野を見つけ出すのだ。
単品(COBOLといった言語)だけだと、なかなか若い人には生産性で勝てない。
20年も30年も長く経験を経ているシニア。若い人に負けない多くの経験や広い範囲での実務経験を積み重ねてきている。
自分の経験・スキルを単純に列挙するよりも、掛け算、足し算して、経験者としての深く・濃い部分をみつけだそう。
1.掛け算
たとえば、言語だけではなく、業務スキルを掛けてみる。
単純にVBAでは提案難しくても、保険料計算の業務経験があれば、VBA+保険料計算 となるとがぜん競争力が増す。
2.深さを足す
PMOのような分野ではスキルとプロジェクトニーズのマッチングが難しい。
PMOとして求められる範囲はピンからキリまである。(あなたが、キリの部分で働きたいと思うなら、それは若い人に
取って変わられます。)
・単純にプロジェクト支援という経験を提示するより、
・品質管理で指標を作りながら成果をあげた、
・大規模プロジェクトで数百名のプロジェクトのコントロールをした
顧客の立場で業務要件のとりまとめや、ベンダーコントロールしてきた。
といった”支援”という仕事を深堀して、より”具体的”に提示できるといいだろう。
3.幅を狭める
たとえば汎用機言語であれば、COBOLよりアセンブラ。
市場も少ないが、若い人はまず経験しない分野だ。また、汎用機でも言語より基盤のほうがそもそも人口が少ない分
競争も少ない。
現状でも、ほぼシニアしか携われない分野が残っているのも事実だ。
こうした分野をかじっていれば、もうあなたしかいない ということになる。
このように自分のスキルを要素分解して掛けたり、深堀したり、フォーカスしたりすることで
自分の特徴なり、競争力が増してくる。
要素分解はできるけど、今の市場で求められているのか・・
自分の経験・スキルの要素分解は出来ると思う。
でも要素分解の内、その要素が市場で求められているかどうかわからないと、
”強み”としてアピールできるのかわからない。
一番は、様々なエージェントとあって自分のスキル”要素”がマーケットでどのくらい求められているか
確認することだ。
多くのエージェントがニーズが多くあると言ってくれればそれは求められている可能性が高い。
そこまではできないという方は、indeedのようなサイトで検索して、
どんな要素が求められているのか、求められている要素とその数を見てみることだ。
多くの案件で共通的に求められている要素であれば、それは強く求められている可能性がある。
自分の強みを認識して
シニアのエンジニアには、長い経験の蓄積があり、強みを生かせる部分が必ずある。
自分のスキル・経験要素を掛けたり、深堀したり、狭めたりして、自分の”強み”が
どこにあるのか自分なりに認識してもらえればと思う。
自分の強みを認識することによって、仕事を探す上での最初の一歩も違ってくるはずだ。