IT業界では「リーダー経験」がとにかくよく求められます。
求人票にも、キャリア相談でも、転職市場でも、よく聞く言葉ですよね。

しかし、多くの方はこう思っているのではないでしょうか。

「怖い」「まずは技術力をつけてから…」「コスパよいとは思えない。」
その考えが悪いとかはありません。自身のキャリアイメージに関して、他人から文句言われる筋合いはないですね。

ただし問題は、メンバーのままでいることは“安全なポジション”ではなくなってきていることです。

特にここ数年、AIエージェントを使った開発が急速に広がり始めています。コード生成、テスト作成、ドキュメント生成など、これまでエンジニアが行っていた作業の一部は、すでにAIが担えるようになってきました。では、こうした変化の中で、IT業界はどのように人材を評価するのでしょうか。

その答えが、今回のネタ。**「リーダー経験が重視される理由」**の中にあります。

この記事では、

• なぜIT業界でリーダー経験が重視されるのか
• どんなリーダー経験が市場価値につながるのか
• そして、これからの時代にエンジニアが取るべき立ち位置

について、IT業界の構造も含めて整理してみたいと思います。

リーダー経験が重視される理由

それは、IT業界が「責任範囲＝利益」になる構造だからです。

IT業界は「人月ビジネス」で動いている

まず前提として、日本のSI業界では **「人月（にんげつ）」** という考え方で仕事が見積もられます。

1人のエンジニアが1か月働く量を 1人月 とし、プロジェクトの規模は「何人月か」で表現されます。
例えば　【5人 × 6か月＝ 30人月】という形です。

この仕組みについては、こちらの記事でも解説しましたので、詳しくは飛ばします。

参考：
【「エンジニア不足」はウソ】: 実は供給過多であるために未経験・高齢エンジニアは冷遇され続ける。これが発生する構造。

※人月ビジネス構造とは何か（だいたいこんなの）の項（ctrl+F で検索するとヨロシ）

要は日本のIT業界は、【頭数を集めたら儲かる】構造な訳ですね。（雇うでも借りてくるでも良い）
例えば、一人の優秀なメンバーは、人月『１』です。　2名のメンバーを抱えたPGリーダーは、人月『3』に関与します。　
（ここでいうPGリーダーは、詳細設計以降のPGチームを指揮する、経験3年くらいのエンジニアがやってたりするポジションのこと）

加えて、PGリーダーは、初級PGの仕事を生み出すことができます。

基本設計が終わったレベルの実装タスクが、PGリーダーにまとめて渡されるとします。

PGリーダーはそれを分解し、
・難易度が高い部分は自分や経験者が担当
・難易度の低い部分は初級PGに割り当てる
という形でタスクを再構成します。

これで、初級PGが戦力として機能する人月枠を自チーム内に『１』、作ることができます。

この場合、PGリーダーは、人月『3』に関与するだけではありません。自分の人月『1』に加え、未経験者でも担当できる人月『1』を生み出す働きをしています。
一人の優秀なメンバーの人月『１』と比較して、この経験3年のPGリーダーの方が利益を生む。初級PGのエンジニア人生の為にも有益な動きをしている。という事になります。
つまりIT業界では「優秀な人」より「人を動かせる人」の方が価値を持ちやすい構造になっています。

責任範囲が広いほど、扱う人月が増える

上記では経験3年くらいのPGリーダーを例に挙げましたが、責任範囲によって関与する人月数も変われば、生み出せる可能性のある人月数も変わります。下記の図はよくあるSIプロジェクトの体制ですが、元請・2次請・3次請。それぞれのリーダーが責任を負う範囲は変わりますよね。

大きな範囲の責任を負った経験。それを遂行できる能力は、当然ながら高い価値となる訳です。

だからリーダー経験が評価される

IT業界でリーダーとは、単純に「人をまとめる人」という文脈でのみ扱われません。

より大きな責任範囲を担当する人　です。

そのため転職市場でも、

• 設計経験
• チームリード経験
• プロジェクト管理経験

といった要素が評価されることになります。

ここまでが、現在の日本のIT業界のビジネス構造の中での『リーダー』の価値です。
そしてこの構造は、AI時代になるとさらに重要になります。

AIエージェント時代に危ないポジション

ここまで、IT業界では責任範囲が広いほど価値が高いという構造を説明しました。そしてこの構造は、AI時代になるとさらに重要になります。

AIの話になると、「エンジニアの仕事がなくなる」といった極端な議論がよく出てきます。

しかし実際には、AIが置き換える仕事にはかなり偏りがあります。

AIが得意な仕事

現在のAIエージェントは、主に

• コード生成
• テストコード生成
• ドキュメント作成
• バグ調査
• 実装補助

といった作業を得意としています。

これらはすべて、メンバー層が担当することが多い仕事　です。

AIが苦手な仕事

一方でAIが苦手なのは、

• 設計方針の決定
• 顧客との調整
• 要件整理
• プロジェクト判断
• 最終責任

といった仕事です。

これらはすべてリーダー・マネジメント層が担当する仕事 です。

AIが代替するのは「作業人月」

ここで人月ビジネスの話を思い出してください。

IT業界では

• メンバー → 作業人月
• リーダー → 設計・管理人月

という構造になっています。

AIが代替しやすいのは、作業人月の部分です。

つまり、AIが最も影響を与えるのはメンバー層の仕事です。

だからメンバーのままだと危ない

AIが普及すると作業の生産性は大きく上がります。これはIT業界全体にとっては良いことですが、同時に次の変化も起こります。

必要なメンバーの人数が減る

という変化です。

一方で、

• 設計
• 判断
• 責任

といった役割はむしろ重要になります。

つまりAI時代では、リーダーの価値は下がらない。　　一方で、メンバーの価値は相対的に下がりやすい　構造になります。

ただし、ここで注意が必要です。
世間で飛びかう「リーダー経験」というワード。　すべてが同じ価値を持つわけではありません。

意味のないリーダー経験

SES等でよく発生しがちな状態。（SESが悪いて話ではない）例えば、下記のSESチーム(赤)のリーダー役などは、実務上、ほとんど意味が無い状態と言えます。

この図では上位会社のPL役(青)がSESチームの各メンバーへタスクを振っており、PL役が依頼の分解、タスクとして割り振り、タスクの進捗管理をしている構造になります。

責任はPL役側に発生しており、SESチームのリーダー役は、他のメンバーのタスクの内容や進捗を把握できず（つまりフォローすることが難しく）、ロースキルPG向けの作業を生み出すこともできません。実質関与している人月は自身の『1』　このような場合のSESチームのリーダー役の役割は、勤務表の回収係というところになるでしょうか。

このような状態はリーダー役の能力や受注者側の意向に依らず、発注者側のスタンスによっても発生します。例えば、

• サボらんように直接タスクを振りたい
• できる外注は可能な限り自身でタスク振りたい
• 外注と自社社員の区別があいまい

などの意向を発注側が持っていた場合、この派遣契約のような状態が望まれたりします。※注①

また、近年のSES会社は『自由度が高い(いつでも現場抜けられるよ)』『責任を負わないのが準委任契約の利点だよ ※注②』などと言うトークで採用活動を頑張る会社も多い印象です。これらは自身から責任を放棄するスタンスを売りにしている訳ですし、それを魅力的に感じるエンジニアの在籍率が高いという事にもなるでしょう。近年のSES会社が未経験者のアサインに難儀する原因の一つにもなっていそうです。

※注①
準委任契約では、受託者の裁量で業務を遂行することが前提であり、発注者による直接的な指揮命令は原則NGです。偽装請負という違法状態に該当する可能性があります。
（それもあって、大手企業はこのような体制で発注すること自体を好まない傾向があります。）

※注②
準委任契約は契約書への記載有無に関わらず、善管注意義務という責任を負いますので、『責任が無い』というのはかなーり間違いです。

このように、世で言われる『リーダー』という肩書すべてに実務上の価値がある訳ではありません。経歴書上は全く同じ『リーダー』ですので、錯覚資産として給与を吊り上げる効果は期待できますが、それを行うと実務上のリーダーの経験が無いまま、リーダー経験者として、リーダーの給与で、リーダー未経験者が入社する。という、普通に考えて極めて危険な状態が爆誕します。

悪意で狙うならばともかく、『なんちゃってリーダー』の経験を根拠に『ぼくはリーダー経験ある』と感違いで高望みのムーブをしてしまう事は、避けましょう。

では、実務的な価値を持つリーダー経験は、どこで積めるのでしょうか。

商流の影響

単純に考えたら、商流の影響が無いわけがないですね。
階層ごとに役割が異なりますので、階層ごと、役割に責任を負う立場というのが発生します。責任を負う訳ですので、基本的には役割を請け負った会社の社員がリーダー・マネージャー役を担当することになります。

ここで要求されるのはスキルの高低ではなく、『責任の所在』なワケですから、若手であっても上位階層の社員が担当するという事はよくあります。
平等・不公平の問題ではなく、単純にビジネス上の責任の所在がどこにあるかの問題です。

つまり、実務的な価値を持つリーダー経験を積みたいのであれば、どの商流で仕事をしているのかという点も、無視できない要素になります。

例外

ベンダーと直接契約しているフリーランスが、ベンダーのリーダー役を代行すると言う事はけっこうあります。
ですので『SESでもリーダーできるだろ』という問いへの答えは、Yesとなります。

よくあるパターンは決まっており、『リーダー的な業務をかつて経験している』『発注側のベンダーとの信頼関係がある』という条件付けが入ってきますので、『SESでもリーダー経験をしやすいか？』という問いになりますと、答えは、Noとなります。

特に、フリーランス/SESの場合は、責任を負わないことが利点として挙げられる業態となりますので、責任を負う種類の経験獲得においては、基本的に不利になりますね。

ではどうすればいいのか/まとめ

リーダーになるルート。リーダー回避するルート。

リーダーになる論

1. 小さくてもリーダー経験を作る
2. ビジネスの構造を理解する
3. 商流もキャリア要素として見る

小さくてもリーダー経験を作る

当記事で紹介した、PGリーダーあたりからがとっつきやすいです。要求スキルレベルは、基本設計を分解して詳細レベルのタスクに落とせる。レビューできる。くらいですから、中級者に入りかけの若手でも挑戦可能。経験3年前後～。

加えて、商流的な影響も受けづらい。
３次請はPG工程が多いですし、経験を見られるSESだって参画しやすい。同僚のPGと協力してロースキルの枠を作るってのは、業態選ばずほとんどの会社で喜ばれるムーブではないでしょうか。なお、作る枠は、経験者PG２名に対してロースキル1名くらいで考えるとよいと思います。それ以上ですと、かなり厳しくなるかな。

上流のベンダーのビジネス構造は、このようなチームの工程・商流を上げ、規模を拡大。していったものになります。PGリーダーでも十分、一歩目なのです。
もちろん、上昇・拡大した先では新たな問題が待ち受けますが、『リーダー経験のある若き中級者』であれば、上流のベンダーから見ても投資価値のある存在という判断になり、採用もされやすくなります。

ビジネスの構造を理解する

カネも責任も、その辺から勝手に生えてきません。上位階層から流れてくるものになりますかね。
誰がどんな事情で、どういう動機があるからそうするのか。　これが分かってくると先回りができます。提案もしやすくなります。クライアントの考えてる事やお悩みポイントが分かる訳ですね。それを解消してやることで評価と信用を得る事ができます。　

また、自社側の譲れないラインなどもわかる様になります。対外的にその事情を説明し、利害の調整ができます。
利害の調整のしようがない相手であれば、『引く』という選択肢を検討できるようになります。（損得のラインが見えないと、引くという判断もできない）
さらに先の動きとしては、クライアントとの利害がWinWinになるポイントを把握し、『その様にやろう』と提案できるようになります。

難しいように見えますが、これもいきなりできる必要はありません。最初はまず、『知ろうとする』ことからで十分です。
逆に、常に責任範囲を限定し、『知ろうとしない』ムーブの果ては、さほど芳しいものではないことが多いです。　ITに限らない話ですが。

商流もキャリア要素として見る

これ、２０年くらい前は当たり前でした。当時は業界内の様々なベンダーや、事業会社。それらの取り組みなどの情報が、割と簡単にネットで見れた様な印象がありますね。自身の性格や専門性のタイプから、『気になる会社』みたいなのを持ってたりするもんだったのですが。

近年これがなくなったというのは、やはり人材系の広告の影響が強いのかな。そういう情報を目にしづらくなった。
わかりやすい例を挙げれば、２０年前は企業のテックブログなどが有効でしたが、現代ではほぼ読まれない。興味が無いというよりも、ネット上を流通しづらくなりました。

ともあれ、それで下層に固定というのもまずい訳でして、上層の会社のことも意識的に知る様にしていく方がよいでしょうな。ビジネス構造が違えば、そこで求められる立ち回り、リーダーとしてのタイプ、テクニカルスキルの種類など、異なるという事になりますので、知らないことには努力のしようもありません。

転職不要の方法論として、下層の自社のビジネスにコミットし、商流を上げていくと言うアプローチもあります。
これでもビジネス構造理解のほか、自社ビジネスへのコミットメントいう、転職による個人昇格ルートとは別の市場価値が得られますので、全くダメとかではありません。『やるだけやった』という事実は、それだけ価値があるものとして世間から評価されます。

なお、全方位戦略でやたらめったら資格とるとかは、投入コスト(労力)あたりの効果としては、ほとんど意味は無いかもですね。

リーダー回避して生き延びてやる論

1. チームや全体の生産性に資する知見を得る
2. フォロワーシップを発揮する
3. 本業プラスワンで、強みを用意する。

チームや全体の生産性に資する知見を得る

開発の方向性や方式を提案・推進したり、コードの品質の担保であるとか、技術でチームや全体と言った範囲にバフをまく役割。
５人チームの生産性を0.2ずつ上昇させたら、１名分追加と同じ働きですね。

人月上のプラスはありませんので売上への直接貢献とはなりませんが、請負契約が主体であるとか、SIのように大規模であるとかすると、需要が高い人材という事になります。ひょっとしたら意外に思われる方もいるかもしれませんが、SIerなどの大手企業にはだいたいこの手の人たちがいます。

利点は、『SESでも経験しやすい』

SESで大規模プロジェクトの最初期に参画することはほぼ不可能ですが、それ以外のケースであれば、だいたいチャンスはあるのではないでしょうか。ビジネス構造が影響するリーダー経験の取得に比べますと、商流の影響が小さいはずです。

やるこた、勉強する。PJ内で信用される。提案する。ですかね。　できる奴は勝手にやります。できない人はだいたい１歩目からやりません。

SES側での難点は、『売上への影響がほぼない』ことに尽きると思います。
もちろん、経歴書上で見分けつくレベルの差ですので、個人の単価への影響は大きなものです。しかし、あくまで個人レベル。上限もSES企業として決めうる金額あたりが現実的上限となってきます。これでは給与も上がりづらい。このため、最終的にフリーランスの道を歩む人が多い印象でした。最近はこの手のSESの人に平場で出会う事がなくなったので、わかんないす。

フォロワーシップを発揮する

『リーダーはどうしても無理なんだ。』『スーパーな知見もない』という方向けの、現実的なアプローチ案ですかね。

主体性の低いメンバーを抱えると、リーダーはめちゃしんどいです。『言われたことしかしない』という責任範囲限定ムーブは、リーダーの視点になりますと、『何から何まで指示してやらないと動かない。油断するとすぐアイドリングする』というものになります。　報告すら怠って、サボろうとするのもいます。　監視が必要になります。

全メンバーのタスクを把握し、管理し、指示。かつ監視も怠らない。　これは単純に工数を食います。その上でリーダー本来の業務も行う訳ですので、リーダーは忙しくなりがちです。
実際に、『エンジニアファースト』を強く掲げた会社のリーダーほど、潰れがちです。これには会社の大小もあまり影響ありません。

フォロワーシップとは、これと真逆。　
チームや組織の成果を最大化するために、主体的かつ自律的にリーダーやメンバーを支援し、建設的な影響を与える能力のことを指し、本来はチーム全員に求められるものです。ですが、ＩＴ業界はあまりこのあたりのレベルが高くありません。というか低いです。　ですので、フォロワーシップを持っているメンバーはそれだけで優秀勢側に入ります。

若手としては、リーダーのフォローを行う中で様々なコンテキストを学んでいく機会を得ます。次期リーダーへの最短ルートでしょう。これは１年目からできる事です。

オジサンとしては.....、非常に効果的な役割が一つあります。

〇先任伍長ムーブ

そうはいってもオジサン。
他の一般的な若手メンバーと比べて、プロジェクトの経験、技術への造詣など、段違いなはずです。
チーム内ではメンバーから頼りにされますし、参考にされる立ち位置になります。　それでありながら、おじさんは『メンバー』　他のメンバーとは明確な指揮命令関係にはないことになります。　この立ち位置が、絶妙に組織に役立つ立ち回りを可能にします。

経験が浅いリーダーや、年齢が若いリーダーは、それだけで苦労はするものです。摩擦を恐れ、命令をすることに対しても、躊躇する事かと思います。先任伍長ムーブのおじさんは、メンバーの立場ですので、【命令という形を避けつつも、他のメンバーに対しての規範を示す】という事をやりやすく、リーダーを効果的に支援できます。　

例えば、TVでよく出てくるステレオタイプなZ世代的なワガママムーブの若手メンバーがいたとします。サボる目的でやたらと労働者を主張してくるとします。報告を怠るとします。やらかしたうえで他責全開で『リーダーが悪い』と主張するとします。『弱い労働者の立場』を盾に、指揮命令者であるリーダーの言動を封じようというライフハックな訳ですが。

このようなシチュエーションで、メンバーでありながらも経験豊富なエンジニアがリーダー側につき、『うるせえ。やれ。あたりまえだろ。』と当たり前の価値観を置きなおしてくれるのは、リーダー側は非常に助かります。

チームのリード面においても、経験豊富なオジサンの提案や助言は有効です。　『これを放置したらこの結末に至る。』オジサンはこのようなパターンを無数に知っています。対処することの優先順位の高さを知っています。それらを活かした立ち回りでもあります。

〇注意点

オジサンの視座が低く、全体最適を欠いた個別最適的な主張を繰り広げるとなりますと、オジサンは一気に老害と化します。
いい歳こいてエンジニアファースト的な思想にお目覚めにでもなられ、リーダーやクライアントに戦いを挑みだした日には、もはやモンスター登場と言っても差し支えないでしょう。

一応、反面教師的な効果は発揮でき、おじさんの痛い姿を見た若手は健康的な成長を志す様になりますから、プラスはゼロではないのですけれど、まあ、普通はいらない子になっちゃいますよね。若手に反面教師的に見られることを望む人も、そんなにいないでしょう。

第一線を避けて先任伍長ムーブに落ち着くとしても、『ビジネスの構造を理解する』という要件に関しては変わらず重要ですので、お気をつけて。