プロダクトマネージャーの役割や仕事、求められるスキルまとめ

  • このエントリーをはてなブックマークに追加
  •      
  • LINEで送る

どうもマツバラヤスユキです。

近年、よくプロダクトマネージャーという言葉を聞くようになりましたが、その役割や仕事内容、求められるスキル、キャリアパスとはどんなものでしょうか。

先輩PMの方々がまとめられた定義や見解などを参考に解説させていただきます。

僕も最近は、意識的にプロダクトマネージャーと名乗るようにしております。

もちろん、実務内容も伴いますが…w

 

プロダクトとは

プロジェクトマネージャーについてお話する前に、

マネジメントの対象である「プロダクト」について整理したいと思います。

プロダクトとは、直訳すると、

製品、商品、生産物、製作物、生成物、産物、成果、生産高、所産などの意味です。

一般的には、企業などが顧客に販売する製品のことを指しますが、

これにはソフトウェアやデータなど物理的実体のない無体物も含まれます。

従来、サービス(役務)とは区別されることが多かったのですが、

パッケージ化・標準化されて提供されるサービスのことは

ソフトウェア製品になぞらえてプロダクトと称する場合もありました。

しかし、近年、パッケージ化・標準化されて提供されるサービスとしての

ソフトウェア製品のみではなく、より広い意味で使われるようになってきています。

以下の記事にもある通り、

プロダクトマネージャーやプロダクトマネジメントについて語る上で、

「プロダクト」と言った場合には、B2Cのサービスも含まれることとなります。

「プロダクト」という用語が包括するものが、日本語の「製品」から想起されるものよりも広いからである。日本語で「製品」というと、一般的にB2B製品を指す場合が多いが、プロダクトマネジメントで扱う「プロダクト」は、B2Cのものも含まれる。さらに、形がある製品や商品だけではなく、形がないサービスもプロダクトマネジメントの対象に含まれる。

海外のビジネスパーソンの利用が多いSNSであるLinkedInでプロダクトマネジメントに関するグループを検索すると、1300以上ものグループがヒットする。例えば、その中で3551人が参加している(本稿執筆時点)保険に関するプロダクトマネジメントのグループをはじめとして、インターネット上のサービスや金融サービス、ソフトウェア、小売、医薬品、ヘルスケア、食品などのプロダクトマネジメントグループが存在している。このような事例からも、プロダクトマネジメントが扱う対象が幅広いことがわかるだろう。

なお、ここでは「製品」と「プロダクト」の違いを明確にするために両者を厳密に使い分けて解説したが、これ以降、本稿では「商品」や「サービス」も含んだ概念を「製品」という用語で統一して表現する。

引用:https://pmstyle.biz/column/product/product1_1.htm

プロダクトマネジメントとは

プロダクトの定義の次は、

プロダクトマネージャーが実践するプロダクトマネジメントについて、

見ていきましょう。

プロダクトマネジメントとは、

その言葉から解釈しようとすると「プロダクト」を「マネジメントする」こととなります。

直訳すると「製品」を「管理する」(マネジメントを管理をは捉えておりませんが)となりますが、

「製品管理」という直訳された用語から想定されるイメージは、

実際の「プロダクトマネジメント」とは大きく異なるものです。

以下の記事には、こんな定義がありました。

“The Product Manager’s Desk Reference”では、プロダクトマネジメントを次のように定義している。

「製品、製品ライン、あるいは製品ポートフォリオのレベルでのビジネスマネジメント」

製品の管理ではなく、「ビジネスマネジメント」が重要視されていることがポイントですね。

「プロダクトマネジメント」は、先ほど紹介した「製品管理」よりもカバーする範囲が広いことに気付く。特に” The Product Manager’s Handbook”の最新版の定義を見ると、プロダクトマネジメントにおいては、プロダクトだけではなくて、顧客も念頭に置かれていることがわかる。つまり、プロダクトマネジメントとは、プロダクトと顧客の間に位置し、プロダクトの管理だけを行うのではなく、プロダクトを通して顧客満足を生み出すために行うものなのである。

f:id:yaspontax:20180714211501j:image

プロダクトだけではなく、「顧客」も念頭に置かれているとある通り、

顧客(市場)のニーズや課題を正確に捉え、

プロダクトを顧客(市場)にフィット(プロダクトを通して顧客満足を生み出す)させていくことがポイントであると分かります。

プロダクトマネジメントというのは製品に関する幅広い分野を扱う職務である。その全体像を整理したものが、下記に示す「プロダクトマネジメント体系」である。

f:id:yaspontax:20180714211411j:image

この図は” The Product Manager’s Handbook”の最新版の内容を元に作成したものである。同書ではプロダクトマネジメントの機能を上流(upstream)と下流(downstream)に分類して整理している(プロダクトマネジメントを体系的に整理する場合、これ以外の分類もあり得るが、本連載ではこの分類にしたがい、プロダクトマネジメントの全体像を解説する)。

わかりやすく言うと、製品やサービスの市場投入を境として、市場投入までに行うべきことを「上流」、市場投入後に行うべきことを「下流」として分類している。

「上流」は、製品のコンセプトを検討し、製品化した上で、市場に投入するフェーズに相当する。この段階は新製品を市場に投入するまでの計画立案や、それに伴うさまざまな点を考慮する段階である。一方、「下流」は製品投入後、新たに投入した製品とすでに投入されている製品をあわせて管理するフェーズである。この段階は、新製品のマーケティングを行うことに加えて、既存製品の強化や撤退などといったライフサイクル管理を考慮する段階である。

そして、上流・下流の両方のフェーズに共通して必要になるのが、ベースとなるビジネススキルである(なお、この図で示しているものは代表的なものであり、網羅的ではない)。プロダクトマネジャーとして必要なリーダーシップや意思決定などのスキルに加え、意思決定を行う際に必要となる会計や価格に関する情報を把握し、分析することができるスキル、そしてコンペティティブ・インテリジェンスと呼ばれる競合の状況を分析するためのスキルなどもここに含まれる。

引用:https://pmstyle.biz/column/product/product1_1.htm

プロダクトマネジメントを製品管理と捉えてしまうと、

全く足りていないことがお分かりになるかと思います。

プロダクトマネージャーとは

続いて、プロダクトマネージャーについてです。

プロダクトマネージャーのミッションは、大きく3つだと考えております。

  • プロダクトが顧客に提供する価値の最大化
  • マーケティング戦略(セグメンテーション、ポジショニング、セグメンテーション、4P)の計画及び推進
  • プロダクトライフサイクルを一貫してコミットする

プロダクトマネージャーについても、

先ほどから参考にさせていただいた記事に記載がありました。

『プロダクトマネジャーの教科書』では、プロダクトマネジャーの定義として次のような記述がある。

「特定の製品ラインやブランド、サービスについて、既存の製品の管理やマーケティングを行ったり、新製品開発の役割を負っているミドルマネジャーである」

「事業戦略家であると同時に優秀な実践者でもある。担当する製品を通して顧客の満足を積み重ね、最終的に利益を上げなければならない。また、そのようなプロセスを直接的な権限を持っていない人たちをまとめながら進めなくてはならない」

さらに、『プロダクトマネジャーの教科書』の原書である” The Product Manager’s Handbook”の最新版(第4版)では、プロダクトマネジャーの職務を次のように定義している。

「プロダクトマネジャーの仕事とは、製品ライン、あるいはサービスラインのあらゆる側面に責任を持ち、高い顧客満足を作りだしながら、同時に自らが属する企業に長期間にわたって価値をもたらすこと」

引用:https://pmstyle.biz/column/product/product1_1.htm

「事業戦略家であると同時に優秀な実践者」という表現が

まさに思い描くプロジェクトマネージャー像だと感じました。

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

プロダクトマネージャーが、事業戦略家であると同時に優秀な実践者であり、

担当する製品を通して顧客の満足を積み重ね、最終的に利益を上げなければならず、

また、そのようなプロセスを直接的な権限を持っていない人たちを

まとめながら進めなくてはならない人である

と、プロダクトマネージャーに求められることは多岐に渡ることは分かりましたが、

企業において、どのような役割を担うことが求められるのでしょうか。

プロダクトマネジャーは、日々の業務の中でさまざまなステークホルダーとかかわりを持つことになる。プロダクトマネジャーがかかわりを持つ可能性があるステークホルダーの役割(部署)をまとめたものが次の図である。

f:id:yaspontax:20180715000538p:plain

これらのすべてのステークホルダーと等しくかかわりを持つわけではなく、関係が深い役割とそうでない役割が存在する。もちろん、関係の深さは、プロダクトマネジャーが所属する業界や取り組んでいる製品によって変わるが、通常、図に挙げた中では、「営業」や「研究開発」などの役割を負うステークホルダーが、特に関係が深い役割だと言える。

「営業」は製品の売上げにかかわる重要なステークホルダーである。そのため、製品の市場投入前の計画・準備段階から市場投入後まで、さまざまな場面で営業とかかわることになる。例えば、プロダクトマネジャーが計画を立てる段階では、売上予測を作成する際、営業から情報をもらうことが重要になる。さらに、市場投入後は営業支援や営業に対するトレーニングでかかわることになる。営業支援という点では、営業に対して製品情報を提供したり、場合によっては一緒に営業に同行することもあるだろう。営業のトレーニング時、プロダクトマネジャーが営業スキルについて指導をすることは、通常、あまりない。むしろ営業がターゲットとする市場の情報の共有などの役割を担うことになるだろう。

「研究開発」では、新製品開発時にかかわることが多い。研究開発の担当者は、新製品に今までにはなかったようなさまざまな新しい機能を実装したいと考えるかもしれない。だからといって、そのためにコストを度外視して良いわけではない。研究開発の担当者との間に立ち、そのバランスを取るのがプロダクトマネジャーの役割である。

引用:https://pmstyle.biz/column/product/product1_1.htm

顧客(市場)の課題解決やニーズを満たす為に、

すべてのステークホルダーを巻き込みながら

プロダクトを改善し顧客満足を実現していくことが役割であると言えます。

プロダクトオーナーとの違い

最近、プロダクトオーナーという言葉もよく耳にしますが、

その役割の違いは何でしょうか。

僕自身もあまり理解できておりませんので、

お知恵をお借りします…

プロダクトオーナーを語る上では、切っても切り離せないのが、

アジャイル開発の手法「スクラム」とのことですが、

詳細は、以下をご参照ください。

 スクラムでは、「チーム」を重視します。これまでの連載では、下記のことを説明してきました。

  • 刻々と変化する状況に対応するため、チーム全員が目標を共有する
  • きちんとコミュニケーションできている状態を維持するため、チームの人数を適切に保つ

●解説記事

  • プロジェクト予測の限界、改善法としてのスクラム
  • 最適化した開発チームは3~10人で美しく回る

 スクラムでは、開発チーム内での「上司と部下」の関係や、「コマンド&コントロール(命令・指揮)」を用いたマネジメントは行いません。チームメンバー皆が情報を共有して理解し、チームの方針を決めていきます

スクラムにおける、2つのリーダー像

 そうはいっても、責任者がいた方が効率的な場合もあります。そこで、スクラムでは2つの異なるリーダー像を定義しています。なお、前提として、スクラムでは従来のリーダー像・マネージャ像を分解し、主な責任はチームに委譲しています。

  • プロダクトオーナー
  • スクラムマスター

 どちらもチームをサポートする役割ですが、機能は異なります。これから2回に分けて、2つのリーダー像を説明します。今回は「プロダクトオーナー」です。

プロダクトオーナー:プロダクトの方向性を決める舵取り役

 プロダクトオーナーは、チームが生み出す成果物(プロダクト)の方向性を決める「舵取り役」です。

 「オーナー」というと、日本語ではかなり強い権限を持った「所有者」という印象がありますが、スクラムではそれほど強い意味ではなく、「責任者」や「当事者」というぐらいの意味です。

役割は「方向性を決める」こと

 プロダクトオーナーの責務は、「方向性を決めること」です。具体的には、プロダクトバックログを記述し、常に最新の状況に合わせて、プロダクトバックログ内の項目の優先度を変更していきます。

 「チームに権限を委譲しているのに、なぜその方向性をチーム自身が決めないの? それじゃ通常のリーダーと変わらないじゃないか?」

 この疑問はもっともですが、通常のリーダーとプロダクトオーナーの違いは、「チームとの関係性」にあります。

チームを指示しない

 プロダクトオーナーは、チームに指示しません。あくまで、プロダクトバックログの編集を通じて、チームに情報を渡すだけです。プロダクトバックログに記載されたものがいつまでにできるかは、チーム自身の見積もりと計画によって決まります。

 プロダクトオーナーが渡す情報は、例えば以下のようなものがあります。

  • チームが開発する対象物はどのような価値があるか
  • 誰が使うのか、使う人々はどういう人で、いつ使うのか
  • 予算を出す人は誰で、お金を出すにあたって必須の条件、重要視していることは何か
  • チームメンバーは何のスキルを持っていて、チームはどのような状態か
  • チームの中の専門家はどういう見立てをしていて、それらすべてを生かして顧客の要望に応えるにはどのような順番で開発を進めるべきか

 こうしたことを、プロダクトオーナーが把握し、具体的な機能や作業のリストに落とし込み、プロダクトバックログとしてチームに提示します。

引用:https://www.atmarkit.co.jp/ait/spv/1204/09/news115.html

プロダクトオーナーの位置付け

翻って、プロダクトオーナーについては、「事業部門側/ユーザー側の人」 という想定があり、開発側がまだそこまで思いが至っていないことが多い。しかしながら、プロダクトオーナーはスクラムの中でもプロジェクトの成否を決定する非常に重要な役割です。

私は、プロダクトオーナーの役割を説明する際に、以下の2点を強調します。

  • スクラムチームの旗振り役です
  • この人によってチームがいかに効率的に働けるかが決まります

「旗振り役」とは、スクラムチームという船の舳先に立って、「こっちに行って」 「次はこっちの方向へ」 と旗を振っているのがプロダクトオーナー、とイメージしていただければよいでしょう。
目的地が厳密に決まっていないアジャイル開発チームという船で、穏やかなこともあれば荒波もある大洋の中を進んでいく。荒波を何とかして超えていくのは、開発チームやスクラムマスターの腕かもしれませんが、目的地を指し示すのはプロダクトオーナーです。さらには、目的地は途中で変わりうる(目的地が最初に決まって、プロジェクト期間中変わらないのであれば、アジャイル開発にする必要はありません)。プロダクトオーナーは、途中で変わるビジネス状況をしっかりと踏まえて、チームを導く必要があります。

ふたつめの「効率」について。特にご注意いただきたいのは、ここでいう効率が、決して 「開発者の稼働率が高いこと」 ではなく、いかにビジネスに役立つシステムになっているかという度合いだということです。有名な統計として、典型的なシステムの実に45%の機能は全く使われていない、さらに19%もめったに使わない、というものがあります(Standish Group Study Reported in 2000 Chaos Report)。開発者がどんなに稼働率高く働こうが、作るコード量が多かろうが、それが使われていないのであれば、単なる「ゴミ」。プロダクトオーナーはこの無駄な機能をいかに作らせないかということに、責任があります。

引用:https://www.mamezou.com/techinfo/agile_devops/nakanohito_005

プロダクトマネージャーとプロダクトオーナーでは、

プロダクトチームとの距離感や立ち位置の違いがあります。

その為、プロダクトマネージャーの役割の中にプロダクトオーナーが内包されるのかというと、

そうではないという理解が正しそうです。

※理解が間違っておりましたら、ご指摘ください!

プロジェクトマネージャーとの違い

プロジェクトマネージャーとの違いについては、

どちらも経験しておりますが、明確な違いがあります。

プロジェクトマネージャーのミッションは、

  • プロジェクトの目的/ゴールを実現すること
  • 実現方法の検討及び推進、課題解決
  • QCD(品質・コスト・納期)を計画し達成すること
  • プロジェクト終了までの期限付きでコミットする

であり、プロダクトマネージャーに求められるものとは全く異なります。

プロダクトマネージャーが、WhyとWhatを求められるのに対して、

プロジェクトマネージャーは、HowとWhenが求められます。

過去に、プロジェクトマネージャーとプロジェクトマネージャーの

役割の違いについてまとめておりますので、

ご興味があれば詳細は以下をご覧ください。

プロダクトマネージャーの仕事内容

プロダクトマネージャーは、具体的にどのような業務を行うのでしょうか。

ミッションである

  • プロダクトが顧客に提供する価値の最大化
  • マーケティング戦略(セグメンテーション、ポジショニング、セグメンテーション、4P)の計画及び推進
  • プロダクトライフサイクルを一貫してコミットする

の実行となりますが、

既にまとめられている記事がありましたので、

引用させていただきます。

プロダクトマネージャーは、プロダクトの責任者なので、企画立案、デザイン、開発、テスト、リリース、マーケティング、ビジネスまで幅広いプロセスに関わります。具体的には日々以下のような仕事をしています。(本の内容を抜粋して簡単にまとめました)

︎調査と計画
・ロードマップの作成、提案
・顧客のニーズ、競合の動向、ビジネスのニーズ、チームの専門性に基づいて機能とシナリオに優先順位をつける
・常に決定した機能のエキスパートとなり、これから解決していく問題と機能のゴールについて深く考えていく
・メンバーの「なぜこれに取り組んでいるのだろう」という疑問に常に答えを持っている必要がある
・どうすれば成功と言えるのかを定義する
・OKR(Objectives and Key Results=目標と主要な成果)に従ってチームとコミュニケーションをとり、効果測定可能な成果を上げるためにチームとともに尽力する

︎デザイン
・PMは詳細な仕様をすべて書き表す
−ゴール
−ユースケース
−要求事項
−ワイヤーフレーム
−機能のあるべき状態をすべて記述した箇条書き
−国際化
−セキュリティ

︎実装とテスト
・実装期間の最も重要な仕事は、エンジニアが効率良く働けるように支援すること。PMは定期的にチームをチェック進捗状況を把握する
・実装中は以前のバージョンのフィードバックに収集を行う
−ユーザビリティ調査、ドッグフーディング
・それらの実験で得たフィードバックをもとに問題点を特定し、機能のデザインを反復することでより優れたソリューションを探る

︎リリース
・ローンチのチェックリストをすべて確認する
−法務などの重要なステークホルダーからの最終的な承認を得たり、マーケティングやオペレーションなどのチームと調整したりする
・プロダクトのこの先の進行を支援するチームの準備状況を確認する
−Webのプロダクトであればカスタマーサービスのチーム、サービスベースのプロダクトであればオペレーションチーム
・考えられるすべての問題点に備える
−リリースが近づくと緊急性が高い問題が持ち上がるもの。PMはそのときのための存在

引用:https://tanack.com/?p=395

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

多岐に渡る役割や仕事内容のプロダクトマネージャーに

求められるスキルとはどのようなものでしょうか。

以下の記事に分かりやすくまとめられておりました。

知識

  • 市場・事業・ユーザーに関する知識
  • プロダクト開発プロセスに関する知識
  • Webサービス、スマホアプリ固有のデザインパターンに関する知識
    • UIトレンドの理解、技術的な実現可能性の理解

スキル

  • 問題の構造的理解とソリューション考案力
    • システム思考、デザイン思考、ロジカルシンキング、マーケティングの基本フレームワークを使いこなす力
  • コンフリクトマネジメント力
    • 優先度判断、妥協点の発見
  • コミュニケーション力
    • 伝達力、理解・共感を得る力、ファシリテーション力

コンピテンシー

  • 変革力
    • 前提を覆しパラダイム転換を志向する意欲
  • 粘り強さ
    • 難易度の高い問題に取り組み続ける力
  • 共感力
    • 他人の目玉を通してみる、Thinking hatsを被りなおす力

引用:https://tannomizuki.hatenablog.com/entry/advent-calendar-2015

その中でも、僕が最も重要だと考えるのは、

  • 顧客(市場)の課題やニーズを正確に捉える力
  • チームを巻き込み課題解決・ニーズを満たすプロダクトへの改善継続力
  • プロダクトに対しての思い入れと、事業の成功へのコミットメント

だと考えております。

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

そんなプロダクトマネージャーになる為には、

どんなキャリアパスを歩めば良いのでしょうか。

セミナーや勉強会、社会人マッチングアプリyentaなどでお話を聞く

他社のプロジェクトマネージャーの方々のキャリアパスは様々です。

営業出身の方や、デザイナー出身の方、エンジニア出身の方、

ディレクター出身の方、CS出身の方といった感じです。

その為、特にキャリアパスとして、こうじゃないといけないといったことはありませんが、

プロジェクトマネージャーになる為の条件として、

納得できるものがありましたので、ご紹介します。

プロダクトマネージャーになるには
では、仮にいま、プロダクトマネージャーとしてのキャリアを思い描いている人がいたとしたら、何をすればよいでしょうか。

ことITの世界においては、一番かんたんなのは、自分でコードを書いてプロダクトを作り、運営することです。そうすれば、誰でもプロダクトマネージャーの立場に身を置くことができ、様々な学びの機会を得られるからです。

この場合、一人で全部作りきり、運営からサポート、クレーム対応まで全部やることが貴重な経験になります。このような経験を粘り強く続ければ、プロダクトの全体像が理解でき、様々なトラブルへの耐性もつき、また人に語れる経験を持つことで、「自信」が周囲にも伝わるようになります。

その意味では、大企業やレイターステージのスタートアップなど規模が大きく組織的な開発を志向する組織では、一人で何から何までやらなければならない、という境遇に身をおける人が限られているので、プロダクトマネージャーを目指す方にとっては物足りないケースもあろうかと思います。

最近では、チームワークを重視し、エンジニアにとって働きやすい職場であろうと努力している経営者が多く、それ自体は本当に素晴らしいことですが、ことプロダクトマネージャーを育てるという目線に立つと、分業や体制整備が行き過ぎていると思うこともあります。

「1万時間の法則」から考える
ある領域でトッププロのレベルになるには、だいたい1万時間程度の訓練が必要と言われます。プロダクトマネージャーとして頭角を現す人も、概ねこの1万時間の訓練を積んでいる人ということになります。

たとえば、一人でそこそこの規模のコミュニティサービスを運営していると、単にコードを書いたり、インフラを整備したりといったことだけでなく、人間関係のトラブル含め、休みも深夜も関係なくいろんな問題が起き続けますので、365日、毎日14〜15時間くらいはプロダクト運営に関与せざるを得ない、ということが起きます。これを1年続けると、プロダクトマネージャーとして5300時間ほど費やしていることになります。

ですから、一人でプロダクトを作り、そこそこの規模まで成長させた状態で2年続ければ、プロダクトマネージャーとして一流と呼べるポジションまで成長できる可能性があります。

スポーツや音楽などは、体力や物理的な場所などの兼ね合いで、毎日14時間も練習できません。しかも、活躍時期が10〜20代と若い。しかもこの年代の人は学校に行く必要もあるので、とにかく練習時間が取れません。
そうなると、これらの領域でプロになるレベルを目指すには、3歳とか5歳とか、かなり幼いときからみっちりやらなければ「1万時間を突破しプロになる」こと自体が不可能なのです。

成長スピードの差が生まれる要因
一方、ITプロダクトにおけるプロダクトマネージャーであれば、コンピューター1つあればできますし、体力や場所、年齢などの制約は少ない。プロダクトマネージャー業界は、スポーツや音楽ほど参加者が多くないこともあって、現実的に2〜3年でトップレベルに上り詰めることは可能です。

しかしながら、会社員など、1日8時間の労働で、土日は休んでいる人がプロダクトマネージャーとして腕を上げる場合、年間の稼働日数は240日、1日のうち、メールや経費精算、会議などの時間を省いて6時間程度しかプロダクトの仕事ができないとすると、年間1440時間程度しか費やせません。これだと、プロダクトマネージャーとして一流になるためには7年以上かかる計算です。

大企業ですと、これに加えて、人事査定だとか様々な雑務が入ってくるので、プロダクトに費やせる時間はさらに減って、年間1000時間もないと思います。

こうなると、10年くらい続けてようやく一流、というレベルですが、その10年のうちに、人事異動でまったく別の仕事をやることだってありそうですし、道を極める前に「俺は人事をやりたいな」とか、「経営者を目指そう」といった風に目移りをして、本人が1万時間の取り組みを途中でやめてしまうことも多々あると思います。

引用:https://ishiidaichi.com/2017/11/07/プロダクトマネージャーという仕事について/

プロダクトマネージャーの求人を見てみる

プロジェクトマネージャーの求人の状況はどのような状況でしょうか。

  • indeed

プロダクトマネージャーの求人 | Indeed (インディード)

全然ありませんね。他のポジションの求人ばかりです。

  • green

プロダクトマネージャーの求人 | 転職サイトGreen(グリーン)

同じく、全然ありませんね。

  • en

プロダクトマネージャーの転職・求人情報|エン ミドルの転職

意外にも、最も多い印象を受けました。

いきなりプロジェクトマネージャーとして、

転職することは難しいと思うので、上記の結果は当然なのかもしれません。

新規事業・プロダクトの立ち上げであれば、可能性はあると思いますが。

もしくは、現在はまだ「プロデューサー」として同じ役割期待のポジションが募集されているのかもしれないですね。

しかし、今後、よりプロダクトマネージャーという役割が浸透して来ることが予想されますので、

数年で状況は変わって行くと思います。

プロダクトマネージャーが必ず読むべき本

最後に、現役のプロジェクトマネージャーや

プロジェクトマネージャーを目指す方が読むべき本をご紹介します!


スポンサーリンク

よろしければtwitterでフォローを!

twitterで積極的に情報発信しております!

 

主に以下のようなことをつぶやきます。

・PM関連の気付き・学んだこと

・チームメンバー育成に関する実体験

・日常のどうでもいいこともたまに(笑)

 

「記事の内容が参考になった」、「今後も記事を見たい」、「今後の成長に期待する」などと思っていただける方も、ぜひフォローください。


twitterへ移動する

SNSでもご購読できます。