2017/11/14 pmconfjp
・Sessionを聴講していて気づいた中で、
自分が大事だと考えたこと
ユーザ視点が足りていない
広い視野で見ること
PCで記載しにくいことは手書きでもメモする
・2日間の間では触れられなかったことで、
自分では大事だと考えたこと
発言が足りないこと
・Next Step
現状の役割に対して役割以上の働きをしようとしない甘えをどうにかすること
・昨年の現状
プロダクトマネージャの価値観がまだ知られていなかった。
プロダクトマネージャが考えることはなんなのだろうかというのを話した。
・反省
みんな同じようなことを思ったりなど
個人を指名して意見を出してもらった方が良かったのでは？
というのがあった
・目的
2日間、言葉や背景を汲み取って今後に生かしてください
執筆・写真等々OK
先にまとめとかはこれ見た方が早い
https://twitter.com/search?q=%23pmconfjp&src=tyah
10:10 - 10:50 なぜ今プロダクトマネジメントか
齊藤 満 氏
楽天株式会社 Senior Manager
MicrosoftのSE/PMの人だった
本を書こうとしたときにPMとはこれだというものをなかなか書けない。
PMだと思うものはデザインやサービスを定義すること
ビジネスの構成としてSales Product Marketing
Productの役割に PM Developer ServiceOwner QA
PMが考えなくてはならないこととしてEnd to End
End to Endを忘れがち
PMはインターフェースを決める役割もあるが専門的に行うためのPMも存在
プロトコルはDevloperが行うべき
Abstracttion Layerや
Memory/GPUなどの専門的な
Physic PMというのも別であるべき
UX PM
Protocol PM
PMのいる価値について
PMのスタイルとは3つ
Generalize
誰かがやってることを真似してやってるのは価値がないPM
ランダムなゴールがあったときにコアな問題にどれだけ近づけるかが良いPM
アジャイルを一気に入れたときに目の前の問題を解決しようとして
結局コアな問題解決ができていないというのがよくある話
この1つを解消したら他の様々なリクエスト全部解消できそうなどが見えてると良い
観点として
Culture
Personality
Service
Data Type
Action/Method
Categorization
の分析が行えると良い
Communication Skill
PMの95%の仕事はディスカッション
ユーザが増えるほどフィードバックがなくなり孤独になる現象があったり
遠くの人の意見を聞かずに近い人の意見を多く聞くようになる傾向が出てくる
Decision Making
いろんな方のフィードバックから自分が納得した上で決断すること大事
WindowsのPrintメニューを
接続していないときにユーザに表示しても
意味がないのでPrintメニューを表示しなくても良いのでは？という議論があった
常に話を聞く体制を作って自分の力を持って決断できる人が求められる
11:05 - 11:35 トークン・エコノミー時代のプロダクト設計
宇野 雅晴 氏
Omise Japan株式会社 Business Development Manager
現在ICO調達中
ICOとは IPOと似ているがクラウドファンディング（投資）に近い
ブロックチェーン 中央管理がないP2Pの台帳（データベース）
各ノードで管理されるものなのでデータ改ざんが難しい
過去の取引履歴を見ることができる
BitcoinとEthereumの違い
元々はEthereumはネットワーク使用料として使われていたもの
基本ICOは全てトークン
ここでいうトークンとは
通過型
購入するような
利用権型
分散型のDropBoxがあったとき
各PC同士でストレージの貸しあいができるような
DAO配当券型
プログラム上で自動的に配当されるようなもの
ハッキングされて不正分配ができたりという悪例がある
がある
今後出てくるであろうトークン
会員券・プリペイド型
SteamPower ⇔ Steam ⇔ SteamDoller
ポイント
報酬設計を考える必要
サービス外での利用性とか
OmiseGo
分散化されたeウォレットや決算の取引場を作成中
ブロックチェーンの問題点
トランザクションが遅い
11:50 - 13:15 プロダクトマネージャートークセッション
齊藤 満 氏
楽天株式会社 Senior Manager
Takeoiyo 2017
伊豫 健夫 氏
株式会社メルカリ 執行役員
Ryoheimiyota
御代田 亮平 氏
LINE株式会社 開発1センター プロダクトマネージャー
Kazushifujita
藤田 和司 氏
株式会社サイバーエージェント アドテク本部 アドテクスタジオ チーフプロダクトオフィサー
Takoratta
[ファシリテーター]
及川 卓也
Product Manager Conference 実行委員
フリーランス
なぜ今プロダクトマネージャなのか（再見
PMの裁量について
PMガプロジェクトマネージャ・プロダクトマネージャが同一視されてしまうのがあって
プロダクトマネージャとして成長することがないみたいなことがある
PJMではなくPDMになりたい、という人が増えてる
プロダクト愛
ものづくりが好きなこと 貢献しようということ
0ベースで考えられること
概念をない状態で1にできるような人はPMに向いてる
https://app2.sli.do/event/9nor8pyx/ask
質問内容とか #S132
・会社によってもちろんProduct Managerのカバー範囲も違うと思いますので、
みなさんのケースでよいのですが、責任を負っている具体的なKPIは何ですか？
それはご自身の責任でContorolableなKPIですか？
KPIの定義はだいたいみんな数字的なものだか影響力も
エンジニアよりのPMはデモアプリやQiitaなどのコミットを評価したりなどもしてる
UUやCVだけ追いかけてもイノベーションは生まれない
・プロダクトマネージャと事業責任者の違い
風土によってこの２つは同一視されるものではあるが
エンジニアサイドのPMだと事業的なとこ弱かったりするので分離させてるとか
PMというのかCTOと同一しているというか
・経営者や他部署（営業等）とのコミュニケーションで気をつけていることはありますか？
PMが方針を決めてもステークホルダーが多すぎて利害関係を調整しきれないし、
要件を持って来すぎれば自部門（製品開発部）からそっぽを向かれてしまうし、
結局残業で頑張ってる感を出す位しか認めてもらえない状況です。
あなたならどう落とし所を作ります？
ステークホルダの人の立場になって、相手にとってのお客を主語にすること
組織のことを思って全体のビジネスモデルのビジョンを語ること
・ある程度育ってきたプロダクトだと「なにをしないか」「なにを捨てるか」の判断が業務の大半になってきます。
組織としてもどんどん身動きが取れなくなり、なにもできなくなってしまいがちなのですが、
みなさんのオススメの「捨て方」を教えてください。
無駄なUIを削ってより良い機能を入れるために
削って試してみたときの数値をみるしかないのでは？
手段が目的になっていてたまたま別の対応で手段削れそうな時はごっそり削るとか
・プロジェクトマネージャーとプロダクトマネージャーの1番の違いは？
プロジェクトマネージャーの経験があるのですが、
プロダクトマネージャーに転身しようと考えています。
プロダクトマネージャ 全体的なファシリテートができる人
スクラムマスターとプロダクトマネージャの違いに通じそう
・規模の大きいアプリ・サービスだと、領域を分解してプロダクトマネージャーを複数配置しても、
全体のUI/UXやソースコードが分解できず、複数の施策がコンフリクトしてしまい、
スピードの鈍化や施策のサスペンドが多発してしまいがちだと思っています。
どういったアプローチでこういった課題を解決していますか？
ここのコンフリクトとして
アーキテクト的な思考の違いか
プロダクトの行いたいもののコンフリクトが考えられる
コミュニケーションだけではコンフリクト回避することは難しい
マイクロサービスでのアプリケーションを作成している少数チーム内で対応できるような体制にしたりしている
プロダクトの中に複数のプロジェクトがあるような状態が望ましい
・弊社のPMは製品のデリバリーにまで責任を負っています。
製品に組み込んでいるミドルウェアの不具合でデリバリーが２ヶ月遅延しています。
自チーム都合ではないので残業してリカバリーをするにも士気が落ちてしまっており、
どうしたものかと思案しています。あなたならどうしますか？
自社責任ではないのにモチベーション下がってしまうような出来事
線を引き直すとか 遅延前は時間があるはずなのでその時間を活用してモチベーションをあげるとか
・「プロダクトマネジメント」という言葉自体の社内における認識が低い（ない？）と感じていて、
それにより会社全体としてプロダクトに向かうような取り組みができていないのかなと思っております。
プロダクトマネジメントを社内で広めるためのアプローチなど
トップダウン・ボトムアップ含めてご経験からお聞かせいただきたいです。
PDMを広げるには
お客にプロダクトの価値をコミットできる
企画をするとか
PDMのカバーできることをお伝えするとか
13:30 - 14:00 プロダクトマネージャーに経営者が期待するもの
佐藤 裕介 氏
株式会社フリークアウト・ホールディングス 代表取締役社長
プロダクトマネージャが経営者に求めること
プロダクトバリューの変化を厭わないこと
バリューとは技術・ユーザ・市場によって変化するもの
一貫したプロダクトバリューとかいう嘘
巨大なソフトウェア以外はビビるぐらいに変化するということを意識すること
プロダクトバリューの例1
SSP（アドエクスチェンジ、ネットワーク）のPC在庫からリダケユーザだけまとめて買えるとかの
販促をする
プロダクトバリューの例2
宣伝系に向けて効果測定を行なった
プロダクトバリューの例3
モバイルの対応などいろいろでプロダクトバリューが不明になり
経常利益も下がっていく一方だった
プロダクトバリューの例4
モバイルの良質な掲載面で独占的に買い付けが可能でCPA/CPIを販促系に売り出した
なんとか再浮上することに成功した
14:15 - 14:45 IoT、ビッグデータ、人工知能によるユーザー理解を通じたプロダクト開発
岡田 陽介 氏
株式会社ABEJA 代表取締役CEO
ディープラーニングが売れない理由として
ユーザが人工知能をやりたいというわけではないということ
今まで
データに対してプログラムを施し意図通りに動かす
現在
アルゴリズムを作るためのアルゴリズムを行なって自動生成が初めて行えているという話
ディープラーニング自身がユーザを理解するためユーザに最適化されたモデルができる
ディープラーニングで重要なこと
まずリリースする データを貯める
アノテーション作業が大変
犬、猫をぽちぽちし分ける作業
実はデータサイエンティストが隠れてこの作業をやってるらしい
画像の枚数は多ければ多いほど良いが基準はPMが決めることも
大きいモデルのものだと学習する時間が一日かかるときがあり
たまにプロセス死ぬときがあるので難
精度は何%あれば良いのかのすり合わせ
15:00 - 16:00 Salesforceで行われているプロダクトマネジメント
浅田 慎二 氏
株式会社セールスフォース・ドットコム セールスフォース・ベンチャーズ 日本代表
Ken Wakamatsu 氏
（生まれが日本国籍でなかったため漢字の名前がないらしい）
株式会社セールスフォース・ドットコム
VCが考える良いプロダクト
ベンチャー企業が潰れる理由 経営数字が出ていない 人が欲しがるもの作ってないなど
よいプロダクトの3つ条件
・誰のPainなのかどのようなPainなのか
・ユーザPainのストーリがかけている
・MustHave担っている
UIが優れていることがベストであるが
デザインがイマイチでも結果的に使えればいい
3大原則
・Make it Simple
・Release it quickly 手描きでも可
・Ask Users
Product Managerとは
salesforceではProductの最大責任者
開発チームはTechnology&Productsで形成
なぜ分けているのか
役割における目的が違う
テレビを例にすると
テレビを薄くするのはテクノロジーの役割
薄くしたテレビを壁にかけるような風にしたりするのはプロダクト
スクラムチームの役割
写真撮った
ロードマップなどどう作成するのか
V2MON ADM(アジャイル開発)
V2MONというプラン設計
https://trailhead.salesforce.com/ja/modules/manage_the_sfdc_organizational_alignment_v2mom/units/msfw_oav2m_creating_org_alignment_v2mom
ADM
http://www.publickey1.jp/blog/11/post_149.html
紙でのプランニングを行い、saleforceではほぼほぼプランを変更しない
TRUSTがもっとも大事
Automationなどを行うようにし品質向上をしている
BUG FixによるROI 損でしかない
バグ報告は全てのチームに見えるようにしており
見えるようにしていないと今後の作業着手できるかわからんから
コードのクオリティが高いのは木曜日
なのでこの日はミーティングを行わない 出社しなくて良い
16:20 - 16:50 メルカリUKにおけるプロダクトマネジメント
木下 慶 氏
株式会社メルカリ
JP US UKでの国ごとのデザインの違いがある
チーム構成
Marketing
Product Team 1 & 2
- iOS Android
- BI
- QA
- PM
- API
- Design
Team1はCRM担当（検索・購入前処理
Team2は購入後の処理担当
CS
Ops
QuarteryはOKRを使ってる
http://careerhack.en-japan.com/report/detail/781
Analysis
lookerを使用している
BIツール
購入者の行動履歴を見れるようにしている
仕様はConfluence
ストーリを記載する
プロトタイピングは
デザインはsketch、inVisionでフローを作る
MA & CRM Tools
appboy 一度も購入を行なったことがない人にプッシュ通知行ったりしてる
UKにいる日本人の方にインタビューして見て
日本と海外の違いを教えてもらった
ロンドン UKはデリバリーを行うのが盛んで
Webでハンバーガを購入して店で受け取るようなのも盛ん
ロンドンでの意見として写真を大きくして見たいとか
日本では逆に一覧で表示などUIの違いを取り入れてる
17:05 - 17:35 開発チームが安定したプロダクトマネジメントを実現するための７つのルール
御代田 亮平 氏
LINE株式会社
LINEログイン機能などで3rdパーティサービスでの利用を今後増やしていきたい
プラットフォーム機能を後悔していくことによる利用性
API内の問題で
独自実装
謎のマジックナンバー
とかあったり
JSONの中身が配列指定されているが複数指定できない
イベントタイプがマジックナンバーらしい
多様なステークホルダー
開発者 ユーザ パートナー etc
トレードオフな問題
セキュアにするとAPIのフレキシビリティが減る
大きいパートナと組めばレベニュは得られるが
開発チーム
Authentication
Token
Strage
Bot
Login
FE
SDK
不明瞭なOwnershipが原因で不完全なプロダクトをリリースしてしまう
開発体制変更と7つのルール
目標
・開発目線のプロダクト
・事業目線にも優れたプロダクト
・クオリティを損なうことなく迅速に継続的にリリース
7つ
-
Ownership
「誰」の一存で決まるのか決める
その「誰」が意思決定プロセスに常に加わっていること
CEOとつながる謎のAPI Xチームみたいな体制が昔あった -
依存関係が見える化
関係者を束ねるようにする
ツールでカバー
PMが人力で依存関係を整理したりする
どのチームがいつリリースするかをわかるようにする -
新規開発プロセスの明示
5W1Hを明示する -
3つの数字を最大化
開発者が開発に注ぐ時間 * 書いたコードがリリースされる割合 * 実際に使われる頻度
実際に使われる頻度 売り上げやPVなど -
Slient Majority or Vocal Minority
最重要パートナであるVocal Minorityに耳を傾ける
謎パラメータだらけになってしまうかもしれないがドキュメントやチュートリアルでカバー
→ プロダクトライフサイクルにおけるコストを考えなければならない
メンテナンス
カスタマーオペレーション
本来の方向性との一貫性
引き継ぎ -
スクラムマスターやPjM
QA ⇔ 要件定義 ⇔ 開発のサークルを回すわけだが
PMが開発やQAのフォローにかける時間を少なくする -
Party Managerでもある
2日目
10:10 - 11:35 今いるメンバーで「大金星」を挙げるチームの法則
仲山 進也 氏
仲山考材（株）代表取締役・楽天（株）楽天大学学長
なんかグループでフラフープを下げて指から離れないかみたいなことやってた
その際での振り返り
振り返りの視点として
みんなで１つの仕事を成し遂げた時に
うまくいかなかった時どうだったか
逆にうまくいった時どうだったか
フラフープ下げて見ての振り返り
一旦あげたほうがよかったのではというのもあったが
皆が下げようという思いがあったので結果的にクリアできた
自然と自分の役割を理解して作業をできた
意図のわからないタスクを振ってしまわないようにするの大事
時間の期限というのが設けれていなく割とみんな急ぎにやろうというのはあったのかも
共通の課題があったからやりやすかったというのある
事前に名前とか共通の認識があればもっと早くクリアできたかもしれない
グループのチームの違い
使い分けあるけど
チームは個性のあるパズルに似ている
グループは集まり
チーム成長法則
赤点ゾーンから這い上がりしてる時が一番パフォーマンス出ている時
成長ステージ
グループ
フォーミング（形成期）
何も情報がない状態
ストーミング（混乱期）
就活するときのグループ面接みたいな状態
意見のバッテイングが起きる状態
チーム
ノーミング（規範期）
自分たちのルールができて役割分担ができてきた状態
トランスフォーミング（変態期）
大会で勝ったときの状態
スクラムできてる状態
フラフープの件
人数が多くなれば難しくなる
会社も人が多くなると難しくなる
Googleのプロジェクト・アリストテレス
どのチームでも生産性が高いときの分析を行うと心理的安全性が共通していた
フォーミング状態で意見を求めるというのではなく
とにかく喋ることが大事
フラフープの時自己紹介を先にするべきだった...
フォーミングの状態で、ストーミングのために「意見を言ってくれ！」というのはただのご乱心
https://www.facebook.com/TimelineNews.tv/videos/2398069700418423/
ハイネケンのCM
役割分担をしてから意見を言い合うとか
プチストーミングって大事だと思う動画だった
仕事ってアクティビティだよねという共通言語を持てるとチームビルディングは加速できる
ストーミング超えたお客が一番良いお客というのはよくあること
11:50 - 12:20 Product strategyによって組織は大きく成長できる
詫間 亮平 氏
楽天株式会社 レジャーサービス開発課 ゴルフプロダクトマネジメントグループ マネージャー
優先順位の変更
問い合わせによる機能改善とか
各々のタスクに集中しているため全体が見えていないとか
ゴルフにおける問題点
90年代ゴルファー多かった ゴルフ場個々で成り立っていた
2000年代ゴルフォー減った ゴルフ場個々では成り立たなくなった
Rakuten GORAでは出会いの場としてゴルファー仲間を集めゴルフの問題点を解決を目指した
当時のPMの口癖
影響範囲が大きい 工数がかかる 技術的に実現できない
エンジニアの成長をPMが妨げていたというのがあった
PMに求められること
妥協せずに理想を描きみんなが熱狂するStrategyを作ること
なんども繰り返し提案する熱意と情熱
やることとやらないことを決めること
（だいたいやろうとしていることの80%は今すぐにできないことが多いため
批判とかもあるが結果が出れば批判は無くなるので覚悟が必要
12:20 - 13:30 多様性を成功に導くプロダクトマネジメント ５選
大阪リモートチームとのプロダクトマネジメント
尾部 絵里子 氏
Sansan株式会社
プロダクトマネージャー兼エンジニアが語るリモートワークが当たり前の組織
高木 咲希 氏
株式会社ソニックガーデン
Remote Work Labo リモートワークのやり方について記載されてるサイト
価値観の多様性 | スウェーデンと日本 Global Teamにおけるプロダクトマネジメント
高橋 りさ 氏
ソニーモバイルコミュニケーションズ株式会社
PM文化のない組織にPM文化をつくる
石田 隼 氏
ChatWork株式会社
ハブとなるPMになるためには
・いろんな軸でチームと話す
・意思決定を常に意識する
プロダクトマネジメントをチームに導入するということのリアル
篠原 佳奈子 氏
株式会社ビズリーチ
OKR設定の問題
ゴールは同じなのに設定するところが部署によって異なってしまう問題
13:30 - 14:00 ユーザーの“心の声”を探るUXリサーチ
奥泉 直子 氏
フリーランス・ユーザーリサーチャー
UXリサーチとは
User Centered Design 人間中心設計
UXリサーチ方法
時間軸と行動から色々な気づきがある
行動観察だけではいけないのか
エスノグラフィ調査
対象者と一緒に行動してみた観察手法
認知特性
トップダウン処理（思考内情報） / ボトムアップ処理（視覚情報）
14:15 - 14:45 PM が UXするために必要なのはおそらく IA
小久保 浩大郎 氏
株式会社CAMPFIRE
名前大事という話
15:00 - 15:30 エンジニアがプロダクトマネージャーとしての役割を全うするために何をするべきか
株式会社サイバーエージェント
木村 衆平 氏
数日前にPjMとPdMの違いというのをなんとなく理解した程度
難しい点
目標設定・意思決定が難しい
論理的にものを作ろうとしてるがエンジニア視点なものだったりと
セールスにはしにくくかったり
意思決定をする
データに基づく意思決定
データを見れるのはエンジニアの利点だったりするので
論理的に答えが出にくい意思決定
データから判断できないときは
どうしても人やPMが決定しないといけない
データからはイノベーションは生まれない説について
データで意思決定を行う素材として活用できるが
データ化されていないものをデータ化されていないものに価値があるのではというのある
変化を捉える
バックグラウンド的なものの本質を見た時にエンジニア（テクノロジー）的な要素ある
15:50 - 16:50 プロダクトマネージャーの採用と育成
Bryan Cheng 氏
Google, Inc.
GoogleのPM
UX,エンジニアリング,ビジネスの間に生きている
日本でのGoogleのPM
コンピュータサイエンスのPMを育てる
APM13というチームがある
associate product manager
APMトリップ
新卒時代2週間海外で研修を行う
中途採用の際にAPMを行うか
勤務経験3年以下ならAPMを受けられる