2016年1月7日 PFIセミナーの資料です。動画はこちら https://www.youtube.com/watch?v=IBAsSzdFwQM

1. プロダクトマネージャのお仕事
⽐⼾将平
Preferred Networks America, Inc.

2. ⾃⼰紹介
l ⽐⼾将平（HIDO Shohei）
l TwitterID: @sla
l 専⾨：データマイニング、機械学習
l 経歴：
l 2006-2012: IBM東京基礎研究所データ解析グループ
l 機械学習のアルゴリズム研究開発（主に異常検知）
l 2012-2014: 株式会社Preferred Infrastructure
l ⼤規模オンライン分散機械学習基盤Jubatusチームリーダー
l 2014-: 株式会社Preferred Networks
l 2015-: Preferred Networks America, Inc. @ シリコンバレー
l Chief Research Officer
2

3. 目次
l プロダクトマネージャとは何か
l プロダクトマネジメントの重要性
l プロダクトマネージャの役割
l 応用編：R&Dとプロダクトマネジメント
3

4. プロダクトマネージャの定義
l Wikipedia（経営学用語として）
「企業においてマーケティング活動全般の権限と責任を持つ管理者
の地位にある者…権限というのは製品の開発から、その製品の宣伝、
販売、流通などの広範囲にわたっており…」
l IT業界においてより狭義には、
「製品/サービス/アプリなどを、開発・製造、マーケティング、ア
フターサポート、社内外へのレポート業務まで、製品のライフサイ
クルの全てに渡って、責務を担うマネジャーを指す。担当している
製品に関わるすべての意思決定に関与し、開発、マーケ、営業、財
務など、関連する全ての人々をまとめていく仕事」
4
http://innova-jp.com/google-product-manager/

5. プロダクトマネージャの話が微かに増えている
5

6. 想定する「プロダクト」
l ソフトウェア、ないしソフトウェアを用いたアプリ／サービス
– パッケージソフトの例：Microsoft Word、Norton Antivirus
– ミドルウェアの例：IBM DB2、MongoDB
– スマホアプリの例：Uber、Instagram、パズドラ
– サービスの例：Amazon、iTunes、Netflix
l プロダクトマネジメントの文脈では
– 企業で開発される商用ソフトウェア
l マーケ、エンジニア、デザイナーが関わる
l OSSでも良いが設計・管理の面でかなり違いがある
– 受託開発ではない
l 特定の顧客専用ではない
l 多数のユーザ向けに提供される
6

7. プロダクトの全責任を負う者として
l 主要な役割：“正しい”プロダクトを見つけ出す
– 売れるプロダクト
– 使えるプロダクト
– 実現可能なプロダクト
l ライフサイクル全てに責任
– 企画・立案
– 設計・人材集め
– プロトタイプ開発
– バージョン1.0開発
– パッケージング・リリース
– メンテナンス・サポート
– バージョンアップ開発
l 全ての意思決定に関与する
7
© 2011 Martin Eriksson. Re-use with appropriate attribution.

8. 本セミナーの目的：プロダクトの会社として
8
メンバー全員が
プロダクトマネジメント視点を
持とう！！！

9. 目次
l プロダクトマネージャとは何か
l プロダクトマネジメントの重要性
l プロダクトマネージャの役割
l 応用編：R&Dとプロダクトマネジメント
9

10. プロダクトマネージャは本当に必要なのか？
l 恐らくプロダクトマネージャがいなくてもソフトウェアは作れる
l しかし意思決定の一貫性やバランスに問題が発生する可能性がある
10
デザイナー
© 2011 Martin Eriksson. Re-use with appropriate attribution.
エンジニア
マーケティング／セールス

11. PMの不在(1/3)：ビジネス偏重のプロダクト
l マーケティングやセールスの立場が強すぎる場合
– 見込み顧客、特に声の大きな要望それを代表するとする要望をリストアップ
– PMがいないため、直接エンジニアに要望リストが場当たり的に送られる
– エンジニアが重要度や優先度を判断できず、可否だけを考えて作ってしまう
l 結果：キャズムの罠
– コアプロダクト：差別化できる機能のみ、アーリーアダプターならば使える
l 例：アルゴリズム単体、検索・クエリ処理・機械学習のエンジンレベル
– ホールプロダクト：All-in-oneパッケージ、アーリーマジョリティが求める
l 例：Webインタフェースや可視化、レポーティング機能付き
– コアプロダクトしかない時期にホールプロダクトを求める顧客の
声を聞いてこれでは売れないとして発売延期・開発延長
– コアプロダクト自体の成熟度が足りないため後々問題になったり
競合他社に先に市場を押さえられてしまったりする
11

12. PMの不在(2/3)：エンジニア都合のプロダクト
l エンジニアが大きく決定権を持っている場合
– エンジニアの好みや推測によって必要な機能をリストアップ
– 例えば流行のアルゴリズムの導入（ディー⃝ラーニングとか…）
– 顧客が本当にそれを欲しているかどうかの確認が不足（全く無い）
l 結果：誰も使いたくないオレオレ最強プロダクト
– ニーズのない新機能ばかりのリリース
– 放置されるバグ・改善要求
– 頻繁なフレームワーク変更・リファクタリング
– ユーザーの都合を無視した互換性のない変更
– ビジネス側で正しく顧客の要望とのマッチングが取れず
プロダクトの価値がまったく高まらない
12

13. PMの不在(3/3)：UX視点が欠けたプロダクト
l デザイナーがいないか、権限が弱すぎる場合
– デザイナー的センスを持ち、デザイナーと密に連携するPMが不在
– UXが重要だと思われていない企業ではエンジニアが兼任する
– いるとしても、従属的な立場で言われたことをやるのみになることも多い
l 結果：酷いUX
– 一貫性のないデザイン
– 増改築を繰り返した無様なGUI
– ビジネス都合に引っ張られた操作フロー
– シンプルさと利便性と汎用性と互換性のバランスが崩壊したAPI
13

14. 過去どうプロダクトマネージメントされてきたのか
l 成功したプロダクトはたくさんある
l 全てにプロダクトマネージャという役割の人が居たわけではない
l 部分的に誰かがやっていたケース
– 小さなスタートアップであればCEOやCTO
– アーキテクト、リードエンジニアに近い開発者
– ビジネスもソフトウェア開発も理解するデザイナー
l 合議制でバランスをとってきたケース
– その都度メンバー同士で意思決定
l 最近プロダクトマネージャ職に注目が集まる理由
– 米国IT企業ではプロダクトマネージャ職が確立され重要視されている
– 流行したスクラム開発におけるプロダクトオーナーがほぼ同じ役割
– 一方、組織をまたがったノウハウやベストプラクティスの共有が少ない
– →草の根組織やInspired輪読会、ブログ等での言及が増えている
14

15. ソフトウェア化する世界の中で高まる重要性
l 伝統的な（国内）IT産業
– 受託中心、プロジェクト指向、プロダクトを内製する企業は少数
– 注：ゲーム産業などは例外だったと思われる
l ソフトウェア化する世界における位置づけ
– ハードウェアのソフトウェア化、サービスのソフトウェア化
– ハードウェア／サービスに近いソフトウェア製品の開発が増加
– →ソフトウェアにおけるプロダクトマネジメントが必要になってきた
l 関連：トヨタ自動車における「主査」制度
– 1953年から続く主査（チーフエンジニア）制度
– 各車両開発における単一の総責任者
– 部門の長ではなく、関連部門と連携する役
– 市場・競合分析からコンセプト作り、開発まで一貫
15

16. 目次
l プロダクトマネージャとは何か
l プロダクトマネジメントの重要性
l プロダクトマネージャの役割
l 応用編：R&Dとプロダクトマネジメント
16

17. 典型的なプロダクトマネジメントのワークフロー
17 http://open-pmw.org/

18. 必要な機能を持つ「正しいプロダクトを作る」ための
コミュニケーション、利害調整、意思決定
l 機能要望を集めて真に必要な機能要素をピックアップ
l 緊急度、難易度、人材計画などを加味して優先度を決定
l リリース計画を作成して周知、顧客との調整を協力
l 営業資料や技術資料の作成をサポート
18
顧客
経営陣
マーケ／セールスパートナー
開発エンジニア デザイナー
l 機能の実現可能性とコストについて開発エンジニアに照会
l UXについてデザイナーと議論、方針を決定
l 基本的にコードは書かないが製品の細部について理解
l 必要なリソースについては経営陣に直接かけあって補填

19. マーケティング／セールスにおけるPM
l 企画・設計
– 顧客ミーティングに同行して顧客の真の要求を探る
– 集めた機能候補リストをまとめて優先度付けを行う
l 開発・リリース
– 機能リリース予定を伝える
– リリースする
– サポートを行う
l 改善・メンテ
– バグレポートや改善要望を受け付ける
19
© 2011 Martin Eriksson. Re-use with appropriate attribution.

20. 開発におけるPM
l 企画・設計
– 機能候補の実現見込み、コスト見積もりをエンジニアに依頼する
– リリース計画を立案して必要なチームづくりを行う
l 開発・リリース
– 開発を待つ
– 出来上がったプロダクトの動作を理解する
– ドキュメントやサポートの準備を行う
l 改善・メンテ
– サポート体制を維持する
– バグ対応を依頼する
20
© 2011 Martin Eriksson. Re-use with appropriate attribution.

21. デザインにおけるPM
l 企画・設計
– 製品の企画段階でおおまかなデザインの相談をデザイナーに行う
l 開発・リリース
– エンジニアが作業を始める前に詳細なデザインを詰める
– 可能であればプロトタイピングとその修正を数ループを回す
– プロトタイプをマーケや顧客に触ってもらってプロダクトの相互理解を確認する
– プロトタイプをもとに実際の開発にとりかかる
l 改善・メンテ
– サポート体制を維持する
– バグ対応を依頼する
21
© 2011 Martin Eriksson. Re-use with appropriate attribution.

22. 他の役職との違い
l プロジェクトマネージャ
– 小さいチーム単位で開発作業のリードや進 等の細かい管理まで行う
– プロダクトマネージャの仕事には含めないほうが良い
l プロダクトマーケティング
– ビジネス側、製品の売上に対して責任を持つ者
– 顧客との利害調整のためにはプロダクトマネージャと人を分けたほうが良い
l 組織上の所属長
– プロダクトマネージャは多くの役職の人と連携する
– 職能別組織ではプロダクトマネージャは所属長にはならない
l CTO
– スタートアップでは兼任することが多い
– やがてCTOはプロダクト横断の役割が必要になる
22

23. 目次
l プロダクトマネージャとは何か
l プロダクトマネジメントの重要性
l プロダクトマネージャの役割
l 応用編：R&Dとプロダクトマネジメント
23

24. R&Dとプロダクトマネジメント
l 課題：機能の実装に不確定さが増す
– 機能自体が新規であるか、その実現手法が新しい場合
– 機能実装を確定させるための見積もりが難しい
l 解決案
– 実現を試すR&D活動をまず行う
– R&Dが上手くいったところでプロダクトに組み込む開発を行う
– 社内R&D活動として、あるいは共同R&Dプロジェクトとして
l 注意点：開発コストと再利用性のトレードオフ
24
プロダクト
OEM/
ライセンス/
パートナー
プログラム
R&D
プロジェクト
パッケージング
再利⽤
機能追加
スケールしない スケールさせるR&Dとスケールするライセンス
ビジネスの間をつなぐ存在

25. まとめ
l プロダクトマネージャはプロダクトの全てに責任を
持ち、マーケ・エンジニア・デザイナーを中心とす
るステークホルダー全員と連携しながら「正しいプ
ロダクト」を生み出すことに全力を注ぐ仕事
l 皆さんの日々の仕事のなかでも今回話があった、プ
ロダクト全体を見渡したうえでのコミュニケーショ
ンがあればもっと楽になるかもしれません
l プロダクトマネージャをゼロから育てるのは難しく、
素質を持った人が成るのが最も早いそうです
25
メンバー全員が
プロダクトマネジメント視点を
持とう！！！

26. l 「Inspired: 顧客の心を捉える製品の創り方」
Martin Cagan著、SVPG Press
l 「世界で闘うプロダクトマネジャーになるための本
トップIT企業のPMとして就職する方法」
Gayle Laakmann McDowell & Jackie Bavaro著、マイナビ出版
l 「キャズム」
Geffrey Moore著、翔泳社
l “プロダクトマネージャーについて”
http://d.hatena.ne.jp/naoya/20151026
l “Googleのプロダクトマネージャーに学ぶ６つの仕事術”
http://innova-jp.com/google-product-manager/
26
参考文献