※2022年12月8日更新

昨今、デジタル世界のビジネスにおける、プロダクトマネジメントの重要性がいっそう高まっています。

プロダクトマネジメントとは、製品の構想から提供、モニタリング、改善、および撤退を行うプロセスの全てを指します。プロダクト開発チームの中でも、特にプロダクトライフサイクルを成功させ、ビジネスインパクトを最大化することに焦点を当てた役割です。

そのプロダクトマネジメントをリードするプロダクトマネージャー（PM、PdMとも表記されます）の仕事は、市場や競合他社の調査から、顧客や製品の分析、ビジョンやロードマップの策定と維持まで多岐にわたります。

プロダクト成長のためには欠かせないプロダクトマネジメントですが、さまざまな領域との依存関係を持つその複雑さがゆえに、各社における位置づけはバラバラです。また、明確にプロダクトマネージャーという役割を置いていない企業も少なくありません。

そこで今回は、今後ますます重要になるプロダクトマネジメントとその担い手であるプロダクトマネージャーについて、その定義や歴史をわかりやすく解説します。

本媒体SELECKで取材した8社の事例から、現場での実際の動き方や必要なスキルやフレームワークも学べるようにまとめましたので、ぜひ最後までお読みください。

＜目次＞

• 【まずは定義から】プロダクトマネジメントとは？
• 「トヨタ生産方式」が大きく影響。プロダクトマネジメントの歴史
• プロダクトマネージャー（PM、PdM）とは？ その具体的な仕事
• プロダクトマネージャー（PdM）とプロジェクトマネージャー（PjM）
• 実例から学ぶプロダクトマネジメント（働き方、スキル、フレームワーク等）

• • プロダクトを「国」と捉える独自のプロダクトマネジメント / Pococha
  • スケールするプロダクトマネジメント組織を作るための育成 / クラウドサイン
  • フレームワーク「OPMW」でプロダクトマネジメントを体系化 / ベルフェイス
  • 「地図とコンパス」のフォーマットで開発ロードマップを描く / LayerX
  • PO4名体制＋全社でプロダクト改善を仕組み化 / ヤプリ 
  • 「CS全員がPdMを兼ねる」プロダクト開発の進め方 / hokan
  • オンラインストア作成サービス2社におけるPdMの役割 / BASEとSTORES

【まずは定義から】プロダクトマネジメントとは？

まずは、1994年からデジタル製品の開発に携わり、現在はヨーロッパのトップ5ベンチャーキャピタルであるEQT Venturesにてプロダクトパートナーを務めるMartin Eriksson氏による、プロダクトマネジメントの定義を見てみましょう。

彼は、プロダクトマネジメントは「ビジネス、ユーザーエクスペリエンス、テクノロジーの交差点」であると説明しています。

• ビジネス：プロダクトマネジメントは、何よりも製品のビジネス価値を最大化することに焦点を合わせている。プロダクトマネージャーは、ビジネスゴールを達成するために製品を最適化し、投資対効果を最大化することに執着しなければならない。
• テクノロジー：技術スタックやコンピューターサイエンスを深く理解することは、正しい決定を下すために非常に重要である。特にアジャイルの世界では、プロダクトマネージャーは社内の他の誰よりも開発チームと毎日過ごす時間が長いため、より重要となる。
• ユーザーエクスペリエンス（UX）：プロダクトマネージャーはビジネスにおけるユーザーの声と、ユーザーエクスペリエンスに情熱的でなければならない。特に新興企業では、製品をテストし、ユーザーと話し、そのフィードバックを直接得る必要がある。

※出典：What, exactly, is a Product Manager?

このように、プロダクトマネジメントは非常に幅広く多様な分野にまたがっています。それをより具体的に表現しているのが、Dan Schmidt氏が定義した「プロダクトマネジメントトライアングル（The Product Management Triangle）」です。

※以下、画像含めた出典：The Product Management Triangle

このトライアングルでは、プロダクトマネージャーが活動する領域を「プロダクトネットワーク」と呼ばれる上図の三角形で表現しています。

プロダクトネットワークの中心にあるのは、プロダクト自身です。そしてそのプロダクトは、開発者（Developers）、ユーザー（Users）、ビジネス（The Business）という3点で繋がっています。そして、下記の図の「A」「B」「C」の領域において、それぞれの活動を担う役割が存在します。

例えば、Aの領域（開発者とユーザーの間）をつないで活動する役割には下記のようなものが挙げられています。

• コミュニティマネジメント
• ソーシャルメディアマーケティング
• SEO（検索エンジン最適化）
• ユーザーリサーチ
• Webアナリティクス
• デザイン

そして、この三角形すべての領域を健全に機能させることに責任を持つのが、プロダクトマネージャーです。Schmidt氏は、下図における空白領域（A、B、C）と融合領域（AB、BC、AC）、そのどちらの領域もマネジメントをするのがプロダクトマネージャーだと説明しています。

具体的には、A、B、Cという分断された領域をリンクさせ、またAB、BC、ACそれぞれの領域から得られるインプットを融合させた上で、各領域におけるストーリーを組み立てる必要があります。その中で、プロダクトマネージャーによる活動は、状況に応じて幅広く存在するといいます。

長くなるので本記事では割愛しますが、引用元ではそれぞれの領域におけるシナリオも具体的に説明されていますので、興味のある方はぜひご覧になってみてください。

※翻訳版はこちらの記事がおすすめです：
【翻訳】プロダクトマネジメントトライアングル

「トヨタ生産方式」が大きく影響。プロダクトマネジメントの歴史

このように、製品開発の要とも言えるプロダクトマネジメントですが、特にデジタル企業では長い間その明確な定義はなく、アジャイル製品開発の方法論の成長とともに進化してきました。

ここでは、プロダクトマネジメントの発祥とその歴史を見ていきます。

1930年代　〜プロダクトマネジメントの起源が誕生〜

1931年、P&G社でマーケティングマネージャーを務めていた Neil H. McElroy氏が、特定の製品を管理する従業員である「ブランド・マン」の必要性について300ページのメモを作成しました。

このメモに書かれていたのは、売上の追跡から製品、広告、プロモーションの管理まで、ブランドに対する責任を果たすためには、徹底したフィールドテストと顧客との対話が必要であるという内容でした。

これが後のブランドマネジメント、そして最終的にはプロダクトマネジメントに関する現代の考え方の礎となったと言われています。

その後、McElroy氏がスタンフォード大学のアドバイザーになり、Bill Hewlett氏とDavid Packard氏という、のちの1939年にHP（ヒューレットパッカード）社を創業する2 人の起業家に影響を与えました。

1940〜1950年代　〜HPとトヨタによる新しい考え方の発展〜

Hewlett氏とPackard氏は、ブランド・マンの理念を、意思決定をできるだけ顧客に近づけ、「プロダクトマネージャーの声＝顧客の声」とすることだと解釈しました。この原理を導入したことで、同社は1943年から1993年までの50年間、前年比20％増の成長を維持し続けたといいます。

一方で戦後の日本では、トヨタがJIT（ジャストインタイム）生産システムや「カンバン方式」を生み出し、生産プロセスにおける継続的な「カイゼン」を行う「トヨタ生産方式」を発展させていきました。そしてこの仕組みは、HP社にもすぐに取り入れられることになりました。

1970年代〜1980年代　〜テクノロジー組織へと進出〜

HPの卒業生は、顧客中心主義やブランドマネジメント、そしてトヨタから学んだリーンな生産方式といった新しい考え方を、当時ハードウェアやソフトウェアの領域で成長著しかったシリコンバレーにも浸透させました。それがあらゆる会社に広がり、現代の私たちが知っている世界的なムーブメントへと繋がったのです。

しかし、当初のプロダクトマネジメントは、顧客のニーズを理解した上で、古典的なマーケティングミックスを使ってそのニーズを満たす方法を見つけるプロセスが中心で、その大部分はマーケティング機能の一部でした。

なぜならば特に製造業においては、新製品の開発・生産に非常に時間がかかるため、ブランドマーケティングと製品の（実際の）開発が別々の役割として発展していったためです。

しかし、テクノロジー分野においては、顧客のニーズを正確に理解した上で、製品の開発と生産を一体化させることが不可欠です。こうした背景から、多くのテクノロジー企業ではマーケティングがブランドと顧客獲得を担当し、プロダクトが価値提案と製品開発を担当するように進化していきました。

2000年代　〜そしてアジャイルの時代へ〜

そして2001年、アジャイル マニフェストが発表され、その原則のひとつとして、「ビジネスサイドの人間と開発者は、プロジェクトを通じて日々一緒に働かなければならない」と提起されました。

※アジャイル開発について、詳しい説明はこちらの記事をどうぞ。
【事例7選】「アジャイル」とは？ 開発やHRなど多くの分野で注目される理由を徹底解説！

プロダクトマネージャーは、まさにこの実現を果たす役割として、アジャイル開発の拡大とともに広く普及することになったのです。ここに、今現在の私たちが知っているプロダクトマネジメントが誕生しました。

機敏・迅速・柔軟なソフトウェア開発の手法であるアジャイル開発は、今やさまざまな領域で取り入れられていますが、その中において顧客の声を代弁しながら、各領域をつなぐプロダクトマネジメントは非常に重要な役割を果たすようになりました。

※参考：
What is product management?
The History and Evolution of Product Management

プロダクトマネージャー（PM、PdM）とは？ その具体的な仕事

プロダクトマネジメントトライアングルでも説明されていたように、プロダクトマネージャーの責任領域は非常に広範にわたります。それをより具体的にイメージするために、まずはGoogle社のプロダクトマネージャー職の求人内容を見てみましょう（※編集部よる抄訳）。

プロダクトマネージャーは、技術部門とビジネス部門の垣根を越えて、製品の構想から発売までをサポートする役割を担います。複雑な問題をステップに分解し、製品開発を推進します。

Google は、世界中の情報を整理し、ユーザーが普遍的に利用できるような製品を開発することを目指しています。Google のプロダクトマネージャーは、新しいテクノロジー、プラットフォーム、消費者向けの製品、企業向けのシステムに携わる可能性があります。
最終的な目標は、あなたの興味、経験、そして最も大きな影響力を発揮できる場所に最も適したチームを紹介することです。

最低限必要な資格

• 学士号、または同等の実務経験
• 戦略的な製品ロードマップの作成、部門横断的なチームとの協働など、技術的な製品管理の経験4年以上
• 製品ビジョン、市場参入戦略、設計の議論を推進した経験
• インターネット製品および技術の開発経験

望ましい資格

• テクノロジーまたはビジネス関連分野の修士号
• 日々の技術やデザインの方向性を管理した経験
• プロダクトマネジメント、エンジニアリング、UX/UI、セールス、カスタマーサポート、ファイナンス、マーケティングなど、複数の機能領域と効果的に協働した経験
• 直接的な権限を持たずとも、複数の関係者に影響を与えることができる能力

※出典：https://careers.google.com/jobs/results/104640027251614406/?hl=ja_JP

具体的に「何」をするかまでは明確に記載されていないものの、やはりビジョンや戦略の策定から、具体的な製品開発まで、様々な役割を持つ人と関わりながら仕事を行うことが想像できますね。

本記事の後半では、具体的な各社の事例から実際のプロダクトマネージャーの仕事を学んでいければと思いますが、一般的なプロダクトマネージャーの仕事には下記のようなものがあります。

• 顧客インタビューと市場アセスメントの実施
• ビジネス要件から技術仕様への変換、またその逆の作業
• 製品ロードマップの企画・設計
• 人的リソースの割り当て
• デザインスプリントの実行
• 製品機能の優先順位付けと、その理由のステークホルダーへの伝達
• 価格設定と収益モデリング
• 成功指標の定義と追跡
• すべてのステークホルダーとの効果的なコミュニケーション
• コスト超過のないタイムリーな製品完成の確保

※参考：Product Manager Job Description (2022)

上記のようなプロダクトマネージャーの仕事についてよりわかりやすく理解するために、まずはプロダクトマネージャーに近い役割を担う人々を見ていきましょう。

プロダクトマネージャー（PdM）とプロジェクトマネージャー（PjM）

※以下、各役割の定義や業務内容については、各社で異なるものの、ここでは最も一般的に知られているものをご紹介します。

プロダクトマネージャーと最も混同されやすいのが、「プロジェクトマネージャー」です。

以前は、両者ともに「PM」と表記されることもよくありましたが、最近ではprudcut、project、それぞれの文字を用いて「PdM」「PjM」と表記することで違いを明確に記載することも増えています。

プロジェクトマネージャー（PjM）は、開発プロジェクト全体の管理を行い、業務計画の実行と進行管理を通じた目標達成を目指す責任者です。一方でプロダクトマネージャー（PdM）は、ここまで見てきた通り、プロダクトに対して全体的な責任を負い、利益の最大化を目指します。

両者の違いをよりシンプルに表現すると、

• プロジェクトマネージャー：プロジェクトを「いつまでに作るか（when）」、「どうやって作るか（how）」を考え、主にプロジェクトチームのメンバーの方を向いて仕事をすることが多い。
• プロダクトマネージャー：商品やサービス、プロダクトについて「なぜ作るのか（why）」、「何を作るか（what）」から、市場や顧客と向き合って考えていくことが多い。

プロジェクトマネージャー以外に、プロダクトマネージャーに近い役割としては下記のようなものがあります。

• CPO（チーフプロダクトオフィサー）：最高製品責任者。企業経営におけるプロダクトの最上位ポジションとして、経営戦略・経営計画に応じたプロダクト戦略・ロードマップの策定を行い、あらゆる角度からその実現に注力するための意思決定を行います。
• PO（プロダクトオーナー）：プロダクト所有者。プロダクトの価値を最大化する方法について考え、その成功・失敗について責任を持つ役割。プロダクトの方向性・コンセプト・機能・要件等に優先順位付けを行って記述した「プロダクトバックログ」の作成・管理が主な役割。プロダクトマネージャーが定義した要件をユーザーストーリーに落とし込み、チームと一緒に詳細を詰めていく。
• PMM（プロダクトマーケティングマネージャー）： 顧客のニーズ・ウォンツを満たせるようなプロダクトの企画・設計やマーケティング・販売の方法を考える職種。プロダクトマネージャーの業務範囲が広すぎるため、ビジネス・マーケティング部分に特化するための新しい職種として誕生。

※参考：
Product manager vs. project manager: What’s the difference?
Ending the PM and PO Confusion — The Story of Bob and Janet
Product Manager vs. Product Marketing Manager: What’s the Difference?

実例から学ぶプロダクトマネジメント（働き方、スキル、フレームワーク等）

ここまで、プロダクトマネジメントの定義やプロダクトマネージャーの役割について一般論を説明してきましたが、ここからはより実践的で具体的なナレッジを、各社の事例からお伝えできればと思います。

※本パートに記載の情報は、すべて引用元記事の公開日に基づくものであり、現在は変更されている可能性があります。

プロダクトを「国」と捉える独自のプロダクトマネジメント / Pococha（DeNA）

2022年9月末時点で国内累計429万以上のダウンロードを誇る、株式会社ディー・エヌ・エーが運営するライブコミュニケーションアプリ「Pococha（ポコチャ） 」。

Pocochaが2022年8月に公開した「Culture Deck（PC版 、スマホ版）」では、同アプリのこれまでの軌跡やプロダクト戦略をオープン化するだけではなく、Pocochaというプラットフォームを「国」と捉える独自のプロダクトマネジメントの考え方やフレームワークを公開したことでも話題となりました。

▼PocochaのロングテールPF FlyWheelと名付けられた独自のフレームワーク

具体的には、Pocochaを運営するための「行政機構」として、組織を3つのメインプロトコルに分化した上で、各プロトコルには、専門職としてプロダクトマネージャー（PdM）ならぬ「プラットフォームマネージャー（PfM）」を配置。

PdMとPfMが協働することで、複雑性の高いプロダクト開発において、より多くの人の声を取り入れた意思決定を可能にしているといいます。

PocochaのCulture Deckを読まれると、思想やコンセプチュアルな考え方が強い組織だという印象を持たれるかもしれません。ですが、今の考え方に至る2年以上前の方が、もっとそれが顕著だったんです。

というのも、以前はある種、「水田の思想に乗れるか、共感できるか」で物事を判断するようなシーンも多かったんですね。それが今では「国造り」がモチーフになったことで、誰かの思想ではなく歴史的に証明されている考え方や研究をベースに判断ができるようになりました。

僕の思想ではなく、より学術的な意味で多くの人のレビューや批判にさらされた上で、それをくぐり抜けてきたものが今の考え方のベースになっているので。Pocochaが目指しているものの正当性や可能性について、よりロジカルに腹落ちできるようになったと思います。

こちらの記事ではより詳しくPocochaの取り組みをお読みいただけます：
プロダクトマネジメントは「国造り」。Pocochaの急成長を支える哲学とフレームワーク

スケールするプロダクトマネジメント組織を作るためのPdM育成 / クラウドサイン

弁護士ドットコム株式会社が2015年より展開する、契約マネジメントプラットフォーム「クラウドサイン」。同事業を製品の観点からけん引するのが、プロダクトマネジメントグループです。

同グループでは組織を、仮説検証を主体的に推進する「ディスカバリーチーム」と、アジャイル開発におけるPOを務める「デリバリーチーム」に分け、各自の強みや志向に合わせて専門性を強化できるプロセスを構築。入社後にまずはデリバリーチームに配属することにより、PdMとしてのスキルアップを目指す仕組みを確立しているといいます。

▼クラウドサインの製品開発プロセス（同社提供）

また、あらゆるステークホルダーに挟まれ、孤独化しやすいPdM同士の横のつながりやコミュニケーションを増やすための取り組みも行っています。

PdMって、あらゆる方面からのステークホルダーに挟まれてとても孤立化しやすい職種だと思っていて。精神的にも大変ですし、スクラムチームの中でも、常に前向きにチームをリードしなければいけないシーンもあります。

そこでプロダクトマネジメントグループでは、デイリーで30分のミーティングを実施しています。そこでは、エピックリストにあるAという課題を仮説検証している人や、アジャイル開発のBレーンのPOの人など、それぞれの視点から見えている情報を共有しています。

それによって、誰もが自分の担当領域以外のところで何が起きていて、他のPdMは何に課題を持っているかという情報に触れ続けることで、製品全体を見る力を少しずつ養っていけるようにしています。

PdMはスピーディに意思決定をしなければいけないことが多いですが、「果たしてこれでよかったんだろうか」「◯◯さんだったらどうするだろう」といったことを話すことで、組織の学びを最大化し、経験値の浅いメンバーの成長にもつなげています。

こちらの記事ではより詳しくクラウドサインの取り組みをお読みいただけます：
スケールするプロダクトマネジメント組織を作るには？ クラウドサインに学ぶPdM育成術

フレームワーク「OPMW」でプロダクトマネジメントを体系化 / ベルフェイス

チームの売上を最大化するオンライン営業システム「bellFace」を展開するベルフェイス株式会社は、2020年まではマーケティング戦略の成功やコロナ禍によるIT投資への助成金といった後押しもあり、順調に成長を続けていました。

しかし、それはある種マーケットの波に乗れたという運の成長が強く、いわば「再現性のない成長」だったといいます。

そこで、2020年12月にCTOとして入社し、現在はCPOも兼務する山口 徹さんは、同社のPdM組織に「オープンプロダクトマネジメントワークフロー（OPMW）」を導入。

▼OPMWのプロセス（ベルフェイス社がopen-pmw.orgを参考に翻訳し作成したもの）

本プロセスに沿ってそれぞれの成果物を可視化した上で、横軸で情報の受け渡しができるようなパイプラインを設計し、プロダクトマネジメントを徹底的に体系化。その結果として、PdMに必要なスキルも可視化されたといいます。

OPMWは、プロダクトマネジメント組織を「Strategy」「Technical」「Go-to-Market」の大きく3段階に分けて進めていくフレームワークです。

ベルフェイスでは、当時プロダクトマネジメントの経験値が少なく、また、体系立ったやり方も、「なぜ」作るのかというWhyの要素もなかったんですね。その状態を立て直すためのフレームワークを探す中で、OPMWがBtoB SaaS向けのプロセスであったこともあり、採用したという背景です。

（中略）現状、PdMは20名ほどなのですが、Strategyフェーズを担当しているのが3、4名ほどで、残りはTechnicalフェーズを担当しています。Go-to-MarketになるとPMMが担当しますが、何を重視していくかといった観点はPdMが出しています。

（中略）ベルフェイスのPdMの場合は、OPMWのプロセスに対して「これぐらいの給与レンジの人は、これができなければいけない」ということをすべて定義してあります。今は採用においても、それに応じてスキルセットの見極めを行っています。

こちらの記事ではより詳しくベルフェイスの取り組みをお読みいただけます：
「再現性のない成長」を脱却。プロダクトマネジメントの大変革を経たベルフェイスの現在地

「地図とコンパス」のフォーマットで開発ロードマップを描く / LayerX

2018年に創業し、「BtoB取引のデジタル化」「証券・資産流動化のデジタル化」「PrivacyTechを活用した企業間データ共有の活性化」という三つの軸で事業を展開する株式会社LayerX。

中でもSaaS事業「バクラク」シリーズのプロダクトマネジメントにおいては、同社が得意とする「爆速開発」を実現するため、「地図とコンパス」と呼ばれる同じフォーマットを使って開発ロードマップを描き、開発チームとして進むべき道を指し示しているといいます。

加えて、開発においては「やらないことを決める」「要望通りの仕様で作らない」「仕様をシンプルにする」という三つのポイントを重視し、ユーザーの真のニーズを十分に拾い上げながらも、開発スピードを緩めない工夫を行っています。

▼企業属性や業界を分けた上で、顧客からの要望をプロットした開発の「地図」

▼地図を基に、開発する時期や順序を示す「コンパス」

弊社の爆速開発を下支えしているのが「寄り道しない開発ロードマップ」である各PdMが作成する「地図」と「コンパス」です。

まずセールスとカスタマーサクセスが持っている新規・既存ユーザーの声といった一次情報に加えて、ユーザーの行動ログの情報をPdMが集約して整理していきます。その上で機能要件をまとめ、求めている企業群の属性を企業規模や業界などで振り分け​​てマッピングしたものが「地図」です。

（中略）次に、この地図を基に、いつ・どの順番で開発していくかを細分化して、四半期や月次ごとにタスク分けをし、開発の方向を指し示す「コンパス」としてのロードマップを作ります。

この手法をプロダクトごとに変えると認知コストが掛かるので、どのプロダクトにおいても同じフォーマットでまとめている形ですね。PdMのみんなは、これらの仕組みの元でプロダクトマネジメントをしているわけです。

こちらの記事ではより詳しくLayerXの取り組みをお読みいただけます：
「爆速開発×ユーザー体験向上」を実現するLayerX。その鍵となる「地図とコンパス」とは

PO4名体制＋全社でプロダクト改善を仕組み化 / ヤプリ

アプリ開発・運用・分析をノーコードで提供するアプリプラットフォーム「Yappli（ヤプリ）」を開発・提供する株式会社ヤプリ。

2013年に3名で事業をスタートした同社も、今や正社員数は250名に迫り（2022年6月末時点）、サービスの導入実績は600社以上。Yappli自体に50以上の機能があることから、プロダクト全体の知見を持つメンバー4名でPOを分担して担当しているといいます。

POの基本的な役割は、中長期の目線でやるべきことをリストにして、経営陣と話し合って開発の優先順位を決めることです。

そして実際に作るものが決まったら、リードエンジニアとPdMがアサインされ、キックオフして進めていきます。その中の要所要所で、POに相談や壁打ちをしながら、全体で合意形成をしていきます。

この体制になったのは2年ほど前ですが、それまではプロダクトマネージャー的なメンバーも足りていなかったので、優先順位の判断が遅れるなど、ボトルネックになってしまうこともありました。

そこでPOを4名立てて役割を分割しつつ、従来のPMをPdMという名称に変更して、より開発を進めやすくした形です。

また同社の特徴として、プロダクト改善を全社で仕組み化していることが挙げられます。

• 月に2回、好きな改善に集中できる「Yappdateday」
• 誰でも改善アイデアをプレゼンできる「ヤプリク」
• 開発生産性を高めるための精鋭エンジニア「遊撃」

上記のような取り組みを行うことで、POやPdMだけではなく全社でプロダクトをより良くすることに関われる体制を構築しています。

こちらの記事ではより詳しくヤプリの取り組みをお読みいただけます：
誰もがプロダクト改善に参加する組織を。巨大な技術的負債も乗り越えたヤプリの現在地

「CS全員がPdMを兼ねる」プロダクト開発の進め方 / hokan

特にスタートアップにおいては、創業期にCEOがPdMを兼務することも多くあります。その中で、ユニークな「兼務」をを取り入れているのが、保険営業のためのクラウド型顧客・契約管理サービス「hokan」を提供する、株式会社hokanです。

同社では、カスタマーサクセスのメンバー全員がプロダクトマネージャーを兼務し、顧客の声を開発に反映する体制を取っています。

要件定義においては、デザインツールの「Figma」を使ってイメージ画面を作成し、顧客へのヒアリングを実施。ユーザーが最もイメージしやすい環境をつくった上で要件をすり合わせることで、開発の手戻りをなくしているそうです。

▼実際にFigmaで作成したUIデザイン画面（同社提供）

開発すると決まった機能に関しては、細かい要件を定義していくため、チケットごとにPdMがアサインされます。基本的には、リクエストのあった顧客を担当するCSメンバーが担当します。

そしてCSチームは全員がデザインツールの「Figma」を使って、イメージ画面を作成し、要件のすり合わせを行っています。

というのも、お客様は保険営業のプロではあっても、システムのプロではないんですよね。また、ITリテラシーが高い方ばかりではないので、要件定義書などを確認したとしても、合意したイメージと実際に出来上がった機能が全然違っていた、みたいなことが結構あるんです。

であれば、お客様が一番イメージしやすい環境をつくって意見をいただいた方が、開発の手戻りが少なくなり、結果的に早く価値提供することができる。なので、デザインを見せながら「ここはこうしてほしい」などの要件や情報のロジックを確認していく、というやり方にしています。

こちらの記事ではより詳しくhokanの取り組みをお読みいただけます：
「CS全員がPMを兼ねる」プロダクト開発の進め方とは？ 顧客と共創するSaaS開発の裏側

オンラインストア作成サービス2社におけるPdMの役割 / BASEとSTORES

最後に、若干昔の記事（2019年）ではあるのですが、「PdMの役割」について「BASE」と「STORES.jp」といういわば競合である2社のPdMが対談した記事をご紹介します。

STORESにおけるPdMの役割と体制

• PDMの仕事は基本的には意思決定。その種類を大別すると3つくらいに分けられる。
• 一番大きな部分は、数年単位の長期スパンでどういった課題を解決すべきか、競合マーケットの中でどういうポジションを取っていくべきか、といった意思決定。
• そこからブレークダウンしたプロジェクトであったり、KPIに対する施策の優先順位を決めるのが、2つめの意思決定。さらに、仕様やUI/UXデザインなどの最終的にユーザー体験に落ちる部分が、3つめの意思決定にあたる。
• これらの意思決定の中で、「自分が今、どの部分の意思決定をしているのか」を自覚することが重要。
• もともと、社長がPdMを兼ねていたが、そこから専任者が入社。取材時には3名が所属。
• PdMの主な役割としては、関係部署と連携しながらプロジェクトをリードしつつ、開発の要件定義をしていくこと。

BASEにおけるPdMの役割と体制

• KPIだけを追っていると短期的な視点になりがちなので、意思決定のたびにこれは短期なのか、中期なのか、長期なのか、ということは非常に意識している。
• 加えてその意思決定をするために、ショップオーナーさんの課題をいかに見つけられるか、ということを大事に。ヒアリングに同席することも多い。
• PdM1名体制から、徐々にプロダクトマネジメントグループという形で組織化を進め、役割を分担している。例えば、プロダクト戦略を考える人、ユーザー体験の向上を担当する人、プロジェクトの進行管理をする人といった形。
• PdM組織とは別に、オーナーズグロースグループという組織があり、そちらではショップオーナーの方々が目指す世界観の実現をミッションとして、カスタマーサクセスのような役割を担う。

こちらの記事では2社のPdM対談をより詳しくお読みいただけます：
【特別対談】BASE x STORESのプロダクトマネージャーが語る、PMの役割と未来への挑戦

プロダクトマネジメントの在り方とプロダクトマネージャーの役割について、実践的な内容も含めてご紹介いたしましたが、いかがでしたでしょうか。

当媒体SELECKでは引き続きプロダクトマネジメントについての取材記事を増やしていきますので、気になる方はチェックしていただけますと幸いです。

最後までお読みいただき、ありがとうございました！