この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の実践編 #03 です。
- 導入編はこちらからどうぞ。
- 実践編 #01 「全員がAIを使える」チームは、なぜ崩壊するのか
- 実践編 #02 誰もやらなかった仕事をやる人が、次の時代のキーマンになる
- 実践編 #03 「AIネイティブチーム」の現場で何が起きているか ← 今ここ
- 実践編 #04 PGからプロンプトアーキテクトへ。キャリアを変えた人たちの話
- 実践編 #05 組織がAIを導入して半年後、生き残ったエンジニアの共通点
「AIを使っているチーム」と「AIネイティブなチーム」は違う
最近、現場の話を聞いていて気づいたことがあります。
「AIツールを導入しているチーム」と「AIを前提として設計・運営されているチーム」は、全く別物だということ。
前者はCopilotを入れた、ChatGPTを使っている、という状態。後者は「AIがいることを前提に、チームの役割・フロー・評価基準まで再設計している」状態。
この記事では後者——AIネイティブなチーム——の現場で実際に何が起きているかを、複数の現場から聞いた話をもとに整理します。
ケース①：スタートアップのプロダクト開発チーム（5人）
何が変わったか
エンジニア3人、PM1人、デザイナー1人の小さなチームです。AIを前提にした体制に移行してから、開発サイクルが大きく変わりました。
従来は「PM → 要件定義 → SE → 設計 → PG → 実装 → QA → リリース」という流れ。今は全員がAIを使いながら同時並行で動く形になっています。
PMがAIで要件の叩き台を出しながら、エンジニアがAIで技術検証を同時に走らせる。設計と実装の境界が曖昧になり、「作りながら設計を固める」スタイルに変わった。
生まれた新しい役割
このチームで面白いのは、特定のメンバーが**「AIアウトプット統合者」**という非公式な役割を担い始めたことです。
全員がAIを使うと、各人のアウトプットの粒度や方向性がバラけることがある。それを「チームとして一貫したプロダクトになっているか」という視点で統合・調整する人が自然発生した。
その人は元PGですが、今はコードをほとんど書いていない。でもチームの中で最も重要な役割を担っています。
課題
品質のムラが大きい。AIのアウトプットをレビューするコストが、実装コストより高くなることがある。「AI使ったら早くなるはずなのに、なぜかレビューで詰まる」という逆転現象が起きている。
ケース②：大手SIerの社内新規プロジェクト（15人）
何が変わったか
規模が大きくなると、AIの導入効果と摩擦が両方大きくなります。
このチームで特徴的だったのは、ドキュメント生成の速度が上がりすぎたことで生じた混乱です。
設計書・仕様書・議事録——AIで量産できるようになった結果、ドキュメントが多すぎて誰も全部読めなくなった。「書いてある」けど「読まれていない」ドキュメントが大量発生。
情報の量は増えたのに、チームの共通認識は減っていた。
生まれた新しい役割
この課題に対応するため、「ドキュメントキュレーター」とでも呼ぶべき役割が生まれました。
AIが生成した大量のドキュメントから「今、このチームが本当に必要な情報」を選び出し、整理して、参照しやすい形にする人。
司書に近い仕事、と言った方がわかりやすいかもしれません。技術知識よりも「何が重要かの判断力」と「構造化の能力」が問われる役割です。
課題
ベテランメンバーとのギャップ。「AIが書いたドキュメントは信用できない」という不信感が根強く残っており、AI活用の度合いがメンバーによって大きく異なる。
これは「技術的な問題」ではなく「文化の問題」で、時間と丁寧なコミュニケーションが必要なケースです。
ケース③：フリーランスエンジニア集合体のプロジェクト（8人）
何が変わったか
正社員チームとフリーランスチームで、AIの影響の出方が違うな、と感じた事例です。
このチームは全員フリーランスで、各自がAIを使いながら独立して作業する形。コミュニケーションはSlackとGitHubのみ。
面白いのは、AIがフリーランス間の「言語の統一」に貢献している点です。バックグラウンドの違うエンジニアが集まっても、AIが出すコードのスタイルガイドを共通の基準にすることで、コードの一貫性が保ちやすくなった。
生まれた新しい役割
一方で「コンテキストの番人」が重要になっています。
フリーランスが集まるチームは、プロジェクトの背景・歴史・意思決定の経緯を共有しにくい。AIはそのコンテキストを知らない。
「このプロジェクトがなぜこういう設計になったのか」「過去にこのアプローチを試して失敗した理由」——そういう「プロジェクトの記憶」を保持して、新しいメンバーやAIへのインプットに使える形で管理する人が欠かせない存在になりました。
3つのケースに共通していたこと
規模もスタイルも違う3つの現場ですが、共通していたことがありました。
共通点①：「AIを使える人」より「AIのアウトプットを統合・整理できる人」が希少
全員がAIを使えるようになったとき、「使える人」は差別化にならない。「バラバラに生成されたアウトプットをチームとして整合させられる人」がボトルネックになる。
共通点②：情報の「量」ではなく「質と文脈」の管理が課題になる
AIは情報を増やします。でもチームに必要なのは「使える情報」であって「大量の情報」ではない。生成・整理・選別のサイクルを回せるチームが強い。
共通点③：「AIが触れない領域」に人間の役割が集中する
意思決定の根拠、ステークホルダーとの関係、チームの文化——AIが立ち入れない領域に、人間の仕事が凝縮されていく。テクニカルな仕事ほど自動化され、「人間らしい」仕事ほど残る、という皮肉な逆転が起きています。
「AIネイティブ」への移行で失敗しないために
ケーススタディを踏まえて、1つ強調したいことがあります。
AIの導入は「ツールの問題」ではなく「チーム設計の問題」です。
Copilotを入れても、ChatGPTを解禁しても、それだけでは何も変わらない。むしろ前回書いた「崩壊パターン」に陥ることもある。
重要なのは「AIが入ったとき、誰が何を担うか」を意識的に設計すること。役割の再定義、責任の明示、品質基準の更新——これらを並走させないと、ツールだけ変わってチームは変わらない、という状態になります。
まとめ
| ケース | 生まれた新役割 | 共通の課題 |
|---|---|---|
| スタートアップ5人 | AIアウトプット統合者 | レビューコストの増大 |
| 大手SIer15人 | ドキュメントキュレーター | ベテランとの文化ギャップ |
| フリーランス集合体8人 | コンテキストの番人 | コンテキスト共有の難しさ |
次回 #04 では、実際にキャリアを変えた人たちの話を紹介します。「PGからプロンプトアーキテクトへ」「SEから AIアウトプット品質責任者へ」——どうやってキャリアを作っていったのか、具体的なストーリーを書きます。
「うちの現場でもこういうことが起きている」「違うパターンがあった」という話、ぜひコメントで教えてください。ケーススタディは読者の声で育てていきたいと思っています。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。