「何でも屋」になるべきか、分担を守るべきか——会社規模で変わるAI時代の役割設計

• 想定読者： 自分の守備範囲をどこまで広げるか迷っているエンジニア、チーム編成を考えるテックリード／EM、AI時代の組織設計を検討する経営・人事
• 前提知識： ソフトウェア開発チームにおける役割分担（フロント／バック／インフラ／QA など）の基本的な感覚
• 所要時間： 約28分

概要

「これからのエンジニアは何でも屋にならないと生き残れない」——AI時代のキャリア論で、この言説は強い説得力を持って語られる。AIが実装コストを下げ、一人でこなせる範囲が広がったからだ。一方で「いや、分担を守ったほうが品質も安全も保てる」という反論もある。だが、どちらも会社規模という最大の変数を無視している。

結論を先に言う。AI時代に役割分担はなくならない。役割の”顔ぶれ”が入れ替わる。「ITエンジニア＝実装する人」という事実上ひとつだった役割が、AIが実装を引き受けることで6つ——プロダクト／FDE型・実装指揮・技術領域検証・エージェント基盤・ガバナンス・データ／ML——へ分化する。そしてこの6つの顔ぶれは規模を問わず共通で、変わるのは”何人で分けるか”だけだ。スタートアップは1人が全部かぶる（実質「分担なし」）、大企業は1役割＝1専任に分かれる。

土台にあるのは、DORAが2025年の調査でまとめた「AIはすでにそこにあるものを増幅する」という事実だ¹。だから幅を広げるほど、AI出力を見抜く深い軸＝検証力が要る。各役割の重心は「コードを書く」から「AIに書かせ、見極め、束ね、統制する」へ移る。従来のフロント／バック／インフラやPdM・SEといった役割も消えず、多くが「実装担当」から「検証・統制役」へ横滑りする。

長期（2028年以降）には、AIエージェントの自律化でチームは小型化し、人間は実装から「オーケストレーション」へ上流化する。Gartnerは2030年までに80%の組織が大型エンジニアリングチームを小型のAI拡張チームへ進化させると予測する²。

本記事は、この6つの役割と「今の役割からの移行マップ」を示し、それを規模別にどう配るか、中央チームに固めるか各チームに埋め込むか、スキルと評価がどう変わるかを順に整理する。最後に、混同されがちな「AIを束ねるオーケストレーション（対AI）」と「人を束ねる対人マネジメント（対人）」を切り分ける——前者はほぼ全員に有用なスキルだが、後者は志向する人が選ぶ専門トラックで、「AI時代だから全員が管理職を目指すべき」という連想は成立しない。

なぜ「何でも屋 vs 分担」は噛み合わないのか

AI時代のキャリア論には、対立する二つの神話がある。

• 多能工神話: 「AIで一人の生産性が跳ね上がった。これからは一人でフロントもバックもインフラもこなす何でも屋が勝つ」
• 分担死守神話: 「いや、AI生成コードは品質が不安定だ。専門分化を守り、各領域のプロがレビューする体制こそ安全だ」

どちらも一理ある。だが両方とも、最も効く変数である「会社規模」を議論から落としている。3人のスタートアップと、エンジニア1000人の大企業とでは、最適な役割設計はまるで違う。同じ処方箋を当てれば、片方では生存戦略になり、もう片方では事故になる。

「何でも屋」という言葉が二つの意味を抱えている

議論が噛み合わない原因の一つは、「何でも屋」という言葉が二つの異なる状態を指していることだ。

1. T型／π型: 一つ（または二つ）の深い専門の軸を持ちつつ、AIを使って隣接領域へ幅を広げた状態。軸がある。
2. 軸なしフルスタック: どの領域も浅く、全部を「そこそこ」こなす状態。いわゆる器用貧乏。軸がない。

研究や成功事例が支持するのは前者であって、後者ではない（この区別は別記事「I型・T型・π型——深さと幅のスキルマトリクス」で詳述した）。AI時代に「何でも屋になれ」という助言が危ういのは、しばしばこの二つを混同し、「軸を持たずに広く浅く」を奨励してしまうからだ。本記事で「多能工」「幅を広げる」と言うときは、つねに深い軸を前提とした T／π型を指す。

会社規模とチーム規模を分ける

規模の定義も先に整理しておく。本記事では二つの規模を区別する。

• 会社規模（従業員数）: 採用余力・ガバナンス要件・組織階層に効く。便宜上、スタートアップ＝数十人未満、中堅＝数十〜数百人、大企業＝1000人以上を目安とする。
• チーム規模（開発組織の人数）: チーム構造の型に効く。後述する flat / functional / matrix の3モデルはこちらの軸だ。

両者は相関するが同一ではない。SaaSスタートアップとSIer大企業のように業態が違えば、同じ従業員数でも開発組織の形は変わる。

大前提：AIは「すでにあるもの」を増幅する

規模別の話に入る前に、全規模に共通する土台を一つ。Googleの DORA が2025年に約5,000人の開発者を対象に行った調査は、AIの効果を一言でこう要約した——「AI amplifies what’s already there（AIはすでにそこにあるものを増幅する）」¹。強いチームはAIでさらに伸び、弱いチームは問題がさらに悪化する。

これは個人にも当てはまる。深い軸を持つ人がAIで幅を広げれば、検証眼が効いて成果が増幅される。軸のない人がAIで手を広げれば、誤りを見抜けないまま破綻が増幅される。Stack Overflowの2025年調査でも、84%が AI を使う／使う予定である一方、46%が出力の正確性を信頼しておらず、66%が「ほぼ正しいが完全ではない」出力の修正に追加時間を費やしていた³。AIは検証コストを肩代わりしてくれない。だから「幅を広げる」話は、つねに「軸という検証基盤」とセットでなければならない。

「実装する人」が6つの役割に分化する

ここから本題に入る。AI時代の役割分担は、なくなるのではなく顔ぶれが入れ替わる。「ITエンジニア＝実装する人」という事実上ひとつだった役割が、AIが実装を引き受けることで、次の6つへ分化していく。各種の業界提言（ITmedia の4ロール⁴、McKinsey の agentic organization⁵、Gartner のガバナンス専任²、Palantir 系の FDE⁶）を、実際のチームに置ける形へ整理すると、こうなる。

1. プロダクト／FDE型エンジニア — 顧客の課題に張り付き、AIで機能をエンドツーエンドに実装する。「要望→実装→価値」を一人で通す。従来のアプリ開発者に、PdM／SE が担っていた翻訳の一部が溶け込んだ姿だ⁶。
2. 実装指揮（テックリード型） — 自分で書くより、AIに何を書かせ、出力をどう検証するかを設計・指揮する。アーキテクチャとコード品質の番人⁴。
3. 技術領域スペシャリスト（検証役） — フロント／バック／インフラ／データ／セキュリティといった技術領域ごとに、AI生成物の落とし穴を見抜く。旧来のレイヤー専門家が「書く人」から「検証・統制する人」へ進化した姿だ⁷。（要件・仕様などの”業務ドメイン”は 1 のプロダクト／FDE型が担う。ここでの”領域”は技術スタックを指す）
4. AIエージェント基盤エンジニア（Platform／SRE型） — エージェントが安全に動く実行基盤・権限設計・ガードレールを用意する。
5. AIガバナンス専任 — AI利用の統制・監査・コンプライアンス・セキュリティ方針を担う²。
6. データ／MLスペシャリスト — モデル選定・評価・改良。AIがプロダクトの本質に関わる場合に立つ⁴。

この6つに加えて、オーケストレーション（複数エージェントにタスクを分け、非同期で上がる成果を束ねる）は、特定の役割ではなく全員の共通スキルになる⁵⁸。

整理を一つ。これらは「対AI」と「対人」で性質が分かれる。実装指揮・基盤・ガバナンス・オーケストレーションは基本的に対AIのスキルで、ほぼ全員に有用な方向だ。FDE は対AI（実装）に加えて顧客との対人の比重が高い。一方、人とエージェントの混成チームを率いる管理職（McKinsey の言う hybrid manager）は人を束ねる対人の専門性で、これは後述の通り志向する人が選ぶ別トラックとして切り分けたい。FDE の役割境界の再編は別記事「PdM 不要論と FDE 躍進」で詳述した。

今の役割はどこへ移るのか

では、いまの——AIとは関係ない——役割は、この6つのどこへ移るのか。主な移り先を対応づけると、こうなる。

従来の役割（AI以前）	主な移り先	変化の要点
フロントエンド開発	技術領域検証（フロント）	実装はAIへ。UX・体感品質の検証役に
バックエンド開発	技術領域検証（バック）	データ整合性・境界設計の検証役に
インフラ／SRE	AIエージェント基盤 ＋ 技術領域検証（インフラ）	エージェント実行基盤の番人として比重↑
QA／テスト	検証スキルの全員分散 ＋ 検証の設計・自動化	「最後に検証する人」から「検証を仕組み化する人」へ
データエンジニア	データ／MLスペシャリスト	モデル選定・評価が中心に
PdM	プロダクト／FDE型に一部吸収（戦略部分は残る）	中間翻訳層がAI補助エンジニアに溶ける
SE／ブリッジ（要件・顧客折衝）	プロダクト／FDE型	要望→実装→価値を自分で通す
テックリード	実装指揮	「書く設計」から「AIに書かせ検証する設計」へ
セキュリティ	AIガバナンス専任 ＋ 技術領域検証（セキュリティ）	AI生成コード・エージェント権限の統制が加わる

ポイントは2つ。第一に、多くの役割が「実装する人」から「検証・統制する人」へ横滑りする——消えるのではなく、AIに実装を渡して一段上流へ移る¹⁷。第二に、インフラ／SRE は移り先がむしろ増える。AIエージェントが自律的にコードを書き、やがて本番に触れる時代には、エージェントが安全に動く実行基盤・権限設計・ガードレールを用意する役割（Platform Engineering／SRE 的な仕事）が組織のAI活用の前提になるからだ。実装の自動化が進むほど、その実装が走る基盤を統制する仕事の価値は上がる——これは現時点の見立てだが、方向としては自然だ。

規模が「分け方」を決める

役割の顔ぶれは共通でも、それを何人で、どう分けるかは会社規模で変わる。役割分担は目的ではなく、人数と複雑性が一定を超えたときに要る手段だ——小さいうちは分けないほうが速く、大きくなるほど、分けないと統制が壊れる。

まず短期：全規模で「幅」、でも圧力の質が違う

AIによる生産性向上で、一人がカバーできる範囲は確実に広がる。ここは全規模共通だ。だが「何でも屋圧力」の出方は規模でまったく違う。

スタートアップでは、そもそも分業するほどの人数がいない。AIで守備範囲が広がることは、ほぼ即座に「一人で複数領域を持つ」現実に転化する。これは圧力というより生存のための合理的選択だ。

大企業では別の経路で同じことが起きる。AIによる業務代替で採用が絞られ、場合によっては人員が減る。マイナビが2025年12月に採用担当者2,101人を対象に行った調査（HRzine が報じた）では、「AIの業務代替によって既に人員削減の影響が出ている」が全体12.3%、従業員1000人以上では16.2%と、規模が大きいほど影響が大きかった⁹。若手の入口はさらに狭い。スタンフォード大学の研究「Canaries in the Coal Mine」（2025年11月版）は、ADPの給与データから、AIに最も晒された職種で22〜25歳の雇用が約16%相対的に減少したことを示した（年長層・低エクスポージャー職種との比較、企業要因を制御後）¹⁰。採用が絞られれば、残った人の守備範囲は自動的に広がる。大企業の「何でも屋圧力」は、号令ではなく頭数の制約として現れる。

採用要件も変わり始めた。Findy が2025年3月に公表した調査（回答企業188社、プラットフォーム利用企業の自己選択サンプルである点に注意）では、98.4%がAIを活用し、約7割が今後の採用要件の変化を見込んでいた¹¹。ただし共通の落とし穴がある。短期の圧力は「広さ」を求めるが、広さだけを追って軸を失えばAI出力を検証できなくなる。求められるのは「軸を保ったまま幅を足す」T／π型化であって、「軸を捨てて広く浅く」ではない。

チームの形：flat / functional / matrix

チーム構造そのものも規模で変わる。コンサルティング企業 8allocate は2026年のチーム構造を、規模に応じた3モデルで整理している（ベンダーによる枠組みであり、データではなく整理として参照する）¹²。

flowchart TB
    subgraph S["スタートアップ / Flat（3〜10人）"]
        direction TB
        S1["多能工チーム<br>領域の壁が薄い"]
        S2["速度優先<br>ガバナンスは軽量"]
    end
    subgraph M["中堅 / Functional（10〜50人）"]
        direction TB
        M1["機能別の分担<br>+ AI活用ロール導入"]
        M2["品質と速度の<br>バランス設計"]
    end
    subgraph L["大企業 / Matrix（50人以上）"]
        direction TB
        L1["小型AIポッドの集合体"]
        L2["明確な役割境界<br>ガバナンス重視"]
    end
    S --> M --> L

フラット（スタートアップ）は領域の壁を薄くして速度を取る。機能型（中堅）は機能別分担が戻り、そこへAI時代の新しい役割を接ぎ木する。マトリックス（大企業）は、全体をフラットにせず、明確な役割境界を持つ小型のAIポッドに分割し、ポッド間をガバナンスで束ねる。

6つの役割を、規模別にどう配るか

同じ6役割が、規模ごとに次のように配分される。

役割	スタートアップ（〜10人）	中堅（10〜50人）	大企業（50人〜）
プロダクト／FDE型	全員がこれ	一部が担う	専任機能として分離
実装指揮（テックリード）	兼任	全エンジニアが持つ	専任のリード
技術領域スペシャリスト（検証役）	1人で全領域を兼任	機能別に分担	技術領域別の専任
AIエージェント基盤（Platform／SRE）	置かない（最低限のみ）	1人が兼任	専任チーム
AIガバナンス専任	置かない（安全な初期設定のみ）	テックリードが兼務	専任
データ／MLスペシャリスト	必要時に兼任	専任 or 兼任	専任

スタートアップは6つを1人が全部かぶる——3〜10人に分業を持ち込むのはオーバーヘッドにしかならず、実質「役割分担しない」のが正解になる。大企業は1行＝1専任に分かれる——複雑性・コンプライアンス・監査の要求が高く、分けなければ統制が崩壊する。とくにエージェント基盤とガバナンスは大企業から先に専任化する。中堅はその中間で、上の行から順に専任化が進む。

トレードオフを直視すると、こうなる。

	何でも屋化（多能工）	分担維持
スタートアップ	短期生存に有効・速度が出る／長期スケールしにくい	人数的に非現実的
大企業	ガバナンス崩壊リスク大	安定するがイノベーションが遅れがち

だから「ITエンジニアの役割分担はいるのか」への答えはこうだ——役割（6つ）の顔ぶれは規模を問わず共通。変わるのは”何人で分けるか”だけ。スタートアップだけが1人に畳み込むので「分担なし」に見える。「何でも屋になるべきか」も同じで、スタートアップは Yes、大企業は No。普遍解はなく、自社の規模に当てるのが正攻法だ。

中央に固めるか、各チームに埋め込むか

「何人で分けるか」の次は、「分けた役割をどう束ねるか」だ。6つを独立した”AI専門チーム”に集約すべきか、各プロダクトチームに埋め込むべきか——これは古くからある 集約（centralized）／埋め込み（embedded）／hybrid の組織設計論が、そのままAIに当てはまる論点だ¹³。

• 集約（中央AIチーム）: エージェント基盤・ガバナンス・データ／MLを一つのチームに固める。深い専門性とガバナンスの一貫性が出る。Deloitte の言う「AI Center of Excellence」もこの形で、人材・技術を全社で使い回せる¹⁴。半面、中央チームがボトルネック化し、プロダクト文脈から切れて「依頼待ちの内部代理店」になる失敗が、データサイエンス組織で繰り返し報告されてきた¹³。
• 埋め込み（各チームに分散）: AI役割を各プロダクトチームの中に置く。文脈に近く速いが、一貫性とガバナンスが弱くなりがちだ。
• hybrid（折衷）: 一貫性が要るもの——エージェント実行基盤・ガバナンス・セキュリティ・ツール標準——だけを中央に固め、オーケストレーションやAI活用は「スキル」として各チームに埋め込む。AI時代の組織論でも、2026年時点の実務的な結論はこの hybrid に収束している¹⁵。

hybrid を具体的に置くと、6役割＋オーケストレーションの置き場所はこうなる（大企業の典型。スタートアップは全部が1チームに同居するので「中央／埋め込み」の区別自体が消える）。

役割	hybrid での置き場所
プロダクト／FDE型	各プロダクトチーム（埋め込み）
実装指揮（テックリード）	各プロダクトチーム（埋め込み）
技術領域検証	各プロダクトチーム（埋め込み）
AIエージェント基盤（Platform／SRE）	中央（集約・platform team）
AIガバナンス専任	中央（集約）
データ／MLスペシャリスト	プロダクト次第（中央 or 埋め込み）
オーケストレーション（スキル）	全員が持つ（埋め込み）

これは Team Topologies の語彙ときれいに対応する¹⁶。中央のAIチームは、各プロダクトチーム（stream-aligned team）に基盤を「サービスとして」提供する platform team と、AI活用を各チームに浸透させる enabling team。中央に寄せるのは「全社で一貫させたいもの」——基盤とガバナンス——だけで、価値を生む実装系は各チームに残す。「中央は薄く、現場は厚く」が原則だ。

ひとつ留保を。hybrid 推奨は十年来の実務・応用研究の幅広い合意だが、対照実験で証明された最適解ではない。「中央に何を固め、何を各チームに残すか」は、自社の規模・規制・プロダクト密度に応じて引き直す前提のガイドラインだ。出方は規模で決まる——スタートアップは中央チームなし（全部1チーム）、大企業ほど中央のAIプラットフォーム＋ガバナンスが独立する。

スキルと評価はどう変わるか

役割が変われば、求めるスキルと、人を測る軸も変わる。

スキルの重心は「書く」から「見極める・束ねる・つなぐ」へ

方向は明確で、「コードを書く力」から「AIの出力を見極め、システムとして束ね、価値につなぐ力」へ移っていく。

• コーディング実装力の比重は下がる（ゼロにはならない）: BCG はソフトウェアエンジニアリングを代表的な「amplified（増幅される）」職種と位置づけ、コード生成が加速する一方でコーディングそのものの優先度は相対的に下がり、システムレベルの判断＝システム思考の比重が上がると指摘する⁷。
• 検証力が中核スキルになる: AIは「ほぼ正しい」出力を大量に生む³。誤りを見抜く検証眼——前述の「深い軸」——が、書く力に代わる中核になる。
• オーケストレーション力が新しい基礎教養になる: 複数のエージェントにタスクを分け、非同期で上がる成果を束ねる。Addy Osmani の言う「Conductor から Orchestrator へ」の移行であり⁸、特定職種でなく多くのエンジニアの基礎動作になる。
• ビジネス・顧客価値への翻訳力: FDE に代表されるように、技術判断と顧客の課題を往復し、要望を実装に、実装を価値に翻訳する力の比重が上がる。
• ガバナンス・統合の専門性が立つ: 規模が大きいほど、AIの統制・データ整備・システム統合が独立した専門スキルとして顕在化する。

評価軸は「量」から「プロファイル」へ

最大の変化は、実装量で測れなくなることだ。AIが実装を肩代わりするほど、コミット数や機能数といった「どれだけ書いたか」は成果指標として崩れる。AIは質を増幅するのであって¹、量はもう人の価値を表さない。評価の重心は 検証と統制 へ、つまり「何を書いたか」から「何を見抜き、何を防ぎ、どんな判断をしたか」へ移る。ここで “AI利用率” や “プロンプト数” のような測りやすい代理指標に飛びつくと、Goodhart の法則（測った値が目標化して歪む）どおり、別の的外れな行動を強化してしまう。

評価の「形」も変わる。人は一つの数字には潰せない。技術領域の深さ（検証力）と、担う機能の広さは別々の軸で見るしかなく、評価は順位よりプロファイルに近づく。広く覆うゼネラリストと深いスペシャリストを同じ梯子で比べると壊れるし、スタートアップ（広く兼任）と大企業（深く専任）では物差し自体が変わる。

厄介なのは、検証・統制は「鳴かなかった犬」だという点だ。防いだ障害や未然に止めた事故は観測しづらく、SRE やセキュリティと同じ評価の難しさを抱える。ここを過小評価すると、人は”見える実装”へ戻り、まさに避けたかった逆インセンティブが生まれる。「派手に作った人」より「静かに事故を防いだ人」をどう可視化するかが、評価設計の勘所だ。

最後に、対AI／対人の切り分けは評価でも効く。オーケストレーション力は評価すべき対AIスキルだが、「優秀だから」と対人マネジメント職へ上げて報いるのは別問題だ。評価で報いることと、昇進トラック（とくに管理職）を動かすことは切り離す必要がある——さもないと、AI活用の達人を対人マネジメントの素人にして両方失う、という古い失敗を繰り返す。

長期（2028年以降）：エージェント自律化で再専門化へ

ここまでは、AIが主に「個人の生産性ツール」だった短期の話だ。長期では、AIエージェントが自律的にタスクをこなす度合いが上がり、構造そのものが変わる。

複数の主流予測が同じ方向を指す。Gartnerは2026年の戦略技術トレンドとして、2030年までに80%の組織が大型ソフトウェアエンジニアリングチームを小型のAI拡張チームへ進化させると予測した（Deloitteの2026年ソフトウェア業界アウトルックもこれを引用）²¹⁷。McKinseyは「agentic organization」で、組織図が階層的委譲から人間とエージェントの自律ネットワークへ移り、agent orchestrator・hybrid manager・AI coach といった役割が生まれると論じる⁵。BCGは、AIが置き換えるより多くの仕事を「作り変える」とし、ソフトウェアエンジニアリングを代表的な「amplified」職種に置く⁷。

人間は「実装者」から「オーケストレーター」へ

人間の重心は実装からオーケストレーションへ移る。Addy Osmani は、働き方が一つのAIと密に対話する「Conductor」から、複数の自律エージェントを非同期で束ねる「Orchestrator」へ移行すると整理している⁸。全部を自分で書かないからこそ、何を検証できるかという軸が価値になる。規模別の長期像も粗さが変わる——スタートアップは極端には「1人＋エージェント群」で会社が回る方向へ、大企業は小型ポッド内で人間の役割が「エージェント群の設計・検証・統制」へ再定義され、ガバナンス専任の比重が増す。

ただしこれらは現時点の主流予測だ。エージェントの進化が遅れれば従来の分業が長く残り、速ければスタートアップの「1人企業化」が前倒しになる。方向としては「小型化・再専門化」に賭けるのが合理的、というのが現在地だ。

オーケストレーション（対AI）と対人マネジメント（対人）を混同しない

「人間はオーケストレーターになる」と言うと、しばしば「ではこれからは全員が管理職を目指すべきか」という連想が生まれる。ここははっきり切り分けたい。

エージェントを束ねるオーケストレーションは対AIのスキルだ。指示の出し方、タスクの分解、出力の検証——ほぼ全員に有用になる。一方、人を束ねる対人マネジメントは別物だ。人間には自律性や承認の欲求があり（自己決定理論の言う基本的欲求）、AIエージェントには無い。だから対AIで効く手法と対人で効く手法は根本的に異なる。

既存のマネジメント論は、個人がAIエージェントを扱ううえで役立つ。だが「AI時代だから全員が対人マネジメントを学び、管理職を目指すべき」という結論には飛ばない。オーケストレーション能力を磨くことと、対人マネジメントの専門トラックに進むことは、独立したキャリア選択だ。多くのエンジニアにとって、前者は必須スキルになり、後者は志向する人が選ぶ専門領域であり続ける。

組織設計の問題として捉える

視座を一段上げておきたい。ここまで「個人がどう動くか」と「チームをどう組むか」を並べてきたが、より本質的なのは後者——組織が規模に合った構造を設計するという問題だ。

「何でも屋として個人が頑張る」だけで解ける問題ではない。どの規模でどんな役割境界を引き、どこにガバナンスを置き、何を中央に固めるかという設計判断が成否を分ける。これは個人の努力量ではなく、組織設計の質の問題だ。

この点で、日本企業には固有の難しさがある。長く続いた終身雇用・新卒一括採用・同質的な人材を前提とした時代には、組織設計やマネジメントは「経験を積めば自然にできるもの」とみなされ、専門性として認識されてこなかった。だが多様な人材・AIツール・急速なスキル勾配を扱う今、組織設計は明確に専門的な営みになっている。これは「日本企業が悪い」という単純な批判ではない——かつて合理的だった慣行が転換点を迎えているという構造的な話だ。役割再設計を個人の心がけに押し付けず、組織の設計課題として正面から扱えるかどうかが問われている。

業態差も忘れてはならない。プロダクトを高速に回すSaaSと、要件定義から運用まで工程が固定的なSIerとでは、同じ「大企業」でも最適な役割設計は変わる。本記事の規模別の地図は出発点であって、自社の業態・顧客・規制環境に合わせて引き直す前提のものだ。

実務家が今やるべきこと（規模別チェックリスト）

スタートアップ（〜数十人）

• 多能工化を「軸なしの広く浅く」にしない。各人が一つの深い軸を保てているか確認する
• ガバナンスは軽量に。ただし「後で効いてくる」セキュリティ・データ取り扱いの最低線だけは引く
• 人数が増えてもフラットを惰性で続けない。機能別への移行タイミングを意識する

中堅（数十〜数百人）

• 既存の機能分担に、AI活用ロールを「専任採用」より先に「役割の上乗せ」で導入する
• エージェント基盤・データ系をどこまで専任化するか、上の行から判断する
• 「幅を広げた人」の検証眼（軸）が維持されているかをレビュー体制で担保する

大企業（1000人以上）

• フラットな多能工化を全社展開しない。小型AIポッド + マトリックスで束ねる設計を検討する
• AI基盤・ガバナンスは中央チームに集約しつつ、AI活用は各チームに埋め込む（中央偏重のボトルネック化を避ける）
• 採用抑制で生じる「一人あたり守備範囲の拡大」を放置せず、明示的に役割を再設計する

個人（規模を問わず）

• AIで幅を広げる前に、検証の基盤となる深い軸を一つ確保する
• エージェントを束ねるオーケストレーション能力を磨く（≠ 管理職を目指す、とは別物）
• 対人マネジメントは「志向するなら」専門トラックとして学ぶ。連想で流されない

まとめ

AI時代の役割分担に、規模を超えた唯一解はない。だが具体的な見取り図は描ける。

• 役割は6つに分化する: 「実装する人」が、プロダクト／FDE型・実装指揮・技術領域検証・エージェント基盤・ガバナンス・データ／ML に分かれる。従来の役割（各レイヤー・QA・PdM・SE・テックリード）はこの6つへ横滑りし、多くは「実装」から「検証・統制」へ移る。
• 分け方は規模が決める: 顔ぶれは規模共通で、変わるのは”何人で分けるか”。スタートアップは1人が全部（実質分担なし）、大企業は1役割＝1専任。「何でも屋になるべきか」もスタートアップは Yes、大企業は No。
• 束ね方は hybrid: 一貫性が要る基盤・ガバナンスだけ中央に固め、AI活用は各チームに埋め込む。中央に寄せすぎると「依頼待ちの内部代理店」化する。
• スキルと評価: 重心は「書く」から「検証・束ねる・つなぐ」へ。評価は実装量でなく「プロファイル」で見て、検証・統制という”鳴かなかった犬”を可視化する。対AIスキルの評価と管理職昇進は切り離す。
• 長期（2028〜）: エージェント自律化でチームは小型化・再専門化し、人間はオーケストレーションへ上流化する。

「何でも屋になれ」も「分担を守れ」も、それ単体では半分しか正しくない。正しい問いは「自社の規模で、6つの役割を何人にどう配り、どこを中央に固めるか」だ。そしてそれは、個人の頑張りではなく、組織設計の質の問題である。

関連記事

このテーマに関連する他の記事もご覧ください：

• I型・T型・π型——深さと幅のスキルマトリクス - 「何でも屋」の二義性と、軸を持つ多能工（T／π型）の定義
• PdM 不要論と FDE 躍進——AI が再編するソフトウェア組織の役割境界 - AIによる役割境界の再編という同じ現象を職種軸で分析
• チーム協業を「密結合」から「疎結合」へ——AI時代の働き方の設計論 - チーム設計を結合度の観点から捉え直す
• プロンプトを書かない熟練者——メタプロンプティングとオーケストレーターへの進化 - オーケストレーターへの上流化を個人スキルの視点で深掘り
• AI-Nativeエンジニアリングチームの構築：OpenAI Codexガイド解説 - AIネイティブなチーム構築の実践アプローチ

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

1. 2025 DORA State of AI-Assisted Software Development - Google / DORA (2025). 約5,000人の開発者を対象とした調査。「AI amplifies what’s already there（AIはすでにそこにあるものを増幅する）」という結論、AI採用率の上昇、チームのアーキタイプ分類の出典。【信頼性: 高】 ↩︎ ↩︎² ↩︎³ ↩︎⁴

2. Gartner Identifies the Top Strategic Technology Trends for 2026 - Gartner (2025年10月20日). 「2030年までに80%の組織が大型ソフトウェアエンジニアリングチームを小型のAI拡張チームへ進化させる」という予測の一次情報。【信頼性: 高】 ↩︎ ↩︎² ↩︎³ ↩︎⁴

3. 2025 Stack Overflow Developer Survey: AI section - Stack Overflow (2025). 84%がAIを使用／使用予定、46%が出力の正確性を信頼していない、66%が「ほぼ正しいが完全ではない」出力の修正に追加時間を要する、などのデータの出典。【信頼性: 中〜高】 ↩︎ ↩︎²

4. IT／AIエンジニアはどうなる？ 2026年に求められる4つの役割 - ITmedia Deep Insider (2026年1月6日). AIコーディング実用化に伴う4つの新ロール（AI実装指揮官／AX実務エキスパート／AIデータサイエンス・スペシャリスト／AI導入戦略家）と各スキルの提案。「すべてを一人で担う必要はなく、適性と関心で柔軟に配置を選ぶ」とする。【信頼性: 中】 ↩︎ ↩︎² ↩︎³

5. The agentic organization: Contours of the next paradigm for the AI era - McKinsey & Company (2025). 組織図が階層的委譲から人間＋エージェントの自律ネットワークへ移行し、agent orchestrator・hybrid manager・AI coach などの新ロールが生まれると論じる。【信頼性: 中〜高】 ↩︎ ↩︎² ↩︎³

6. What are Forward Deployed Engineers, and why are they so in demand? - Gergely Orosz, The Pragmatic Engineer (2025). FDE の歴史・採用動向・主要企業（Palantir / OpenAI / Anthropic / Ramp）の実態を整理した一次情報。AIが実装コストを下げるなかで顧客最前線のエンジニア需要が高まる構図の出典。【信頼性: 中〜高】 ↩︎ ↩︎²

7. AI Will Reshape More Jobs Than It Replaces - Boston Consulting Group (2026). 仕事の50〜55%が2〜3年で意味のある形で作り変えられると予測。ソフトウェアエンジニアリングを代表的な「amplified」職種とし、システム思考の比重上昇を指摘。【信頼性: 中〜高】 ↩︎ ↩︎² ↩︎³ ↩︎⁴

8. Conductors to Orchestrators: The Future of Agentic Coding - Addy Osmani (2026). 単一AIと密に協働する「Conductor」から複数自律エージェントを非同期に束ねる「Orchestrator」へのパラダイム移行を整理。【信頼性: 中】 ↩︎ ↩︎² ↩︎³

9. AIの業務代替による人員削減、企業規模が大きいほど影響が出ている傾向 - HRzine (2026年1月22日). マイナビ「企業人材ニーズ調査 2025年版」（採用担当者2,101人、2025年12月調査）を報じた記事。人員削減影響「既にあり」全体12.3%、1000人以上の大企業16.2%の出典。【信頼性: 中〜高】 ↩︎

10. Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of Artificial Intelligence - Erik Brynjolfsson, Bharat Chandar, Ruyu Chen, Stanford Digital Economy Lab (2025年11月版). ADP給与データを用い、AIに最も晒された職種で22〜25歳の雇用が約16%相対的に減少したことを示す。【信頼性: 高】 ↩︎

11. 【IT/Webエンジニア調査】AIにより約7割の企業が採用要件の変化を予想 - ファインディ株式会社 (2025年3月26日). 回答企業188社（プラットフォーム利用企業の自己選択サンプル）。98.4%がAI活用、約7割が採用要件変化を予想、の出典。サンプルの偏りに留意。【信頼性: 中】 ↩︎

12. How to Build and Structure an AI Development Team in 2026 - Alina Rovna, 8allocate (2026年2月19日). flat（3〜10人）／functional（10〜50人）／matrix（50人以上）の3モデルの整理。ベンダーによる枠組みであり、データではなく整理として参照。【信頼性: 中】 ↩︎

13. Centralized vs Decentralized Data Science Teams - DataScience-PM (2025). 集約／分散／hybrid の3モデルとトレードオフ（集約＝動きが遅く官僚的・支援が手薄、分散＝サイロ化、hybrid＝推奨だが連携コスト増）を整理。【信頼性: 中】 ↩︎ ↩︎²

14. Leveling up the AI center of excellence - Deloitte (2024). AI能力を中央に集約する CoE の概念。人材・技術・テクノロジーを全社で使い回せる利点を整理。【信頼性: 中〜高】 ↩︎

15. Operating Structure for the AI Era #7: Centralized AI Team or Embedded AI Capability? - Antoine Buteau (2026). AI特化の集約／埋め込み論。中央はセキュリティ・基盤標準を、各チームは成果と定着を持つ hybrid を主張。中央が抱えすぎると「内部代理店」化しボトルネックになると指摘。【信頼性: 中】 ↩︎

16. Team Topologies - Matthew Skelton & Manuel Pais, IT Revolution (2019, 第2版2025). チームを stream-aligned／platform／enabling／complicated-subsystem の4型と3つの相互作用モードで整理。platform team は stream-aligned team の認知負荷を下げる、という整理が「中央AIチーム＝platform/enabling」対応の根拠。【信頼性: 中〜高】 ↩︎

17. 2026 Global Software Industry Outlook - Deloitte (2026年2月12日). 上記Gartner予測を引用し、AI拡張チームへの移行と新ロール追加を論じる。【信頼性: 高】（Gartner予測の二次引用） ↩︎