PdMがCursorと二人三脚で1日1PR出すようになった話

はじめまして、株式会社SODAでPdMをしている辛いものが好きなmyo3mです！ 3月頭から少しずつ機能開発にトライする機会を作っています。SODAでもCursorが導入されたことで学習のスピードがあがり、最近では1日1PR出せるようになったので今回はその成果を報告します💪 ちなみにこの文章はAqua Voiceとともに書いています

💡SODAでは #dev-cursor / #dev-claude-code / #dev-devinというチャンネルがあり、日々そこでAIを活用した開発について最新情報の共有がされています

さてここで問題です。私がコードを書き始めた理由は何でしょう？👀

• AIがすごすぎてPdMの仕事が変わりそうで、将来が不安だった
• なんか仕事に余裕がでてきた
• プロダクト開発のスピードや品質をよくしてもっとアウトカムを出したかった

A. 正解は、全部！

もともと仕様理解やプランニングの予習としてコードを読むことはしていましたが、最近の圧倒的なAIの進化＆プロジェクトが一段落ついた＆品質をあげるためにはより深いプロダクト理解が必要と思うことが多くあり、少しずつコードを書くことにトライさせてもらっています

とはいえ私は文系出身で元々プログラミングの知識はないので いきなりコードを書こうといっても、 当然チームの即戦力になるわけではありません

知識がないレベルでいったらこんなかんじです（2025/3/5 19:19の自分）

ただ、まったく開発に関する知見がゼロというわけではなく、

• どのテーブルに何が入って、どのタイミングで更新されるかは一応理解してる、SQL少しわかる
• バリデーションや比較的簡単な処理なら、AIなしでもコードを読んで理解しようとし、わからないところがあったら質問できる

が私のスタート地点でした

いったい何を実装しているのか？

というわけで開発にトライしているわけですが、こんなことに取り組んでいます💪 1から開始して、最近は2と3の開発を主に行っています。

1, backlogの後ろのほうに積まれているけど直近ではやられなそうなPBI

自分自身がPdMだからこそ思うのですが、開発リソースが限られている以上どうしても優先度をつける必要があります😢これらに取り組むことで、即時的にわかりやすい成果は出にくいが、ユーザー体験がよくなる改善、生産性に関わる改善がしやすくなりました

• メールテンプレートの見直し
• イベント実装のリファクタリング
• 今となっては必要のない機能の削除

2, チームの開発に対して先行して動くことでフロー効率がよくなるPBI

例えばチームメンバーがAPIを実装しているのと並行し、自分がUIの作成をしておけば、APIが完了したタイミングで機能のマニュアルテストに移ることができます

1スプリントでAPIの実装→ もう1スプリントかけてUIとのつなぎ込み…を実施していたのが、自分自身が先行してタスクに取り込むことによってフロー効率を向上することができました💪

3, チームの開発🙌

最近ではスプリントゴールに関わるチームの開発にも入っていけるようになりました。なるべく近い範囲の実装をまとめて担当することで、

• まずは1つの範囲の実装にトライし、全体の流れを理解する
• 類似の実装を再度行うことで理解を深める＆修正がでにくいでPRのレビュー依頼をする

という状態を目指しています

1機能群に対してBEからFEの実装を通しで担当し、実装したものを関係者と連携し改善していくプロセスも行うことで、開発するうえで手戻りや待ちなど、非効率になりやすい部分はどこかも少しだけ見えてくるようになりました

初心者だからこそやってること

とはいいつつ、私自身はPdMですし特定のメンター/オンボーディングサポーターがいるわけでもないので、何か機能開発をするときには、できるだけ周りのメンバーの手を借りず、とはいえ必要なときは適切なヘルプを出すように心がけています

SODAではスクラムをベースに機能開発をしているのですが、具体的にはこのようにやっています📝

• プランニング前に自分のGFIになりそうなPBIにあたりをつける
• 自分が担当するとしたら何をどのように実装するかを事前調査
• プランニングでわからないことを質問しつつ、自分がPBIをもらうことに合意を得る
• ローカルで動作確認用データを作成しつつ実装
• PRに実装意図・詳細や質問したいことを記載してレビュー依頼！

これが今のところの成果だ！

これを繰り返すことで、最近では＼＼ ならすと1日1PRくらい出せてる（かも） ／／な状態になりました💪

実装している内容も、こんなかんじで少しずつレベルアップしています。すごい風に見えるように多少盛っています

🆙🆙🆙🆙🆙🆙🆙

• メールテンプレートの編集
• GTMやAppに送るイベントの改修
• クエリをEXPLAINしつつデータの取得とロジックを実装→コードの変更に伴い発生するバグを想像しつつテストかく！
• ひとつのまとまった機能群について既存実装を調べてファイル構成や実装方針の提案→ステークホルダーと仕様調整をしつつ機能実装（FEもBEも！）
• そして、AIを使った新たな開発のかたちを部署内外と模索中！

🆙🆙🆙🆙🆙🆙🆙

Cursorを使うことでコードがどう動作しているのか、複数のファイルがどう関連するか…を毎回質問せずとも理解できるので、インプットの効率があがりますし、「人にきかないといけない」という心理的抵抗により学習が止まってしまうこともありません

また、自分の理解をサマリしたうえでチームのメンバーにわからないことを質問することで、Cursorでは解説できない社内独自の背景によるコードの差分なども理解できるようになりました

PdMが開発することで得られたこと

自分自身が開発することで、おそらくエンジニアのあるあるであろう＆感覚値としては分かってるけど実態としてはわからない、下記を身をもって体験することができました

• PRDにこの条件が書いてあると助かるな / こう書かれても正直わからないな（例：「期限が近い」などの曖昧な表現だとロジック組めない）
• Figmaのここ、こんな情報が盛り込んであったらいいのに！（例：コピペで日付が並べられているからどうgroup byすればいいかわかりにくい）
• リアルタイムで◯◯してほしい、などの仕様上の表現と実際の期待値の違い（例：入力したIDに対してリアルタイムでデータを返す場合はパフォーマンスなども気にして実装が必要だが、実際はそこまで望まれてないよね、とか）
• このタイミングでこの仕様変更があるととてもつらい（例：「文字を変更するだけに見えても実際は関係する箇所が多く、修正に時間がかかる！）

じゃあこれからどうするん？

自身が開発に入っていくことでPRDがもっとこうなっていたらいい、逆にこれだとコンテキストとして渡しづらいというイメージがよりつくようになってきたので、今後は組織がよりAIを活かした開発をしやすくするために、こういった土台づくりを行っていく予定です

• PRDの記述と読み解きにかかる認知負荷を軽減する
• PM (仕様作成)→エンジニア (実装)→QA (マニュアルテスト)が同じPRDを実務に活用しやすい状態にする
• AIが「仕様の背景・ドメイン構造」を正しく解釈し、誰もが品質高くアイディアの起案と実現を行えるようにする

→

具体的には下記を土台として整備しつつ…

• ドメインマップの作成
• ドメインごとに適切に管理されたProduct Specの作成

そして、最終的にはこんなかんじで 機能開発が進む状態をイメージしています

• 誰か/誰もがが作りたい機能を考える
• それをAIに伝える
• AIが関連ドメインを引っ張りだし、網羅性のあるPRDの土台を書く
• 人間がブラッシュアップ
• 上記ドキュメントをコンテキストとしてAIに渡すことで、情報の再構成の手間ができるだけないかたちで実装が考慮漏れなく爆速で進む

さいごに (小話)

この取り組みは、自分自身の仕事をなくすための取り組みでもあります

PdMの仕事のやり方はこれからも変わっていくと思いますし、もしかしたらAIによって私の仕事はなくなるかもしれません。それでも、この大きな変化に乗らないわけにはいかないので、組織がAIを活用してスケールするために、人間とAIにとってよりよい開発のかたちを探ろうと思います

いつかAIによって仕事がなくなるなら、そのときは中央アジアでロバと暮らしたいし、お腹が壊れることを気にせずに辛いものを毎日食べたい

それでも生きていける世界でありますように🙏