プロダクトマネジメント（PM）についての、学術的研究の歴史と定義

この記事は Product Manager Advent Calendar 2019 の 14 日目に向けて記載されたコンテンツです ... と思って書きながら、とはいえ投稿が遅れていたら、 Advent Calender の枠が他の人に上書きされていた！笑 そういう仕様なのですね、、反省。

プロダクトマネージャー 2 年目の @kan です。 現在は株式会社メルペイで PM として、日々たのしく仕事をさせてもらっています。また、個人的な活動として「ソフトウェアプロダクトマネジメントの体系化」を目的にした論文を書いています。仕事をしながら学術的な研究の、 2 重生活を送っています。刺激的でとてもたのしい。

このまとめでは、研究活動から学んだ学術的世界から見た、プロダクトマネジメント研究の歴史とその定義についてまとめていこうと思います。本当は「プロダクトマネジメントにおける活動 / フレームワーク・プロダクトマネージャの役割」についてもまとめたかったのですが、長くなりすぎるのでそれは後日...。

用語の整理ですが、学術的には「プロダクトマネジメント（車などのハード）」と「ソフトウェアプロダクトマネジメント」は完全な別物として扱われています（参考）。ここでは用語を一般の理解と揃えるために「ソフトウェアプロダクトマネジメント = プロダクトマネジメント」として話を進めていきます（*1）。

「プロダクトマネジメント」の一般的な定義

まずは、プロダクトマネジメントの一般的な定義について。日本で PM の著名な人と言えば及川さん（@takoratta）かと思います。彼の定義によるとプロダクトマネジメントとは、「『プロダクト』の開発を推進し、グロースさせるためのすべてをマネジメントすること」というのが上げられています（参考）。

その他プロダクトマネジメントに関するよくみる表現には、プロダクトマネジメントトライアングルがあります。プロダクトマネジメントとは「このトライアングルのすべての要素を健全に機能させること」というのが考案者の Daniel Shmidt による定義です。 

シンプルに言うと「実装・顧客・事業」の 3 つのバランスを取ることがプロダクトマネジメントの役割だとまとめられています。 3 つのどこに比重を置くかで、その他の職種の定義を行っています。

個人的にはここにオペレーションも追加されるべきかなと思っています。オペレーションが存在しない事業など存在しないからです。とはいえ、Consumer 向けの事業をやってる限りでは上記の定義で大枠あてはまりそうかなと。

一般的な定義が長くなっては主題とずれてしまうので、さくっと終わらせて学術的な話に進んでいきます。ここまでの定義を何となく頭に入れて、「一般的に理解されてるプロダクトマネジメントと、学術的な定義って近いんだっけ？」というような視点で続く部分を呼んでいただければと思います。

1997 :  New challenges for version control and configuration management: a framework and evaluation by Kilpi 

学術的な観点からプロダクトマネジメントに関して初めて言及されたのは 1997 年、 Kilpi がソフトウェアプロダクトマネジメントのプロセスについて記載した論文です（参考）。

Kilpi はプロダクトマネジメントを技術的な側面から捉え、「バージョンコントロール・システム構成管理・プロダクトマネジメント・プロダクトの全体管理」の 4 つのプロセスからなると定義しました。

Kilpi の研究ではソフトウェアプロダクトマネジメントは、クルマなどのハードのプロダクトマネジメントを含めた概念としています（ここだけ冒頭の用語定義のせいでおかしな話になってしまった）。

クルマなどの「プロダクトマネジメント」では、主にマーケティングやセールス活動に焦点があてられてきました。それは開発プロセスとの距離が遠く離れていたためです。工場の製造ラインを利用したプロダクトプロセスと、 10 人ほどで成り立つソフトウェア開発プロセス。この差分が、ソフトウェアプロダクトマネジメントを更に複雑にしている要素として存在していると整理しています。

2006 : The impacts of software product management by Christof Ebert 

Kilpi が論文を書いた 1990年代はまだソフトウェア開発の黎明期。もう少し時間を進めて、 2006 年に記載された「The impacts of software product management by Christof Ebert」についても目を通してみます。

彼は、コンピュータサイエンスを専門とする教授で、ソフトウェア開発のコンサルティング会社を営む起業家の顔も持ちます。彼の論文は読みやすく事例が豊富なので、お時間のある方は呼んでみることをおすすめします。

彼がプロダクトマネジメントに価値を見出してるのは、そのビジネスインパクトの大きさからです。彼の研究によると、プロダクトマネジメントを導入している企業では、製品の質が 80% 上昇し、機能開発のサイクルに必要な時間が 36% 程削減されたそうです（参考）。

Ebert はプロダクトマネジメントを「事業価値を最大化するために、ある機能の構想から市場や顧客に提供をするまでを管理する役割や職務」と定義しています。上記の定義を実現するための具体的な活動は「要件定義・リリース判断・プロダクトライフサイクルコントロール・チーム作り・プロダクト開発」だと説明しています。

そして彼はプロダクトマネジメントを「プロジェクトマネジメント・マーケティングマネジメント」の 2 つと比較し、より定義を厳密にしていきます。全体像は以下の画像の通りで、プロダクトマネジメントにおける一部の活動として、マーケティングマネジメントやプロジェクトマネジメントが切り出されていると説明しています。

プロジェクトマネジメントでは「スコープが決定されたプロジェクトを、最善な形でやり遂げるための管理」と説明されています。プロダクトマネジメントでは、「走らせるプロジェクトとそのスコープを決定する」ことが求められます。プロジェクトマネジメントよりも 1 つ上流過程の意思決定をしているようです。

一方マーケティングマネジメントでは「プロダクトやサービスのどの様に売るのかを管理」を決める（参考）、つまり顧客に製品を届けることがマーケティング・マネジメントにて求められます。その担当者は、市場とカスタマーサクセスに責任を持ち、顧客のニーズや市場のトレンド、営業的観点や競合関係について深い知見を持つ必要があります。

プロダクトマネジメントでは、戦略決定から顧客へのデリバリーまでの、全てのプロダクトライフサイクルに責任を持ちます。戦略策定から開発 、顧客へのデリバリー、プロダクトを閉じるところまでがライフサイクルの意味するところです。

ここまで話し Ebert は、 Product Management にて行われるべき活動を以下の図に集約しています（参考）。

シンプルに言うと Product Management で達成するべきは、「全社戦略と個別プロジェクトにおける活動の一致」。ぼくはスタートアップでは「経営 = プロダクトマネジメント」だと考えています。中間レイヤーも Project も少なく、経営者が戦略と日々の活動のズレを無くし、会社と組織を正しい成長へと導いていけるからです。

先日、 @yamotty3 さんから「スタートアップの本当の強みは、ストラテジーと実装の一致」という、 Ebert が考える「プロダクトマネジメント」に近いツイートがありました。組織の規模が大きくなって来ると自然と経営者は全てに目が届かなくなる。その時に、経営者と同じ目線で戦略と実装を一致させる。それこそがプロダクトマネジメントで果たすべき活動であり、「プロダクトマネージャー = mini CEO」と言われる所以なのかもしれません（参考）。

Ebert 以降もプロダクトマネジメントに関する論文はいくつか執筆が行われています。しかしそれらの関心事はプロダクトマネージャーの役割や、プロダクトマネジメントにおける活動（フレームワーク）などに向けられ始めます。プロダクトマネジメントの定義とその重要性は、 Ebert のこの論文によって学術的な世界での共通認識となりました。

では続いて ... と行きたいところなのですが、すでに結構な長さになっているので、今回はここで終わろうと思います。もしもそれなりに反響があれば、前の段落に記載したような話についても今後記載していこうかなと思います。

さいごに

自分の考えを少しと、小さなまとめを。

自分がプロダクトマネージャーになった理由は「最も "事業" について理解できる職種」だと直感的に思ったからです。日々の仕事・学術的な研究を行っていくうちに、その直感は次第に実感へと変わりました。それ故「将来は自分で事業をやりたい」と思う人が、優秀なプロダクトマネージャーの元で修行をするのはとても価値のあることだと考えています。

とはいえ、そんな環境を手にすることがそもそも難しい。一方自分で学ぼうにも、世にあるプロダクトマネジメント論には（良くも悪くも）オレオレフレームワークが多く、正しいものが分からない。いずれにせよ初心者がプロダクトマネジメントを始めるにはつらい環境です。

じゃぁ自分で解決すれば良いやと始めたのが、「若手 PM 会」というコミュニティ運営と「学術的にプロダクトマネジメントを体系化する」という 2 つの活動。この活動を通して知り合えた方々は刺激的な方が多く、また自分の思考を整理するにもとても良い機会をいただいてます。感謝。

ここまでまとめておいて何ですが、プロダクトマネジメントは座学だけで学べるよう様なものではありません（参考）。成功も失敗も経験しながらプロダクトマネジメントに関する哲学を育て、ある種のオレオレフレームワークを持った上で何かしら成功に導いて初めて、プロダクトマネージャーとして一人前かなと感じています（一周した...？）。

参考

(*1) ソフトウェアは、人類の今までの発明の中で、最も複雑で精巧な製品だとされています（参考1, 参考2）