『プロダクトマネジメントのすべて』共著者・小城久美子氏×アトラシアン 野崎馨一郎　プロダクトマネージャーが本当に成すべきことは

DXの潮流の中、多くの企業がソフトウェアを自社の製品やビジネスの市場競争力強化、あるいは新たな価値創出の術（すべ）として位置付け始めている。それに伴い、注目を集めているのがプロダクトマネージャー（以下、PM）だ。PMの役割とは？　そもそもプロダクトマネジメントがなぜ重要なのか？　プロダクトマネジメントの専門家である小城久美子氏と、アトラシアンのエバンジェリスト、野崎馨一郎氏との対談を通じて解き明かす。

プロダクトマネジメントで目指すべきは「アウトプット」ではなく「アウトカム」

※以下、敬称略

野崎：小城さんは何をきっかけにPMになろうと考えたのでしょうか。

小城：ミクシィでエンジニアとして働いていた頃はプログラミングが楽しくて仕方がなく、当面はプログラマーとしてキャリアを積もうと考えていました。ただ、のちに転職したLINEで働く中で開発の前工程の部分にも興味を抱くようになって。プロダクトが利用者にどう使われ、どんな喜びを提供するかを考えながらモノづくりをマネージする仕事もしてみたいと思うようになりました。

野崎：それでLINE CLOVAの立ち上げではPMを担当されたのですね。今でこそPMへの理解は広がっていますが、当時の日本では理解や明確な定義はほとんどなかったのではないですか。

小城：そうなんです。全てが手探りで、幾度も失敗しました。でもその失敗の繰り返しの中で、いつも同じところでつまずくポイント――言い換えれば、失敗に法則性があることに気付きました。それを回避するマネジメントの術を見いだせば成功を再現できると考え、プロダクトマネジメントの方法論をTably社でのコーチングやLuup社での実務を通じて探求してきました。

野崎：「つまずくポイント」とはどのようなことでしょう。

小城：つまずくポイントはここ数年間で変化しています。かつては、多くのPMがプロダクトディスカバリー※ の段階において「白地図」がなく、情報をそろえた上で何をどう決めればいいか分からず悩んでいました。それが今日では、一度完成させたプロダクトの価値を継続的にどう積み上げていくかで困る方が多いように感じています。

野崎：価値の積み上げで悩むというのは興味深いポイントです。

小城：利用者からのフィードバックをプロダクトに反映させていくうちに、プロダクトの方向性を見失う……例えば、私はよく「蛇足のダソくん」というキャラクターを用いて説明しています（笑）。この「魚（＝プロダクトの例）」の機能改善を図っているうちに、パフォーマンス強化のために不必要な足を生やしてしまう。差別化のために尾ひれをつけてしまう。その結果、もともとの製品コンセプトから外れてしまうリスクがある――といったイメージです。

野崎：それは、アジャイル開発でプロダクトの改善を繰り返していく中でも突き当たりそうな問題ですね。ある意味で、PMの意思決定に関わることのように感じますが。

小城：おっしゃる通りです。プロダクトマネジメントで追求すべきは「アウトプット」ではなく「アウトカム」です。つまり、重要なのは何を作るかではなく、どんな成果をどう生むか、あるいは利用者が本当に望むこととは何かを考え、価値を積み上げていくことです。先ほどの例では、パフォーマンス強化や差別化にとらわれるあまり「かわいい魚」というキャラを外れてしまいました。しかしそうではなく、「『足』や『尾ひれ』は本当にユーザーが求めていることなのか」を突き詰めることが必要です。そうした作業の中で迷いが生じ、間違った方向性に進みそうになるPMは少なくありません。

ロードマップは「リビングドキュメント」　ハードウェア製品にもソフトウェア視点が必要なワケ

野崎：かつてと現在を比べると、やはりプロダクトマネジメントにおける思考レベルが深まっているように思えます。以前は、プロダクトのコンセプトをどう作り上げるかが問題だったのが、今はプロダクトの価値を増すために、コンセプトレベルに立ち戻り、何をどうするのが正解かを考え抜こうとしている。プロダクトマネジメントにおける現場の成熟度は増していると見ていいように思えます。

小城：私も、そう感じています。

野崎：アジャイル開発の現場では利用者からのフィードバックを基に実装する機能の優先順位を変えていきます。それはある意味で、プロダクトのロードマップを絶えず更新していることと同義です。そのようにしてロードマップを更新していくことは、プロダクトマネジメントにおいても重要だと思いますが、いかがでしょうか。

小城：おっしゃる通りです。プロダクトを取り巻く利用者のニーズ、状況は絶えず変化します。変化やフィードバックに応じてロードマップに更新をかけていくことは当然必要ですし、とても大切です。

野崎：それを聞いて安心しました。アトラシアンでは、プロダクトディスカバリーのフェーズにおいて、より深く円滑にプロダクトチームや関連部門、経営層がオープンに効率的なアイデアのコラボレーションを進めるべく、「Jira Product Discovery」の提供を開始しました。プロダクトマネジメントにおいて、ロードマップが固定化、形骸化するリスクを減らせたなら、これほどうれしいことはありません。小城さんのいう通り利用者のニーズや状況は変化しますし、開発すべき機能の優先順位や予算の状況、戦略も変わるかもしれません。ゆえにロードマップはそのプロダクトの利用者が本当に望んでいることは何かという問いを都度突き詰めて考え、更新を重ねる「リビングドキュメント（絶えず変更、編集され続ける、最終版にならない文書）」として扱われるべきです。また、更新内容をプロダクト開発に関係する全員が絶えず、速やかに共有できるようにしておかなければなりません。

小城：そうですね。もちろん、プロダクトの数値目標やアウトカムは、最初の取り決めを守るように努力を払うべきです。ですが、利用者の望みをかなえるための道筋は状況に応じて変えていくことが必要です。もっとも、伝統的なモノづくり企業の中には「ロードマップは経営層に見せる資料なので変更はできない」といったところがあります。こうした企業にリビングドキュメントである必要性を納得してもらうのは大変です。

野崎：特にハードウェア製品の開発では、当初の計画通りにプロダクトを出すことが重視されますよね。とはいえ、ハードウェア製品にしても今日では製品を作り、出荷して終わりという時代ではなく、ソフトウェアを通じて利用者にとってのプロダクトの価値をどう維持、向上させていくかが問われています。つまり、ハードウェア製品のソフトウェア化（サービス化）が進展しているわけです。そう考えれば、「ロードマップ＝リビングドキュメント」との認識が急速に広がる可能性もあると見ています。

小城：私もそう思います。実際、LINE CLOVAもLUUPもハードウェアとソフトウェアを一体化したプロダクトです。ハードウェア製品の開発にプロダクトマネジメントの考え方を適合させるのは難しいですが、マネージする上での醍醐味や面白さはソフトウェアだけよりもハードウェアとサービスが一体化したもののほうが上です。最近は、ハードウェアが絡まないプロダクトに物足りなさを感じるくらいです（笑）

日本企業は「プロジェクト」マネージャー＝PM？　理想のキャリアパスは

野崎：ところで小城さんは、ソフトウェア開発のエンジニアからPMになられたわけですが、私が調べたところ「プロジェクト」マネージャーの方がPMになるケースも増えているようです。その傾向をどう捉えていますか。

小城：日本のプロジェクトマネージャーの方は非常に優秀で、実質的にPMとしての役割も担っていることが多々あります。PMへの転身は自然な流れのように感じますし、単純にジョブタイトルが変わっただけのようにも思えます。

野崎：日本の大手製造では、モノづくりの体制が確立されています。その中にプロダクトの企画や開発、マーケティングやエンジニアリングなど、多岐にわたる領域をマネージするPMという職務をどう当てはめるのが適切か、決めあぐねています。小城さんは、その点をどのようにお考えでしょうか。組織体制によっては、PMの役割は事業責任者が担うしかない会社も存在する、との意見もありますが。

小城：まず、プロダクトマネジメントはPMが単独で行う仕事ではなく、事業責任者や担当者、エンジニアやマーケターなどが総がかりで行う仕事です。そして大手企業の中で、一人でプロダクトの全てを見切れるかといえば、それは至難です。ですので、プロダクトマネジメントに必要な要素を細分化してそれぞれに目標を持ったPMを配置し、プロダクトオーナーが束ねるという体制が現実的ではないでしょうか。また、プロダクトマネジメントを実践する上で大切なのは、PMという肩書を持った人を置くことではく、モノづくりの在り方をアウトプット指向からアウトカム指向へと転換することです。そして、アウトカム指向でモノづくりを進めていけば、企業内の誰がPMとして適任かが自ずと定まっていくと見ています。

責任の所在とプロダクトマネジメントの現場にも不可欠な心理的安全性

野崎：先ほど、プロダクトマネジメントはさまざまな職務の人間が全員で取り組むものとお聞きしました。そこで浮かんでくるのが「プロダクトが仮に失敗した場合、誰が責任を背負うのか」という質問ですが、小城さんはどうお考えになりますか。

小城：失敗の責任は誰も背負う必要はありません。プロダクトマネジメントは仮説検証の繰り返しであって、仮に失敗をしたとしても、それは仮説検証の選択肢が1つ減っただけのことといえます。もちろん、数値的な目標が達成できなければリカバリーしなければなりませんし、失敗したのちにどのような仮説検証を行うべきかを決めるのはPMの責務です。その責任を担う上でも重要なことは、失敗から学ぶことです。ロードマップを変更して目的とするアウトカム、つまりは利用者の願いをかなえていく努力を続けることが大切です。ロードマップは、チームで成功イメージを合わせるとき一番具体的なツールになります。「プロダクトの成功＝ビジョンの実現」なので、ぜひチームでそれを目指していきたいですよね。

野崎：まさにそれは、アジャイル開発の考え方そのものですし、アトラシアンがチームの成果を最大化する上で大切にしてきたことと同じです。要するに、失敗の責任を誰かに背負わせるのではなく、失敗から学び、自分たちを成長させる組織文化を育み、誰もが安心して働けて自分の能力、アイデアを試せる場をつくるようにすることが、チームの成功や革新的なチームづくりにつながるという考え方です。プロダクトマネジメントのチームでも、その考え方が有効であることが、小城さんのお話で確認できました。本日はありがとうございました。