POとPOじゃない人の勉強会 #06

2015/06/16 GMOペパボのライティ

12章 〜 14章

製品を見つけ出す

製品理念

製品委員会

12章製品を見つけ出す

ソフトウェア開発は2つの段階に分けられる

● エンジニアリングの段階に入ったら入ったらかき回さないこと！● バージョン1の実行と2の発案を並行すると良い

正しい製品を定義する

作るべきものを作る

（発案作業）

それを作る（実行段階）

製品の発見を予定通りに進めることはできるのか？

こんな風に進めば最高● 事業性評価● ユーザーインタビュー● 製品要求のたたき台を作

る● プロトタイプ作り● ユーザーテスト● 製品仕様の見直し

うまく事は運ばない● ユーザーは製品アイディ

アに興味なし● 理解してもらえるプロトタイ

プ作成が困難● 反応がイマイチ● そのままエンジニアリング

に着手。結果イケてない製品のできあがり

フィードバックを元に製品開発を軌道修正しないと何にもならな

い

製品の発見を予定通りに進めることはできるのか？

「製品を見つけ出すこと」

○ その製品を欲しがっているユーザーは本当にいるかどう

か知る

○ 問題に対する価値ある実現可能なソリューションを見つ

け出す

「製品要求の定義とデザイン」はサイエンスというよりもアート

製品の発見を予定通りに進めることはできるのか？

● ソフトウェア業界では製品発見のフェーズを計画的に進める

ことにこだわっている

○ ※ではどうすれば良いのか？

● ベンチャーが失敗するやり方。エンジニアを雇ってやれるこ

と何でもやらせる。「構え」「打て」「狙え」

● うんと早い段階で製品発見プロセスに注力。ソリューション

を見つけたら実行あるのみ。

● 作るべきものを決める段階と作る段階は分かれている

● 作り始めたらかき回さないこと

● フィードバックを元に製品開発を軌道修正しないと何にもな

らない

● ユーザーは本当にいるのか？価値あるソリューションはみ

つけ出せるのか？

● うんと早い段階で製品発見プロセスに注力

12章 まとめ

13章製品理念

● 製品開発のための一連の原則を定めたもの

● 両立させるのが難しいものの折り合いを付けて

優先順位を変えるときの判断基準となる

● 映画サイトの例

○ ※どこに価値を置くか、を決めること？

● 製品開発チームを一つにし、考えをまとめるメ

リットがある

何が大切なのかを決める

意見の対立を解決する

● 製品に関する意思決定でことさらに起こる諸問題(だらだら

続く会議、決まったことに従わない、複雑な人間関係など)○ みんな製品に一家言ある

○ 全員が強い思い入れがある

○ 自分を製品ターゲットのユーザーに近い存在だと考えて

いる

● 製品開発チームに命令できる立場にないので辛い

● 身動き取れなくなった場合は上の人間に決めてもらう。しか

しこの状況は既に**失敗**。

● 意思決定をするのは大変なので以下の点について全員の

理解を一致させておこう

○ 解決しようとしている問題はいったいなんなのか？

○ いったい誰のためにこの問題を解決しようとしているの

か？つまり、どういうペルソナを対象としているのか？

○ この製品化で達成しようとしている目標は何か？

○ これらの目標の中での優先順位は？

筆者の経験ではほとんどの場合、意見が食い違うのは目標の解釈や優先順位がメ

ンバー間で統一されてないのが問題

意見の対立を解決する

プロダクトマネージャーは意思決定のプロセスと理

由付けをみんなに完全に見えるようにしておくこと

が大事。

直感だけに頼っている、とメンバーから思われるよ

うではダメ

意見の対立を解決する

● 何が大切なのかを決めよう

● 意見が対立して、上の人間に決めてもらう事態は既に失敗

のケース

● 「解決しようとしている問題」「誰のためか」「達成しようとして

いる目標」「優先順位」について、全員の理解を一致させて

おこう。

● 意思決定のプロセスと理由付けを見えるようにしておくこと

13章 まとめ

14章製品委員会

● 主な関係者と意思決定者が顔をそろえる仕組

みを用意するとスムーズ。そのために製品委員

会を作ると良い。

● 製品を市場に送り出すために必要な意思決定

をする、という明確な目的のために主な意思決

定者を全員集められる。

タイムリーで確実な意思決定をするために

製品委員会の目的

1. 製品戦略の方向性を決めること

2. 製品のために人や予算を配分すること

3. 会社による製品の取り組みを適当なレベルで監

視すること

● CEO, COOまたは担当部門の部門長

● プロダクトマネジメント担当部門長

● ユーザーエクスペリエンス担当部門長

● マーケティング担当部門長

● エンジニアリング担当部門長

● サイト運用担当部門長

● 顧客サービス担当部門長

※ペパボだったら1サービスにまとまってる気がする

委員の顔ぶれ

1. 製品戦略と製品ロードマップをレビューし、詳細な市場機会

の調査をするべき製品を選定する

2. 市場評価と提案をレビューし、ソリューションを見つけだすた

めの作業に進めるかどうかを決定する

3. プロトタイプ、ユーザーテスト、コスト見積もりをレビューし、

エンジニアリング作業に進めるかを決定する

4. 製品の正式版、品質保証の結果、販売開始計画、市場へ

の影響の評価をレビューし製品の発売を決定する

委員会の役割

補足

● 製品委員会では小規模なアップデートや修正をレビューす

る必要は無い。

● 製品のデザインを決める場ではない。

● 2のコスト感を当てにしない。3では責任持てるレベルの見積

もりを出す。

● 発売後も委員会が関わると時として有益。

● プロダクトマネージャーが委員会でプレゼンできるようにしま

しょう

プロジェクトコストの見積もりは いつやれば良いのか？

● 見積もりには混乱が多い

○ 経営陣は早い段階から知りたいが、正確な見積もりができるのはプロジェ

クトのずっと後だから。

● おすすめのやり方

○ 経営陣に解決しようとしている問題の価値を判断してもらうために市場性評

価のための10個の質問を評価する

○ ここでざっくりした見積もりをする。「膨大な」「ある程度の」「たいしたもので

は」というレベル

○ この市場機会が予測コストのわりにまずまずなら、製品を定義するための

指示がでるはず

○ エンジニアメンバーも巻き込んで製品の詳細な仕様を決める作業が終わる

と、精度の高い見積もりもできているはず

○ それを持って経営陣が製品開発をするかどうかの最終決定をする

● つまり、最初ざっくりやって、その後仕様を決めるときに詳細に見積もろう＼

(^o^)／

● 関係者と意思決定者が顔を合わせる仕組みが製品委員会

● 方向性の決定、人や予算の配分、監視が目的

● 製品開発のポイントポイントでレビューや承認を行うことで

製品開発全体を捗らせる

● 見積もりは最初にざっくりやって、その後仕様を決めるとき

に詳細にやる

14章 まとめ

15章へ続く...