AIで組織はこう変わる──LinkedInが再発明した「Full Stack Builder」モデルとは
「2030年までに、現在の仕事に必要なスキルの70%が変わる」。
LinkedIn前CPOのTomer Cohenは、インタビューの冒頭でこう語ります。ポイントは、「転職するかどうか」に関係なく、いまの仕事そのものが別物になっていくということです。
変化のスピードが人間の学習・適応スピードを上回り始めた今、企業も個人も、これまでの「プロダクト開発の常識」そのものを見直さざるを得ません。LinkedInがその答えとして提示したのが、Full Stack Builder（FSB）モデルです。
これは「PMという役割を廃止する」という話ではありません。むしろ、PM・デザイン・エンジニアリングといった境界を溶かし、AIと人間が一体となって動く“新しいビルダー像”をつくる試みだと言えます。
1. なぜLinkedInはプロダクト開発を作り直したのか
1-1. プロセスと組織の肥大化が限界に達した
Cohenがまず問題視したのは、「仕事そのものの難しさ」ではなく、「それを取り巻くプロセスと組織構造の複雑さ」でした。
大企業では、機能追加ひとつのために、多数のステップとレビューが積み上がります。リサーチの段階だけ見ても、ユーザーインタビューやログデータ、フィードバックチケット、SNSでの反応など、10〜15種類の情報源をチェックしなければ「十分に調べた」と言えない状態になっている。さらにその後には、デザインレビュー、プライバシーレビュー、セキュリティレビューなど、各専門チームとのやり取りが続きます。
こうしたステップにはそれぞれ合理的な理由がありますが、全体として見ると、小さな機能を出すだけでも、複数チーム・複数スプリントを要する巨大な仕組みになってしまった。結果として、「実際にユーザー価値が立ち上がる“改善フェーズ”に到達するまでが異様に長い」という構造的な問題が生まれていたのです。
Cohenは「仕事自体は本来そこまで複雑ではないのに、我々が積み上げたプロセスと組織が複雑になりすぎた」と振り返っています。
1-2. スキルと職種の“賞味期限”が短くなった
LinkedInは、世界中の職種・スキルデータを持つプラットフォームとして、労働市場の変化を誰よりも早く検知できます。そのデータから見えてきたのが、「必要なスキルの70%が2030年までに入れ替わる」という事実です。
これは「今のスキルを少しアップデートすればよい」というレベルではありません。エンジニア、マーケター、リクルーターといった職種でも、日々の仕事の中身が根本から変わっていく。さらに、いま「急成長職種」と分類されている仕事の70%は、昨年の時点ではリストにすら載っていなかったというデータも紹介されています。
つまり、今ある役職や分業体制を前提に「どう効率化するか」を考えるだけでは、変化の速度に追いつけない。職能の切り分け方そのものを再設計する必要があるというのが、FSBモデル導入の背景にある問題意識です。
2. AI時代の“Full Stack Builder”とは何か
2-1. アイデアからローンチまでを一人（＋AI）で回すビルダー
Full Stack Builderの核心は、「優れたビルダーが、自分の肩書きに関係なく、アイデアを市場に出せるようにする」という発想です。従来は、PMが仕様をまとめ、デザイナーがUIを作り、エンジニアが実装し、と役割ごとにバトンを渡していました。
FSBモデルでは、一人のビルダーがAIエージェント群を活用しながら、リサーチ、構想、設計、実装、ローンチまでを一気通貫で進めることを前提にしています。もちろん「完全なひとり開発」ではなく、小さなポッド（少人数チーム）で動きますが、各メンバーは職能の枠を超えて、プロダクトづくり全体に手を伸ばすことが期待されます。
このとき、人間側が担うべきコアスキルとしてCohenが強調するのが次の5つです。
ビジョン（どんな未来を実現するのか）、エンパシー（どんな課題を誰が抱えているのか）、コミュニケーション（他者を巻き込む力）、クリエイティビティ（ありきたりでない発想）、そして何よりもジャッジメント（曖昧で複雑な状況で決める力）。それ以外の作業は、可能な限りAIに任せていくという思想です。
2-2. Navy SEALs型の“小隊組織”へのシフト
組織構造もFSBモデルに合わせて再設計されています。従来のように「PMチーム」「デザインチーム」「エンジニアリングチーム」が縦割りで存在するのではなく、ミッション単位で組成される小さなポッドが基本単位になります。
ひとつのポッドは、フルスタックに動けるビルダーたちの集まりです。メンバー全員がある程度コードを書けて、ある程度デザインもできて、ユーザーリサーチもこなし、AIエージェントを当たり前のように使いこなす。彼らはNavy SEALsのように、状況に応じて柔軟に役割を変えながら、短期間で任務を遂行し、終了後は別のポッドに再編されます。
Cohenは、「専門職としてのPMをなくす」というより、“ミッションに責任を持つビルダー”を増やす方向への重心移動だと説明しています。
3. LinkedInが構築した“AIエージェント群”の実像
3-1. まずは“AIが扱える基盤”に作り変える
LinkedInは、最初から「既製のAIツールをそのまま導入すれば解決する」とは考えていませんでした。実際に試してみると、Copilotや外部のエージェントツールは、巨大で特殊なLinkedInのコードベースやデザインシステムを、そのままではうまく理解できないことが判明したからです。
そこで同社は、AIがコンテキストを理解しやすいように、コードの構造やUIコンポーネントの設計を見直す「基盤側の改修」から着手しました。Figmaやデザインシステムも、AIと連携しやすい形式に整え直しています。
つまり、「ツールを買う」のではなく、自社のソフトウェアを“AIフレンドリー”に作り直すところから変革を始めているのが大きな特徴です。
3-2. LinkedIn独自のエージェントたち
基盤が整ったうえで、LinkedInは自社特有の知見を反映したエージェントを次々と作っています。
たとえば、Trust Agentは、LinkedIn特有の“信頼・安全”のルールやこれまでのインシデント事例、ポリシー文書などを学習したエージェントです。新しい機能の仕様書を流し込むと、どんな悪用リスクがあり得るか、どの点が脆弱かを指摘してくれます。実際に「Open to Work」機能の過去の仕様書を trust agent に通したところ、人間のチームが後から気づいた課題まで洗い出せたといいます。
Growth Agentは、過去の実験ログやファネルデータ、成長ループの構造を学習しています。あるアイデアや仕様を入力すると、「どのような成長インパクトが見込めるか」「どの指標に効きそうか」といった観点から批評してくれます。ユーザーリサーチチームが「どの機能に注力すべきか」を決めるときにも、このエージェントを使って優先度付けを行っているそうです。
さらに、ユーザーペルソナやサポートチケット、過去リサーチを統合したResearch Agent、SQLを書かなくてもLinkedInの巨大グラフをクエリできるAnalyst Agentなど、“職能ごとに固有だった暗黙知”を反映したエージェント群が用意されています。
最終的には、これらを束ねる「Product Jam Agent」が、ひとつの入口から裏側で複数エージェントをオーケストレーションする構想も進んでいます。
4. パイロット結果：AIは誰を最も強くするのか？
4-1. すでに「週数時間」の削減と品質向上が見えている
FSBモデルとエージェント群は、まだ全社展開前の段階ですが、パイロットチームではすでに「週に数時間単位の作業削減」が報告されています。
PMは、リサーチや要求整理の初期作業をエージェントに任せ、より深いインサイト抽出に集中できるようになりました。デザイナーはプロトタイプづくりだけでなく、簡単なコード修正やPR作成にも手を伸ばし始めています。エンジニア領域では、ビルド失敗時の修正対応を担う「メンテナンスエージェント」が導入され、失敗ビルドの約半分を自動で修復しているというデータも出てきました。
Cohenは、インパクトを測る指標として「実験数 × 実験の質 ÷ アイデアからローンチまでの時間」というフレームを提示しています。エージェントの導入により、数（＝実験の量）と質（＝インサイトの深さ）の両方が向上しつつあり、その割にかかる時間は減っているというのが、現時点での評価です。
4-2. 一番伸びているのは“もともと優秀な人”
興味深いのは、AIを最も使いこなしているのが、もともとのトップタレントであるという点です。Cohenは「AIは“普通の人を優秀にする”のか、“優秀な人をさらに優秀にする”のか」という問いに対し、明確に後者寄りの印象を述べています。
新しいツールを積極的に試し、自分なりのワークフローを作り込み、フィードバックを開発チームに返す。そうした「成長マインドセット」を持つ人ほど、AI導入の恩恵を先に獲得しているのです。
これは、AIを導入すれば自動的に「組織全体の平均生産性」が上がるわけではない、という現実も同時に示しています。
5. 変革の要は“文化”──ツール導入だけでは失敗する
5-1. 期待値・評価・成功事例を通じて“カルチャー”を書き換える
Cohenが繰り返し強調するのは、「プラットフォームとツールだけでは不十分で、カルチャーへの投資こそが決定的だ」という点です。
LinkedInでは、まずマネジメント層からFSBマインドセットを求めました。もともとPM出身のリーダーにも、デザインやエンジニアリング側から360度レビューを受けてもらい、「実際にフルスタックに振る舞えているか」を測定しています。また、採用と評価制度にもAIリテラシーやエージェント活用力を組み込み、「AIを使いこなすことがキャリア上のプラスになる」というメッセージを明確にしています。
同時に、限定的なポッドからの成功事例を全社に可視化し、「このチームはこうやってエージェントを活用して、ここまでスピードと質を上げた」というストーリーを繰り返し共有しています。そこから「自分も試してみたい」というFOMO（取り残される不安）を、健康な形で喚起しているのです。
さらに、従来のAPM（Associate Product Manager）プログラムを終了し、代わりにAPB（Associate Product Builder）プログラムを新設しました。新卒や若手には、入社直後からコーディング・デザイン・PMスキルを横断的に学ばせ、FSB前提の育成カリキュラムで鍛えることで、「最初から境界のない世代」を増やしていく方針です。
6. 企業はどう採用すべきか──3つの実践ポイント
Cohenは、同じような変革を考える企業に対して、次の3点を挙げています。
第一に、Platform（基盤）への投資です。既存のコードベースやデザインシステム、データ基盤をAIが扱いやすい形に整えなければ、どんなエージェントも本来の力を発揮できません。
第二に、Tools（エージェント）の独自カスタマイズです。汎用エージェントにDriveや社内Wikiへのフルアクセスを与えるだけでは、重要度の違いや文脈を理解できず、ハルシネーションも増えることがわかっています。どの知識を“金のサンプル”として学ばせるかを人間が選び抜くことが、品質の鍵になります。
第三に、そして最も重要なのが、Culture（文化）への継続的な働きかけです。評価制度、表彰、育成プログラム、社内コミュニケーションなど、あらゆる接点で「AIを使ってフルスタックに動く人」を支持するメッセージを出し続ける必要があります。
終論：PMは“終わる”のではなく“進化する”
LinkedInのFull Stack Builderモデルは、決して「PMという職種の死」を意味しません。むしろ、PM・Designer・Engineerといった職種ラベルの意味を問い直し、“ビルダーとして何ができるか”を軸にキャリアを再定義しようとする試みです。
AIは、分業のために分断されていた作業を再び統合し、「つくる力」の定義を広げていきます。そのなかで価値を持ち続けるのは、ビジョンを描き、ユーザーに共感し、複雑な状況で判断し続ける人間の能力です。
Cohenが引用した言葉を借りれば、“Becoming is better than being”──固定された役割にとどまらず、変わり続けること自体を楽しめる人こそ、AI時代のビルダーになれる。
プロダクトマネージャーの終わりではなく、プロダクトビルダーの始まり。LinkedInの実験は、その未来像を先取りしているのかもしれません。
