はじめに
私たちの開発組織では、プロダクトマネージャー（PdM）とプロダクトエンジニア（Dev）の役割を分業にせず、一人のエンジニアがプロダクトマネジメントとプロダクト開発の両方を担う働き方を実践しています。Netflixが提唱するフルサイクル開発者や、Atlassianのプロダクトエンジニアの考え方をさらに広げ、プロダクトマネジメントまで踏み込んだ働き方であり、プロダクト開発のすべてに関われるという究極の形と言えるかもしれません。
2年ほど運用してみましたが、タフな面も多いものの、AI時代におけるキャリアアップの選択肢として魅力と手応えも感じています。この記事では、少数の組織だからこそできる、その実践から学んだことの楽しさ・大変さの両面をざっくばらんにお伝えします。
なぜこの働き方が生まれたのか
PdM/Dev分業で起きていた課題
Biz対Dev、Dev対Opsなど、異なる立場で働く人の間で対立構造が生まれることは、世の中的によくある話のようです。
今回の本題であるPdM（プロダクトマネージャー）とDev（開発）についても、過去に私たちの会社では組織・役割を分けていたのですが、プロダクト開発を進める中で対立が何度かありました。
Devの立場では「社内受託化」の傾向が強くなりました。「社内受託化」とはその名の通り、社内の「誰か（具体的にはPdM）」から依頼されたものを作るだけの状態です。この傾向が進むと、「PdMが決めたことだから」という責任転嫁の構造が生まれやすく、プロダクトへのオーナーシップが薄れてしまいがちでした。
一方でPdMとしては、営業やマーケティングから「この機能を早く作ってほしい」、カスタマーサポートから「ユーザーの声をもっと反映してほしい」などの声を受けて、開発とビジネスの板挟みになり、組織の中での居場所を見失いやすく、ともすれば孤立化しやすい構造になりがちです。
PdMとDevのどちらも「サービス・事業を大きくしたい」「カスタマーサクセスを実現したい」「社会に貢献したい」といった思いは一緒です。にも関わらずそうした対立が発生するのは、両者が負う役割の性質上、その視点と責任範囲が異なることが一因であると考えています。
PdMは、未来と機会の最大化に焦点を当てます。市場のニーズや理想的な顧客体験を見据えた未来志向の視点からプロダクトを牽引します。一方、Devは現実とリスクの最小化に焦点を当てます。「現実的なリソースやスケジュールでどう実現するか」という技術的な実現可能性や「使われないものを作ることは避けたい」という投資対効果の観点から、現実志向でプロダクトの実現性を担保します。
AI時代の変化が加速させた必要性
上記のような対立をなくして建設的にPdMとDevがプロダクト開発を進めるために「プロダクトエンジニア」という役割がよく知られるようになりました。プロダクトエンジニアは、顧客・プロダクト・事業ドメインを深く理解し、オーナーシップを発揮するエンジニアです。
プロダクト開発において「プロダクトエンジニアであれ」というスタンスは重要ですが、AIの急速な普及が追い風となり、PdMとDevを分ける意義にも変化がきているように思います。
非エンジニア、PdMだけでプロトタイプを作れる時代になり、ドキュメントベースの企画書ではなく実際に動くプロトタイプがプロダクト開発の起点となるケースも増えています。こうした状況で役割が分断されていると、一層社内受託化が進むリスクがあると感じています。
また開発者としては、AIをうまく活用することでプロダクトの開発の大幅なショートカットが可能になりました。人間はAIが苦手とするような領域に時間を使うようになってきており、顧客の声や商談の状況を踏まえて「こういった機能があればよいのでは」という企画的思考などが求められるようになってくるものと考えています。
そうした状況を受けて、PdMとDevを兼任するような働き方を実践・運用することにしました。
私たちの会社では、エンジニアから転身してPdMになるケースがほとんどです。PdMであっても一定の開発経験がある人ばかりだったので、スキルセット的にはPdM/Dev兼任が行いやすい土壌が整っていたという事情があります。
PdM/Dev兼任の強み
実際に運用してみて、いくつかのメリットを感じています。
腹落ち感とオーナーシップ
課題の発見から開発、リリース、結果の分析まで一貫して担当することで、プロダクトへの責任感とモチベーションが最大化されます。「なぜ作るのか（Why）」から「どう作るか（How）」まで自分ごとになるため、深い学びと開発の面白さにつながると感じています。
必然的に顧客の生々しい声や現場の温度感を直接感じながら開発することにもなるので、従来のPdMとDevの間の情報伝達や認識のズレが最小限に抑えられることもメリットです。
また組織設計の観点で、目標設定の納得感も生まれます。リリース数や不具合数を定量目標とした場合、アウトカムを見失ったりビルドトラップに陥りやすくなりますが、顧客に価値提供できるアウトカムの最大化を目標として、プロダクト開発を進めることができるようになります。
意思決定の迅速化と精度向上
フィードバックループが開発チーム内で完結し、デプロイまでの時間の短縮が可能になりました。
個々のエンジニアが広範囲をカバーすることで、コストを抑えつつ、新規事業や新機能の仮説検証を少人数で高速に回すことが可能になります。
小さな課題であれば自分で実装し迅速に解決できるのも、ストレスが少ないと感じています。
ソフトウェアライフサイクル全体の最適化
部分最適ではなく、課題発見から運用まで全体を俯瞰することで、真のボトルネックを解消できます。半年〜2年のロードマップを踏まえ、直近の開発設計が将来的なボトルネックにならないかを考慮しながらコードを書けるのも、中長期的には大きな価値があると考えています。
PdM/Dev兼任の弱み
一方で、この働き方にはタフな側面も確かに存在します。
認知的負荷の増大・切り替えコストの高さ
プロダクトマネジメントと開発の両方を考え続けることは、想像以上に頭を使います。PdMとエンジニアの両方の責任を負うため、タスク過多になり、優先順位付けが難しく、何かを諦めざるを得ない状況も出てきます。
また状況や時期に応じてPdMとエンジニアの業務割合は変動するため、コンテキストスイッチが頻繁に発生します。集中して没頭できる状態できる時もあれば、割り込みだらけの環境になることもあるのが正直なところです。
短期思考に陥るリスク
顧客の真のニーズよりも、技術的な面白さや実装の容易さを優先した設計になりがちというリスクがあります。「作れるもの」や「工数がかからないもの」に流され、「顧客にとって何が理想か」という本質的なPdMの視点がおろそかになりやすいのは、常に意識しておく必要があると感じています。
権限とタスクの抱え込み
自分でやった方が早いとタスクを抱え込みがちになり、PdMとして必要な「顧客の解像度を高める」「競合を深く理解する」「事業計画からの逆算で考える」といった外部に向かう思考の時間が不足することもあります。
UI/UXに対する全体最適性の欠如
機能単位でオーナーシップがバラバラ担っている場合、全体視点でのデザイン統制や顧客体験の一貫性をチェックする時間が不足し、プロダクト全体として見たときに、機能間のつながりが断絶したり、類似の機能が重複して開発されたりする懸念があります。
結果としてユーザーは一貫性のない、わかりにくい体験を強いられることになります。
これは、部分的な機能の完成度が高くても、プロダクト全体としてのユーザー価値を損なうことにつながります。
おわりに
PdMとDevを兼任する働き方はタフであり、ともすればデメリットの方が大きくなるでしょう。
しかし、AI時代において、技術だけでなくプロダクト全体を見渡せるエンジニアの価値は今後ますます高まっていくと思います。課題発見から実装、検証まで一気通貫で経験することは、エンジニアとしての成長において他では得難い学びをもたらします。
というわけで、万人に勧められる働き方ではありませんが、成長を求め、プロダクトの成功に本気で向き合いたいエンジニアにとって、PdM/Dev兼任は魅力的な選択肢の一つと言えると思います。
Discussion