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

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

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

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

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

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

30代までであれば、個のプログラマーでも十分に市場価値があります。その後は普通、市場価値は減衰します。（おまけに給料や単価も高くなる）営業はそういうのを毎日見ています。事実です。60歳70歳で仕事取れてる人もいますが、そういう人もいるってだけで、市場価値はふつう加齢で減ります。
そういう人を一人二人見たから、歳とったら仕事減るなんてのはウソだ！いう人もいますが、仕事Getできるオッサンもいるってことと、市場価値が減るって事は、ふつうに両立しますよね。彼らホントにプログラム書ける人なんですかね？心配です。

とは言え、まったく酷い業界です。若いうちは貴重な宝石のように扱っていたくせに、歳とったら手のひらを返してくる訳です。使い捨てって言う意見も、そりゃ出るだろうと思います。（異業界出身の営業とかみんな、まずこの実態を見て驚きます。人によってはIT業界が大キライになります。）

加齢による市場価値の減衰のメカニズムなどは、下記の記事で詳しく触れています。とりあえず本記事では本題の方の話を進める事とします。

【ＩＴ人材が不足というウソとSE35歳定年説の謎】
https://www.wantedly.com/companies/trash-briefing/post_articles/116545

そんなオッサンなのに、こなせる仕事が若手と同じものだったりすると、若手に競合負けしますよね。
なんか、経験のあるオッサン特有の強みを活かしたいところです。

そこでチームリーダーですが、これは【個のエンジニアとして勝負】ではなく、【チームとして成果を上げるところで戦う】と言う勝負になります。それなりの商流を持つ中堅層の開発会社や受託会社での売上や利益。若手育成機会の創出や、主要顧客への影響力拡大など、大きな成果となります。

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

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

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

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

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

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

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

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

※画像は悪い例です。

２.リーダーってなによ？

PLや、PMと言ったポジションの話はいったんさておきたく思います。会社やプロジェクトによって役割や責任・権限は様々ですし、あまり統一された言葉ではない様に感じます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

４.リーダー不足の要因

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

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

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

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

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

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

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

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

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

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

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

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

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

・自社社員のスキル感
超重要です。
大量のロースキルを引き連れて人身御供になるか。
能力が高く、よく知っているメンバー達とチーム組んで主体的に動くか。
これで決まります....。

大量のロースキルを抱えている会社は、経験者とセットで売りたいんです。ですので、リーダー欲しいって言います。2～3名の詳細設計者に対して、未経験一名などであれば、ある程度フォローしながら立ち上がるのを待つというのが可能です。極論、未経験の面倒をメンバーに任せて、リーダーはリーダー業務に専念する事も出来ます。リーダー1名に未経験２～３名とかの話は、ちょっと無理めのミッションです。ですが、儲かります。転職などの場合は、どちらのスタンスの会社か、よく判断する必要があります。

・有利な状況
準委任参画チームにリーダーで入るのが手っ取り早い気がします。詳細以降の製造リーダーで、微妙な経験者やロースキルを抱えるようなケースが多いでしょうか。また、受託会社でリーダー不足と言う状況ですと、PMの負担を増やす以外に会社規模を大きくする術がありません。そういう場で『リーダーやってみたいっす』を言うのが手っ取り早そうです。
受託じゃできないという話ではないです。しくじれないだけ。ポジションを完全に自社の自由で決定できますので、普段から自社に『リーダーやりたい』言うておけば、それだけで、しかるべき時にチャンスが来るでしょう。

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

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

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

6.会社の業態によるリーダー経験しやすさ

この記事を転職活動に活かそうって人も、そりゃいるだろうから、書いとくか。

・自社で主体的にチーム組む業態
である必要がまずありますな。
言うても、SIも受託もソフトウェアベンダも、サービス担いでる会社も、ふつうに考えてチーム組みます。と言うか、システム開発はチーム戦ですので、ふつうはチーム組みます。この辺は特に考えなくても大丈夫かと思います。サービス会社を偽装したSES会社だけ注意しましょう。嘘つく事に対する抵抗感とかも低そうですね。
さて、リーダー経験しやすさ。判断が難しいのは準委任常駐が主力の会社かなあ。

・リーダー経験できるのかどうか。
まず、SESと言う言葉はとても曖昧です。私はSESと言う言葉を『多重派遣の代替サービス』と定義しています。『単品派遣の需要に対して、多重派遣を回避するために準委任契約で契約、労働力を提供する』と言うサービスです。この場合、単品派遣が求められている訳ですから、そもそもチーム戦ではなく、リーダーの需要もあまりありません。エンドに見せる体制図にも載っちゃう訳で、適当な外注を投入と言うのは難しいです。（言うても実際にはリーダー飛んだから代わりほしいとか、他社のリーダーに自社の未経験くっつけて売りたいとか、案件自体はなくはない。）

というわけでまず、SES（多重派遣の代替サービス）の会社ではリーダー経験はしづらい。となります。

では、準委任でチーム戦主体の会社はどういう会社か。
先の項で少し触れましたが、SIerの商流では、再委託回数が制限されており、3次請けの社員までしかプロジェクトに参画出来ない。さらに、偽装請負の回避のため、プロジェクトに参加する各企業が、自社の指揮命令者を参画させなくてはいけない。と言う縛りがある事が多いです。この指揮命令者が、『リーダー』に当たります。

現場側の視点で考えますと、『参画するプロジェクトの数だけリーダーが必要』となりまして、とにかくやたらとリーダー役が必要になります。そんな無限にリーダーできる人間がいる訳もなく、経験なくてもやるしかないって事が発生しがちです。当然、元請け側にも事前に相談。初心者リーダーってことで気を使ってもらう前提でスタートしたりと、請負契約よりは低いハードルで初経験する事ができたりで、悪いことばかりではないようです。縛りのせいで発生する特殊事情の為、リーダー経験は意外としやすい。ほうと言えるでしょう。

・SESって言葉が迷彩になっちゃう
で、このチーム戦主体の企業なんですが、自社の事を『SES』だと思っていたりします。なんだそれってなりますよね。ここでのSESの定義は、私の言うものとは違います。『準委任契約』のことを『SES』と呼んでます。リモートワーク当たり前の時代ですから、常駐どころか自宅や自社側で開発してたりしますが、それでも準委任契約であれば、彼らにとっては『SES』です。　つまり、SESの定義が人によって違う為、SESかどうかで判断しようとすると、難しい。ってなってしまいます。

※余談ながら、このSESと言う言葉の定義が人によって違うので、TwitterとかでSES論争するんだわ。『SES』＝『悪質なロースキル派遣会社』て考えてる人からすれば、『SESはスキルつかない』は、実際成り立つわけですが。ただ『準委任契約』の事だと思ってる人は、『準委任＝スキルつかない？何言ってんだコイツ』って反応になる訳で....。
『準委任』って言葉があるんだから、いい加減『SES』って言葉使うのやめたらいいのに。定義があいまいな言葉使って認識齟齬るとか、エンジニア的にはイケてないムーブだと思うんですけどね。

・チーム戦か、個人戦か。
というわけで、そもそもこの辺を自覚していない人がこの業界には多いです。
チーム戦と個人戦、得意なことも苦手なことも違えば、そもそも勝利条件から違います。勝利条件が違うので、戦略も戦術も違います。採用ターゲットも違います。これもう、別のビジネスです。別のビジネスゆえに、お互いの事をよくわかっていません。
ですので、派遣的なSESさんも、『チームで仕事する』って言ってたりします。（未経験とセット売りしたいので。もありうる）『受託取りてえ』言ってたりします。チーム戦の開発会社も、自社のビジネスを『SES』って言ってたりします。『請負はやらない』って言ってたりもします。（ハードルや利益のイメージを具体的に持ってる為）もう、この辺の話を真に受けてもダメです。ITはホームページの内容も信用できないですしね。

・見分けやすいポイント
というわけで、ビジネスモデルの特徴から読み取る考えで行きましょう。

１．案件数が馬鹿みたいに多い。
個人戦のSESの特徴です。SES市場では、たくさんの単品派遣需要のメールや、派遣したい人材のメールが飛び交っています。この単品派遣需要のメール（案件情報）を、自社の案件情報としてカウントすれば、それは常時ウン千件と言う数になる訳です。嘘をついている訳ではないです。
では、他の会社はどのようなものを案件情報としてカウントするかと考えますと、自社サービスでは、そのサービスの開発案件。受託では、実際に受注する受託案件。チーム戦のSESでは、自社のチームが参画済の案件の増員枠（わざわざ知らん会社にバラで自社の社員出したりしない）とかになる訳でして、ウン千件とかの数には、絶対になり得ません。20000人とか社員いるなら別ですけど。

2.自由度が高い
個人戦のＳＥＳの特徴。強みに当たる部分です。
チーム戦型もカスみたいな会社は当然あって、自由度低く、リターンが無い。みたいな感じだったりします。この手の会社に対してのカウンターとして、この自由度はアピールされやすい項目です。

特定の取引先を重視せず、毎回平場営業で勝負。と言うのが、4次請け以降がメインのSES会社の戦い方になります。加えて、商流を上げていくつもりも無しとなれば、特定の取引先に媚びる必要がありません。バラ売りですし、会社全体としても優先する案件や技術の種類を固定しなくてよくなります。
そうなると、各エンジニア個人の要望に沿った案件選択と言うのがとてもやりやすくなります。（その案件を取れるだけの市場価値をエンジニアが持ってる必要はある）

また、取引先を固定しないのであれば、やり切って評価を得る必要も無いです。
『嫌なら撤退調整』『単価上がんないから撤退調整』など、主張しやすくなります。求人などで受注した契約に対して、責任取る気ねぇなーって角度の、『エンジニア守りますトーク』が乱発されてたら、つまりはそういう事です。

※実際、商流深いと変なのが間に挟まりがちである為、このくらいの勢いで撤退調整とかしていかないと、エンジニアがつぶれたりします。
『やる・やらない』のラインを決めて、営業も力を入れて、成果を出しつつ。ちゃんとした固定的な商流・取引先を確保するのが根本的な解決策だったりしますが、そのルートはスパッと切って、自由度の確保を重視する。と言う戦略ですね。

3.単価連動型
単価連動型も、個人戦特有の仕組みです。チーム戦でできなくはないですが、少なくとも相性は良くないので、あえてやる会社は少ないんじゃないかなぁ。

元請→2次→3次のあたりの単価の決まり方ですが、5人チームで500万とか400万とか、グロスになってることが多いです。

これですとリーダーも新卒も一律80万とかになったりする訳ですが、この80万の新卒。新卒の生産性が80万あるという話では無くて、全体で400万のなか、100万クラスを3人入れたので利益が足りなくなる。1名新卒を入れて利益の帳尻を合わせようとか、そういう理由です。（会社間でそういう話をする）

ここでの功労者は、『400万+新卒投入可能枠』を獲得したリーダーや主力メンバー陣となるかと思いますが、単価連動ですと評価される部分は『80万』。しかも、仕事を用意してもらってフォローまで受ける新卒君の評価も『80万』と、上の人間ほど、周りに貢献する人間ほど、損をする構造になってしまいます。

6.リーダー経験をするメリット

そらもう。『つよつよ判定』ですよ。

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

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

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