ペパボ プロダクトオーナーシップ勉強会 第3回 の発表資料です。Inspired日本語版を読んでいます。

1. プロダクトオーナーシップ勉強会
勉強会#03
「第3章∼5章」
GMO Pepabo, Inc.
Tamon Kumano
2015/05/27

2. ・プロダクトマネジメントとプロジェクトマネジメント
・プロダクトマネジメントとデザイン（設計）
・プロダクトマネジメントとエンジニアリング（実装）

3. ・前回は製品開発における担当者と役割について
・プロダクトマネージャーとプロジェクトマネージャーの違い
についてでした
・3 5章ではプロダクトマネージャーといくつかの役割を持つ
人との関係性について述べています
おさらい

4. ・プロダクトマネージャーとプロダクトオーナーの役割を区別しましょう
・従来のパッケージソフトを作る環境ではインターネットのサービス（ソ
フト）とリリースサイクルが大きく異なります
＞ 今現在の皆さんの置かれている立場やサービスとWindows
のリリースサイクルを比較するとわかりやすいのでは？
＞ だから製品とプロジェクトはだいたいは作業の精度や頻度の点で一致し
ていて(ry
どこにだからがかかっているのか理解できなかった
第3章：プロダクトマネジメントとプロジェクトマネジメント
インターネットがこの２つの役割分担をも変えた

5. ・積極的で強力なプロジェクトマネジメントで管理される必要がある
＞ 消極的ではうまくいかない諸刃の剣？
・プロジェクトマネージャーは重要な調整が多い
・そのためプロダクトマネジメントとの役割を分けなければ必要以上
に時間がかかってしまうだろう
＞ ペパボだとPOやSMがプロジェクトマネジメントしていることが
多いかな
トレインモデルについて

6. ・パッケージソフトとインターネットサービスについての違いを述べたが、筆
者が振り返るにはパッケージソフトの開発であれ、プロダクトマネジメントと
プロジェクトマネジメントの本質は違うのでロールを分けることが有益である
・プロダクトマネージャーとプロジェクトマネージャー
・「価値のある」「使いやすい」「実現可能な製品を見つける」こと
・上記で作られた製品を市場へ適切に送り出すこと
インターネットサービスとプロジェクトマネジメントのまとめ

7. ・緊迫感 -> チーム全体の空気をだらけさせないこと
・立案者たること -> 管理するプロジェクトのゴールの共有と明確な定義づ
け
・明晰な思考力 -> 組織のパワーバランスや、人間関係を円滑にするための
絡まった紐をほどく
・データ指向 -> 直感ではない事実（データ）に基づく道標をつける
・決断力 -> ある要素に対して実行するべきか中止するか意思決定をするこ
と
・判断力 -> あるデータを元に進むべき正しい道、タイミングを見いだすこ
と
・姿勢 -> プロジェクトをやり遂げるため、前向きに問題に立ち向かい解決
へ向け前進すること
優れたプロジェクトマネージャの７つの条件

8. ・ユーザエクスペリエンスデザインはないがしろにされている
・ユーザエクスペリエンスデザインを理解していますか？
・いい製品にするには優れたUXが必要であり、プロダクトマネジメント
とUXデザインが噛み合っていなければならない
第4章：プロダクトマネジメントとデザイン（設計）
ユーザーエクスペリエンスデザインを理解する

9. ・インタラクションデザイン
・ターゲットを深く理解し、ワイヤーフレームを利用する
・ボタンやナビゲーションの位置などのラフにあたる
・ビジュアルデザイン
・インタラクションデザインをうけ、見た目や雰囲気を整える
・ラピッドプロトタイピング
・プロトタイプを作りユーザーでテストをする
＞ ユーザーでテストととは？ユーザビリティテストの前段階だと思っているのですが、ピンとこない
・ユーザビリティテスト
・仮説 実証（デザインの実装）検証のサイクルをして最終的な着地点をプロダクトマネージャーと見つ
ける
UXを構成するデザイン

10. ・デザインとはユーザーのニーズを満足させ、かつ製品要求との適切な着地点を見つけるこ
とである
・製品要求とはプロダクトマネージャーそのものであるため、1章を割いてプロダクトマネ
ジメントとデザインについて記したと思われる
・UXがなぜ必要か？
・機能、コンセプトが似通った他社との差別化である
＞ いい例が思い浮かばなかったけど、minneとcreemaとか？

11. ・デザインの重要性について理解はした！！１
・が、人がいないし外注しようというのはやめま
しょう

12. ・ユーザーや製品に必要十分な理解を外注に求めても彼らには時間がないでしょう
・継続的に上記の知識を彼らは引き継がないでしょう
・細かい修正や検証を即座にできない
＞ 地理的な問題？発注元1社の仕事だけをしてるわけではないから？
・UXは製品にとっての核なのでそんな簡単に外部に出さないほうがよいだろう
＞ UXの技術的な問題ではなく、製品の意思決定に寄与するところであるから
・ビジュアルデザイン、ユーザビリティテストは外注でもよいだろう
・その他の注意事項
・ラピッドプロトタイピングは製品レベルのコードである必要はなく、プロトタイプの使い捨てと心得よ
＞ ラピッドプロトタイプの特性上、採用されない可能性もある段階の製品にエンジニアの手を煩わせるべきではない
インタラクションデザインは外注しないほうがいい理由

13. ・プロダクトマネージャーはエンジニアチームといい関係でいなければならない
・マネージャーの提案にたいしてソリューションを提供するのはエンジニアだから
・信頼関係と対等な関係が必要
・マネージャーは製品を作るためにエンジニアが必要だと思っていることは自由にさせてあげる
・逆にエンジニアはマネージャーが価値のある製品を自由に思い描けるように配慮する必要がある
＞ 技術的制限の撤廃（難しいのでできません、やったことがないのでできません）
第5章：プロダクトマネジメントとエンジニアリング（実装）
正しい製品を作るのか、それとも、製品を正しく作るのか

14. ・エンジニアをよりユーザに近いところに連れだそう
・プロダクトマネージャーはエンジニアの考え方や業界の技術動向について把握し、製品開発や問題解決
に役立つものがないか助けを求めること
＞ エンジニアは自分の知見が活かせる時が来たと思うし、単純にマネージャーに頼られるのはうれしい
・エンジニアはできるだけ最初からプロジェクトに関与させ、何をしたいか、何ができるかを共有して見
積もりをするべき
＞ みなさん経験がおありかと思います。「なんで今になって言うんだよ、最初からアサインしろよー。
プンプン」
エンジニアとの関わりかたについて

15. ・目的を達成するため、製品を必要最小限までそぎ落とすこと。
＞ 目的がより明確になり、エンジニアは最短距離で製品を開発することができる
・極力エンジニアチームをかき回さない
・突発的な仕様変更
・フラッシュアイディアの追加
・エンジニアにもプロダクトマネジメントに挑戦するべきだと筆者は勧めている
・エンジニアが力を発揮するのは、作る価値のある製品である必要があるからだ
・問題意識を持つことによって、より素晴らしい製品が生まれてきたのだ
・キャリアアップにもつながるし、なにより製品にとって素晴らしいことであるはずだ
＞ プロダクトマネジメントの大変さを知れ！ということではない
エンジニアにいい仕事をしてもらうために

16. ・マネージャーが開発チームと離れている、言葉、文化の違いがある場合においては前
項までに述べたプロダクトマネージャーと開発者の関係性がより重要になる
・離れたところにいる人の考えや指示の解釈は推測されることがあり、それが当たって
いるとは限らない
＞ 事業部間でもあるのに東京、福岡間ではより顕著にでるのではないでしょうか？
・このような場合にはプロジェクトマネージャーが調整をするのがよいだろう
遠隔地の開発者とうまくやるには？

17. ・外注をすることは必ずしも悪いことではない
・コストが安くなることもある
・時間差を利用した開発スピードの向上
・ただし上記に挙げたメリットは裏返る可能性も大いにある
・開発をするにあたり大事なのは内製か外注かではなく、チームとそれを構成するメン
バーの力量によると認識するべきだ
開発の外注について

18. ＞ ヘッドルーム バッファー
・見積もるときのバッファー問題
・リファクタしやすい設計
・スケールアウトできる構成
・コードを書き直さなくてすむように熟慮する時間
ヘッドルームについて