エンジニアとPdMの仕事は、そんなに違わないかもしれない。何気ない一言から広がった、チームの話
こんにちは。株式会社XAION DATA 開発本部 データプラットフォーム部 エンジニアの髙橋です。
日々、PdM（プロダクトマネージャー）と連携しながらプロダクト開発を進める中で、ある朝の通勤中に、ふと「エンジニアとPdMの仕事は、実はそれほど違わないのでは？」という問いが頭に浮かびました。この何気ない気づきを社内のSlackに書き込んだところ、役割をこえた議論が広がっていきました。
今回は、その対話をきっかけに考えた、エンジニアとPdMの関係性や、チームでプロダクトをつくることについてお話しします。
※本記事は、XAION DATA Tech Blogの「エンジニアとPdMの仕事は、そんなに違わないかもしれない」を一部編集のうえ再掲載したものです。
通勤中にふと思ったこと
ある朝、通勤しながらこんなことを考えていました。
「エンジニアとPdMの仕事って、実はそんなに違わないんじゃないか？」
エンジニアは設計や実装を通じてプロダクトを形にし、PdMはクライアントや事業部門との対話をもとに、解くべき課題や優先順位を整理する。担当する作業は違うように見えます。しかし、「ユーザーの困りごとを言語化して、その解決策を考える」 という真ん中の部分は、両者で共通しているように思えたのです。
ベン図で描くと、重なっている範囲がかなり広いということです。この見方をする大きな利点は、PdMが「機能の発注元」ではなく「一緒に価値をつくる仲間」として、より明確に見えてくることだと思います。そしてそれは、結果的に自分の仕事をしやすくしてくれる気がしています。
この思いつきを、社内Slackに何気なく書き込んでみました。すると、すぐに同僚から反応があり、そこから思いのほか、議論が盛り上がっていったのです。1人のつぶやきが、いつのまにかチームの対話になっていきました。本題に入る前に、まずはこの「盛り上がり」がこの記事の出発点だったことを書いておきたいと思います。
「仕事をくれる人」ではなく「一緒に課題を解決する仲間」
PdMを「要求を渡す人」、エンジニアを「その要求を実装する人」とだけ捉えてしまうと、両者の関係が一方向になり、要求の背景や目的が見えにくくなります。一方で、PdMを「一緒に課題を解決する人」と捉えると、要求の背景にあるユーザーの課題や、実現したい価値を共に考えられるようになります。
これはスクラムの考え方とも重なります。スクラムでは、PO（プロダクトオーナー）はスクラムチームの一員として、プロダクトの価値を最大化する責任を担います。PdMもまた、開発者に要求を渡すだけの存在ではなく、同じゴールに向かってプロダクトの価値をともに考える仲間だと、私は捉えています。
プロダクトは「価値があると信じられている仮説」の総称
私自身、エンジニアとして経験が浅かったころは「PdMが整理した要求を、エンジニアが実装する」という関係を当たり前のように捉えていました。しかし、PdMが提示する内容も、最初から正解が決まっているものではありません。「ユーザーのこの課題を解決するには、この機能が有効なのではないか」という仮説をもとに、開発の方向性を考えています。
ここで、同僚との雑談でとても刺さった一言がありました。
「昔スクラムマスターの研修で、『プロダクトとは、対象に価値があると考えられている仮説の総称』と教わった」
プロダクト＝仮説の総称、という捉え方をすると、いろいろなことが腑に落ちます。要求の裏にある仮説を、エンジニア側も一緒に考えるとPdMも楽になるし、もしかしたら本来は必要のなかった開発を減らせるかもしれません。「言われたからつくる」から「価値の仮説を一緒に磨く」へ見方が変わると、貢献できる範囲もぐっと広がります。
仮説を「小さな単位」で扱うと何が嬉しいか
この仮説検証のプロセスを、エンジニアとPdMがチーム一丸となって回していくうえで、ユーザーへの価値につながりそうな仮説をより小さな単位で定義すると、こんなメリットがあると考えています。
認識の齟齬が減る：エンジニアとPdMを含む全チームメンバーの間で、仮説に対する理解のズレを減らせる
スピード感が上がる：1つの仮説を実現するまでが速くなる → 検証して、次の仮説に移れる
時代の変化についていきやすい：小さく速く回せるほど、外部環境の変化に追従しやすくなる
特にAIの台頭でプロダクトを取り巻く前提がどんどん変わっていく今、「小さく仮説を切って、速く検証する」ことの価値はますます高まっていると感じます。
1つの書き込みから、チームの対話へ
ここまでは、エンジニアとPdMの関係について、私自身が考えたことを書いてきました。ただ、こうした気づきは、自分の中だけから生まれたものではないのかもしれません。過去に誰かが投げかけてくれた言葉や、さまざまな場所で触れてきた考え方が自分の中に残り、あるとき1つの気づきとして形になったようにも思います。
今回も、「エンジニアとPdMって似てない？」という社内Slackへの何気ない書き込みから、思いがけず議論が広がっていきました。あるメンバーからは「プロダクトとは仮説の総称」というスクラム研修の話が共有され、別のメンバーからは、これまでの経験をもとにした意見が寄せられました。気づけば何人ものメンバーがそれぞれの経験や知見を持ち寄り、スレッドはどんどん伸びていました。1人ではたどり着けなかった考えも、メンバーとの対話を通じて少しずつ形になっていきました。
余談：データの世界でも同じ動きが
ところで、この「役割の境界がにじんでいく」流れは、エンジニアリングに限った話ではなさそうです。
データサイエンスの領域でも、エンジニアが「データを出す人」から「一緒に分析する人」へ変わっていく動きが見られます。たとえば食べログのテックブログでは、AIエージェント（Devin）と協働してデータ分析を進める取り組みが紹介されています。
道具やロールが変わっても、「課題を一緒に解く」という本質は変わらない。むしろその本質がより前面に出てきているのだと思います。
*参考: Devinと協働するデータ分析（食べログ Tech Blog）
おわりに
エンジニアとPdM、役割の名前は違っても、向かっている先は同じです。
お互いの立場を「要求する側と実装する側」ではなく、「課題を一緒に解決する仲間」として捉え直すこと。要求の裏にある仮説を一緒に磨くこと。そして、意見を共有し合いながら、考えを深めていくこと。今回のカジュアルなチャットを通じて、そうした対話の面白さを実感しました。小さな視点の転換から、チームが見る景色が変わるかもしれません。
そして、こういう議論が何気ないチャットから自然に立ち上がる空気が、私は好きです。役割の垣根をこえて課題を一緒に解くことを楽しめる仲間が増えたら、さらに面白くなりそうです。
組織の拡大に伴い、積極採用中！
私たちは「AI × DATAで世界中の価値を最大化する」というミッションに共感いただける仲間を積極的に募集中です。まずはカジュアルに話を聞いてみたいという方も大歓迎です！ぜひ、弊社の採用サイトをご覧ください。
皆様とお話しできることを楽しみにしております！
