iwashi氏が語る、AI時代も変わらない本質とは？dev、EM、PMの視点から考える“プロダクト開発のいまとこれから”

AI技術の急速な進展により、プロダクト開発は大きな転換期を迎えています。大きな変化の波にさらされ、チームやプロダクト開発のこれからをどう考えていけばよいのか、何を学んでいけばいいのか、見通しの立てにくい状況が続いています。

AIが進化していくなか、私たちは何を学び、どこを目指して進化していくべきなのでしょうか。

本記事では、ポッドキャスト「fukabori.fm」のパーソナリティ・岩瀬義昌（iwashi）氏によるQiita Conference 2025 Autumnでの講演を一部再構成してお届けします。

デベロッパー、エンジニアリングマネージャー（EM）、プロダクトマネージャー（PM）という三者の視点から、AIによって「変わったこと」と「変わらない本質」を整理。AIとの協働が進むプロダクト開発の現在地と未来像、そして、今後に向けて何をしていくべきか、実践的な知見が得られる内容となっています。

• keyboard_arrow_down デベロッパー: AI時代でも変わらないのは「説明責任」と「-ity（性）」の担保
• keyboard_arrow_down EM: 開発の不確実性を取り除き、ステークホルダーと対話する
• keyboard_arrow_down PM: 「深いドメイン理解」と「人を動かす力」の重要性は変わらない
• keyboard_arrow_down いまから、AIという「力の増幅器」を使い倒そう
• keyboard_arrow_down まとめ

まず、デベロッパーから見ていきましょう。ここでいうデベロッパーは、ソフトウェアエンジニアのことを指しています。

ソフトウェアエンジニアの領域では、AIによって何が変わったでしょうか。皆さんも散々聞いているかと思いますが、「AI支援コーディング（AI-assisted coding）」が非常に浸透し、コーディングスタイルは劇的に変化しました。

以前はすべて自分の手で書いていましたが、数年前にはTabキーを連打してエディタの補完機能を多用するスタイルが主流になりました。現在では、コーディングエージェントに対して自然言語で「こういう仕様で」「こういう意図で」と指示し、コードブロック全体を生成するスタイルになっています。

開発者の役割は「コードを書く人」から、「コーディングエージェントの管理者」や「指示を出す人」、つまり一種のマネジメント的な役割へと変化してきています。

また、市場も変化しています。エンジニア向け情報プラットフォーム「LeadDev」が約880人を対象に行ったアンケートでは、半数以上の人が「ジュニアエンジニアの採用は長期的に減少する」と回答しています。求められるスキルや採用の基準が変わりつつあることが伺えます。

もちろん、新卒採用や中途採用で求められるスキルも変化していくはずです。では、AIが単純なコーディング、「How（どう作るか）」の部分を代替してくれるようになったいま、人間にはどのようなスキルが求められるのでしょうか。

まずは幅広さ、つまりフルスタック的な能力です。現状のAIは、コンテキストウィンドウの制限などで全体を把握することが難しいため、クラウド、フロントエンド、モバイルなど複数の技術領域やアーキテクチャを横断的に理解したうえで判断できる知識が重要になります。

同時に、AIが生成したコードの妥当性を判断するための深い知識が求められます。T字型スキルの縦軸に例えられるように、「データベースなら誰にも負けない」「ネットワークならマニアックに語れる」といった専門性も重要です。これが、AI時代に変わったこと、これまで以上に求められるようになったことです。

一方で「変わらない本質」として、個人的には2つあると考えています。

1つ目は「説明責任」です。以前、「ChatGPTがこう言っていたので、こうしました」というコードレビューのコメントが話題になったことがあります。そういったやり取りを、実際に見聞きしたこともあります。しかし、その説明をされたとして納得できるでしょうか。きちんと説明をすることは、これからも人に宿る重要な責務なのではないかと思います。

もう1つ、個人的に変わらないと思うのは「-ity（性）」の担保です。セキュリティ（Security）やアベイラビリティ（Availability）など、非機能要件でよく使われる「-ity」です。オブザーバビリティ（Observability）の一部のように数値化できるものもありますが、その数値を「どうすれば達成できるか」を判断するのは、現時点では人ですよね。

「現時点では」とお伝えしたのは、10年後にどうなっているか分かりませんし、もっと早い変化もありえます。とはいえ、いまはまだ「-ity」の判断をするうえで、人間の専門性がとても重要だと思います。

EMの役割において大きく変わった点が2つあります。

1つ目は、先ほど述べたように、デベロッパーが複数のコーディングエージェントを管理するようになったことです。それによってEMは、AI支援コーディングを行うIC（Individual Contributor）をマネジメントしていますが、その下にはAIエージェントがいます。バーチャルな部下が増えているんですね。マネジメントの対象が少し変わっていることを理解したうえで、動くのがいいと思います。

もう1つの面白い変化は、コードを書く時間を確保しやすくなった点です。コーディングエージェントにタスクを投げながら、1on1などの他の業務に取り組むことが可能になりました。バッチジョブ的なタスクがやりやすくなり、仕事の負荷が上がった側面もありますが、EMのプレイングがしやすくなったと感じています。

では、EMにおける「変わらないもの」は何かというと、仕事の本質は全く変わっていないと考えています。

ベクトルが揃わずバラバラに走っているチームの頑張りは「無」を生み出します。何かができていくのですが、プロダクトとしての価値は「無」なんです。そうならないようにリーダーシップを発揮し、「私たちはどこに向かっていき、何をしたらいいのか」を明確にして不確実性を取り除くことが、マネージャーの変わらない役割です。

そのために、マネージャーはあらゆる手段を講じます。私が特に意識しているのは「環境整備」と「ブロッカーの排除」です。例えば、AI支援コーディングを導入していない組織はいまや、生産性において著しく不利になる可能性があるため、AIを使いこなせるようにチーム環境を整えていく。会社のルール変更が必要なときには法務や知財へ相談したり、ガイドラインを策定したりもします。これらは面倒な作業ですが、チームの成長をブーストするために必要ですよね。

もう一つは、「ステークホルダーとの会話における翻訳の役割」です。「このタスクは、AIではうまく処理できない」「このような課題には向いていない」といったことは、実際にAIに触れている人が一番知っています。そのような肌感覚を持ったうえで、開発とビジネスの言葉を“翻訳”し、経営層などのステークホルダーと合意形成する。これもEMの変わらない役割です。

最後の1つは、「ボトルネックの見極めと解消」です。マネージャーは、チームが自走してみんなが全力で働けるようにしたい。そうするとレビュープロセス、デプロイ、ルール、セキュリティなど、ボトルネックになる問題がどんどん生まれるはずなんですよね。

私はよく1on1で「いま、困っていることはありますか？」と聞くのですが、そのように一歩引いてチームを観察し、ボトルネックを見つけ出して一つずつ潰していく役割は、AIがあってもなくなりません。「AIとチームが一緒に走れるように頑張る」ことが、マネージャーの変わらない仕事だと思います。

PM（プロダクトマネージャー）でもっとも分かりやすい変化は、「ディスカバリーの高速化」ですね。

「紙芝居」「ポンチ絵」など、呼び方はいろいろあると思うのですが、いままではスライドやFigmaで絵を描いて、ユーザーにアイデアを説明していたと思います。しかし、v0やLovableなどにより、動くプロトタイプをすぐに作れるようになりました。

動くプロトタイプの効果は絶大です。

スプリントレビューなどにステークホルダーを呼んでも、仕様を言葉で説明している段階では「ふーん」という感じで一歩引いているものです。しかし、動くデモを実際に見せたり触ってもらったりすると、途端に自分事として捉えるようになります。背中の角度が変わって、本当に前のめりになるんですよ。結果としてフィードバックサイクルがどんどん回り、スプリントのサイクル全体が高速化します。

すると当然、手数が増えます。PMはアイデアを伝えるために、文章を書いたり図を描いたりとさまざまなドキュメントを用意しますが、ゼロから書くことはほとんどなくなりました。これも変わったことだと思います。

一方で、PMの「変わらない本質」もあります。「深いドメイン理解」の重要性は、いつになっても変わらないはずです。

AIは、インターネット上の情報から膨大な知識を得ています。しかし、「この業界、このドメイン、この企業のユーザーペインはここにあるんだ」というところは特定できないんですよね。本当にユーザーが困っていることを見つけ出すためには、やはり顧客のもとへ足を運んで、観察し、自分のセンスを使って「ここだ！」と見つけないといけません。

もちろん、インタビューで得た情報をAIで分析し、インサイトを抽出することは有効です。しかし、「ここに絞り込むんだ」という優先順位付けは、まだ人間が行うべき領域だと考えています。

また、「WhatとWhyの伝道師」になることも変わらない役割だと思います。PMは「何を作るのか」「なぜこのプロダクトを作るのか」を開発メンバーに納得してもらう必要があります。ナラティブやストーリーを使って「こういうユーザーの困りごとを、こう解決すれば、素晴らしい世界が作れると思うんだ」と熱意をもって伝え、人を動かす能力は、今後もAIには難しいのではないでしょうか。

NotebookLMなどにPRDを読みあげさせることはできますが、そこで仕様を伝えても熱意は伝わりません。AIの言葉だけで人間が深く腹落ちし、動かされる可能性があるかというと、個人的にはグレーなラインだと思います。

最後に、「今後に向けて、何をしたらいいのか」という点についてお話します。

まず「AIは力の増幅器である」ということを押さえてください。デベロッパーのところで話した通り、自分の専門性があって初めて、AIは真価を発揮します。10の力がある人がAIを使えば20の力が出せますが、人の力が0.1だけでは、効果はもちろん限定的です。AIからより良い力を引き出すために、自身の専門性を磨くことが非常に重要です。

もう1つは、「試行錯誤と手数の重要性」です。

AWS、GC、Azureなどのクラウド黎明期には「クラウドはおもちゃだ」と様子見している人が多くいました。そんななか、実際にクラウドを試して業務に取り入れた人々は、大きな優位性を獲得しました。これは個人だけでなく、企業の競争優位にも直結しています。AIに関しても、たぶん同じことが起こるだろうなと思っています。

ですから、試行錯誤を重ね、手数を増やすことが非常に重要です。「どのAIツールが生き残るか」と様子見するのではなく、肌感覚を得るために楽しみながら使い倒す。これだけAIが注目されていても、実際に手を動かしている人は10〜20％程度ではないかと。いまは、やっているだけでアドバンテージが取れる面白い時代だと思います。

チーム観点の話もしましょう。

Amazonなどには「2 pizza team」、ピザ2枚で足りるくらいの少人数チームが望ましいという考え方があります。しかし、AIによって前提条件が変わりました。PMが一部のコードを書き、デベロッパーがデザインの一部を手掛けるなど、役割分担のあり方が変化しつつあります。

少人数のほうがコミュニケーション密度が高まるメリットがあるため、チーム規模はどんどん小さくなっていくでしょう。今後は「1 pizza team」になっていくと予想しています。もしかすると「half pizza team」になるかもしれません。

「AIは力の増幅器」―― 裏を返せば、増幅させるべき人間の力がなければ、AIもまた真価を発揮できないということでしょう。

AIに任せられる仕事を任せながら、人間はものづくりの本質を追求する。そのために、私たち人間には、これまで以上に確かなスキルが求められることになるのではないでしょうか。

テクノロジーがいかに進化しても、「ユーザーに価値を届ける」というゴールは変わりません。この増幅器をどう操り、どんな未来を実装するのか。それを考えるべき時代なのかもしれません。