PjMからPdMになって始めたこと、辞めたこと

久しぶりの投稿！あれこれ書きたいネタは溜まっていたものの、タイミングを逃して年末になってしまいました。

今回は、プロダクトマネージャーのアドベントカレンダー2021 をきっかけにして再開。17日目の記事を担当します。

プロジェクトマネージャーとプロダクトマネージャー

さて、皆さんは「PM（ピーエム）」と聞いた時、プロジェクトマネージャーとプロダクトマネージャーのどちらを想像しますか？

ほんの1年前まで、私は圧倒的に前者の「プロジェクトマネージャー」しか想像できていませんでした。

---

• プロジェクトマネージャーは「When（いつまでに）」「How（どうやって作るのか）」を考える
• プロダクトマネージャーは「What（何を作るのか）」「Why（なぜ作るのか）」を考える

---

どのサイトでも再三言われていますが、プロジェクトマネージャーとプロダクトマネージャーそれぞれの職業の違いは上記のように定義されることが多いです。

昨今のIT業界では、新しい職能として「プロダクトマネージャー」が浸透しつつあり、元々プロジェクトマネージャーの意味での「PM」だった人が、プロダクトマネージャーとしての「PM」にキャリアチェンジ（キャリアアップというべきか？）する事例も増えているように感じます。

今後も益々重要なポジションになってくるであろうPjM→PdMという流れについて、実際の業務ではそれぞれどのような価値観を持ち、どう関係性を構築して職務にあたっているのか、今回はそのどちらも経験した身として、自身に起きた変化をまとめてみたいと思います。

PjMからPdMへ、思考・行動の変遷

はじまりはプロジェクトマネージャー

私がプロジェクトマネージャーの業務に触れ始めたのはSIer時代。エンジニアとして参画していた開発プロジェクトでPM不在となるタイミングがあり、代理でPM業務をし始めたことがきっかけでした。

それから何度かプロジェクトでマネジメント職を経験するも、あくまでそれは「ソフトウェア開発プロジェクト」という限定された範囲のPMです。ソフトウェアの枠を超えて外にある世界（サービスがどう販売されるのか、ユーザーはどんな風に使うのか）については関心を持てていたとは言えません。

その後、私は一時期マーケティング部署の立ち上げをしたり、自社サービスの戦略から考えたりする管理職についていた時期がありました。

会社の収益や他事業とのシナジーを考慮した施策を打ち、機能に反映したり広告を出してみたり… 今思えば、あれがプロダクトマネジメント思考の触りだったとも言えますが、当時(2016年頃)は周囲で「PdM」という役割すらあまり聞かなかったように思います。

そうこうして自分で会社を立て、独立したものの、あくまでプロジェクトマネージャーという意味での「PM」であると自覚をして、開発プロジェクトに従事してきました。

プロジェクトの外のスコープへ

この感覚に変化が訪れたのはコロナ禍に入ってから。

緊急事態宣言を受けた世間では、それまでオフラインで営まれていた事業を持つ企業の状況が一変し、これまで関わっていた取引先とは毛色の違う、様々な業界(非IT事業)からDX推進の依頼や経営視点からのIT事業づくりを求められることが増えました。

そうしてようやく、これは単なるプロジェクトマネジメントでは太刀打ちできない、と感じてプロダクトマネジメントの存在、役割を意識し始めることになるのです。

余談ですが、やはり「プロダクトマネジメントのすべて」は最初に読みたいバイブルです。 まず取り組むべき業務の全体像を効率的にキャッチアップできました。

プロダクトマネージャーになり、始めたこと

ここから本題ですが、思っていた以上にPjMとPdMの役割は別物でした。もちろん重なる部分も多々ありますが、注力すべきスキルは違ってきます。
特に、スコープの決まった中で成功に導いていた頃のPjM業務とは違い、PdMとしては終わりも正解も見えない闇の中を手探りで掘り進めていく感覚がありました。

そんな中で、なんとかプロダクトの指標を求めるべく始めた主な行動を以下に紹介します。

ユーザーとの対話

プロダクトを育てる最初のステップは、兎にも角にもユーザーヒアリングです。そもそも誰も使いたいと思っていないプロダクトでは、作る意味がありません。 まずは、誰かの課題を吸い上げること、その誰かのために作ってみること、を意識して、その繰り返しによって少しずつプロダクトの道筋がクリアになってきました。

ユーザーヒアリングの細かいTipsは今回紹介しませんが、弊社で副業もしてくれている津田さんが以前記事を書いているのでそちらもぜひご覧ください。

効果的なユーザーインタビューを設計する4つのステップ

マーケット調査・分析

これもPjMの時にはやっていなかった業務のひとつです。

システム開発としてのPjMでは、すでに作るものは決まっている前提で要件を整理したり実装の具体的なタスクを切っていく、ということがメインでした。作るものを依頼されてから開発チームで市場調査するなんてことはなかったと思います。

ですが、不確実性の高い新規事業やDX推進となると、闇雲に突発的なアイデアを実装してしまうのはリスクしかありません。

内部で出たアイデア、ユーザーからヒアリングできた課題を元に、それが本当に市場価値あるのか？ビジネス的な視点で分析するフェーズが必須となりました。

プロダクトマネージャーになり、辞めたこと

先に話した通り、PjMとして担当していた業務とは求められることが異なるPdM。当然、やらなくなった業務も出てきます。もちろんこれらが必要ないということではなく、PdMという立場では注力しなくなった点、という意味です。（兼任する場合はやっているし、ほとんどの場合は役割分担します）

細かい進捗管理

毎日朝会で全員のタスク詳細を確認したり、誰が何時間作業しただのの稼働管理を手放しました。

最初こそ不安もあり、ちょくちょく進捗管理表を覗いてしまうこともありましたが、その時間にPdMとしての生産性はありません。

PdMとしてチェックするのは、ユーザーにどんな価値をいつ届けられるか、その時期にどういうインパクトがあるか、という大きなマイルストーン軸のみとなりました。

技術仕様の調査・設計

エンジニア出身PMならではかもしれませんが、これまではタスクに落とす前にある程度の技術要件まで自分で想定してしまうことがありました。その上で「こういう設計方針でいくと良さそうだけど」と半ばトップダウンで実装に落とし込んでしまう節もあったと思います。

PdMとしては、実際の細かな技術仕様よりも、現状の開発リソースでの実現有無や、リリース後のランニングコスト含めた収支観点、仮説検証する上での機能としての柔軟性のほうが大切になりました。

餅は餅屋というくらいなので、技術のことはエンジニアを信頼して相互に話し合いながら進めるのが一番です。

PjMもPdMも、両方大事

ここまで、PjMとPdMにおける思考や行動の違いをピックアップしてみました。

これは私の持論ですが、プロジェクトマネジメントもプロダクトマネジメントも、背景にある価値観は違えど相互理解しておく必要のある領域だと思っています。

大きなプロダクトには小さなプロジェクト群で行われる様々な施策が必要であるし、一つ一つのプロジェクトが成り立ってこそプロダクトの成長につながるわけで、どちらの職能もおざなりにはできません。

常に人材不足が取りだたされるIT業界特有の難しさもあるわけで、個人的にはエンジニア出身PM（PjMでもPdMでも）は今後もすごく価値が高まると考えています。

最後に突如宣伝のような紹介にはなりますが、そんなIT業界の現役PM、これからPMを目指す皆さん両者に向けた無料の開発PM勉強会も開催していますので、関わるプロジェクトを、プロダクトを、より良くしていきたい皆さんはぜひ次回の参加お待ちしております♪

https://peer-quest.connpass.com/event/