エンジニアとPdMの仕事は、そんなに違わないかもしれない

通勤中にふと思ったこと

ある朝、通勤しながらこんなことを考えていました。

エンジニアとPdM（プロダクトマネージャー）の仕事って、実はそんなに違わないんじゃないか？

エンジニアはプログラムを書き、PdMはCSチームやクライアントと話す。担当する作業は違うように見えます。しかし、、「ユーザーの困りごとを言語化して、その解決策を考える」 という一番真ん中の部分は、両者で共通しているように思えたのです。

ベン図で描くと、重なっている範囲がかなり広いということです。この見方をする大きな利点は、PdMが「機能の発注元」ではなく「味方」に見えてくることだと思います。そしてそれは、結果的に自分の仕事をしやすくしてくれる気がしています。

この思いつきを、自分のtmチャンネル——タスクの状況共有から、ちょっとした相談までゆるく投げられる個人チャンネル——に何気なく書き込んでみました。すると、すぐに同僚から反応があり、そこから思いがけず議論が盛り上がっていったのです。一人のつぶやきが、いつのまにかチームの対話になっていきました。本題に入る前に、まずはこの「盛り上がり」がこの記事の出発点だったことを書いておきたいと思います。

「仕事をくれる人」ではなく「一緒に課題を解決する仲間」

PdMを「仕事を与えてくる人」として見ると、どうしてもストレスが溜まります。降ってくる要求をこなす側、という構図になってしまうからです。

一方で、PdMを「一緒に課題を解決する人」として見ると、ずいぶん気持ちが楽になります。

これはスクラムの考え方とも一致します。スクラムでは PO（プロダクトオーナー / PdM）はスクラムチームの一員として定義されていて、開発者と同じ方向を向いている仲間という位置づけです。組織図の上では分断されがちなので前者のような見え方になってしまいがちですが、理想は同じチームメンバーとして、常に連携して同じゴールを達成する仲間でいられること。視点ひとつで、関係性の捉え方は大きく変わります。

プロダクトは「価値があると信じられている仮説」の総称

エンジニア駆け出しのころは、「PdMが要求したものをつくる」というトップダウンの主従関係に、なんとなく慣れてしまいがちです。

でも実際には、PdMは完璧ではありません。彼らは「ユーザーのこのペインを解決するには、この機能が良さそうだ」という仮説を立てて、機能開発の要求をしています。

ここで、同僚との雑談でとても刺さった一言がありました。

昔スクラムマスターの研修で、「プロダクトとは、対象に価値があると考えられている仮説の総称」と教わった

プロダクト＝仮説の総称、という捉え方をすると、いろいろなことが腑に落ちます。

要求の裏にある仮説を、エンジニア側も一緒に考えるとPdM も楽になるし、もしかしたらやらなくてよかった開発を未然に減らせるかもしれません。「言われたからつくる」から「価値の仮説を一緒に磨く」へ見方が変わると、貢献できる範囲もぐっと広がります。

仮説を「小さな単位」で扱うと何が嬉しいか

この仮説検証のプロセスを、PO＋Dev を合わせたチーム一丸で回していくうえで、ユーザーの価値となりそうな仮説をより小さな単位で定義すると、こんなメリットがあると考えています。

• 認識の齟齬が減る：PO＋Dev を含む全チームメンバーの間で、仮説に対する理解のズレを減らせる
• スピード感が上がる：1つの実現までが速くなる → 検証して、次の仮説に移れる
• 時代の変化についていきやすい：小さく速く回せるほど、外部環境の変化に追従しやすくなる

特に AI の台頭でプロダクトを取り巻く前提がどんどん変わっていく今、「小さく仮説を切って、速く検証する」ことの価値はますます高まっていると感じます。

この考え方を、どうやって広げるか

ここまでは個人の心構えの話でした。では、こうした考え方をチームや組織に広げるにはどうすればいいのか。

正直なところ、最初は 他人の考え方を直接変えるのは難しい と感じていました。自分自身を振り返っても、誰かに言われて変わったというより、「この考え方がいいかも」と試してうまくいったり、失敗して反省したりする中で内側から変わってきた——きっかけは、たいてい内側から来るものだと思っていたのです。

でも、まさにこの点を同僚と話す中で、見方が少し変わりました。「直接相手を変えることはできなくても、種をまくことはできる」という指摘です。

言われてみれば、内側から湧いたように感じる「気づき」も、過去に誰かが投げかけてくれた言葉や、いろいろな場所で触れてきた考え方がどこかに刷り込まれていて、あるとき芽を出したものなのかもしれません。だとすれば、いきなり天から降ってきた発想などなく、誰かがまいた種が時間をかけて育っている、ということになります。そう考えると、直接の説得そのものより、「種をまく」こと——情報発信や日々の対話の積み重ね——にこそ意味がある と思えてきました。次の誰かの「気づき」のために、種をまくのです。

そしてその種まきは、組織やチームとしてなら、より意図的に——「影響を与える」かたちで設計することもできるはずです。手段は大きく2つあると整理しています。

1. 強制力をつくる

会社の Value、チームの KPI、人事評価の軸といった仕組みに組み込むことで、会社が向かいたい方向への成長を後押しする方法です。

評価制度の例として Google の話が議論で挙がりました。Google の人事評価は 「WHAT（何を成し遂げたか）」と「HOW（どうやって成し遂げたか）」の2軸で見られていて、どれだけ素晴らしいインパクトを出しても、HOW が職位に期待される振る舞いでないと評価は上がりきらない、という設計になっているそうです。さらに個人レベルの OKR に、伸ばしたい行動（Development Area）を明示的に組み込む、といった運用もあります。

• 参考: Google's Performance Management Playbook

2. カルチャーをつくる

もう一つが、メンバー間のカジュアルな会話からカルチャーをつくっていく方法です。

前述の通り、この記事のもとになった議論自体、コーヒーチャットでのちょっとした雑談から生まれたものでした。「エンジニアとPdMって似てない？」という一言を Slack に投げてみたら、これが思いのほか盛り上がりました。

別のメンバーから「プロダクトとは仮説の総称」というスクラム研修の話が飛び出し、また私は「PdM も同じチームメンバーとして同じゴールを目指す仲間だ」と語り、さらに前職で大企業のマネジメントを経験したメンバーが Google の評価制度の話を持ち込んでくれました。気づけば何人もが自分の経験や知見を持ち寄って、スレッドはどんどん伸びていきました。

誰かに指示されたわけでもなく、こうした議論がナチュラルにコーヒーチャットや Slack で発生し、スレッドが続いていく——評価や KPI のような「強制力」だけでなく、こうした日常の会話の積み重ねこそもじわじわと組織に影響を与えていくのだと思います。盛り上がれる場があること自体が、すでに一つのカルチャーなのかもしれません。

XAIONDATAでの実践

弊社XAION DATAでも、Value の体現（Value Embodiment）は評価の観点に組み込まれています。組織的なインセンティブを設計することで、メンバーの成長を会社が求める方向へ促せる、という発想です。

また、「エンジニアのカスタマー意識を育てる」という観点では、開発チーム自身が自社プロダクトの本物のユーザーになることで、圧倒的なユーザー視点の獲得と品質向上を目指す、といった取り組みも進めています。いきなり「全員にユーザー視点がつく！」というものではありませんが、少しでもそのきっかけになることを期待しています。

余談：データの世界でも同じ動きが

ところで、この「役割の境界がにじんでいく」流れは、エンジニアリングに限った話ではなさそうです。

データサイエンスの領域でも、エンジニアが 「データを出す人」から「一緒に分析する人」へ変わっていく動きが見られます。たとえば食べログのテックブログでは、AI エージェント（Devin）と協働してデータ分析を進める取り組みが紹介されています。

• 参考: Devinと協働するデータ分析（食べログ Tech Blog）

道具やロールが変わっても、「課題を一緒に解く」という本質は変わらない。むしろその本質がより前面に出てきているのだと思います。

おわりに

エンジニアとPdM、あるいはデータを出す人と分析する人——役割の名前は違っても、向かっている先は同じです。

立場の違いを「主従」ではなく「協働」として捉え直すこと。要求の裏にある仮説を一緒に磨くこと。そして、意見を共有し合いながら、より高い次元へと進んでいくこと。いわばアウフヘーベンに近いものを、カジュアルなチャットを経験した気がします。

小さな視点の転換から、チームが見る景色が変わるかもしれません。

そして、こういう議論がコーヒーチャットから自然に立ち上がる空気が、私は好きです。役割の垣根を越えて「課題を一緒に解くこと」を楽しめる仲間が増えたら、もっと面白くなりそうです。