PdMをやめて、"プロダクトビルダー"という働き方に変えました
3ヶ月前、PdMをやめました。
正確には、要件をまとめて開発チームに渡すこれまでのPdMの働き方をやめて、プロダクトビルダーという働き方に変えました。
PdMが自分で作らない人でいられる時代は終わったと思ったからです。
こんにちは、Ubieでプロダクトビルダーをしているしきち（shikichee）です。
AIエージェントを使えばなんでもできる時代に、PdMの役割はなくなるのか。
この1年、PdM界隈でずっと議論されてきた問いだと思います。
実際、AIエージェントの登場でそれっぽいものは誰でも一瞬で作れるようになりました。企画書も、デザインも、動くプロトタイプなどなどです。
PdMの役割はなくなるとは思っていません。
PdMの役割は大きく二つに分かれていくと思っています。
1つは、徹底的に現場を観察して何をするかを意思決定する役割です。
もう1つは、顧客の願いを高速に形にしながら検証していく役割です。
Ubieではこの後者を突き詰める働き方を「プロダクトビルダー」と呼んでいます。
自分の専門性を軸足にしながら、顧客価値を届けきるところまで越境する人の総称です。
「AIをフル活用すれば、一人で全部作れるのでは？」という仮説を立てた
自分はプロダクトビルダーという新しい働き方に挑戦することにしました。
「テーマを持って考えるところから価値を届けきるところまで、一気通貫でやりたい」
社内でそう宣言して、一人でなんでも作るPdMへの挑戦を始めました。
始める前の仮説はシンプルでした。
コードはAIが書いてくれます。デザインの叩き台もAIと組めばすぐにできます。環境はもう揃っているのだから、企画からデザイン・プロトタイプ・本番運用・改善までを一人で完結できるのではないか、という仮説です。
同じことを考えている方は多いと思います。この仮説を3ヶ月かけて検証してみました。
AIだけに頼った先で、3つの壁にぶつかった
それっぽく動くものはAIを使って本当に一瞬でできます。
ただ、使い込むほどはっきりしてきたことがあります。
AIは正しいものを作るのも速いですが、間違ったものも一瞬で作ってしまいます。
それっぽい企画書も、それっぽい画面も、動いてしまうプロトタイプも、正しさまでは保証してくれません。むしろ動くものが一瞬でできてしまうからこそ、間違いに気づくタイミングが遅れます。
そしてそれっぽいプロダクトの先で、私は立て続けに3つの壁にぶつかりました。
一人で作っていると、顧客の顔も、壁打ちできる専門家もいないまま、数字が頭打ちになる
デザイン・エンジニアリング・医学、専門領域の深いところには、AIと自分だけでは届かない
現場を知らずに作ったものは、顧客に刺さらない
壁1：個人開発で月間8万PV。しかし、顧客の顔が見えなかった
自分は元エンジニアですが、直近5年はPdM専任で、開発には5年のブランクがありました。そこでまずリハビリを兼ねて、休みの日に個人開発でサービスを立ち上げました。
ドメインを借り、SEO対策をして、広告をつけて、収益化まで一通りやり切りました。
価値を届けきる一連の営みを週末で素振りした形です。サイトは月間8万PVペースまで伸び、気づけば数週間で自分の手で300個以上のPull Requestを開発していました。
AIを使えば、ブランクがあってもここまで作れるという自信がつきました。
同時に、はっきりとした壁も感じました。
顧客の顔がまったく見えないのです。
誰の何を変えられているのかを語れません。打ち手は自分の想像の中からしか出てきません。
そうしてプロダクトは頭打ちになりました。
いま振り返ると、この壁の原因は「一人で完結していたこと」でした。
自分がやった個人開発には、フィードバックをくれる顧客も、引き出しを貸してくれる専門家もいませんでした。
本業にはその両方がいます。専門家と顧客がいる環境で、一人でどこまでやれるのか。
それを確かめる場がちょうど巡ってきました。
壁2：専門領域の深いところには、AIと自分だけでは届かなかった
その頃、本業ではtoC向けプロダクトから医療機関向けのプロダクトチームに異動しました。
担当したのは、診察室の会話をその場で文字起こしして、カルテの下書きがリアルタイムに組み上がっていく機能です。チームから引き継いで現場での改善まで推進したいと手を挙げました。
実装ではAIをフル活用しました。supersetというgitのworktree機能を支援するツールで開発を並列にバンバン回し、新機能の開発と既存機能の改善と不具合修正を、複数のAIエージェントに同時に走らせて一人で捌きました。
デザインシステムのAIの社内の仕組み（skills）を使えば、ある程度のデザインも自分でできます。AIを使い倒せる環境は整っていました。
それでも、専門領域の深いところで3回つまずきました。
デザイン：デザインの情報設計は、自分からは出てこなかった
デザインの叩き台は自分で作れました。それっぽい画面はAIと組めばすぐにできます。
でも、社内のデザイナーと壁打ちして痛感したのは、自分の情報設計の引き出しの少なさでした。情報設計の本を数冊読みましたがダメでした。
たとえば、医師向けの画面は画面遷移を増やさず一つの画面で完結させるという知見です。
診察中の医師は画面をあちこち動き回れないからです。言われれば「それだ」と分かります。
でも自分一人では永遠にたどり着かなかったと思います。
エンジニアリング：2〜3週間の試行錯誤が、CTOの一晩に負けた
次の壁は音声認識の精度でした。
環境によって書き起こしが抜け落ちたり、正しくカルテ生成できないことがあるのです。いつも起きるわけではなく、手元で試すと普通に動きます。
ネットワークをわざと遅くして再現を試み、テスト用の音声を何パターンも作り込み、原因を1つ特定しては直してリリースする、という繰り返しでした。
それを2〜3週間続けても、潰しても潰しても、別の環境で別の課題が発生しました。直すこと自体はAIのおかげで速いのです。問題は、次にどこで課題が発生するかが見えないことでした。
そんな中で迎えた総合病院でのデモの評価は「60点」でした。
音声認識の品質が上がらなければリリース断念の可能性もある、とチームに共有するところまで追い込まれました。
そこでCTOのyukukotaniに助けを求めに行きました。
CTOがやったのは抜け落ちを直すことではありませんでした。音声の評価基盤を整えて、AIで改善サイクルが回り続ける仕組みを作ったのです。これは、いわゆるループエンジニアリングというものです。結果、一晩で精度が10pt以上改善しました。
2〜3週間越えられなかった壁が一晩で消えたのです。エンジニアリングの深いところは素直に頼ってよかったと思いますし、むしろ、もっと早く頼ればよかったです。
医学：医師にとって意味のあるカルテは、自分からは出てこなかった
3つ目がいちばん本質的な壁でした。カルテの項目を正しく埋める機能は作れます。
でも、どんなカルテが臨床的に良いカルテなのかは自分には分かりませんでした。
検証の場で、社内の医師がこう言いました。「情報をただ書くだけじゃなくて、後から見た人が『ああ、これは喘息だね』と分かる、ストーリーのあるカルテにしたい」。
自分が作っていたのは情報が正しく埋まるカルテでした。医師が求めていたのは思考の流れが読めるカルテでした。この差は自分一人では何ヶ月かけても発見できなかったと思います。
この一言をその日のうちにPRにすることができたのです。カルテ生成の方針そのものを、その場の課題感のまま組み直しました。従来の分業なら要望チケットになって、数週間かけて実装されていたはずのものが、当日プロダクトに乗りました。
3人の専門家が教えてくれたのは、答えは自分の頭の中ではなく、専門性の中にあるということでした。
壁3：現場を知らずに作ったものは刺さらない。だから病院に張り付いた
実は、音声認識機能を最初にもくもくと作って社内の医師に見せたとき、評価はズタボロでした。
現場を知らずに作ったものは、どれだけ速く作っても刺さらないことを実感しました。
そこで方針を変えて、現場に速く深く潜ることを最優先にしました。
セールスやカスタマーサクセス経由の情報だけで考えると、どうしても情報が欠落していくからです。
導入先の病院での現場検証に張り付きました。医師が実際に使う様子をこの目で見ると、機能の良し悪し以前の情報が集まってきます。
AIツールを使うときの心理的なハードルや、過去の説明会での失敗体験、現場での人間関係までが見えてきました。
どれも活動報告や議事録には決して載らない情報です。
個人開発で感じた「顧客の顔が見えない」の答えもここにありました。現場に潜れば、顧客の空気感が伝わってきます。
そういった情報を元にプロダクトを作り込み、最終的に、現場で「すごい」という声をもらえました。話すそばから画面に文字が現れて、診察が終わる頃にはカルテの下書きが出来上がっている状態です。AIと向き合ってもくもくと作っていた頃には決してたどり着けなかった評価でした。
専門性を軸足にした越境の衝突から、いいプロダクトが生まれる
3つの壁を並べて気づいたことがあります。デザインの情報設計の知見も、エンジニアリングの仕組みで解く発想も、医学の臨床的な観点も、全部自分一人からは出てこなかったものです。
どれも自分の専門の外側にある同僚の専門性から来ていました。
一人で作るのは速いです。
判断も実装も自分の中で完結するからです。
でもその速さと引き換えに、プロダクトが自分の想像力の範囲に閉じていきます。スピードは一人で手に入ります。でも視点の広がりは他者からしか来ません。
3ヶ月の実験結果をまとめます。一人で作れるのは7割まで。プロダクトを本当に良くする残りの3割は、専門性を軸足にした越境の衝突からしか生まれませんでした。
7割まで一人でいけること自体、数年前には考えられなかったことです。でも勝負を決めるのは残りの3割でした。
冒頭の問いに戻ります。何を作って、何を作らないか。その判断材料はAIの中にはありません。
現場の一次情報と専門家の中にあります。
理想のチームの働き方。専門性と越境する力を持っているチーム
では、結局もとの分業に戻るのかというと違うと思います。
理想は、全員が専門性の軸足と越境する足を持っているチームです。
以下のような例があると思っています
医師が医学を軸足に、コードへ越境する
デザイナーが情報設計を軸足に、現場へ越境する
エンジニアが技術を軸足に、顧客へ越境する
そしてPdMは要件定義力を軸足に、実装や顧客へ越境する
従来のリレー型、つまり「セールスやカスタマーサクセスからの情報 → 要件定義 → 作って渡す」という流れでは、専門性は縦割りの壁でした。
越境し合うチームでは専門性は軸足になります。
全員が一次情報を取りに行き、現場で思いついたものをその場で作り、自分の限界に当たったら隣の専門家の力を借りる。AIで開発が効率化して空いた時間を現場に使い、解像度が上がるから作るものの質が上がる、という循環です。
大事なのは、越境は専門性を薄めるものではない、ということです。苦手を埋めるための越境ではなく、いちばん得意な一点を最大限に活かすための越境です。私が実装まで自分で走ったからこそ、CTOへの頼みは音声の安定性まで絞り込めていました。自分の限界まで走った人の助けは一点に絞れています。丸投げと越境は違うと思っています。
PdMの役割は、翻訳して渡す調整役から、顧客解像度を軸足に作るところまで越境する人へ変わっていくと思っています。翻訳の仕事は減ります。でも、現場に張り付いてN=1の声から「これだ」というものを掴む力は、PdMがキャリアで鍛えてきた力です。
その力は、越境した瞬間にいちばん強い武器になります。
まとめ：PdMは、翻訳して渡す調整役から越境して作りきる人へ
長い記事をここまで読んでいただきありがとうございます。キーワードをまとめておきます。
一人で作れるのは7割まで。勝負を決める残りの3割は、専門性を軸足にした越境の衝突からしか生まれない
AIは正しいものを作るのも速いが、間違ったものも一瞬で作る。動くものが一瞬でできるからこそ、間違いに気づくのが遅れる
スピードは一人で手に入る。でも視点の広がりは他者からしか来ない
答えは自分の頭の中ではなく、同僚の専門性の中にある。
現場を知らずに作ったものは、どれだけ速く作っても刺さらない。
PdMはこれから、翻訳して渡す調整役から、顧客解像度を軸足に作るところまで越境する人に変わっていく
プロダクトビルダーという新しい働き方
ユビーでは、医療ドメインの不確実な現場に自ら入り、AI と自分の手で、end-to-end で顧客やユーザーに対しての価値を提供し続ける人として、プロダクトビルダーを定義しています。
まだ道半ばですし、この働き方が組織でどうスケールするかも検証中です。
どこまで自分で手を動かし、どこから専門家と組むべきかという線引きも模索の真っ最中です。
それでも、これだけは確信を持って言えます。
現場で掴んだ「これだ」と思ったものが劣化せずにそのままプロダクトに乗り、現場で「すごい」と言われる瞬間の手応えは、一度味わうともう戻れません。
めちゃくちゃ楽しいです。
医療現場には、ドメインに潜らないと見えない課題が山ほど眠っています。
PdM・エンジニア・デザイナー・医師、自分のコアの専門性を軸足に、顧客価値まで越境してみたい人や、職種という枠を窮屈に感じている人に、ぜひ来てほしいです。まだチャレンジの途中だからこそ、一緒に試行錯誤できる仲間がほしいです。
この楽しさを一緒に味わいましょう。
我々の専門性はどこまで越境できるでしょうか。「その働き方、やってみたいかも」と思ったら、まずは採用ページを覗いてみてください。
