ブログ

プロダクトマネジメントは幅広い活動が含まれます。製品のロードマップや仕様を定義し、関係各所と認識をすり合わせるよう、情報共有を促進するのはプロダクトマネージャーの責任です。プロダクトマネジメントの仕事を支援するよう、様々なツールが開発されてきました。「正しいものを正しく作る」ため、効率的かつ効果的なプロダクトマネジメントを行えるよう、最先端のツールを賢く利用するようにしましょう。

プロトタイプ：Figmaを始め、多人数での共同作業に適したクラウド型が人気

製品を実装する前に、ラフな絵を作成して、その完成イメージを共有する作業は頻繁に採用されます。営業・マーケティング部門は、ユーザーからニーズがある機能が含まれるか確認し、また、開発チームは実装にかかる時間や労力が見積もれます。手書きの画像でも構いませんが、近年はワイヤーフレームと呼ばれるツールを使って、簡単な枠線を描き、製品イメージを作成します。ボタン遷移などの挙動も確認し、ユーザーから見た使い勝手を確かめます。ちなみに、ExcelやPowerPointでワイヤーフレームを作成する企業も見受けられますが、多人数の開発の場合、バージョン管理や情報共有が困難になるため、利用は推奨されません。

近年は、クラウド型のプロトタイプ・ツールが提供されるようになり、多人数の開発でも、リアルタイムで最新のバージョンが確認できるようになりました。中でも、Figmaはリーダー的な存在で、複数人でのデザイン作業に向いています。

• Figma

Macユーザーの間では、Sketchの人気も高いようです。直感的な操作性がデザイナーから評価されています。

• Sketch

より高機能なサービスを希望する人は、以下のようなものも試してみると良いでしょう。多くのサービスでは、無料体験を用意しているので、リスク無しでその使い勝手が確認できます。

• InVision
• Balsamiq
• Proto

Adobe XD. XUI/UX.をデザイン、プロトタイピング、共有

ロードマップ：プロダクトマネージャーの重要な責務を、効率化するツール群

プロダクトマネージャーにとって、製品開発のロードマップを作成するのは、最も重要な仕事の一つです。戦略的に計画を立て、どのような順番で何に資源を投入するのかを明確にし、企業にとってどんな成果がもたらされるのかを経営層や関係各所に伝達します。中長期的な視点でロードマップを作成するのがポイントであり、短期的なリリース管理は「プロジェクト」マネージャーの責任となるのが一般的です。

ロードマップはExcelで作ろうと思えば作れるものですが、長い期間、整合性をとれるようにメンテナンスし続けるのは難しいという課題があります。クラウド型のロードマップ作成ツールであれば、直感的な機能で、プロダクトマネージャーの負担を軽減してくれます。

世界的に人気なツールとしてAha!が知られています。後述するタスク管理ツールとの連携が充実しており、要件を優先順位付けして開発チームに伝達するのに容易となります。

• Aha!

大手企業から採用されているProductPlanも使いやすい機能で人気です。同社のブログやメールマガジンは、プロダクトマネジメントに関する情報が充実しており、とても参考になります。

• ProductPlan

その他にも、ロードマップを含めたプロダクトマネジメントツールは多数存在します。「プロジェクト管理」ツールでも、同様の機能が含まれるため、競争が激しい分野と言えます。多くのツールは大企業向けの有料プランになっているので、採用には慎重な判断が求められるかもしれません。

• Roadmunk
• Craft
• AirFocus

ユーザーの行動に関する仮説検証に焦点を当て、プロダクト開発を支援するGuildHubが開発されています。ベータ版ですが、その独自のアプローチで、プロダクトマネジメントの高度化を推進していくことが期待されます。

• GuildHub

タスク管理：開発者の作業管理・コード管理との連携が肝

製品の仕様は、優先順位と共に、開発チームへと伝達されます。実装するべき機能の一覧は「バックログ」と呼ばれ、プロダクト開発に関わる人が共有するべきものです。アジャイル開発を採用している場合、バックログから2週間程度の開発期間である「スプリント」や製品リリースごとに実装するべき要件を、シームレスに管理できる機能が求められています。

世界的にはJIRAとGithubを採用している企業が多く見られます。JIRAは開発者向けのツールが多数用意されているため、一つのライセンスで多くの作業が網羅できます。Githubはオープンソース向けに使われているケースが多く、使用に慣れた開発者も多く存在します。マイクロソフトによる買収でも話題になりました。

• Atlassian (JIRA)
• Github

日本ではBacklogの人気も高く、利用している企業も多く見受けられます。

タスク管理、ファイル共有もできるプロジェクト管理ツールBacklog

アジャイル開発を徹底する企業では、PivotalTrackerもが採用されています。

• PivotalTracker

タスク管理だけではなく、幅広いプロジェクト管理に使えるAsanaも有名です。そのユーザー体験の高さが特徴と言えます。

• Asana

カンバン形式のタスク管理が簡単に行えるTrelloも有名なツールです。直感的に使えるのが利点ですが、開発に関わる人数が増え、プロセスが複雑化すると、対応が困難になり、上記の本格的なツールが必要になる印象があります。

• Trello

フィードバック：Webサイトやアプリを利用するユーザーの行動を分析する

製品をリリースしたら、ユーザーの行動を分析し、問題を特定したり、さらなる機能改善の契機にしたりするのも、プロダクトマネージャーの重要な仕事です。Webサイトやモバイルアプリであれば、どのユーザーが何のボタンをクリックしたか、という情報を確認できるため、詳細なユーザーの行動が分析対象となるのです。また、ヒートマップと呼ばれる技術で、ユーザーが閲覧またはクリックした領域を、色分けする手法もあります。

近年は、セッション・リプレイという方法を使い、ユーザーが閲覧している画面を録画してしまう場合もあります。これまではユーザーがパソコンを使っている背後に立って、使い勝手を確認しなければならなかった作業がオンラインで行えるようになっています。

ユーザーの行動を確認するツールとしては、Hotjar、Heap、Fullstoryといったものが知られています。Googleアナリティクスでも十分に対応できるかもしれませんが、さらなる高機能を求める人は、下記のようなツールの利用を検討すると良いでしょう。

• Hotjar
• FullStory
• Heap

まとめ

プロダクトマネジメントの仕事は多岐にわたるため、それに関連するツールも多くのものが提供されています。はじめから全てのサービスに登録すると高額になってしまうので、自社の開発プロセスが成熟するに従い、少しずつ導入していく方法が推奨されます。本記事では、プロトタイプ、ロードマップ、タスク管理、フィードバックと分けて解説しましたが、これらの垣根が小さくなってきている傾向も見られます。多くの機能が一つになると、情報連携が容易になる一方で、各ステップで使いたい機能が利用できないという可能性もあります。ツールの最新情報を確認し、自社にとって最適なものを選択したいものです。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネージャーの役割は、取り扱う製品やビジネスモデル、さらには企業文化に影響されます。プロダクトマネージャー一人一人にインタビューすれば、その回答は全て異なるのではないかと言われる程です。同じ会社でも、部署が違えば求められる能力も違います。

例えば、AirbnbのようなB2C企業であれば、ユーザー体験に詳しいプロダクトマネージャーが求められるでしょう。一方で、AWS（アマゾン・ウェブ・サービス）を始めとする技術者向け製品であれば、技術的な素養が必須です。本記事では、GAFA、GAFAM、FAANGと呼ばれる米国のテック企業を例に、その役割の違いについて考察します。

Amazon：技術寄り、ビジネス寄りと異なるプロダクトマネージャーの役割

Amazonは徹底した顧客主義やデータに基づいた意思決定を重視する企業文化で知られています。プロダクトマネジメントにおいても、顧客にとっての価値をKPI（重要評価指標）で証明する態度が求められ、数字に強いプロダクトマネージャーが求められる印象があります。

Amazonの求人サイトを見ると、技術寄り（Technical）のプロダクトマネージャーと、技術寄りではない（Non-technical）プロダクトマネージャーが募集されています。技術寄りのプロダクトマネージャーは、顧客のニーズを製品計画や仕様に落とし込む役割を担います。ソフトウェア開発の学位や就業経験はもちろん、MBAの学位が評価されます。技術とビジネスの双方に知見のある人材が求められています。

一方、技術寄りではないプロダクトマネージャーは、担当する領域の業務知識やユーザー体験に関する知識が必要です。技術寄りではなくても、基本的なソフトウェア開発方法論を持っている人材は好まれます。

Facebook：個人に責任が委譲されたフラットな組織で周囲を巻き込み製品開発を牽引する

世界を開かれて、つながったものにするというミッションを掲げるFacebookは、全世界に20億人以上のユーザーを抱えるようになりました。そのミッションが表すように、従業員たちの関係もフラットで、個人に責任が委譲されていると言われます。ザッカーバーク氏が「完了は完璧よりも良い（Done is better than perfect）」と唱えたように、スピード感を持って、柔軟に取り組んでいく姿勢が求められる環境です。

Facebookでの製品開発は、多数のユーザーに展開してもコストが増加しないよう、拡張性が重視されます。プロダクトマネージャーも、技術的な知識が求められる場合が多く見られます。また、フラットな組織であっても、リーダーシップを発揮して、周囲を巻き込んでいく能力が評価されるようです。

Google：関連部署との利害を調整できるコミュニケーションが要求される

検索エンジンやGoogleマップに見られるように、Googleは膨大な情報を多くのユーザーが活用できるようユニークな製品を開発してきました。現在の姿にとらわれず、ユーザー体験の向上を追求し、それを世界中に展開するのを得意としている企業です。初めは馬鹿げたアイデアに見えても、それを可能にしてしまう技術力があります。

Googleのプロダクトマネージャーは、関連する領域の担当者とコミュニケーションをとり、戦略的に製品開発へ取り組める人を求めています。言われたことを実行するよりも、価値のある問題発見、問題設定ができる態度が好まれます。

実際、ジョブ・ディスクリプション（職務記述書）では、開発・マーケティング・法務・ユーザー体験といった関連部署と協業する責務が明記されています。知識や興味の異なる部署と会話するには、それらの分野の基本的な知識と高いコミュニケーション力が必要になるでしょう。

Apple：ソフトウェアからハードウェアにまたがるビジネスモデルへの理解

Appleの企業イメージと言えば、洗練さや創造性といったものが挙がるのではないでしょうか。iPhoneに代表されるように、誰もが羨むような高品質な製品を発明し、情報産業を牽引してきました。いわゆるGAFA企業の中では、ハードウェアの開発を手掛けているという違いがあります。

Appleのプロダクトマネージャーは、ユーザー体験への理解が欠かせません。徹底した顧客目線により、洗練された製品開発を牽引します。全く新しい製品カテゴリに対し、起業家精神をもって取り組む役割が与えられる場合もあります。また、Appleは独自の仕様に基づいて製品群を提供する「閉じたエコシステム」を展開する傾向があるため、Apple製品への理解も評価される傾向にあります。

Netflix：博士課程の保持者を含め、高い専門性が期待される

動画配信プラットフォームとして急成長を遂げたNetflixは、個人の自由と責任を重視する企業文化で有名です。例えば、休暇を何日でもとっても良いとされる一方で、その分、個人に与えられた成果は確実に達成することが要求されます。ポリシーよりも個人を尊重するというやり方は人を選ぶと言われます。

Netflixのプロダクトマネージャーには、担当する分野への興味と共に、高い専門性が求められます。例えば、コンテンツの検索機能を担当するプロダクトマネージャーであれば統計や機械学習技術に関する修士や博士の学位取得が要件となる程です。

Microsoft：製品開発の各フェーズでリーダーシップを発揮する

マイクロソフトは、WindowsやOfficeを始め、企業のIT利用、生産性向上に欠かせない存在であり続けています。近年は、クラウド事業に注力し、大企業ながら、柔軟にビジネスモデルを変えていく頑健さを見せてきました。多様な技術を取り入れ、ビジネスの成長にするのが特徴です。

マイクロソフトのプロダクトマネージャーは、ビジネスの成長を実現するリーダーとしての役割が求められています。関係各所とコミュニケーションをとり、製品開発の各フェーズで求められる責任を愚直に遂行していくことが要求されているようです。

まとめ

ソフトウェア業界におけるプロダクトマネジメントは、GAFA等のテック企業で発展してきた側面があります。プロダクトマネージャ―は技術とビジネスをまたぎ、関連部署を結びつけて、製品開発に関するリーダーシップを発揮します。たとえ、人事上の部下を持っていなくても、戦略立案と遂行において、その責任は重要なものです。その分、大手テック企業では、高い給料が与えられる役職でもあります。やりがいある仕事に挑戦したい人は、プロダクトマネージャーへの理解を深め、そのキャリアパスについて検討してみてはどうでしょうか。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネージャーとプロダクトオーナーは、製品開発工程の中で異なる部分に注力しながらも、互いに重なった責任範囲を持ち、協力しながらプロダクトマネジメントを実施します。プロダクトマネージャーは顧客寄り、プロダクトオーナーは開発寄りの責任を担うのが一般的です。企業の規模や開発する製品の特徴に応じて、その役割を定義していく必要があります。

プロダクトマネージャーとプロダクトオーナーの違いとは

プロダクトマネージャーは、製品開発の工程の中でも、より上流・顧客寄り・長期的・戦略的な仕事を担います。一方で、プロダクトオーナーは、下流・開発チーム寄り・短期的・戦術的な部分に責任を持っています。

プロダクトマネージャーは、顧客の声を代表する存在として、市場やユーザーを深く理解し、その解決策を提案する役割です。製品ロードマップを作成し、マーケティングチームと協業しながら、製品の価値を市場に届ける仕事があります。ビジネス側の観点から製品開発に携わり、収益性の評価や予算の獲得などを通して、経営層にレポートします。

プロダクトオーナーは、開発チームで行われる週次・日次のミーティングに参加し、実装するべき製品機能を伝える役割があります。実装するべき機能は「バックログ」と呼ばれるリストにまとめられますが、そのチームのバックログについて、優先順位を立てたり、必要なくなった機能を削除したりといった仕事が求められます。

プロダクトマネージャー及びプロダクトオーナーは、「何を」実装するかを管理しますが、「いつ」「どのように」実装を行うかは、プロジェクトマネージャーやスクラムマスターの責任に移ります。開発者に作業を割り振ったり、見積もりを行ったりするのは、開発チームに委ねられており、プロジェクトマネージャーがその責任を負います。

プロダクトマネージャーとプロダクトオーナーは、どちらが偉いということはなく、そのコミットするべき仕事が異なっているのです。チームが小さいうちは、役割が兼務されていても、チームが大きくなるにつれて、細分化し、役割分担が進んでいきます。その仕事はゆるやかに重なっており、それぞれが情報交換しながら、製品開発に取り組みます。

技術寄り、ジェネラリスト、ビジネス寄りのプロダクトマネージャー

プロダクトマネージャーやそれに関連する役割は、企業や携わる製品によって異なってきます。米コンサルティング会社マッキンゼーは「Product manager for the digital world」の中で、典型的なプロダクトマネージャーの3類型として、「テクノロジスト（技術者）」「ジェネラリスト」「ビジネス・オリエンテッド」を挙げています。

技術寄りのプロダクトマネージャー

エンジニアとして経歴を積んだ人が、テクノロジーの視点からプロダクトマネージャーの役割を担うケースです。ソリューションの技術面に注目しているのが特徴で、主に、複雑なB2B製品やバックエンド製品を扱う企業でよく見られます。ビジネス上の指標よりも、技術的な面白さを追求する傾向があります。Amazon Web Serviceのようなエンジニア向け製品の開発が例となります。

ジェネラリストのプロダクトマネージャー

技術的な経験を持ちながら、ビジネス上の知識を持ち合わせている人が、ユーザー体験を重視して、製品開発に取り組むパターンです。B2B製品のフロントエンド開発や、B2C製品の開発によく見られます。利用者の指標に基づいて、製品ロードマップを作成していきます。FacebookやAmazonの画面回りといった製品開発をイメージすると良いでしょう。

ビジネス寄りのプロダクトマネージャー

ビジネス系の経験を積んだ人がプロダクトマネージャーになるケースです。B2C製品でよく見られる配置で、ビジネス上の指標を最大化するのを目的としています。ゲームの開発のような場面がその例となります。

まとめ

プロダクトマネージャーは製品開発工程のうち顧客寄りの部分を担当し、プロダクトオーナーは開発寄りの作業を実施します。プロジェクトマネージャー等を含め、関連する役割は、それぞれ重なった責任を持ち、情報共有しながら仕事を行うことになります。企業の規模や開発する製品によって、プロダクトマネージャーの役割は異なってくるので、チームの現状を踏まえた上で、その役割を定義する必要があります。

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

プロダクトマネージャーは、その経験に応じて、ジュニアレベルからシニアレベルまで役職が設けられています。初めのうちは、機能の一部だけに責任を持っていたところから、徐々に製品全体、あるいは、複数の製品ポートフォリオを管理するようになっていきます。経営層ではCPO（チーフ・プロダクト・オフィサー。最高製品責任者）を設けている企業もあります。

情報科学やマーケットに関する知識がプロダクトマネージャーへ転身するのに役立つ

プロダクトマネジメントは、ユーザーや技術にまたがる様々な知識と経験が必要です。プロダクトマネージャーになるには、それに近い役割で経験を積み、ステップアップするというアプローチが現実的かもしれません。エンジニアとして要件定義から実装、テストまで全ての工程を経験した後に、ビジネス要件やシステム要件に力を注ぎ、プロダクトマネージャーへ転身するキャリアパスが考えられます。

新卒でプロダクトマネージャーに進むには、情報科学やそれに類する学位を取得した後、デジタル・サービスを開発する企業に就職するのを狙うことになるでしょう。また、既に起業を経験した人や、副業で自分のモバイルアプリやWebサービスを制作してきた人も、優れたプロダクトマネージャーの候補になり得ます。自分で製品を作るというのは、ユーザーについて思いをめぐらし、彼らが抱える課題を解決するプロダクトを生み出すというプロダクトマネジメントのプロセスに他ならないからです。

大企業においては、MBA取得後のキャリアパスとして、プロダクトマネージャーは一つの選択肢となります。MBAでは会社経営について浅く広く学ぶため、それぞれ異なる利害関係者と会話するのに役立ちます。また、指標の分析やビジネスケースを作成するのに、ビジネススキルが効果的です。

日本特有の状況として文系SEがあります。情報科学の学位を持っていないものの、システム開発の業務経験があるという人にとって、プロダクトマネージャーは魅力的なキャリアパスに映るかもしれません。プロダクトマネージャーはユーザーの体験や情緒的価値に思いを馳せ、それを製品のアイデアに落とし込みます。特有の業界で経験を積んできた人は、その業界においてビジネス寄りのプロダクトマネージャーとして活躍できるでしょう。

6段階のキャリアパス

プロダクトマネージャーのキャリアパスは企業や業界によって異なりますが、一般的には、その経験年数に合わせて、ジュニア・ミドル・シニア・ディレクター・バイスプレジデント・CPO（チーフ・プロダクト・オフィサー）といったレベル分けがなされます。それぞれ、役割や求められる要件が異なってきます。

ジュニア（アソシエイト）レベルのプロダクトマネージャー

初めてプロダクトマネジメントに携わる人が、その仕事の一部を担当し、より上位の役職者へ提案を行います。ユーザーの行動にまつわる指標を分析して、ユーザーのニーズを理解したり、小さな機能についてユーザー体験の定義を行ったりするのが、日常的な仕事となります。

ミドル（中級・主任）レベルのプロダクトマネージャー

他の役割で業務経験を積んだ人がプロダクトマネージャーに転身する場合には、ミドルレベルから始まるのが一般的です。一つの大きな機能について責任を持ち、開発のロードマップの作成などを行います。他のチームの人が、その機能について問い合わせを行う場合の窓口と考えればよいでしょう。開発・UX・マーケティングといった他部門と連携し、一つの製品を作りあげていきます。

シニアレベルのプロダクトマネージャー

プロダクトマネージャーとして複数年の経験を積めば、シニア・プロダクト・マネージャーとして認められるようになります。より若いプロダクトマネージャーに助言をし、複数の製品ラインの面倒を見ます。部門間の衝突を解決したり、深刻な問題が発生した際に対応したりするのが、課長級あるいはミドルレベルでの仕事です。

ディレクターレベルのプロダクトマネージャー

プロダクトマネジメントの実務から、組織運営に移るのが部長級・あるいはディレクターレベルです。より良い業務プロセスを定義・最適化し、組織全体として効率的な業務が行えるよう、働きかけます。プロダクトチームの雇用計画に責任を持ち、より広範な意思決定を行います。

バイス・プレジデントレベルのプロダクトマネージャー

プロダクトマネジメントに関する本部長、あるいは経営層の一人として、会社の運営に携わります。他の経営陣と調整し、予算を獲得し、プロダクト部門を守り、存在感を発揮できるよう働きかけます。企業を代表し、製品の専門家として社外へアピールする役割も担います。

CPO（チーフ・プロダクト・オフィサー。最高製品責任者）レベルのプロダクトマネージャー

大企業では経営層の一人としてプロダクトに責任を持つCPOを任命します。CPOは短期的な指標よりも、長期的な観点から、製品の未来を定義し、製品戦略や全体のロードマップ策定に責任を持ちます。一つの製品だけではなく、複数の製品をポートフォリオとして管理し、予算や資源を最適に配分できるよう努めます。

プロダクトマネージャーに関連するポジション

プロダクトマネージャーに近い役割ながら、より細分化されたポジションに進むキャリアパスが考えられます。例えば、ビジネス寄りのスキルや経験が豊富な人であれば、プロダクトマーケティングマネージャーに進むことが可能です。製品・サービスを市場に出す活動や、市場からニーズを抽出することに焦点を当てたポジションです。関連して、見込み顧客やパートナー企業を含めたコミュニティに対し、自社が提供する技術を広く知らしめるエバンジェリストを設けている会社もあります。

また、技術面に強い人材は、テクニカルプロダクトマネージャーというポジションに進む方法が考えられます。技術的に複雑な製品・サービスを扱う企業でよく見られるポジションであり、開発チームと頻繁に協業するケースが見られます。さらに、開発チーム側に転籍して、テクニカルーリードやアーキテクトとしてのキャリアを進む人もいます。

財務面の指標を管理するプロダクトマネージャーの役割を考慮すると、より経営戦略に近い役割へ進む可能性もあります。事業責任者やチーフ・イノベーション・オフィサーさらにはCEOといった方向性へ進むキャリアもあります。

興味深いのは、自ら企業するプロダクトマネージャーもいる点です。自分のアイデアで製品・サービスを生み出し、成長させる経験を積むと、独立して、そのアイデアを試したいと考えるのも頷けます。顧客のニーズを抽出して製品・サービスへ反映させるというプロダクトマネージャーとしての経験は、スタートアップを立ち上げるのにも共通する部分があるのでしょう。

プロダクトマネージャーに求められるスキル

プロダクトマネージャーに求められるスキルは、その分野横断的な役割から、非常に多岐にわたります。技術・ビジネスはもちろん、ソフトスキルについても高いレベルが必要とされます。

まず、技術的な面については基礎的な事項を理解できている必要があります。必ずしも自身がプログラミングするわけではありませんが、何ができて、何ができないのかが分からないと、要件定義が困難になります。加えて、開発チームと協業する際に、共通認識を持って会話できないのは問題になるかもしれません。基礎的なアイデアや、自社の製品・サービスに関する知識は欠かせません。特に、ユーザー視点の設計を担当する場合があるプロダクトマネージャーは、ユーザー中心設計（UCD）やUX/UI（ユーザーエクスペリエンス、ユーザーインターフェース）に関する知識・経験があると望ましいとされます。

次に、ビジネス面についてもプロダクトマネージャーは、広範な知識が必要です。例えば、市場分析・競合分析ができなければ、どのような機能が顧客に求められているのか、投資に見合った売り上げが得られるほど市場規模は大きいか、といった質問に対し、プロダクトマネージャーは答えられるようにしなければなりません。ビジネス面の情報を分析し、長期的な成功をもたらすよう、戦略的な思考力が求められます。また、売り上げの予測や、価格戦略の策定、コストの分析といった基礎的な財務面の分析についても秀でているプロダクトマネージャーは高い評価を受けるでしょう。

異なる立場のチームをまとめて、製品開発を成功に導くプロダクトマネージャーには、特に、コミュニケーション能力やリーダーシップが必要とされます。自身の意見を適切に伝えられるプレゼンテーション能力や、顧客あるいは利害関係者の意見を聞き取るインタビュースキルといった技術も含まれます。交渉力やプロジェクトマネジメントスキルもあるのが望ましいと考えられます。

様々な利害関係者が携わる中、優先順位をつけて意思決定するのは、相応の経験が求められます。短期的な収益と長期的な繁栄、あるいは、収益につながりにくいセキュリティやプライバシー対応をどう進めるか、といった複雑な問題にプロダクトマネージャーは直面します。その際に、近視眼的にならず、多面的に考えた上で、倫理的な判断も考慮しながら、チームを正しい方向に導く態度が必要です。

プロダクトマネージャーのスキルを身につけるには

これまで見たようにプロダクトマネージャーのスキルは極めて実践的なので、実務を通してスキルを習得するのが望ましいと考えられます。自社でプロダクトマネージャーのポジションが設けられている場合は、そのキャリアに進めるよう、上長とコミュニケーションしてみるのが良いでしょう。その際には、自分がこれまでに得た経験がどのようにプロダクトマネージャーのポジションで活用できるか、これからどのようにして組織へ貢献できるのかをアピールする必要があります。

すぐにはプロダクトマネージャーのポジションにつけなくても、現在のポジションで、その力を発揮できないか考えてみても良いでしょう。例えば、現在、SEとして働いているのであれば、要件定義を含めた上流工程に力を入れるようにすれば、プロダクトマネージャーに求められるスキルが身に付きます。マーケティング側で働いている人は、より技術的な議論に参加し、プロダクトマーケティングマネージャーと重なる領域を担当できないか考えてみましょう。

自社内にプロダクトマネージャーがいる場合は、その人と交流してみて、メンターとしてアドバイスを受けられないか検討します。その人がどのようにしてスキルを身につけたのか、そのポジションに就いたのかといった情報が得られれば、自身のキャリアパスにも大きな影響があります。

社内での可能性が少ない場合は、副業・兼業で機会をうかがってはどうでしょうか。市場調査やUXデザインといった要素技術については、副業人材を求めている企業も多いでしょう。また、自らがプロダクトマネージャーとして、興味のある分野で製品・サービスを実際に作ってみるという方法もあります。自らの責任において、要件定義からリリース、そして運用まで担当するのはプロダクトマネージャーとして欠かせない経験です。他にも、ボランティアやプロボノ、コンサルタントとしてプロダクトマネージャーのスキルを身につける方法もあります。

プロダクトマネージャーの基礎的な知識を身につけるには書籍やオンラインセミナーなどが利用可能です。筆者もCourseraやUdemyといったオンラインプラットフォームで公開されているプロダクトマネージャー向けの研修講座を受講した経験があります。海外で活躍しているプロダクトマネージャー経験者の生の声が聴ける良い機会なので、有効に活用することが推奨されます。

プロダクトマネージャーのキャリアについて解説された書籍を紹介します。

エンジニアからプロダクトマネージャーへのキャリアチェンジ

もし、現在SEやプログラマーとして勤務しているとして、プロダクトマネージャーのキャリアパスを検討しているとしたら何から始めたら良いのでしょうか。まず、前述したようにプロダクトマネージャーに求められるスキルを洗い出すのが推奨されます。そして、自分が現在持っているスキルや過去の経験から、何が不足しているのか、あるいは、何が活用・転用できるのかを検討します。そうすれば、プロダクトマネージャーになるために学ぶべきことや、アクションプランが明らかになります。足りないスキルだけではなく、ネットワーキングの面からも検討してみると良いでしょう。すでにプロダクトマネージャーとして働いている人を知らないのであれば、社内の先輩や、社外コミュニティから話を聞ける人がいないか検討します。

プロダクトマネージャーとして働くには、社内でそのような機会がないか調査する必要があります。一方、自分が副業・兼業でできないかといった選択肢も含めて考えてみるべきです。もし、社内でチャンスがなければ転職を視野に入れることになります。

転職と同時にポジションを変えるのは、一般的に、難易度が高いとされます。多くの企業は、中途採用の場合、経験者を欲しがる傾向にあるからです。そのため、プロダクトマネージャーとしての経験が少ない場合は、可能だとはいえ、十分な準備が必要です。具体的には、履歴書や職務経歴書をプロダクトマネージャー向けにカスタマイズして更新する、オンラインの転職プラットフォームに登録する、考えられる転職先について調査する、といった打ち手が考えられます。また、面接に進めた場合は、どのようなスキルを活用していきたいか、プロダクトマネージャーとしてどのように転職先へ貢献できるか、といった想定される質問に、口頭でどのように答えるかを準備するようにしましょう。

プロダクトマネージャーは、何か資格があればなれるという類のものではないので、実務で経験を積んでいくのが最も重要です。一朝一夕では身につかないため、焦らず、継続的に反復的な学習を進めていくようにする必要があります。

本章ではエンジニアからの転職について、キャリアチェンジの方法を解説しました。他のポジションであっても、共通する点はあります。マーケティング側で働いていたとしても、ギャップのあるスキルを明確にして、それを埋めるアクションをとるというのは同様です。自分のスキルや、自社のやり方に合わせて、キャリアチェンジの方法を考えてみてください。

プロダクトマネージャーの将来性

技術やビジネス動向が変化し続ける中、プロダクトマネージャーの重要性は、まずます高くなっていくと考えられます。市場のニーズや、自社の経営目標、技術的な実現可能性などを考慮し、製品・サービスの開発をリードしてくれる人材は欠かせません。素早く変化する市場のニーズに対応できるよう、アジャイル開発に近い考え方を推進する企業が増える中、プロダクトマネージャーは貴重な人材です。

これまではベンダーに依頼して数か月・数年かけてシステム開発を行ってきたという企業では、運用フェーズで柔軟に機能開発できなくなり、ユーザーのニーズから離れてしまうという可能性があります。これから必要になるのは、限られた期間のプロジェクトを円滑に進める「プロジェクトマネージャー」よりも、リリースした製品・サービスが永続できるよう、継続して開発・運用していく「プロダクトマネージャー」が求められているのではないでしょうか。

企業の中でプロダクトマネージャーの不在が問題となるケースが見受けられます。新しいアプリをリリースしたものの、セキュリティ上の問題が露見し、すぐにアプリが閉鎖される、といった場合でも、プロダクトマネジメントのレベルが向上すれば、このようなリスクが軽減できたかもしれません。より製品・サービスの開発サイクルが短縮化される中でも、優先順位をつけて開発を進められるかどうかは、プロジェクトマネージャーの力量にかかっています。

近年は、人工知能技術の発達により、開発が効率化されています。ノーコード・ローコードツールが豊富になり、また、ChatGPTのような生成系AIがコードを作成してくれる例もあります。システムを開発する方法は高度化されていますが、「何を作るか」という領域については、まだ、プロダクトマネージャーが必要です。AIで自動化が進んだ時代であっても、ビジネスの方向性を決めるのは人間の役割と言えます。むしろプロダクトマネジメントの仕事にAIを活用して、どう効率化を図るかが重要になってきます。

まとめ

プロダクトマネージャーのキャリアパスは、小さな機能の開発から、製品全体の開発へ責任を持つように進んでいきます。経営層に近づくほどに、会社全体の製品戦略を管理し、予算や資源の配分に関心を持ちます。開発側の経験を積んだ人にも、ビジネス側の経験を積んだ人にとっても、プロダクト開発のロードマップに責任を持てるのは、興味深いキャリアパスなのではないでしょうか。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネージャーは「ジェネラリスト」であることが求められます。技術・ユーザー・ビジネスに携わる利害関係者に、製品ビジョンを伝え、製品を作りあげるという役割から、全ての分野について基礎的な知識を身に着ける必要があるからです。また、コミュニケーションやリーダーシップを含め、優れたソフトスキルも欠かせません。プロダクトマネージャーのジョブ・ディスクリプション（職務記述書）を通して、その役割と要件を理解していきましょう。

ハードスキルの観点では、関連する技術や市場調査の経験が求められる

「ジェネラリスト」として必要な幅広い知識と経験

プロダクトマネージャーは様々な部門の橋渡し役を担います。そのため、開発・デザイン・マーケティング・財務など、どの部門の担当者とも会話できるような基礎的な知識が求められる場面があります。それぞれについて、極めて優秀な専門家である必要はありませんが、共通認識を持って、部門間の調整に当たる必要があります。特に、開発に関して、見積もりが甘すぎる・厳しすぎるといった意見は、その人の感覚や経験に頼り勝ちです。リスクの高い部分を特定できるようなスキルを持っている人は優れたプロダクトマネジャーになり得ます。

最近はオンラインコースを使って、無料または安価に、それぞれの領域について学ぶことができます。学位としてのMBAは必ずしも必要ではありませんが、企業経営を薄く広く知っていると、プロダクトマネジメントの仕事に役立ちます。

最新のトレンドや技術に対する理解

優れたプロダクトマネージャーは、業界に関連するトレンドや技術について敏感なものです。ユーザーや市場の変化に敏感になり、競合他社の動きに追随していく必要があります。AIや5Gといった大きなトレンドはもとより、変化の激しいモバイル開発・フロントエンド開発といった分野でも、その概要程度はつかんでいないと、各部署の担当者と会話し、適切な意思決定が行えません。

トレンドの把握には、技術関連のブログやニュースレターの購読が推奨されます。Techcrunch、ProductHunt、VentureBeatといったニュースサイトに加え、ProductPlanのニュースレターは優れたコンテンツを掲載しています。

ロードマップやユースケースを作成するのに必要な思考力と分析力

プロダクトマネージャーが作成する成果物を考えると、それに求められるスキルが自ずと明らかになります。ロードマップを作成するには、関連するタスクを洗い出し、優先順位をつけて、計画を立てる力が求められるでしょう。異なる部署間で認識を合わせるには、求められる機能やユースケースを文章や図で表現し、それを伝達する必要があるので、ライティングやプレゼンテーションの経験も欠かせません。また、製品やユーザーの行動を把握する指標を管理・改善する場合や、プロダクトの収益性を計る際に、数字を扱うため、計算に強い人はプロダクトマネジメントに有利でしょう。

ソフトスキルの観点では、リーダーシップやコミュニケーション力が必要

製品のあるべき姿を示すビジョナリー

プロダクトマネジメントは、製品の「あるべき姿」を描きます。ユーザーが抱える課題に対して最適な解決策を提示し、製品に関するビジョンを示すのです。スティーブ・ジョブスやジェフ・ベゾスといった起業家は、この点に関して圧倒的だと言えるでしょう。その製品ビジョンに関して、利害関係者を巻き込み、成果につなげていくのがプロダクトマネージャーの役割です。

異なる部門をまたがってチームをまとめるコミュニケーション

多くの利害関係者と関わる性質上、優れたプロダクトマネージャーは対人スキルに秀でています。傾聴、交渉、調整、権限委譲といったコミュニケーションにまつわる、あらゆるスキルを使う場面が発生するからです。興味や働き方の異なる部門をまたがり、製品の成功という一つの目標に向けてまとめていくリーダーシップが求められます。

戦略に秀で、製品開発や時間管理において、最適な手段を講じる

不確実な状況で最適な選択が一意に決まらない状況では、勝つ確率を高めるために複数の手段を講じて、より良い方法を模索していかなければなりません。市場や技術、競合他社が変化していく状況では、プロダクトマネージャーは常に、このような戦略的思考を行う必要に迫られています。成果物を作るだけでは十分ではなく、プロダクトの成功という成果にコミットするのがプロダクトマネージャーです。

多くの仕事を抱えるプロダクトマネージャーは、時間の使い方についても戦略的です。自分が成果を発揮できる作業や、重要な仕事に時間をさき、そうでないものは優先順位を下げて、仕事を調整していきます。

プロダクトマネージャーのジョブ・ディスクリプション

欧米では雇用する際に、ジョブ・ディスクリプション（職務記述書）を定義して、その人の役割を明確にするのが一般的です。典型的なプロダクトマネージャーのジョブ・ディスクリプションから、その役割を見てみましょう。

以下がプロダクトマネージャーの雛形であり、大きく2つの章から構成されます。

プロダクトマネージャーの責任と役割

• ユーザー体験を深く理解し、プロダクトの問題や機会を特定する
• シェアを伸ばし、ユーザー体験を改善する新しいアイデアを考案する
• 製品のビジョンに関し、社内で共通理解をつくり、重要な社外のパートナーと共有する
• 価格とポジショニングに関して戦略を立案する
• プロダクト戦略を、具体的な要件やプロトタイプに落とし込む
• ビジネス面での貢献を勘案し、製品開発の優先順位をつける
• 開発チームと協業して、市場に出すまでの期間やリソース配分を最適化する
• PRチームや経営層と協業し、製品リリースを計画する
• マーケティングチームと協業し、製品ビジョンが効果的に顧客へ伝わるよう、プロモーション計画を支援する
• QA（品質保証）チームと協業し、テスト計画を支援する
• 製品の認知度や理解を深まるよう、「エバンジェリスト」として活動する
• 顧客の声を収集し、製品やサービスに関するフィードバックを受ける

プロダクトマネージャーに求められる要件

• プロダクトマネージャーとしての経験（年数は求人のレベルに応じて変わる）
• 製品開発ライフサイクルの各局面における経験
• 製品やマーケティングの戦略を立案し、経営層へ伝えた経験
• ソフトウェア開発のハンズオン経験
• 情報科学や、それに類する学位
• アジャイル手法に関する深い理解
• コミュニケーション、プレゼンテーション、リーダーシップスキル
• 時間管理のスキル
• 分析と問題解決のスキル
• 創造性。細部へのこだわり

まとめ

プロダクトマネージャーに求められるスキルを見ていくと、何でもできる「天才」のように見えるかもしれません。確かに、幅広いハードスキル・ソフトスキルが求められますが、重要なのはユーザーを理解し、製品開発をリードする点です。詳細な部分は専門家へ権限委譲し、何でもやろうと思わないことも重要になってきます。プロダクトマネージャーを目指す人は、それに関連するオンラインコースを受けたり、業界のニュースを分析して自分の意見を持つようにしたりして、その役割を担う準備をするようにしましょう。

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

プロダクトマネジメントとプロジェクトマネジメントは、関連する役割で、かつ似た単語を使っているため、混同してしまう人も多いでしょう。プロダクトマネジメントは、「What」何の機能を作るのか、「Why」なぜその機能を作るのかを明らかにします。一方、プロジェクトマネジメントは「How」どのように「When」いつ作るのかに責任を持ちます。その責任範囲の違いから、役割は区別されます。

プロダクトマネジメントは、ユーザー・開発者・ビジネスの満足を追求する

プロダクトは、何らかの問題を解決し、ユーザーのニーズを満たすものです。プロダクトは初めに市場へリリースされてから、バージョンアップを繰り返し、製品提供をやめるまで、そのライフサイクルは続きます。プロダクトマネジメントは、ある製品についてDesirability（望ましさ。ユーザーのニーズ）、Feasibility（技術的な実現可能性）、Viability（経済的妥当性。収益性）を追求する手法です。ユーザー・技術・ビジネスの三方が全て満足できるよう、実装するべき機能と、その優先順位づけを行います。

プロダクトマネージャーは、製品開発の戦略に責任を持ちます。ビジョンやロードマップといった概要レベルでの製品計画を作成するのが、その役割です。具体的には、ユーザーと会話して要件を収集する、製品にまつわる課題や機会を特定する、実装する製品機能の順位付けを行う、といった作業に携わります。

プロダクトマネージャーが追求するべき指標（KPI）は、製品の成功そのものです。アプリを開発しているのであれば、アクティブユーザー数や離脱率がKPIとなるでしょう。これらのKPIが改善するよう、新たな機能を追加したり、重要な機能を優先的に開発したりするのがプロダクトマネジメントです。

プロジェクトマネジメントは、スコープ・予算・スケジュールをやり繰りする

プロジェクトは、ある「始まり」と「終わり」のある期間で、特定のタスクを遂行するものです。その期間で実施するべき作業が明確に定義されます。プロジェクトマネジメントは、スコープ・コスト・スケジュールの3つのトレードオフを管理する分野です。たとえば、開発するスコープが広がれば、人員を増やしてコスト増加を認めるか、スケジュールを延期するかしなければ、プロジェクトの品質は保たれません。利害関係者が納得するよう3要素を満足させるのがプロジェクトの成功です。

プロジェクトマネージャーは、計画の遂行に責任を持ちます。概要レベルの計画を、開発者が実施できるまで細分化し、実行可能な計画に落とし込みます。作業の見積もりと要員の割り振りにより、定められたリリース日にタスクを完了するよう努めます。リスクや課題の管理、必要に応じてスコープを変更するのも、プロジェクトマネージャーの重要な役割です。

プロジェクトマネージャーの評価指標（KPI）は、チームの効率性に対する評価を使うのが一般的です。一つの作業を完了させるまでのサイクルタイムや、定められた期間で実装できた機能の量（ベロシティ）といった指標を用いると、定量的に効率性が評価できます。

プロダクトマネジメントとプロジェクトマネジメントが混同される理由

プロダクトマネジメントと、プロジェクトマネジメントで共通しているのは、そこで求められているスキルです。異なる利害関係者とコミュニケーションをとり、また、目標達成のためにリーダーシップをとる、というのは共通しているものです。また、時間管理を徹底し、定められた期限に作業を完了させるという点も同様です。

プロダクトマネジメントとプロジェクトマネジメントが混同されやすいのは、似たような成果物を作成するからかもしれません。プロダクトマネジメントでは、概要レベルでのロードマップを作成し、1年～1年半程度の製品開発計画を作成する場合があります。一方、プロジェクトマネジメントでは、詳細レベルのタスクをガントチャートに落とし込み、誰がいつ何をやるのかを明確にします。

プロダクトマネージャーとプロジェクトマネージャーを兼務している際のリスク

企業によってはプロダクトマネージャーとプロジェクトマネージャーが兼務されている場合があります。何を作るのかを定義するところから、それをいつ、どのように作るかまで責任を持つ開発チームのリーダーは少なくありません。

実際、それらを遂行するためのスキルは全く異なるので、問題が発生するリスクがあります。プロダクトマネージャーは市場を最も理解し、顧客の代弁者となるべき存在です。一方で、プロジェクトマネージャーは開発プロセスをよく理解し、何にどの程度の時間が見積もれる人材でなければなりません。

社外に興味を向けるプロダクトマネージャーと、社内を管理するプロジェクトマネージャーは、その利害が衝突するケースがあります。プロダクトマネージャーにとってはユーザーの満足度を高める機能であっても、プロジェクトマネージャーにとっては予算を超過してしまい、実装が難しい機能かもしれません。利害の反する役割を、同じ人間が遂行するのは極めて困難です。

まとめ

プロダクトマネジメントは、何の製品機能を作るのかを決めるのに責任を持ちます。ユーザー・開発者・ビジネスを満足させるのが、その役割です。一方、プロジェクトマネジメントは、限られたスコープ・予算・スケジュールをやり繰りします。

プロダクトマネジメントとプロジェクトマネジメントは、似たような成果物を作ったり、同じ人間が兼務していたりして、混同されてしまう場合があります。実際は、求められるスキルが全く異なり、利害が衝突するケースさえあるものです。その違いを正しく理解し、その役割に適したスキルを磨けるよう、努めていきましょう。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネジメント・トライアングルは、Daniel Schmidt氏によって提唱されたフレームワークで、製品開発にかかわる要素とその関係性を示したものです。プロダクトマネジメントで行うべき活動と、解決するべき緊張関係についての理解を深めてくれます。

プロダクトを取り巻くユーザー・開発者、そしてビジネス

プロダクトマネジメントは、ユーザーを満足させる商品を開発しながらも、開発の予算や人員を上手に管理し、会社に収益をもたらすために追求される分野です。ユーザー・開発者・ビジネスの3者は、それぞれ異なる興味と利害関係を持っています。この関係性を上手く表現したのが、プロダクトマネジメント・トライアングルです。

トライアングルの頂点にはユーザー・開発者・ビジネスが存在します。ユーザーは、製品を通して何らかの目的を実現したいというニーズを持つ顧客です。開発者は、社内でプログラミング等を行い製品を開発するエンジニアを指します。ビジネスは、利益を追求する組織としての会社であり、管理職や経営層が責任を持っています。

それぞれの関係者をつなぐプロダクトマネジメントに関わる活動

トライアングルの3辺には、それぞれの利害関係者をつなげる製品にまつわる活動が該当します。ユーザーと開発者をつなぐのは、ユーザーを理解し、それを製品に反映させようとする活動です。ユーザー調査やWebアナリティクスなどを通して、ユーザーが抱える不満や隠れたニーズを理解します。ユーザーは自分のニーズを充足してくれる製品を探しているのに対し、開発者はその製品をいかに実装するかに興味があります。この異なる興味を橋渡しするのが、この領域におけるプロダクトマネジメントの活動です。

ユーザーとビジネスをつなぐ辺には、収益化やビジネスモデル開発、ビジネスデベロップメントの活動が該当します。ユーザーが頻繁に使う製品であっても、それにお金を払わなければ、会社は存続できません。よくベンチャー企業界隈で、ユーザー獲得に躍起になりながら、収益化を後回しにしている企業が見られますが、そのような企業は、ユーザーとビジネス間の検証を怠っていると理解できます。

開発者とビジネスをつなぐ辺には、予算管理、製品開発計画、資金の確保、プロジェクト管理が含まれます。会社が持つ予算は有限なので、開発者はいつまでも新製品の検証ばかりやっているわけにはいきません。最適な投資を行うために、開発者が最高のパフォーマンスを発揮できるよう支援し、組織が同じ方向に進めるよう努めます。

異なる利害関係から生じる緊張関係と、それを解決するプロダクトマネージャーの役割

各辺同士が交わるところには、それぞれ緊張関係が生まれます。ユーザーに関する部分では、「ユーザー・開発者」間での活動と「ユーザー・ビジネス」間での活動が交わります。たとえば、ユーザー調査の結果、顧客から支持された製品機能が、ビジネス面から見たら全く貢献しない場合、その製品機能は実装するべきでしょうか。広告を画面に表示するのは、ビジネス面ではプラスでも、ユーザーにとってはマイナスだったりします。このような緊張関係を管理し、意思決定を下すのがプロダクトマネージャーの役割です。

ビジネスにまつわる緊張関係では、「ユーザー・ビジネス」と「開発者・ビジネス」が交わります。ユーザーが購買意欲を示した機能について、開発者が優先順位を持って取り組むよう働きかけなければなりません。しかし、開発者は安定した製品運用を行うために、お金になる機能実装よりも、メンテナンスや効率性向上の取り組みを行いたいと希望するケースもあります。このバランスをとるのがプロダクトマネジメントの重要な仕事です。

開発者にまつわる領域は、「ユーザー・開発者」と「開発者・ビジネス」が交わる点です。ユーザーのニーズを検証するには、製品を実際に作るのが一番です。しかし、予算が限られた状態では、際限なく検証を行うわけにもいきません。そこで、最低限の機能を持った製品（Minimal Viable Product）を使ったリーン開発手法が採用されてきました。MVPのリリースにどの製品機能を含めるかどうかを決めるのは、製品開発の成否に大きく関わります。

プロダクトマネージャーの責任範囲

プロアクトマネジメント・トライアングルを踏まえると、プロダクトマネージャーの責任範囲は、複数チームにまたがり、かつ、それらを調整する役割である点が明確になります。具体的には、以下のような作業が含まれます。
まず、マーケットリサーチの実施、市場データの収集、および顧客フィードバックの分析を通じて、市場の機会と顧客のニーズを特定します。これらの洞察を活かし、プロダクト戦略を立案し、チームへ周知します。プロダクトのビジョン、ゴール、プロダクト全体の方向性を定めます。そして、製品戦略は、より詳細化した上で、優先順位を付けて、ロードマップを落とし込みます。プロダクトロードマップには、機能の開発、改善、およびリリースのためのタイムラインが含まれます。また、顧客フィードバックを踏まえて、ロードマップは更新が必要になるので、常に最新の状態にあるようメンテナンスを行います。

さらに、ロードマップから具体的な要件へと紐づけられます。ステークホルダーと連携した上で、詳細なプロダクト要件、ユーザーストーリー、およびユースケースを定義します。企業によってはプロダクトマネージャーがUXデザインを主導する場合があります。製品がユーザーのニーズ、使いやすさといった設計要件に焦点を当ててデザインされるよう試みます。開発局面では、複数チームにまたがるコミュニケーションを促進する役割を担います。例えば、デザイン、エンジニアリング、マーケティング、営業といったチームと連携し、統合されたプロダクト開発プロセスを目指します。

プロダクトマネージャーは、製品の成功を測定するための主要な指標（KPI）を定義し、データに基づいた意思決定が行えるよう目指します。技術的な指標だけでなく、経済面からの指標も対象となり、プロダクトが継続的に収益に貢献するよう確認します。そして、計画から開発、測定に至るプロセスは、反復的に行われるものであり、継続的に改善できるようにするのがプロダクトマネージャーの役割です。

プロダクトマネージャーに求められるスキル

プロダクトマネジメント・トライアングルを踏まえて、プロダクトマネージャーに求められるスキルを考察すると、幅広い分野が対象となります。技術・ビジネスといったものから、コミュニケーションやリーダーシップのようなソフトスキルも含まれます。

技術的知識
開発者である必要はありませんが、開発する製品の基本的な技術については理解しておく必要があります。要件定義の際に、当然、必要になるのに加え、エンジニアと会話する際に、基礎的事項が共有できていると、コミュニケーションが円滑になります。また、技術的な制約や、難易度、実現可能性を評価する際にも技術的な知識は必要です。加えて、近年のプロダクトマネジメントでは、アジャイル開発に基づいた場面が多く見られます。そのため、アジャイル開発や開発プロセスそのものについても理解しておくことが望ましいでしょう。

ビジネスの知識
予算管理や指標の測定・管理といった基礎的なビジネスの知識は、プロダクトマネージャーに求められます。やはり、マーケティングや営業といったビジネス側のチームと会話する際に、共通の言語を理解しておくのが、コミュニケーションにおいて重要になってくるのです。他にも、市場調査や競合分析といったスキルも、求められるビジネス知識に含まれます。広い意味では、戦略的思考やデータに基づいた意思決定、ロジカルシンキング、クリティカルシンキング、リスク管理といったものもビジネススキルの一部です。

ソフトスキル
異なる目標を持ったチーム間で意見を調整するには、高度なコミュニケーション能力が求められます。経営層から顧客に至るまで、幅広い層から意見を吸い上げ、また、必要に応じて、意見を主張する態度が必要です。また、製品ビジョンを実現するよう、リーダーシップを発揮し、目標に向かって複数のチームをまとめていきます。柔軟な対応が求められるアジャイル開発においては柔軟性や優先順位付けが重要になります。他にも、顧客中心主義や時間管理といったスキルも必要になると考えられます。

プロダクトマネージャーのキャリアパス

プロダクトマネジメント・トライアングルを考慮すると、エンジニア側からプロダクトマネージャーへ転身する方法と、ビジネス側から転身する方法が考えられます。いずれの場合も、過去の経験を活用した上で、各チームと連携する役割を担えるのが利点です。

ジュニアレベルのポジション
必要とされるスキルが高度であり、リーダー的な役割が求められることから、新卒レベルからプロダクトマネージャーを採用する企業はあまりありません。しかし、場合によっては、アソシエイト職のプロダクトマネージャーを置く組織もあります。上位の役職者を支援する役割で、市場調査やデータ分析といった仕事を担います。

技術側からは開発者やSE、UX/UIデザイナー、プロジェクトマネージャーといった役割からプロダクトマネージャーへと移る人が見受けられます。技術面の理解が高く、技術者との議論や製品の実現性評価といった面で活躍できます。一方、ビジネス側からは、ビジネスアナリスト、マーケティング分析者などがプロダクトマネージャーの候補となりえます。

シニアレベルのポジション
技術・ビジネスのスキルを身につけた後、プロダクトマネージャーの役割を担えるようになります。プロダクトマネージャーの中には、そのスキルセットに応じて、細分化した役割を任されるケースがあります。例えば、高度な技術の理解が必要な企業では、エンジニア出身の人材をテクニカルプロダクトマネージャーとして置きます。また、プロダクトマネジメント・トライアングルのビジネス側に重点を置いた、プロダクトマーケティングマネージャーへ移っていくケースもあります。

経営層のポジション
プロダクトマネージャーとして経験を積んだ人は、経営層の一人としてCPO（チーフ・プロダクト・オフィサー）へ進むキャリアパスが考えられます。会社全体の戦略に合わせて長期的な成長を目指し、製品戦略やイノベーション戦略を立案する役割です。また、経験を積んだプロダクトマネージャーは、自ら製品を開発するべく起業家になるケースもあります。

プロダクトマネージャーとしての体験談

筆者も技術系スタートアップでプロダクトマネジメントの役割を担った経験があります。プロダクトマネジメント・トライアングルで示されるように、異なるチームと調整する必要に迫られました。まず、開発者・ビジネス側との協業においてはロードマップの作成及びメンテナンスを行いました。CPOがトップダウンで出す戦略と、開発チームがボトムアップで報告する各イテレーションの進捗について情報収集し、ロードマップを最新化する作業です。顧客からの依頼などの受動的な案件が突発的に入るため、常に優先順位は変更され、必要なリソースも変わってくるので、それらの調整は大きな課題となりました。

また、マーケティング調査・市場規模分析・競合分析といった役割も担いました。複数ある領域の中から、それぞれの市場規模を予測し、次に参入するべき分野はどこかを考察する仕事です。スタートアップの資金調達で投資家から聞かれる成長戦略や、開発チームの作業計画に影響するものでした。調査会社が発表したトップダウンとの予測だけでなく、どのような顧客が何社あり、どのくらいの売り上げが期待できるかといった要素に分解し、ボトムアップ型の計算で市場規模を予測するのは簡単ではありませんでした。

筆者の場合、UI/UXに関わる経験は、それほど多くありませんでしたが、企業としてはユーザーインタビューなどを実施し、次なる製品戦略や要件定義に役立てています。このように、プロダクトマネジメント・トライアングルの各要素は、スタートアップの製品開発プロセスで実際に使われていることが理解できます。

まとめ

プロダクトマネジメントとは複数の領域にまたがる仕事なので、それを簡単にまとめるのは困難です。プロダクトマネジメント・トライアングルは、その全体像を俯瞰するのに有効な手法と言えます。実際は、企業によってプロダクトマネージャーの役割は異なっており、ビジネス寄りの人もいれば、開発者寄りのプロダクトマネージャーも存在します。重要なのは異なる利害関係者と上手にコミュニケーションをとり、製品の成功にコミットすることなのではないでしょうか。

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

プロダクトマネジメントの分野では様々なフレームワークが提唱されています。技術や市場にまたがる複雑な事象を簡単に理解できるよう整理し、関係者と共通理解を得るために、製品企画や優先付けに関する手法が生まれてきました。限られた時間や人員の中で、成功の確度を高めるように戦略的な意思決定を行うのがプロダクトマネジメントの肝です。

近年のプロダクトマネジメントは、反復的な検証によって、どの製品機能が有効かを明らかにする「リーン」手法が一般的です。全ての機能を一度に全て実装するのではなく、顧客から見た価値や、開発の容易さといった複数の視点から評価を行っていきます。

フレームワークを学ぶのはプロダクトマネジメントにおいて重要ですが、それらの手法を適切に運用するには、プロダクトマネージャーの力量が問われるところです。そのときの開発状況や業界構造、商品の特性などを考慮し、最適なフレームワークを選択する必要があります。また、評価は往々にして主観的なので、意味のある知見を得るには、よく考えてフレームワークを適用しなければなりません。

狩野モデル

狩野モデルは1980年代に東京理科大学の狩野紀昭教授によって提唱された品質管理に関するフレームワークですが、海外のプロダクトマネジメント分野でも、Kano modelとして一般的に取り上げられるようになりました。製品やサービスに求められる品質について、横軸に製品やサービスの充実度、縦軸に顧客満足度をとり、その要素の特徴を分析します。

「魅力的品質」は、充足すれば満足度を高めるが、不充足でも不満を感じないものです。プレミアム機能が該当し、差別化要因となりえます。

「当たり前品質」は、充足されて当然、不充足では不満を意味します。電話であれば通話ができる、自動車であれば安全に走るといった、基本的なニーズの充足です。コストを抑えながら、必ず充足するようにしなければなりません。

「一元的品質」は、充足されると満足、不充足だと不満といった、性能と評価が比例する機能です。また、充足されても、されなくても満足度に影響しない「無関心品質」、充足されると不満を引き起こし、不充足であれば満足させる「逆品質」もあります。

狩野モデルの分析は、製品開発の方向性を明確にしてくれます。どんなに「魅力的品質」があっても「当たり前品質」が欠けていれば使い物になりません。また、「一元的品質」で過剰に機能を作りこんでも「魅力的品質」による差別化にはかなわないものです。

品質に対する認識は時間をかけて変わる場合があります。以前は魅力的品質と思われたものが、製品の成熟とともに、一元的品質や当たり前品質になってしまいます。たとえば、携帯電話にはじめてカメラが付いたときは魅力的に思えたものが、画素数などの開発競争に至るころには一元的品質になり、今やカメラのついたスマートフォンは当たり前です。

オポチュニティ・スコアリング

新規製品には真新しさが重要ですが、ただ奇をてらったものを作っても意味はなく、何らかのユーザーのニーズを満たす必要があります。特に、既存の解決策では、ユーザーが満足していない分野に、新しいソリューションが提供できれば、大きなビジネスチャンスにつながります。

オポチュニティ・スコアリングは「機会の評価」を意味します。顧客にとって、その機能がどのくらい重要かを横軸、そして、顧客が既存の解決策にどのくらい満足しているかを縦軸にとって、評価を行います。

重要性に対して満足度が著しく低い場合、「Underserved（十分なサービスが提供されていない）」という評価になり、ビジネスチャンスが見いだせます。逆に、重要性に対して満足度が高すぎる場合、「Overserved（供給が過剰）」であり、競合企業との激しい競争が待っています。

既存の解決策を改善するイノベーションの評価に適したフレームワークですが、市場調査のデータを収集するのが簡単ではなく、評価が難しいというデメリットも指摘されています。

2×2 マトリックス（リーン・プライオリタイゼーション）

プロダクト開発は限られた時間・人員・コストで、製品の有効性を検証していかなければならないので、どの機能から開発していくのかを優先順位づけしていく必要があります。製品機能を実装する優先順位を明らかにするために、最も簡単な手法の一つが、2軸で各機能を評価し、4つの象限に分類する方法です。

リーン・プライオリタイゼーションでは、機能の価値と、実装に要する労力の2軸を使います。ここでの価値とは、後述のAARRRモデルで表されるように、ユーザーが製品を使う頻度を上げるような効果を指します。

• 価値も労力も高い：中長期的な成長を狙うため、戦略的に計画する
• 価値は高く、労力は少ない：すぐに効果が得られやすいので、先に取り組む
• 価値は低く、労力が大きい：時間の浪費になりがちなので、優先順位を下げる
• 価値も労力も低い：状況によっては、取り組んでもよい

2軸で分類するのは、シンプルながら応用が効く便利なフレームワークです。価値と労力だけではなく、「価値とリスク」「価値とコスト」「重要性と緊急性」など、様々な組み合わせが使われています。

ICEスコア

ICEスコアは優先順位を決めるのに有効なフレームワークです。ICEはそれぞれImpact（インパクト、影響度）、Confidence（確からしさ）、Ease（容易さ）の頭文字をとっています。各項目を1～10の相対的な値で評価し、3つの要素を掛け合わせた値をICEスコアとします。より大きな値をつけた機能は、優先して実装するべきものと判断可能です。ICEにReach（リーチ、影響範囲）を加えたRICEスコアも提唱されています。

Impactは、製品の成功度合いをあらわす指標、つまりKPIをどれほど改善するかを評価するものです。アクティブユーザー数を増やす、離脱率を減少させるといった効果によって、最終的に売り上げの増加に貢献します。

Confidenceは、上記Impactの評価が、どれほど確からしいかを評価します。プロトタイプを作ってユーザーから好意的なフィードバックを受けていれば高い値を受けますし、担当者のアイデアレベルであれば値は低くなります。ユーザーインタビューや市場調査といったConfidenceを高める取り組みを通して、反復的に製品や市場への理解を深め、成功への確度を高めます。

Easeは、機能を実装するのに要する難易度に対する指標です。開発やテストに要する時間やコストが少ないものほど、優先して検証を行うべきです。

ICEスコアの弱点として、主観的な評価である点が指摘されています。人によってそのスコアは異なるし、たとえ同じ人でも一貫性のある評価は難しいものです。ICEスコアは、完璧な定量化を目指すものではなく、優先順位を俯瞰するのに使うとよいでしょう。ICEの各要素を検証する取り組み自体が「リーン」な製品開発を促進します。

MoSCoWメソッド

MoSCoWメソッドは、優先順位付けを行うために要件分析で一般的に用いられる方法です。

• Must-have：必須。それ無しではいられない欠かせない機能
• Should-have：推奨。大きな価値を生む重要なもの
• Could-have：可能。あってもよい要件で、実施しなくても小さな影響にとどまる
• Won’t-have：先送り。現時点では優先して実施しないもの

開発者とのコミュニケーションに有効なメソッドで、チーム内での優先順位に関する合意を得るための使われます。例えば、次の製品リリースまでにどの機能を含めるかを決める際に、Mustの機能が実現できなければリリースを遅らせる、といった意思決定が可能になります。

どのように各指標を定義するかはチームごとによく吟味しなければ、MoSCoWメソッドはうまく運用できません。たとえば、機能を要求するビジネスチームは、何でもMustにしたがるかもしれませんが、限られた時間内で全てを必須にすることはできません。また、先送りばかりしていると、実装していない機能が山積みになり、管理不能になるケースもあります。

AARRR

グロースハックをはじめとするビジネス側で有名なフレームワークですが、製品のビジネス的な成功に責任を持つプロダクトマネージャーにとっても有効な手法です。5つのフェーズから構成され、以下に示す頭文字をとってAARRRと呼ばれます。

• Acquisition：獲得
• Activation：使用開始
• Retention：継続利用
• Referral：紹介
• Revenue；収益

AARRRフレームワークでは、各フェーズに重要な指標（KPI）を定義して、製品の成功度合いを評価します。1000人のユーザーを獲得したうち、100人が利用を開始し、10人が継続利用している、といった定量評価を行い、その指標を改善するような施策を実施します。

ジョブ理論

「イノベーションのジレンマ」で知られるハーバード大学クリステンセン教授の論文で有名になったジョブ理論。顧客が成し遂げたい目的を「ジョブ（仕事）」として定義し、その目的を達成するために商品を「雇用」するという考え方に基づき、商品企画を行うフレームワークです。

「ドリルではなく穴を売れ」と言われるように、人は商品ではなく、成果を求めているもので、それを達成するためには、様々なオプションがあるものです。ユーザー目線でソリューションを分析するため、製品のあるべき姿を企画できます。ジョブ理論は、社会的な目線や感情的な側面にも注目しているのが特徴です。また、「買わない」という選択肢も含めて考えることで、ユーザーの購買判断を正確に評価します。

顧客目線が重要とはよく言われますが、顧客自身が本当に欲しいものを理解していない場合も多々あります。自動車の開発を行っていたヘンリー・フォードは、「もし人々に何がほしいかと聞いていたら、もっと速い馬が欲しいと答えていただろう」と述べました。ジョブ理論は、このような全く新しい製品カテゴリの開発を行う場合に適しています。現在行っている「仕事」をいかに解決するかを考え、新たなソリューションの創造を目指します。

まとめ

プロダクトマネジメントには様々なフレームワークが提案されています。日本では親しみがないものもあり、日本語にして理解するのが難しいケースもあるかもしれません。このようなフレームワークは頭で理解しているだけでは意味がなく、実践して初めて意味があるものです。プロダクトマネージャーを目指す人は、副業で作成する商品にフレームワークを適用して企画したり、世間で知られている商品をフレームワークで分析したりして、その実践経験を積んでいくと良いでしょう。

テクノロジーの聖地シリコンバレーからPMの仕事や魅力とキャリアの可能性を、在住13年以上、現在米系スタートアップで働く現役Principal Product Managerが具体的事例をもとに紐解きます。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

プロダクトマネジメントは、顧客のニーズを理解し、それに対応するソリューションを定義して、製品の継続的な成功を実現するための手法です。日本ではプロダクトマネージャーを置いている企業が多くないので、その手法を学ぶ機会が限られてしまいます。オフライン、オンラインの研修の機会を紹介します。

プロダクトマネジメントは理論よりも実践が重要な分野であるため、経験に基づいて解説できる専門家の存在が重要です。書籍やオンラインのリソースを使って頭では理解していたとしても、実際に業務で使ってみると、どのようにしたら良いか分からない場合があるかもしれません。そのような場合に、セミナーを介して、専門家の生の声を聞くと、実践的な学びが得られるでしょう。講座によっては、講師や生徒同士で交流する機会が得られるケースもあるので、対話を通じて学んでいくことも可能です。

プロダクトマネジメントのセミナーを選択する際の観点としては、講師の経歴や解説される内容、セミナーの形式、（場合によっては）プラットフォームの仕組みなどが挙げられます。それぞれ、信頼できる情報であること、自身の興味や目的に合致していることを十分に確認するようにしましょう。
プロダクトマネジメントを学ぶ際には、実際のシナリオやケーススタディを通じて学習すると効果が高まります。学んだ理論を実践に活かすため、安全ではあるものの、実務に近い環境で試すと、即戦力として活躍できるようになるでしょう。

セミナーによっては公式の受講証明書を発行してくれるものがあります。このような経験は履歴書や職務経歴書に記載できる場合があるので、プロダクトマネージャーへの昇進・転職を検討している場合は、能力・意欲をアピールできる実績としてセミナーを受講するのも良い考えです。

PMが知っておきたい「プロダクトマネジメント」の視点

日本のシステム開発プロジェクトでは、品質やスケジュールに責任を持つプロジェクトマネージャーが、製品仕様の定義にも責任を持ち、プロダクトマネジメント的な役割を担うケースが多々あります。そのようなケースに役立てるよう、プロジェクトマネージャーがプロダクトマネジメントの視点を持てるよう助けるのが、このセミナーです。
プロダクトマネジメントとプロジェクトマネジメントの違い、プロダクトマネージャーの役割、プロダクトマネージャーに必要なスキルなどが解説されます。定額制で受講できる社員研修制度SEカレッジからの提供です。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management

シリコンバレーでプロダクトマネジメントの経験を積んだ講師がオンラインセミナーを公開しています。米国スタートアップの基準で実施されているプロダクトマネジメントの基礎が学べる貴重なコンテンツです。プロダクトマネジメントの仕事とは何か、アジャイルソフトウェア開発プロセス、プロダクトマネージャーが生きる組織、キャリアパス等が学べます。講師のTwitter（@haruki_sonehara）をフォローしてDMを送ると、割り引きクーポンが発行いただけるという特典が付いています。

プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management：Udemyで開く

プロダクトマネジメント実践講座: シリコンバレーの現役プロダクトマネージャーが伝授する、世界の最前線で使われるKPI

前述した講座の続編として、KPIを取り上げた実践講座も公開されています。プロダクトマネジメントでは、製品がどのように顧客から利用されているのかを定量的に評価するためKPI（重要業績評価指標）の設定および監視が重要なステップとなります。誤ったKPIを設定してしまうと、実装する製品機能やビジネス上の戦略立案において、意思決定も誤ってしまうからです。North Starメトリック、既存顧客維持、ユーザー離脱、A/Bテスト等が学べます。

プロダクトマネジメント実践講座: シリコンバレーの現役プロダクトマネージャーが伝授する、世界の最前線で使われるKPI：Udemyで開く

Digital Product Management: Modern Fundamentals

英語のコンテンツになりますが、米国のバージニア大学で開催されている講座が無料で公開されています。週に3～4時間を4週間かけると、まるで大学の講座を受けているような体験が得られるのが魅力です。
デジタル製品のプロダクトマネジメントについて、方法論や新製品開発のアイデア、既存製品の改善といったテーマを深く学ぶことができます。また、米国でプロダクトマネジメントを実践している人のインタビューもあり、最先端の体験談も含まれています。
講義資料やスクリプトがダウンロードできるので、英語の勉強としても使えるかもしれません。英語で大学の講義を理解できるようになれば、TOEICもTOEFLも良い成績が得られるでしょう。試験をパスすれば、有料でコース認定証の発行も可能です。

まとめ

プロダクトマネジメントは、最近広まってきた手法であるため、講師を務められるような経験者がそれほど多くないのかもしれません。オンライン、オフラインの中から最適なコンテンツを見つけて、体型的に学べるようにしましょう。無料の資料や、書籍から学ぶ方法もあります。一つのセミナーを受講すれば、そこで参照されていた情報に広げて学習を深めていくことが可能です。ソフトスキルを含めた総合的な技術であるプロダクトマネジメントは、プロとしてのキャリアアップにも良い影響を及ぼすことが期待されます。

プロダクトマネジメントは、実践的なスキルであるので、自分だったらどうするか、自分はどのような意見を言えるかという視点で学習を進めることが推奨されます。セミナーを受ける場合でも、積極的に質問したり、Q&Aセッションを活用したりして、インタラクティブな環境を作ると、より良い情報が得られると考えられます。

プロダクトマネジメント不在のまま、製品・サービスを開発し、問題を抱えてしまう事例も見受けられました。優先順位付けができず、売り上げが十分に得られる前に、コストが過剰にかかってしまう。ユーザー中心の考えがなく、不要な機能ばかり作りこんでしまう。セキュリティなどの重要な非機能要件が見過ごされ、サービス停止に追い込まれる。プロダクト・マーケット・フィットが見いだせない。ロードマップが描けず、あったとしても実現できない。規模を拡大する際に、技術的な問題が発生する。問題が社外にも知れ渡った結果、ブランドの毀損、信頼の失墜につながる。以上のように、枚挙に暇がありません。

プロダクトマネジメントのスキルは、様々な場面で活用できます。例えば、エンジニアからプロダクトマネージャーへのキャリアアップを叶えてくれるかもしれません。自分の興味がある分野で、自社サービスを開発・運用している会社へ転職し、プロダクトマネジメントのスキルを発揮できれば理想的ではないでしょうか。また、コーディングの経験があまりないビジネス側の担当者が、プロダクトマネジメントのスキルを習得すれば、製品・サービス開発を促進し、エンジニアとの会話も円滑になるかもしれません。他にも、独立してWebサービスなどを開発するといったキャリアも考えられます。

プロダクトマネジメントは、製品を創造し顧客に届ける全工程において、計画・生産・マーケティングなど、あらゆる作業を含みます。チーム間の調整やデータ、業務プロセスの分析等の手法を適用し、新しい製品を市場に投入する際に考えられるリスクを低減します。

プロダクトマネジメントは、ビジネス・テクノロジー・ユーザー体験の交差点にあるもの

競争や変化の激しい時代では、どんな分野・規模の製品であっても、ただ商品を作れば売れるというわけではありません。また、価値のない商品を、セールスの手法を使って無理やり売り込んだとしても、長期的な成功は見込めません。特に、新製品の場合、問題を抱えた顧客がどこにいて、何のソリューションを提供すればよいのか、明らかではありません。これらの製品開発にまつわる困難に取り組む方法論がプロダクトマネジメントであると言えます。

プロダクトマネジメントの目的は、価値があり（Valuable）、使いやすく（Usable）、そして、実現可能（Feasible）な製品を開発し、顧客に提供することです。ビジネス・テクノロジー・ユーザー体験が重なる領域が、プロダクトマネジメントの本質であると言えます。

ビジネスの観点では、製品から得られるビジネス上の利益を最大化するのが目的となります。プロダクトマネージャーが「ミニCEO」のように振る舞うと言われるのは、製品の成長に責任を負うからです。

テクノロジーの観点では、技術的に最適化された製品を開発する必要があります。プログラミングを全て理解する必要はありませんが、どのような仕組みになっているのか理解し、利害関係者に説明できる責任があります。

ユーザー体験の観点では、顧客が求めるニーズを理解し、顧客と継続的な関係を築けるよう、製品の機能及びサービスを作りこまなければなりません。プロダクトマネージャーは、企業において顧客の代弁者となります。ユーザー自身さえも気づいていない本質的な問題を発見し、それを解決するソリューションを提案します。

プロダクトマネージャーが持つべき部門横断的な機能

プロダクトマネージャーは部門横断的な役割を担います。前述したように、マーケティングや研究開発、カスタマーサポートといった部門と連携して、製品を最適化し、顧客満足度を高めます。企業によってプロダクトマネージャーの役割はそれぞれ異なりますが、主要な機能としては以下のようなものが考えられます。

市場調査：ユーザーの特徴、競合企業、市場に関する調査を行い、専門性を磨きます。

戦略立案：業界に関する知見を織り込み、概要レベルの戦略を立てます。目標・目的、製品の概要、だいたいのリリース時期といった計画を含みます。いわゆるロードマップと呼ばれる文書を作成し、なぜ、いつまでに何を開発し、どのような価値を顧客に届けるのかを定義するのがプロダクトマネージャーの仕事です。

計画の発表：作成したロードマップは利害関係者に伝達される必要があります。前述したように、プロダクトマネジメントは部門横断的なので、経営層・投資家・開発チームなど、全方位でコミュニケーションをとります。

開発作業の調整：ロードマップが各方面に承認されたら、戦略が実行されるよう調整していきます。開発チームはもちろん、リリースした製品が市場にPRできるよう、マーケティングチームと協業する等の仕事があります。

フィードバックとデータ分析：製品が市場に投入されたら、プロダクトマネージャーは市場から得られる顧客の声に耳を傾けます。サポートチームは顧客から苦情を受けるでしょうし、アクセス解析機能を使えばユーザーがどんな機能を使っているのかを理解できます。定性的・定量的なデータを分析し、製品のうち、何がうまくいっていて、何がうまくいっていないのか、追加・削除するべき機能は何か、といった議論が可能になります。各部門と調整を行い、再度、製品のアップグレードを行うのが次のステップです。

プロダクトマネジメントとプロジェクトマネジメントの違い

プロダクトマネジメントは戦略的な役割です。特に、「なぜ」その製品機能を開発する・しないのか、「なぜ」顧客はその機能を欲しているのか、といった質問に答えるのがプロダクトマネージャーの責任になります。

一方で、日常的な作業の管理や「どうやって」開発するかといった仕事は、プロダクトマネージャーの範疇ではありません。プロダクトマネージャーとプロジェクトマネージャーの違いという議論はよく見られるものです。プロジェクトマネージャーの場合、数時間から数日単位のタスクを定義し、各開発者の作業を割り振り、進捗を管理するといった仕事が含まれます。プロダクトマネージャーとプロジェクトマネージャーは分けて考えるべきでしょう。

プロダクトマネージャーに求められるスキル

プロダクトマネージャーになるには、市場や業界について誰よりも詳しくなる必要があります。顧客の代弁者として自社を牽引していくには、顧客が何を欲しているのかを徹底的に研究しなければならないからです。例えば、金融業のプロが、フィンテック開発を行うベンチャー企業のプロダクトマネージャーになる、というのは想定されるシナリオです。

技術について詳しくなければ最適なソリューションが定義できませんが、プログラミングの専門家である必要はありません。顧客からみた要件を定義するのがプロダクトマネージャーの役割です。ある業界で経験を積んだ文系出身者が、テクノロジー企業に移るときに、適したポジションになるかもしれません。

プロダクトマネージャーの役割は、企業によって異なります。同じプロダクトマネージャーの肩書きを持っていても、注力する仕事はわずかに違っている場合があるのです。技術よりのプロダクトマネージャーは、製品のアーキテクチャや、サードパーティの開発者向けのプログラムに興味が向くかもしれません。ビジネス寄りのプロダクトマネージャーは、市場調査やユーザー・インタビューを実施し、市場への理解を深めます。

まとめ

プロダクトマネジメントは日本企業ではあまり見られない役割なので、その考え方を学ぶのは簡単ではないかもしれません。しかし、今後は外資企業やスタートアップを中心に、開発からマーケティングまで、全てのライフサイクルに責任を持って、製品の成功にコミットするプロダクトマネージャーが増えていくでしょう。新製品の無駄な開発を避け、顧客へ継続的な価値を届けられるよう願います。