プロダクトマネージャー(PM)の役割とは

先日ブログに書いた「ピボタルでの1日(午前編)(午後編)」。終日取材を通して感じたのは、プロダクトマネージャー(PM)が非常に重要な役割を果たしているということだ。ただ、PMが具体的にどんな役割を担い、どんな資質を持っている人が向いているのか、大事なポジションだけにもっと詳しく知りたい・・・そんな思いを“Ninjya Cat”のPMのひとり、YUIさんにぶつけてみると、「PMの役割を語る前に、まずはデザイナーとエンジニアの役割から説明しましょうか」と笑顔で話を始めてくれた。

PM、UXデザイナー、エンジニアは三位一体

まず、UXデザイナーには、ビジュアルデザインだけでなく、情報整理の仕方や情報の見せ方といったことから、プロダクトをつかったユーザー体験のストーリー(UI/UX)を描くところまで、システムにおける事案も含めた全体のデザインをすることが求められます。常にユーザー側に立ち、ユーザーにとって最適な解はなにかを考え続けるのがUXデザイナー。だからこそ、PMとともにプロダクトをつくる前にしっかりとペルソナを想定し、実際にユーザーインタビューを重ねながらユーザーにとって何が必要なのかを考え続けることが非常に重要となるんです。

一方、エンジニアには、コードをきれいに、きちんと書くことが求められる。「システム的に、シンプルでつくりやすいものをつくること」がなによりも重視され、仮にPMとUXデザイナーがいいと思うことであっても、エンジニア目線では実現までに膨大な時間がかかる、というような時には、ビジネス側が意図しているものを汲み取り、システム的に実現可能な解決策を提案することが求められるんです。そのためにも、「エンジニアがそもそもなぜそのプロダクトをつくるのかを理解している」ことが非常に重要。だからこそ、エンジニアは受身でも独りよがりでもなく、PMとUXデザイナーとタッグを組んで、プロダクトをつくっていかなければならないんです。そして、プロダクトをつくるためのペースキーピングや品質管理を担うのがPMなのです。

そして、PMの役割はおおきくふたつあります。ひとつは、みんなが「チーム」として上手く動けるように先導する、チームにとっての“羊飼い”的役割。そしてもうひとつは、数字的なところや、何をやるとどいうビジネスインパクトがあるかといった「ビジネスニーズ」をチームに対して一番強く主張するという“ステイクホルダーの代表”としての役割です。

(YUIさん談)

PMの仕事は何もはっきりとしたことがわからないという状況の中で、より“正しそう”な方向、もしくは“間違ったとしてもすぐ戻れる小さい単位”でどうにか一歩ずつチームを前に進めていくこと

一般的なIT企業では、

①テクニカルプロジェクトマネージャー(仕様を決める人のことで「エンジニアリングマネージャー」や「テクニカルキーパー」と呼ばれることもある)

②ビジネスアナリスト

③スクラムマスター(進捗管理)

という3つの役割に分かれていることも多いが、それらの役割をPMがすべて担っているので、PMに必要とされる知識や関わる領域は極めて広い。それゆえ「持つべき知見は広く浅く、専門分野は必要な人(エキスパート)に助けを求めて連携できる人でなければならない」とYUIさんは語る。

また、 PMになるためには、エンジニアのバックグラウンドが必要なのでは?と思われがちだが、実はそうではない。むしろ必要とされるのは、他者への共感力やコミュニケーション能力、そしてバランス感覚だ。PMの仕事は何もはっきりとしたことがわからないという状況の中で、より“正しそう”な方向、もしくは“間違ったとしてもすぐ戻れる小さい単位”でどうにか一歩ずつチームを前に進めていくこと。正しくないかもしれない決断をしなければならない状況で、先入観を捨て、物事の本質を見極められる力が求められるので、深すぎる専門知識はときに思い込みや考えすぎにつながり、正しい解を導く邪魔をすることがある。

いわゆるアジャイル的なアプローチ(アジャイル=正しいプロセス、より効率的なプロセスでものを作る手法)も、それだけでは正しいものは作れず、場合によっては「正しい方法で“う●こ”」(YUIさん談)をつくってしまうこともある。そういうことを起こさないために、仮説を検証して、リスクを減らしていく役割を担うのがPMであり、クライアントから成果物に対する要望や理想形をヒアリングしたあとにも、それに引っ張られずに仮説を立て、実験的に考えていく力が問われる。そして、クライアントが望む機能がその先にいるユーザーにとって本当に必要なのかをテストすることや、それに対して優先順位をつけることをきちんと伝え納得させる力がなければ、PMとは言えないのである。

チームとして最高のパフォーマンスを目指す “Shared Ownership” 精神

そして、なにより大切なのは「チームとして」最高のパフォーマンスを目指すことだというのは、YUIさんに限らず、Pivotalで働くメンバーは皆、口を揃えて教えてくれた。PMもデザイナーもエンジニアも、誰かひとりがスタープレーヤーになるのではなく、チームとしてワークするやり方を模索する、“Shared Ownership”という精神のもと、オーナーシップをみんなで持ってみんなで進めていくという、というのがPivotalの考え方の真髄なのだ。だからこそ、チームひとりひとりがより良い決断、意思決定ができるように情報共有がなされているかなどまで細かくケアするのがPMの務めであり、そのような点からも、知識より先に、決断力とバランス感覚、そしてチームに頼れる信頼力が求められるのである。

自分のことを棚にあげて、ちょっとかっこいいこと話しすぎちゃったかな~」と笑顔を浮かべるYUIさん。詳しいお話、本当にありがとうございました!!

Related Posts