IT業界でリーダー経験を重視される理由。 リーダー経験のしかた。あれこれ。


30代も中ごろになってくると、要求されだすのがリーダー経験でしょうか。

近年は人材不足感もあってか、さほど必須条件として聞くことは減りましたが、それでも検索をしてみると、圧倒的な数がヒットしてきます。

不況に入り需給が逆転すると、必須度はまた高くなってくるのだろうと思います。

そもそも、【リーダーってなによ?】とか【どうやって経験するもんな訳?】ってな疑問もあるはずな訳で今回はそんな方向で一本記事を書いてみる事にしました。


1.オッサンだと、なんでリーダー経験求められんの?

プログラマーの市場価値が年齢見合いで減少する事とも関連ありそうですね。

30代までであれば、個のエンジニアでも十分に市場価値があります。その後は普通、市場価値は減衰します。(おまけに給料や単価も高くなる)派遣やSESはもちろん、正社員で雇用するにしても(むしろ、雇用するからこそ)ただのコーダーではない、雇用する理由と言うモノが欲しくなる訳です。

そこでチームリーダーですが、これは【個のエンジニアとしてではなく、チームとして成果を上げる】戦いになります。(同商流で組めるメンバーたちや商流は必要)会社側への影響は大きく、客先・持ち帰りに関わらず、売上や利益の増大にプラスの影響をもたらします。

ある程度年齢によらないニーズが発生してくるわけですね。なので、市場価値が下がってきた40代以降で応募可能な求人はリーダー経験を求められるものが『相対的に』多くなるものと考えられます。

《余談1 年齢について》
※景況感で変動するので要注意。
※年齢は市場価値のピーク。超えても仕事がゼロになったりはしない。
※ポジション名はてきとう。

コーダー(言われて動く層)28歳~32歳くらい?
所謂オフショアやツールなどで代替できる層。
なので、安けりゃ安いほうがいい。大規模案件の場合は、思考すら期待されていない。何しろメイン担当であるから、技術的なコダワリも強い事が多い。(若いウチは仕方無いんだが)そのまま年齢を重ねてしまって視座が上がっていかないと、プロジェクト全体や顧客の都合を無視してミョーにズレたあるべき論を語るオッサンに成長してしまったりする。これが嫌われるオッサンと言うやつ。

・システムエンジニア(プロジェクトの中で自走できる技術者)30歳~45歳くらい?
所謂オフショアやツールなどで代替しづらい層。
どこ行っても通用する人たち。40代に入ってから市場価値のピークを迎える印象。商流や業務知識の重要度にもよるかなあ。それでも、市場価値は永続はしない。

単独のエンジニアの市場価値のみで、45歳以降を戦っていくのはなかなか難しい。他のエンジニアとは差別化された特別な能力(技術・調整力・業務知識などなど)を駆使して、戦う。

のだが、若いやつらと一緒に現場入るなり、受託回すなりすれば個人の年齢とかあんまし関係なくなったりもするので、そんな路線が現実的かなあと。技術・調整力・業務知識などがあって、若いやつらを助けたり守ったりするオッサンとか、むしろ来てくれ感あるしね。
チームマネジメントやリードは汎用的なスキルでもある為、それなりに経験者がいます。40代になってから『リーダー経験したいです』とか言い出しても、間に合わないかもしれないので注意。だいたい30代の中頃から要求される事が多いかと思います。

リーダーやマネジメントで生き残る路線は、スキルでぶん殴る路線のフリーランスとは違い、他のメンバーや会社の競争力も含めた組織力でぶん殴るという正社員向けの戦略かもしれませんね。

汎用スキルなので、転職後も使える(他のソフトハウスと組めばフリーでも使える。異業種でも使える)と言う点も特筆ですね。


※画像は悪い例です。


2.リーダーってなによ?

PLや、PMと言ったポジションの話はいったんさておきたく思います。会社やプロジェクトによってこの辺りは様々ですし、あまり統一された言葉ではない様に感じます。経験あれば、そりゃ求人がゴロゴロという事になりますけどね。

今回扱う『リーダー』は、開発プロジェクトにおいて複数名の上に立って管理して、さらに上位の権限を持つ(PMとかPLとかお客様とか)人に報告したり、作業依頼を受けて受ける受ける受けないの判断や、メンバーへの作業割り振りのような事の経験をさすテイで行こうかなと。

深い話をすると、リーダーシップとマネジメントとか、話が沼にハマっていくので、今回は回避です。

・受託の場合
受託のPM(?)がいて、複数案件を掛け持ち中。PMが対顧客で調整を行うのに対し。
その下の、案件専属で自社メンバーへの実作業及びタスクの振り分け、進捗の確認、そしてPMへの報告等を担当しているリーダーさん。

・準委任の場合(ウォーターフォール)
発注側のPMがいて、その下の、サブシステム単位専属で自社及び同商流のメンバーへの実作業及びタスクの振り分け、進捗の確認、そしてPMへの報告等を担当しているリーダーさん。

・準委任の場合(スクラム)
そのポジションはありません。(スクラムマスターはちょっと違う)

・派遣の場合
上記の受託の場合・準委任の場合(ウォーターフォール)いずれかに派遣で参画。


SEとは違う視点でプロジェクトに関わっているPM(等)の事情や優先順位を把握して調整ができる事。技術的にはプロとして十分なレベルに達しており、メンバーの教育や支援。作業の見積もりが可能だったり、各メンバーの担当作業を管理できたりする。

こんな人が市場価値が高いのはイメージしやすい話かと思います。

世間で言う(PLではない)リーダー経験とは、多くの場合こういった立ち回りができる人のことを指しているものと、私は推測しています。


《余談2 推進力と実行力》
PMはマネージャーであり、推進力が必要なもの。
推進力は計画を立てて方向性がブレないようにハンドリングする人で、実行力は立ち塞がる課題に対して適切なアプローチが出来る人を指します。

リーダーは実行力が必要です。
実行力は課題解決方法をマネージャーに提案でき、方針に乖離が出ないように推し進める力になります。


※なお戦隊だと、リーダーはだいたい赤い人です。



3.リーダー発の局所的炎上とは

まったく統計的な根拠などは無い話で、あくまで現場サイドの肌感レベルの話です。リーダーできる人の不足はやはり強く感じられます。

PMに対して、何でもYes。できます・やります と言ってしまう人がリーダーになると、とても危険です。

PMはプロジェクト全体の進捗の管理や、顧客への進捗報告を担当しています。PMの立場に立って考えた場合、そりゃ、遅延されたらヤな思いが待っていますし、線の引き直しも発生します。できれば進捗通りにやり切ってくれるとありがたい訳ですが。

チーム単位であっても、想定外の事は起こるもの。使えるはずのものが使えない、環境が動かない、メンバーのスキルの不足、当初の見積もりよりも作業工数が大きい、もしくは難易度が高い。などなど。遅延はいかようにも起きえます。ガンバって進捗守ってくれるチームは信頼もされますが、どうあがいても無理な状態から『できます』ってやっちゃうと、これは大変です。

局所的炎上の発生です。PMはやってくれるつもりでいます。当のリーダーからそう報告を受けています。PMは視座が高い反面、各メンバーの抱えている問題なんかは見えません。ギリギリになってから、突然遅延が報告されてきます。PMはビックリです。顧客に対して『大丈夫』と報告してしまってたりします。そうなると、約束した期日までに、無理目の作業をメンバーみんなでやり切るモードに突入です。まあ、無理なもんは無理なんですが・・・。で、やっぱり遅延が出ます。

PMにしてみれば、虚偽報告くらった状態です。背中からバッサリ切られたようなものです。本来のタイミングで正しく報告されていれば打てた手が、打てなくなったりします。顧客に損害を与えた場合、最悪中の最悪、損害賠償まで発展しかねません。

頑張ってやり切れるならばやってくれた方がありがたい。

無理なら無理と。どういう理由でその遅延が起きたのか。なるべく早いタイミングで知らせてほしい。

こんなのがPM側の希望になります。

こういった立ち回りができるリーダーが、IT業界では結構少なかったりします・・・


4.リーダー不足の要因

もともと、『人と話さなくてもできるお仕事』と勘違いして(言われて?)IT業界を志すタイプの方が少なくない事。特に近年は『リーダー経験が必要』と言う要求も減った気がするので、認識されてないという事もありそう。この辺りはトレンドの問題もあろうからさておき。(特に近年の人材関連トレンドは実情を無視してたりするので)

構造的に影響してそうなのは、下記あたりかなあ。

・プロジェクト規模の矮小化傾向

・準委任契約まわりの厳格化

・プロジェクトの低稼働化


・プロジェクト規模の矮小化傾向
そりゃもう。フレームワークも高性能化してますし、そらそうなりますよ。
今まで10人に一名いればよかったリーダー。5人5人のチームに分けますと、もう一名リーダー格が必要となります。

・準委任契約まわりの厳格化
派遣と準委任の差がはっきりしてきました。
準委任の場合は、複数名で参画。その中でリーダーを立てる必要があります。今まで雑だった部分ですが、準委任メインの(いわゆるSES系)会社の場合、プロジェクトの数だけリーダー格が必要という事に・・・。

・プロジェクトの低稼働化
まー、9割9分『いいこと』なんですが。
リーダーが逃げたから俺がリーダーの代わりやったったわ。って話、昔はありふれてたんですが、最近は聞かないですね。なんか事故って経験できたわってケースも減ったんかなと。

もっとなんか根本的な理由とか潜んでいそうですが、今はまだ見えてきません。そのうち追記するかも。


※なお、ザクの場合は角が生えます。赤いと別の意味を持ちます。



5.リーダーの経験の積み方

基本的に不足しまくっているので『やりたい!』と、会社に言えばそれでほぼルート確定。と言う気もしますが・・・。上が詰まってる。スキル不足。商流上の問題。会社の構造上の問題などがあるかもなので、一応。(ぶっちゃけ、不要かもしれない項目)

・ほしいスキル感
少なくとも自分の作業見積もりはできるレベルである必要があります。必要な経験工程は参画するプロジェクトに寄るので、詳細設計~など、さまざまと言う感じになるかと思います。サブシステム単位で任される場合や受託でのリーダーとなると、そこそこまるっと理解している必要はありそうです。

・有利な状況
準委任参画チームにリーダーで入るのが手っ取り早い気がします。詳細以降の製造リーダーで、微妙な経験者やロースキルを抱えるようなケースが多いでしょうか。また、受託会社でリーダー不足と言う状況ですと、PMの負担を増やす以外に会社規模を大きくする術がありません。そういう場で『リーダーやってみたいっす』を言うのが手っ取り早そうです。

・注意点
未経験リーダーな時点で間違いなく大変は大変ですので、メンバーからの支援を期待できるように、初期段階でお願いしておいた方が良いかと思います。
特に、メンバーからスムーズに進捗状況が上がってこないと、各メンバーを回って進捗を吸い上げる必要が出てきます。(何やってるか把握できないと、フォローもできない。隠れ遅延で事故る。)進捗の報告は職業プログラマーの職務の一端ですので、キックオフミーティングでもやりつつ、そこで握っておくのが良かろうかと思います。

最悪な状況は、上位のリーダーと、自社のメンバーの間で板挟みになる事です。これだけは避ける様に立ち回りましょう。非協力的すぎるメンバーは素直な未経験者に劣ることもあります。コイツダメだなとと思ったら、自社・顧客と相談して入れ替えてもらうのも重要なミッションです。

上位のリーダー(又はPL/PM等)の背景や、プロジェクト全体の目的などをよく理解すると、自分やチームに求められている立ち回りと言うのも見えやすいかと思います。先回りで動けると『かなりできる奴』と言う扱いになりますし、信用や実績の上で大きなプラスを得やすいです。(と言うか、そのレベルでやってくれるリーダーってITではなかなかいないので、超目立つ。)



6.よいこと

そらもう。つよつよですよ。

サブシステム単位で任されて、開発の上でやるべきことや順序を正しく理解しており。(WBSが引ける)PMの背景を理解した上で進捗やリスクの報告ができ、自分以外のメンバーも含めて作業見積もりが出せて。進捗を確認できる構造を作れる。この人は強いです。

また仮に、スクラム等のプロジェクトであっても即座に対応できます。同様に自律判断できるメンバー達と互いの背景や事情を鑑みた上で協働できるかと思います。

ほか、冒頭でも少し書きましたが、将来のくいっぱぐれ回避の視点があります。
フレームワーク・自動生成ツール・パッケージ・オフショア等、メンバーレベルの作業の一部は、現時点でほかのものに代替可能です。(だからプロジェクト規模が小さくなってる)さらに、AIなどが本格的にプログラマの代替品として成長してくる可能性もあります。この辺りは技術の進化により昔から進行してきた話で、今後もこの傾向は続いていくでしょう。この将来のプログラマーの需要減、さらにシステムエンジニアの需要減が起きたケースに対して、リーダーのポジションの経験値は対抗できるものとなります。これはIT業界だけではない普遍のニーズです。



7.〆

なにぶん、私がSE職ではないので、今回の文章に関しては、過剰だったり不足だったりするところが多そうです。いろいろ社内外より指摘や質問を受けて、ブラッシュアップしていきたい内容と言う感じですかねー。

なーんかこう。ポジショントークちっくな文章になった気がする・・・。

BAMV合同会社's job postings
10 Likes
10 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more