
生成AI時代にプロダクトエンジニアは加速する
世はプロダクト戦国時代
AIコードエディタのCursorが最速で$100Mを達成したと話題になりました。
Cursorは1年で売上$100Mで史上最速
— 久保田 雅也@Coalis (@kubotamas) February 5, 2025
SaaSの記録をAI企業が塗り替えていってる pic.twitter.com/eIguc8ut1e
しかも社員数は20名のみと、社員数を増やして売り上げを伸ばす従来の成長曲線とは違う形で成功したことは非常に魅力的なモデルとして語られるでしょう。
なぜCursorは少人数で急成長したのか
この快挙を実現した要素として、そもそもCursorはVSCodeのForkプロジェクトのため基盤の開発が不要であったことや、開発ツールというある意味ツルハシ売りとしては一番売りやすい顧客性質(エンジニアは楽をするのが仕事)であることや開発者自身がユーザーになれるドメイン性質はありつつも、それ以上にプロダクト開発のサイクルが生成AIによって高度に最適化されていることも影響しているのではないかと考えております。
一般的なプロダクト開発サイクル
基本的には以下のプロセスを辿ると考えております。
プロダクト着想 = 課題 or 理想 の発見
ゴールの定義 = 課題 or 理想 の整理
現実的な計画 = 実現手法の策定
プロダクト製造 = 設計、実装、テスト
顧客への提供 = デリバリー
生成AI時代は各プロセスの速度が加速する
調査から仮説を立てる速度
自分自身が顧客になりうるサービスであれば良いですが、そうではないサービスの場合には、顧客ヒアリングや現場観察、市場調査や競合等から顧客の解像度を上げていく必要があります。
これらは非常に時間がかかることや属人化する領域ですが、生成AI時代の「調査力」によってひとつ最適化されています。
例えば、「プロダクト発想」で言うと、顧客の業務フローはChat GPTのDeep Researchを使い1次調査、仮説を立てるスピードが速くなりました。
もちろん今までもインターネット上に断片的に情報はありましたが、これらを読み込み、分別するためには前提の知識などが必要でした。
社内のドキュメントがあれば尚更です。検索と要約性の高さが強みです。
一方で、文章以外のコンテキストが取得できないことが大きなポイントです。言語化できていないこと・表情・関係性など人間的な部分にある大きなヒントから発見・想像するのは人間の強みです。
「ゴールの定義」においても、人の感情の配分が大きいtoCは難しさが残りますが、システマティックに評価されやすいtoBの領域に関しては、その組織や業界の求めることをIR資料や業界レポートやインタビューから、調査・定義することができる様になりました。
ドメインエキスパートや対顧客との対話の精度がグッと上がり、「あの人でないと考えられない」と言う文脈が減ってきていると思います。
ものをつくる速度
ソフトウェア製造における生成AIの進化は目まぐるしいものがあります。
特にWeb開発においては、並走型と言われるAI(CursorやGithub Copilot)が人間の思考と行動を拡張していく動きが見られています。
これまで設計・実装・テストにおいてはシステムの複雑性の解消のために領域ごとにチームを分け、認知や知識が最適化されるシステム量をチーム単位で開発保守し続けていくことが定石でした。
読んでいる方がエンジニアならわかると思いますが、「現状を把握する」ことと「影響範囲を予測し続ける」ことには非常に脳のリソースと時間コストが取られます。
特に優秀なエンジニアは、チームの変更差分を見てこの両方の脳内Indexを更新し続けているわけですが、正直ここには限界があるのです。
その工夫として、仕様書等のドキュメントを整備したり、レビューを活発化して共通認識を揃えていくわけですが、クリエィティブな仕事の中ではもっと情報は取って捨ててができるとベストであるのです。
生成AI時代には開発においてもキャッチアップコストが急激に早くなっています。
過去のPullRequestとソースコードや機能仕様書がコンテキストに入っていれば、現状どの様に何故動いているのかが大枠で把握できる様になりました。
そのコンテキストをもとに設計を行い、実行部分はAIにお任せするとこで、修正部分まで実施することができるわけです。
また、その処理を行う場合の影響範囲の洗い出しもAIの得意分野です。
修正を入れた処理はどこに影響があるのか、変更をするべきなのか、仕様書のコンテキストが揃っていれば、より精度が高く提供できるはずです。
極端な例かもしれませんが、ソフトウェアが巨大化していっても、変更量の期待値が変わらないのであれば、エンジニアチームの拡大化は以前に比べると慎重になれるのではないかと考えています。
(特に自立型開発エージェントのDevinを使っている方はより感じやすいのではないかと思います)
考える人、作る人という分断も変化していく
以前よりプロダクトエンジニアの流れが来るのではないかと考えておりました。
そもそもWebエンジニアの価値が生産性で測られることへの評価制度との限界を感じていたことや、考える人・作る人の分断はソフトウェアという形のない曖昧で変化の激しい世界において、本当に最適なのかは検討の余地があります。
その中で生成AIによる開発プロセスの最適化は、少人数でのプロダクト開発を支えるトレンドになると見ています。
そうなっていくとプロダクトエンジニアにはビジョンや事業計画から逆算し、プロダクト価値を高める上で最適な「変化」を常に探し続け、当てこんでいく = 費用対効果のレバレッジを判断する力の強さが重要になっていくのではないでしょうか。
いくら生成AIでも「本当の意味で価値のあるプロダクト」を100発100中で当てることはできないはずです。
この角度を高めていくスキルが、ものづくりをする人間に求められる力なのではないでしょうか。