Cursorを開発経験の無いPdMが使ってみた

はじめに

こんにちは。NOT A HOTELで予約管理などを行うシステム（PMS）をはじめ、運営スタッフ向けのツール開発を担当しているshunです。
NOT A HOTELでは、これらの運営システムをすべて自社で開発しています。

この記事では、NOT A HOTELがVALUEに掲げている「超自律的な開発スタイル」のなかの、「デモ駆動」にフォーカスし、PdMがどのように取り組んでいるのかをお話します。

具体的にはAI エディタの「Cursor」を活用して、要件定義〜プルリクエストまでをPdMが行なっている取り組みです。
Cursorとは、AIがコードを理解して提案・修正してくれる次世代のエディタです。

自然言語で指示するだけで開発を自動化できます。

この記事は、

• NOT A HOTELでPdMがCursorをどのように使っているか知りたい方

• 開発知識のないPdMで、Cursorを活用に興味がある方

に読んでいただければ幸いです。

前提

1.チーム体制
オペレーションツールの開発チームは、PdM3名、フロントエンジニア1名、バックエンドエンジニア2名という体制です。
スモールチームで効率よくプロジェクト開発や、CSなどからの改善要望の対応をまわしていくためにAIの活用を取り入れています。

2.わたし個人の開発スキル
初心者向けの本やYou Tubeを参考におみくじアプリやじゃんけんアプリを作ったことがある程度で、自分でコードを書くことはほとんどできません。
NOT A HOTELに入社する前はプルリクエストをしたこともありませんでしたし、やり方もわかりませんでした。

Cursorを使ってみたきっかけは、新卒PdMの方が活用しているのを見て、「教えて」とお願いしたというちょっとしたアクションからでした。
繰り返しになりますが、全く開発知識がなく、Cursorに興味はあるけれど手を出せていないPdMの方の参考になればと思います。

PdMがCursorを使うと何が良いのか

先にお話ししておくと、「時間短縮」と「認識合わせ」に個人的にはメリットを感じています。

• 時間短縮

  • UIの軽微な変更であればPdMのみでほぼ完結する

  • 現状の仕様確認をAIに聞ける（膨大な社内資料から探す必要がない）

  • AIに指示を出しておき、自分は他の作業をすることができる

  • FigmaによるUIを用意しなくても、イメージだけで作っていける

  • 日々溜まっていく改善issueの消化ペースが速くなる

• 認識合わせ

  • 要件と合わせてデモがあることでエンジニアと成果物に対するズレがなくなる

  • 大きな機能開発では、利用するチームに事前に動くものを共有できるので、運用に落とし込むイメージがつきやすい

AIにコードベースでの仕様を確認してもらうこともできるので、膨大な社内ドキュメントの中から探す必要も少なくなります。
また、CSなどからの改善要望に対してもリソース的に対応しきれず「溜まっていってしまう」という状況をCursorを使うことでPdMだけで一定処理できるようになり、issueの消化スピードを上げていくことができました。

これまではUIをどう形にするかで手が止まることもありましたが、Cursorなら自然言語で試作しながら考えを整理できます。
「まずつくって確かめる」をPdM自身で実践できるのが大きな変化でした。

AIを活用した全体の流れ

Cursorを使うことで１〜４をPdMが担うことができます。これにより、超自律的な開発スタイルを目指しています。

AI活用が無い場合だと、PdMの担う範囲は上図でいうと１のみであり、２〜６をエンジニアが担うかと思います。
オペーレーションツールの開発チームでは「まず作ってみる」「確かめる」「つくり直す」を実践するためにPdMが４までのプロセスを行なっています。

わたしのように開発知識が全くなく、コードを1行も書けないPdMでもAIを活用することで実装→プルリクエストまでを実行することができます。

AIがコードを書いてくれているだけですが、実際に自分で動くものをつくれると楽しいのでおすすめです。

デモ作成

では、それぞれのプロセスで何をおこなっているか、お話ししていければと思います。
まずデモ作成ですが、要件に沿ってCursorに自然言語で指示を出すだけです。

「〇〇のページにAというタブを追加して」「AというタブにはユーザーNoと日時と内容とステータスを表示して」
この程度の指示でAIがデモを作成してくれます。修正も自然言語で依頼するだけです。
Cursorを触る前は「AIで実装といっても、ある程度知識がないとできないんでしょ？」と思っていましたが、そんなことは全くありませんでした。

上記のような軽微な修正で課題が解決できることもよくあると思いますが、このようなものなら数十分程度でPdMだけでプルリクエストまで進めることができるようになります。

こちらのやりたいことを伝えて、UI自体を丸投げしてアイデアを出してもらうこともできます。PRDを作り込む前にデモを作成しておき、触ってみながら要件を足すということもできます。
一概に「デモ作成」といっても様々な用途で利用できるのがCursorのいいところです。

UI/UXレビュー 〜 プルリクエストまで

デモがローカルで完成したら、実際に動くものをエンジニアさんに見せながらPRDとのすり合わせをオペレーションチームでは行っています。実際に動くものがあることで、要件の認識齟齬も発生しづらくなるのではと思います。

また、他のPdMに体験的なレビューを依頼したり、実際にその機能を使うチーム（CSなど）にもデモを見てもらい、成果物の認識合わせや使いづらいポイントがあるかフィードバックしてもらったりもします。

• デモがあることで成果物の認識齟齬が起こりにくい

• 修正が容易

• 「まず作る」「確かめる」が実践しやすい

また、冒頭でもお話しした、Figmaで全てのフローを作成していく手間もなく、AIに指示するだけで良い点も大きなメリットです。

デモをつくり、体験的なレビューをもらった後は修正後にCursorからプルリクエストを出せば、PdMのCursorでの作業は完了です。
プルリクエストもCursor上で「プルリクエストを出して」と指示するだけなので簡単です。

まとめ

ということで、Cursorを開発プロセスの中でどのように活用しているかについて話してきました。

最初はエンジニアや開発知識のあるPdMが使えるもの、という認識でしたが、一歩踏み出してみると多くのPdM業務の課題を解決することができました。特に、わたしのように開発知識のないPdMの方にこそ使ってみていただけると良いのではないかと思っています。

個人的な意見ですが、昨今のAIの進化を見ていると現在の「プロダクトマネージャー」という職種は5年後10年後に存在しているのか？という気もしています。

これまで明確に分かれていたPdMとエンジニアの領域が少しずつ重なり合い、近いうちに「PdM的な視点を持つエンジニア」や「エンジニアリングに踏み込むPdM」という形が当たり前になっていくのではと思っています。
ドキュメントをまとめ上げる、関係各所を巻き込む、要件定義だけする、意思決定だけする、というPdMは存在しなくなっていくのではないでしょうか。

PdMの責務は今後、新サービス、新機能の立案など事業開発的な領域へとシフトしていくのかもしれません。
そうなれば、事業開発・UXデザイン・エンジニアリングが一体となったチームでプロダクトを創り上げることが、世の中のスタンダードになっていくように思います。

PdMが開発領域にも踏み込みながら動くことが、これからの時代には求められていくと思います。そして、その挑戦を支えてくれるのがAIです。
Cursorをまだ使ったことのないPdMの方は、ぜひ使ってみてはいかがでしょうか。

ここまでお読みいただきありがとうございました。

現在、NOT A HOTELのSoftwareチームでは採用強化中です。
カジュアル面談も受け付けておりますので、お気軽にご連絡ください。