プロダクトマネジメント

一言でいうと

何を作り、何を作らないかを決め、作ったものを事業の成果に結びつける活動です。

提唱者と登場年

英語版Wikipediaは、プロダクトマネジメントの考え方の起点を、1931年にProcter & GambleのNeil H. McElroyが書いた社内メモとしています。McElroyは、石けんのブランドの広告を担当していた当時、ブランドごとに専任の担当者（Brand Man）を置き、そのブランドを1つの事業のように管理するよう求めました。メモは、担当者の仕事として、出荷の分析、販売が弱い地域の原因の調査と改善の計画、広告費の管理、包装の見直しの提案などを挙げています。

この役割は消費財のブランド管理として広がり、のちにソフトウェアの分野に取り入れられました。英語版Wikipediaは、ソフトウェアのプロダクトマネジメントを、この基本をデジタルの製品に合わせたものと説明しています。

何を解決するか

開発の力には限りがあり、顧客の要望、営業の要請、経営の方針をすべて同時に実現することはできません。何を先に作るかを決める人がいなければ、声の大きい要望から順に作られ、事業の目標とのつながりが失われます。

プロダクトマネジメントは、顧客の課題、事業の目標、技術の制約を突き合わせ、作るものの順番を決めます。作らないものを決めることも含まれます。英語版Wikipediaは、担当者が顧客の調査、競合や業界の分析をもとに要件をまとめ、製品の方針とロードマップを作ると記述しています。

実際の進み方

まず、顧客の課題と事業の目標を把握します。顧客への聞き取りや利用データの分析から課題を集め、事業として伸ばしたい指標と結びつけます。

次に、取り組む順番を決めます。課題の大きさ、見込める成果、開発にかかる量を比べ、次に作るものを選びます。選ばなかったものについても、理由を関係者に説明します。

そのうえで、開発チームと一緒に作り、出した後の結果を測ります。指標が動かなければ、原因を調べて次の判断に使います。この活動は、開発、デザイン、営業、カスタマーサポート、法務など、社内の多くの部署との調整を伴います。

導入でよくある失敗

• 要望の窓口役にとどめる。集まった要望を開発に渡すだけでは、優先順位が決まりません
• 出した機能の数を成果とみなす。機能が使われたか、指標が動いたかを確かめないまま次の開発に進みます
• 決める権限を与えない。担当者が優先順位を提案しても、別の部署の判断で覆ると、誰も方針に責任を持たなくなります

求人票にこの語がある場合に読み取れること

「プロダクトマネジメント」の経験を求める求人は、作るものを決める判断の経験を求めていると読み取れます。ただし、企業によって担当する範囲は大きく異なります。仕様をまとめる役割を指す場合も、事業の損益まで責任を持つ役割を指す場合もあります。

面接では、候補者が何を作らないと決めたか、その判断の根拠と結果を聞いてください。作った機能の一覧だけでは、判断を担ったかどうかがわかりません。自社の求人票では、優先順位を決める権限がどこまであるかを書くと、応募者との認識がそろいます。

隣接手法との違い