SE が身につけたい PdM （プロダクトマネージャー） 思考｜SEカレッジ ウェビナーレポート
SE カレッジでは旬のテーマをもとに、 1 時間のウェビナーを毎月 1 回以上、開催しています。
今回のテーマは、 「 SE がおさえておきたい PdM (プロダクトマネージャー) 思考」 です。
近年、ビジネスマンのキャリアとして注目されているプロダクトマネージャー（ PdM ）。このウェビナーでは、実際にプロダクトマネージャーとして活躍されているパネリストの方々の経験や事例をもとに、プロダクトマネージャーのしごとや役割、プロダクトマネージャーになるための必要な思考やスキルを探りました。
Mobility Technologies にて、タクシーを呼べるアプリ GO （ MOV&JapanTaxi ）プロダクトマネージャーを担当中。その他、 IoT スマートロック「 Akerun 」のプロダクトマネジメントや、ソフトバンクでカスタマー向けアプリ・サイトの企画やカスタマーサービスワークフローのシステム化など、さまざまなプロダクトに携わる
株式会社ビビンコ代表取締役。 2000 年よりプログラマ、 SE として企業の業務システム開発に従事し、 2012 年に独立。 AI や IoT に強い IT コーディネータとして活動し北九州市主催のビジネスコンテスト「北九州で IoT 」に応募したアイディアが入選。そのほかセミナーや研修にも多数登壇。著書に「初めての Watson 」、「ワトソンで体感する人工知能」などがある。
もくじ
プロダクトマネージャー (PdM) とその役割とは
まずは、そもそもプロダクトマネージャーとはどのような職種なのか、真崎さんに紹介してもらいました。
では、どう成功を実現するのか、というお話です。
まず、この図にある Core -> Why -> What -> How を一本の線でまとめるのが非常に大事になります。会社のビジョンやミッションに応じて、プロダクトにもプロダクトビジョン、プロダクトミッションが必要です。
この Core がないと、ユーザの意見ばかり聞いてしまって、よくわからない機能が一杯あるということになりがちです。この Core に沿って、「ユーザってどんな人だっけ」「解決したい課題は何」「 UX / UI はどうしよう」「どう実装どうしよう」というのを一本線にします。
次に必要になるのが、あらゆるステークホルダーをマネジメントすることです。
以下の図はプロダクトマネージャーのスキルを説明する図なのですが、ステークホルダーについても説明しやすいのでこれを用いて説明します。
ステークホルダーマネジメントは SI のプロジェクトマネージャーのそれに近いです。ただ、登場人物が増えるところが違っていて、カスタマーサクセス（ CS ）やデザイナーといった職種の方も入ります。
この図にいる IT エンジニアや CS 、デザイナーの方とのコミュニケーションハブとして、対等に話すことができ、それぞれの職種との双方向のスキルと知識が求められます。ただ、 1 人でこの領域すべてをカバーするのは難しいので、得意領域をもったプロダクトマネージャー複数人が分担して、プロジェクトマネジメント組織とするのが一般的です。
プロジェクトマネージャー ( PjM ) とプロダクトマネージャー ( PdM ) はよく戦う？
続いて、プロジェクトマネージャーとの違いを説明します。
プロジェクトはどちらかというと単発で、何か新しい機能を開発して終了するものですが、プロダクトの場合、レールのようにロードマップが敷かれていて、その上でプロジェクトが発生すると考えるとイメージしやすいと思います。プロジェクトマネージャーはそのロードマップ上にある一個一個のプロジェクトをマネジメントします。
また、プロダクトマネージャーは Why, What を考えるのが中心ですが、プロジェクトマネージャーは When, How long を考えていますので、考え方が違います。
ありがとうございます。 2 点、伺いたいことがあります。
1 点目が、私は今まで SIer でプロジェクトマネージャーの経験が長く、今の会社でも務めていますが、一方で IoT 関連の自社製品も開発しています。そこでプロダクトマネージャーとプロジェクトマネージャーを兼務しているのですが、今の話を伺って、どちらかというとプロジェクトマネージャー寄りにスケジュールを優先しまいがちだなと実感しました。
やはり、プロダクトマネージャーとプロジェクトマネージャーは兼務しないほうがよいのでしょうか？
基本は兼務しないほうがよいです。兼務していると、おっしゃった通り、スケジュールを優先して、どうしても要件をどんどん落としてしまいがちです。その結果、価値のあるものになっていないケースがよくあります。
プロダクトマネージャーはそうならないよう、兼務をせず、逆にプロジェクトマネージャーと戦うのが役割です。
SI だとお客様からたくさんの要件をもらうので、そういったスケジュール優先の習性になるのかも知れませんね。
経営者と「ミニ CEO 」のプロダクトマネージャー、どっちが･･･
2 点目は別の話になるのですが、プロジェクトマネージャーは「ミニ CEO 」とも言われます。
小さなスタートアップの場合は創業者がプロダクトマネージャーになりますが、一方で真崎さんの所属企業のように、経営者とは別にプロダクトマネージャーがいるような場合、経営者とプロダクトマネージャーはどのような関係になるのでしょうか？
それはフェーズによって変わります。プロダクトのフェーズは、起業･スタートアップする段階が 0 → 1 のフェーズ、その次が 1 → 10 のフェーズ、その次が 10 → 100 フェーズと大きく 3 つに分けられます。
0 → 1 のフェーズでは創業者がプロダクトマネージャーになりますが、 1 → 10 以降のフェーズになると、創業者は資金調達や採用など会社経営がメインになり、そのタイミングでプロダクトマネージャーにバトンタッチして役割が分かれます。
わたしも同じようなケースでプロダクトマネージャーになりましたが、私のような創業者ではないプロのプロダクトマネージャーの人口のほうが多いと思います。
非 IT 企業がプロダクトマネージャーを募集する時代に SI が果たす役割は？
続いて、いまなぜプロダクトマネージャーが注目されているのか、その理由を探ります。
これは私見も入っていますが、今まで Why と What があまり考えられてないことが多かったからと考えています。
実は、皆さんが使っているようなアプリ・プロダクトでも、意外とプロダクトマネージャーがいなくて、営業や社長から言われたものを When と How long を気にして開発されることが多かったんです。それではプロダクトは成長せず、やはり、ユーザの課題を発見して、それを解決する機能や製品を生み出すプロダクトマネージャーが必要になってきたと考えています。
また今まで IT が中心でしたが、それだけでなく、メーカーのような企業でもアプリやプロダクトを出したいと思う裾野が広がり、メーカーでもプロダクトマネージャーを募集するようになりました。それがプロダクトマネージャーが注目される、もう一つの要因と考えています。
toB 向けにノーコードでアプリを開発できる Yapri さんや、 UI / UX のコンサルティングを行う Goodpatch さんが上場したことは、それを顕著に表しています。
真崎さんがおっしゃる通り、確かに「 DX 」をキーワードに非 IT 企業でもプロダクトマネージャーの需要は増えていて、どのようにデジタル市場に乗り込むのか考えられることが多くなりました。
そうすると「ただサービスを提供して終わり」ではなく、ユーザの課題解決までやるプロダクトマネージャーのような存在が求められるようになっています。
では、今日の視聴者は SI にいらっしゃる方が多いので、そういった非 IT 企業の需要に対して、 SIer はどのような立場・役割を果たすのか、日本の SI 大手企業の事例をいくつか角度を変えながら紹介します。
NEC はお客様企業に入り、実際に新規事業の立ち上げなどを行う DX 人材を育てるというもので、コンサルティングだけでなく検証・開発まで行います。
お客様向けもあるのでしょうが、富士通は富士通自体を DX しようとする面白い取り組みです。
日立は生産現場やスタッフ部門のような IT だけでない人も DX を知ろうという取り組みです。
FUJITSU Agile Labで顧客企業とともに開発の内製化・アジャイル化を目指す――富士通 福井伸彦氏、春日理氏 (1/3)：IT人材ラボ
最後に、もう一つ。少し古い 2018 年の記事ですが、プロダクトマネージャー / デザイナー / IT エンジニア の 3 つの役割を 1 チームとして、そして、ここがユニークなのですが、富士通は IT エンジニアとデザイナーの役割だけを務め、プロダクトマネージャーはお客様側から立てて、開発を進めるというものです。
最後に取り上げたように、やはりプロダクトマネージャーはお客様側にいるんですよね。
とは言っても、お客様側にバシッとプロダクトマネージャーとして一本立ちしている人はあまりいないという印象です。このため、プロダクトマネージャーの補佐が必要になるので、 SIer はプロダクトマネージャー的な思考ができそうな人やプロダクトマネジメントの思考ができる人を育てて、お客様を支援する体制をつくる必要があると思います。
ただ、それでも冒頭にもあったように Why や What ではなく、結局、 When や How long の話をし始めて、ズレが出てしまうことが懸念されます。
プロダクトマネージャーは数字で評価される
そのプロダクトマネージャー的な思考とはどのようなものなのか、話が進みます。
プロダクトマネージャーには MVP ( Most Viable Product ) という、価値が検証できる最小限のものから作りましょう、という思考があります。
100 % 作りきってからローンチするというわけではなく、まず 10 % ～ 15 % ぐらいの完成度でローンチしてから、 100 % に向けて雪だるま式に大きくして開発を進めるスタイルです。
例として、 GO はどうだったのか、かなり大雑把ですが紹介します。
まずは Core の部分から。タクシーの配車アプリというと、タクシーを呼ぶだけのように言われますが、そうではありません。 10 年もすると自動運転時代がやってきます。そのときにはタクシーも無人になっています。そのときにどのように人を移動させるのか、そこでシェア 1 位を取るにはどうするのか、そういったことが Core になっています。
次に「 Why ミッション なぜやるのか」です。
タクシーというと、ビジネスパーソンが使うことが圧倒的だったのですが、もっとコンシューマが使えるように、使いやすくできるように、というのが why です。
続いて What になりますが、ここからは細かい機能などの話になり、私達がいま毎日取り組んでいるものです。例えば、最近リリースした予約機能は、ビジネスサイドとビジネスモデルや収益性などを決めて、デザイナーと体験設計を行い、要求定義をして、 IT エンジニアとどのように作るのか決めます。またリリースしたあともデータ検証を行い、改善を繰り返します。
こういったことをプロダクトマネージャーは考えて、やっています。
伺っていて、ふと思った質問ですが、プロジェクトマネージャーはどうすると評価されるのでしょうか？
プロジェクトマネージャーの場合は QCD をおさえてプロジェクトを完了し、利益が出ていれば評価されるんですが、プロダクトマネージャーの場合は何だろうかと疑問に思っています。
会社によっても大きく変わりますが、やはりプロダクトマネージャーは数値で評価されることが多いです。例えば、リリースしたけどユーザ数が少なく、収益が上がらかなかったというのはプロダクトマネージャーの責任と言われます。プロダクトの責任はプロダクトマネージャーの責任です。
というと、事業部長のようにも聞こえるのですが、それとも違うのでしょうか?
私どもの場合では、事業部長は GO 全体の売上や収益に責任を持ちますが、たとえば、予約機能がついたら、これだけユーザ数が増え、売上や収益が上がる、ということにプロダクトマネージャーは責任を持ちます。
なるほど。実際に開発するものを決めてリリースするだけでなく、それにプラスして、「お客様が使って、利益が出る」までを見るということですね。これは今まで SIer が担ってきてないところですね。
これはお客様と SIer との契約の話になりますが、今までは「作りました」でお金を頂いていましたが、作ったことでお客様の売上が「これだけ出るようになりました、伸びました」でレベニューシェアのような開発の契約になるのかも知れませんね。
プロダクトマネージャーはカンファレンスではなく本でスキルアップするのがおすすめ
では、プロダクトマネージャーになるには知識やスキルをどう獲得するのか、真崎さんから紹介いただきました。
本からエッセンスを獲得するのが一番良いと思います。
Core / Why / What を考えるフレームワークやユーザストーリーマッピングなど、フレームワークや手法ごとに関連する本がだいたい 3 冊ぐらいあり、そこで学ぶのが一番良いです。
またそういった各フレームワークやツールではなく全体を知りたいという方には、最近、翔泳社さんから出版された「プロダクトマネジメントのすべて」という本がオススメです。
SEプラスさんが翔泳社さんのグループ企業だからという訳ではなく（笑）、プロダクトマネジメント界隈で今話題の本です。日本で有名なプロダクトマネージャーが 2 人いるのですが、その 2 人がタッグを組んで書いた本です。
これを読んで、プロダクトマネジメントとは何をするのかがわかり、これはこれまでの業務と関連があるな、とかご自身のスキルをマッピングできると思います。
もう一つが UX です。これにはデザインも含まれます。
まず、ユーザにどうインタビューするのか、ユーザリサーチはどうやるのか、こういったスキルがプロダクトマネージャーに必要になります。
次に、今日のスライドもそうですが、 Android / iOS ともにユーザに馴染みがあるデザインテンプレート、いわゆるデザインシステムがあるので、それを学ぶとユーザの使い勝手の良いものがわかるようになります。
最後は、逆にオススメしないものを紹介します。プロダクトマネジメントは関連カンファレンスが多いのですが、その内容は組織論や自社事例になりがちで、参考にならないことが多く、体系的に学ぶには効率が悪いと思います。
ありがとうございます。本、スゴい分厚いですね（笑）。
UX も含めて、プロダクトマネージャーには広範囲の知識が必要になりそうですね。逆にプロダクトマネージャーがやらないことは何があるのでしょうか？
実際にデザインしたり、コーディングしたり、営業したり、といったことはしませんね。もちろん必要があれば、やりますが、各職種と一緒に考えることはしても、 基本は手を動かしません。ここはかなり気をつけないといけません。
自分で手を動かしてしまうと、冷静にモノを考えられなくなるからでしょうか？
本当にその通りで、プロダクトマネージャーの中には IT エンジニア出身の方が多いのですが、自分がコードを書いてしまうとかわいくなってしまうんですね。そうすると、冷静に客観的にプロダクトをリードできなくなります。
身にしみてわかります（笑）。 あとはプロジェクトマネジメントにおける PMBOK ® のような知識体系のようなものは、プロダクトマネジメントでも出てくるんでしょうか？
わたしはこの「プロダクトマネジメントのすべて」が PMBOK ® に近いと思っています。 PMBOK ® はプロジェクトマネジメントのベストプラクティスからエッセンスをまとめていますが、この本もプロダクトで成功している事例を集めて、フレームワークのようにまとめています。
ここでセッションは終了し、視聴者からの Q ＆ A に移りましたが、沢山の質問が寄せられ、視聴者の関心の高さが伺えました。この Q & A をもって、ウェビナーは終了しました。
まとめ
もともとスタートアップ界隈で注目されていたプロダクトマネージャーが、コロナ禍をうけて全業種・全規模で DX 化が急速に求められるようになり、プロダクトマネージャーはさらに必要とされるようになりました。
このウェビナーでは、そんなプロダクトマネージャーの仕事や必要なスキルとスキルアップ方法を紹介いただき、現在 SIer に多いプロジェクトマネージャーとの違いを探りました。
また DX において、お客様がプロダクトマネージャーになるのか、そうではなく SIer からなのか、業界全体で模索が続いていることもわかりました。ただ確実に、 DX の時代には「作って終わり」ではなく「そもそも何が課題で、作って解決できたのか」という視点が求められている、というのがわかるウェビナーでした。
SEカレッジ ウェビナーは今後も旬のテーマをもとに継続して開催しています。ぜひご参加下さいませ！
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。
プロダクトマネージャーがどういった責務を負うのか、それは「プロダクトの成功」です。
では、「プロダクトの成功」は何かというと、ユーザが自発的に使い続けることです。例えば、 Youtube は皆さん何回も何回も見ていて、ユーザが使い続けることで、利益がもたらされています。これはプロダクトとして成功している最たる例です。