【CEDEC 2017】プロダクトチームの「糊」となる―プロダクトを成功に導くプロダクトマネージャーの仕事術とは？

フリーランスのプロダクトマネージャー・及川卓也氏。

プロダクトマネージャーとは、ひと言でいうと「プロダクトの成功に責任を持つ人」のことをさしている。プロダクトチームには、エンジニアやマーケティング、広報、サポートなど、様々なチームが含まれている。それら全体の面倒をみるミニCEO的な役割を担っているのだ。

「PM」とも略されるこの多いこのプロダクトマネージャーだが、会社によっても異なる呼称や略称で呼ばれることがある。たとえばMicrosoftでは「プログラムマネージャー」と呼んでいる。また「PM」と略すと「プロジェクトマネージャー」や、総理大臣と間違えられてしまうことがあるという。本セッションでは、以降プロダクトマネージャーのことを「PM」と略して表記している。

プロダクトマネージャーは、「何を」「いつ」「なぜ」作るかに責任を持つ。実際にもの作りを担当するエンジニアは、「どのように作るか」に責任を持つ。さらにエンジニアリングマネージャーと呼ばれる職種があり、こちらは強いエンジニアリング組織を作ることに責任を持つ。エンジニアのアサインを行ったり、組織全体を健全な形で成長させたりといった人の面に側面をあてた役割を果たすのだ。

先ほどの略称のときにも出てきたが、そもそもプロダクトマネージャーとプロジェクトマネージャーはどう違うのであろうか？

プロジェクトマネージャーは、いつまでにどの品質のものを出していくかという、管理を行う役割だ。プロダクトはその中にプロジェクトは内包しており、プロジェクトよりも長いスパンで見る必要がある。

プロダクトを作って世に出したときに、初めから終わりを考えているものは少ない。それとは逆に、プロジェクトはいつまでにこの機能を入れたいなど、期間が決まっている。このようにプロダクトの中にプロジェクトがあり、プロダクトマネージメントの中にプロジェクトマネージメントをどうするかということも含まれている。

ぶれないための骨太の方針を決めるための強力な武器となる「PRD」

プロダクトマネージャーにとって役立つツールのひとつに、「製品要求仕様書（PRD：Product Requirements Document）」がある。名称からしてなにか堅苦しいイメージがあるが、こちらは形式を重んじるものではなく、魂が込められた中身が重要なものだ。

この「PRD」は、「Living Document」＝生きているドキュメントとして、常に更新していくことが期待されている。プロダクトマネージャー自身が作成・運用していくことがのぞましいが、必ずしもすべてのコンテンツや内容をひとりで埋める必要はない。プロダクトチームメンバーすべてが、参加して作っていくものなのである。

ではなんのためにこの「PRD」を作るのだろうか？　その目的は、ぶれないための骨太の方針を決めるためである。最初に決められた「何を作るか」ということが、開発期間が長くなると、その通りにいかなくなってしまうという状況が起こりえる。そのときに、本当に必要なものを抜いてしまうと、製品の目標が達成できなくなってしまうのだ。

何を引けばいいかという判断材料は、そのときに考えてはダメなのである。その製品のコンセプトそのもの、つまりPRDに書かれていることを判断材料にするのである。ちなみにこのPRDはGoogleで検索するとたくさん見つけることができる。中にはセクション数が多いものもあれば、簡単なものもある。とくに正解があるわけではないので、これらの資料を参考にするといいだろう。

このPRDの範囲だが、製品という単位だろうか。またはその一機能だろうか。これについては、どちらでもかまわない。機能でもそれなりに大きなものならば、RPDを書いたほうがいいのだ。

PRDとアジャイルの相性の悪さを解消する方法論

このPRDには、文量が多くなってしまいがちという課題がある。また、包括的なドキュメントよりも動くソフトウェアを重視している「アジャイル」との相性が若干悪い。PRD自体はなるべく書いた方がいいのだが、それを置き換えるか補完する形の方法論がある。

そのうちのひとつが、「One Pager」だ。これは固有名詞ではなく、英語でよく言われる1枚に簡単にまとめたものという意味だ。たとえばアマゾンの場合、すべての新機能や製品の提案をプレスリリースを書くところから始める。

プレスリリースはおばあちゃんにでも分かるような言葉で書かれており、かつ必要最小限のことがすべて書かれている。A4サイズの用紙1枚程度に収まるため、まさに究極の「One Pager」といえるのだ。

もうひとつの方法は、「リーンキャンバス」だ。これは事業計画書を1枚のキャンバスで表したものである。リーンの考え方は、仮説・検証を素早く回していくというものだ。一般的な製品はなにかの課題を解決するためにある。その課題が本当にあるのか、まずは検証する必要がある。

誰も欲しくないものは、その課題を誰も持っていないからだ。さらにそれがターゲットにとって、重大な課題なのかを検証するのである。課題が見つかったら、それに対して最善の解決策が何かを考え、それを検証していく。最後にMVPを作ったときに、どう受けられるかということを考えていくのである。

その手順を含めて考えていくのが「リーンキャンバス」である。

さらにもうひとつ。10個のスライドを埋めるだけでPRDの代替になるものがある。それが「インセプションデッキ」だ。その中のひとつの項目「エレベーターピッチ」は、まさにPRDの本質の部分だけを抜き出してきたものになる。

プロダクトマネージャーの具体的な役割は？

プロダクトマネージャーはプロダクトチームの「糊」となるといわれているが、具体的にはどのような仕事をしているのだろうか。たとえばプロダクトチームの構成によってもどの部分で「糊」になればいいのか、変わってくる。

それを紐解くのがDan Schmidtという人がブログに書いた「プロダクトマネージメントトライアングル」という考え方だ。

プロダクトは、「開発者」「ユーザー」「ビジネス」のそれぞれの真ん中でバランスを取っているものだ。さらに「開発者とユーザー」「ユーザーとビジネス」「ビジネスと開発者」というように、それぞれの空白領域が存在する。

実際にはこの3つの空白領域を埋める職種は存在しており、プロダクトマネージャーだけが埋めるということはない。また、それぞれの空白領域で矛盾が生じたり、あるいは妥協を考える必要もある。

プロダクトマネージャーは、自分の組織にその部分のタスクがいなかったときに補っていくのだ。また、トレードオフが発生する難しい判断が必要な場合も、その役割を担当する。このふたつがプロダクトマネージャーの役割である。

※画面は開発中のものです。