pmconf 2019 - システム開発で思うところ

Autonomous Teamsであることで速度を保つ。
意思決定はチームがする。信頼して適切な意思決定を「してもらう」。
結果、失敗からも適切に学びにも繋がる。生かす。これが自主的なチームということ
Will that cause chaos?
price speed(処理速度) convenience coverage（扱えるサービス範囲）
freedom to make decisions?
顧客への影響。データを用いて根拠を積み上げることで決定をする。
つまり自分でプランを作るということ。発注されたものを作るではない。
そして結果にも責任をもつ
PMが出来る人は独立して意思決定も出来る人＝企業経営が出来る人。
それに加えて「企業文化への理解」もあること。
政治ゲームをせず伝道師になる人(チームとして仕事が出来る人)。
６～９ヶ月、時間をかけてPMを立ち上げるようにしている。
freedomはPMが顧客に必要なことや、伝道師としてチームを導くという軸があってこそ、ということ。
３か月毎に宣言をして責任を明確にする（これはこれでキツイ世界だな）

感想

製品紹介の時間が長いの辛かったです。
でも、その中でもPMの育成のスパンや、裁量の委譲について具体的な話も合ったのでそれなりに面白かったです。

海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ

川口恭伸
経歴：ユーザーストーリーマッピングの翻訳など
（私が受講したアジャイル研修のサポートもされていました）
海外にいく理由：一次ソースに会う＆肌感を知るため
スイスでは３年前くらいから内製化（エンジニアを自分達で準備するかなぁ）
経営者自身が入れ替わることなく、自らアジャイルを取り組むように。３年前くらいからなってきている肌感
なぜ、経営層はエンジニアを信用しないのか
「俺に分かるように説明してくれ」が原因。
説明を受けている間にビジネスのスピードが追い付かない（はげちゃびん）
教育心理学概論「学校で学ぶ原理原則（抽象度高い）と経験則」
分かりやすい説明が裏目になる（分かったつもりになるけど、帰ったらどういうことだったか分からない）
事業部門（予算、デザイン（企画、開発（作る　は「綺麗なウォーターフォール」。これはアジャイルではない。
パネルのように開発をしていたらそれはアジャイルではない。
アジャイルあるある
やりやすいことからやってしまう。
はじめは価値があることをやるけど、次第に価値がないものをやるように。。
どこかでシフトチェンジが必要
POが解決する（難しい仕事を分割したりして

感想

CSM研修とPO研修を思い出しつつ拝聴。
時間をかけてじっくり学びたいという方は、アギレルゴの研修を受けるのが良いと思います。日本の経営者も変わっていくのかな？
（歴史の長い）中小企業の経営者がそのように変化するとはなかなか想像できないけれど、寿命も含めて企業承継も含めて数年後には変わっていく可能性は十分ありそうな気もしました。

PMにおけるストーリーテリング

岡田悠
チームにとってもPMにとってもストーリーは大事
Freeeは中小企業向け（スモールビジネス向け）
Faxは今だ現役の世界。そういう人達を楽にしたいというモチベーション
５年もたったらクラウドでのサービスは当たり前になった
→ 機能が足りない
→ （当時はマーケッターだったけど）PMとしてプロダクトを自ら良くしたい
→ backlogをつくって、それを消化する
→ 消化することが目的となって。テンションが下がる
→ ビジョンを掲げよう
→ 無風（絵にかいた餅（苦い経験
→ ストーリーテリングをしよう
ファクトをつなげてストーリーに
誰かの視点をもってビジョンを普及させるためにはストーリーが大事
ストーリーは「話したくなる」「記憶に残る」
静的なビジョンを動的なストーリーへ深堀をする
→ メンバーがストーリーを元にビジョンを語るようになった。ボトムアップ。驚くほど変わった。
イソップの３人の煉瓦職人
最後の職人の「俺たちは、歴史に残る偉大な大聖堂を造っているんだ」な人がイイよねと言う話。
物語の法則
主人公が問題を解決する
主人公は、自分に近い方が説得力が増す。当事者ゲー
問題
あるある：ストーリーに厚みができる
そうなんだ：意外な内容で聞き手を引き付ける
解決
解決された世界には何が待っているのか。つまりはオチ大事
主人公は必ず変化していることを明確にして鮮明な印象にする
ストーリーをどうやって伝えるの？
手段を問わず叫び続ける
PMは手段を選んではいけない
バズれば良い
ストーリーを計測し続ける／オチは達成すべき目標
KPIは利益だけじゃなくてストーリーとしての達成度も計測すること（ストーリーを大切に扱う
もっとも大切なのは自分が夢中になれる物語を描くこと（by ピクサー

感想

現場の方からも推薦された岡田さんの講演。
とても面白かったし、スルスルと引き込む不思議な語り口でした。
BackLogの消化をするだけのモチベーションの低い状態は、特にベンチャーだと危険なことという嗅覚は正しいと思います。良くも悪くもゼロから１の世界には勢いがあるけれど、それを継続する仕組みにもっていくためにはどこかでシフトチェンジすることは大事だと思うからです。
Keynoteでもあった、優秀なPMは伝道師だというのであれば、チームのメンバーが自分の言葉で教義（ここだと製品の訴求力や価値）について自らの言葉で話せるように導くことが大切だということになります。だとすると、ストーリーの力は大きいと思いました。

PMにおけるストーリーテリング（Q&A）

岡田悠
（講演を聞いていなかった人のためにざっくり講演のあらすじを
Q:プロダクトと事業のKPIを分けて考えるのは難しいと思う。そのおとしどころは？
A:物語を浸透させること。そういう物語を練り上げること。ある種の共犯者意識を持ち合うような組織にする
Q:マーケティングからPMになったということだけれど、エンジニアリング（ドキュメント）を作るのか？
A:GodドキュメントをPMとして作成をして、それを全員に浸透させる。
デザイン(What)は作ったり作らなかったり
設計（How）はエンジニア
Q:バックログはつくるの？
A:作る。ユーザーストーリーマッピング。
ドキュメントとストーリを紐付けて話をする
Q:事業とプロダクトのKPIは？
A:OKRをベースに
Q:心に響くストーリーと経営層に向けた要約の案配は？（経営層には長い話を聞いてもらえる時間が取ってもらえない
A:ストーリーは長いので、そういうものをして経営層に理解してもらう。
あとは色々な機会をもうけてプレゼン以外の手段も活用する

感想

聴講者への配慮がきめ細かいと感じました。
ひょうひょうとしていているがこの方の視野や見られる側として、見る側への想像力はどうやったら出来るようになるのか想像もできないです。
雑に言うと、飲みに行って色々な話を聞きたい人。

経営層へのストーリーの話を聞いていた時に個人的に思ったのは、freeeのような創業して何十年も経っていない組織の経営層であれば、ビジョン（静的）な情報で理解出来る、というか理解出来ないのなら多分経営からは離れた方が良いとすら思います。経営層にとっては、ビジョンで分かって当然で、ストーリーはあくまでチームの指針や製品のメッセージとして「対外的に伝わるもの」であるかどうかという手段であり、それが有効か判断するものだと思いました。
先の川口さんの講演ではないけれど、はげちゃびんな経営層であればそもそもはその場所にいること自体が間違っているんじゃないだろうか？とすら乱暴に思ったりもします*2 。
先の質問をされた方の悩みはもちろん理解できるし正直共感もします。ただ本当の問題は長いストーリーを聞いてもらえる時間が無いというよりも、ストーリーをお膳立てしてもらわないと企業の課題が呑み込めない勘の悪い給料泥棒が経営層に…（もうやめておく

教育事業におけるプロダクト・マネジメントとは

（この辺りから、少し私自身の集中力が散漫になり始めてます

Classi
BenesseとSoftBankのジョイントベンチャー
約半分の高校に導入されている
EDUCOM（こちらは小中）と協業して両面をカバーする事を目指している
文科省：生きる力の育成
これまで入試で問われていたのは、知識と技能
2020年からは思考力、判断力や学びに向かう力や人間性を伸ばす
先生側に管理と評価への課題
生徒側もどう学ぶのかという課題
（結局、合格するための手段にばかり目が向くよね、という話）
ビジネスとしてはユーザーである生徒と先生だけでなく、支払い者である保護者にも理解を獲る必要がある難易度の高さ
年一回の大規模開発サイクル
ABテストも容易にできない。（仮説検証のサイクルが回しにくい

感想

教育分野ということだけで聴講。
一応、間接部門的な関わり方とはいえ私も教育には関わっていなくも無いので。
教育現場の課題や、製品の導入側として考えるキーワードを知ることが出来たのは良かったのですが、なかなか没入は出来ませんでした。
おそらく、変に私の方に「意見」があることで、聞き方も良くなかったように思います。

データ/AIを活用したプロダクトの作り方と磨き方

萩原静厳
データ AIを活用したプロダクト
東大松尾研究室
スタディサプリにも関わった人
「ディープラーニング実践編」（本）
データホルダーとデータサイエンティストの間にdirectorが入ることで推進をすることが必要
外からあれこれ言われたくないという技術者をいかにプロダクトに歩み寄らせるのかが大切
データAIをどこに使うのか
有名なのはNetfixとかAmazon
ある事業で集めた情報からほかの業態へつなげる
例、OYOのホテル事業（個人）から地域情報を活用して、レンタルオフィス（企業）を展開
土地の特性などは業態とは関係なく使える。つまり応用が効くということ。
KOMATSU：利用率から故障予測。
すべての重機にセンサーをつけて最終的に全体をコントロールすることをデザインする
データを活用して課題を解決するからデータを活用できる課題を設定する
AI活用の４象限（軸は省略というかメモ忘れ）


市場浸透 (着手はしやすいがインパクトは小さい)	新製品開発（ニーズは見いだしやすいが
新市場開拓 (--メモなし--)	多角化 (ハイリスクハイリターン

日本のAIは画像解析とコストカットがメイン
海外は戦略（ビジネスレバレッジ）を効かせるところに使っている

感想

KOMATSUのIT戦略は、10年以上前に読んだ日経SYSTEMS（かそのあたりの雑誌）でも見ました。重機メーカーの社長がここまで戦略的にITのことを理解し推進しているのかぁ、とその当時も印象深かったことを覚えています。私自身も「俺、良く分かんないけど AIで（ITで、でも良いしインターネットで、でも良い）ビジネス立ち上げて～」というような経営者では意味が無いという話をする際に、KOMATSUの施策を話題に良く出します。一般的に重機とITは距離が遠いという印象を持たれていることもあり、興味深く話を聞いてもらえるネタです。

日本のITは先の岡田さんのQAのところでもあったように、経営層へ現場からお伺いを立てる（？）ケースが多いため、数値に測りやすいコストカットや効率化というアプローチが多いのかもしれないと思いました。現場にある一定の裁量を与えて口を出さないか、トップダウンで推進しないと（出来る人がいないと）、ビジネスレバレッジを効かせる所に使うのは難しいのではないかぁと思ったり。。

発明、ドッグフーディング、プロダクトマネジメント

増井俊之
慶応SFCの教授
POBoxを作った人
Apple フリック入力
Gyazo
増井ラボノート
Scrapbox（！）
ニーズがあるからつくるのではなく自分が使いたいから作る
ユーザーインターフェース研究は論文を書いたら終わりなので実際に作るところまで至らないことが多い（せっかく良い問題を解決するような論文を書いていても実際には作るところまで至っていない）。
発明家兼PMは少ない
発想フェーズと運用フェーズは別物

感想

Scrapboxを作られたのは、この方だったのか！という驚きが一番。
とにかく熱っぽく早口に話す様子が好感しか持てなかった。
自前のIMEで文字入力をしているので、バグがあったら全てが止まるので必死で修正するとかもはやそれはドッグフーディングというよりもセルフバイティングじゃないか？とすら思いました。

Keynote Session(Harry D. Moseley)

Zoom VideoのCIO
（声が役者のように良い）
年々倍々で動画時間が増えている
PMに必要なもの、、情熱
ボックスの中で価値を最大化する
ユーザーのneedを、wantではなく（ここはちゃんと聞けた自信ない）
（低音ボイスの美声）

感想

Zoomって自動翻訳もできるみたいです。凄いですね。精度の話まではしませんでしたが、本プレゼンを Zoomを介して自動翻訳しながらの講演だったらそのインパクトは凄いものだと思った次第です。
Zoomが成功した理由とのことでしたが、成功しているZoomの紹介では？と思ったり思わなかったり。

確実に言えることは、声が良すぎて情報が入ってこない（私の集中力が枯渇していただけという話もある）

ネットワーキング

本カンファレンスを教えてくださった方からの紹介で Agilewareの方*3と少しお話させていただきました。名刺を見て「ん？？どこかで見た製品群（Lychee、GIJI）？？」と思い、記憶を手繰り寄せて「あっ、デブサミ？」と思い出すに至りました。確認させていただいたらその通りでした。滅多にありませんが、こういうこともあるのがカンファレンスや勉強会の面白さかもしれません。
ちなみにGIJIについては、スマートスピーカーを使って多言語対応（同じミーティングで日本語と英語の話者がいても議事録が作成できる）もあるとのこと。面白いですね。

またPO研修で同じグループだった方にも偶然お会いしました。正直、かなりビックリしました。また、その方が PO研修だけでなく、色々なカンファレンスに参加されているというのも伺って、行動的で勉強熱心なところに刺激を受けました。その方には終わったばかりではあるけれど、EOFというカンファレンスが面白かったということで次回機会が合えば行ってみたいと思いました。

2Day

今からはじめるデザインスプリント

佐藤伸哉
翻訳本もあります
お勧め書籍：SPRINT最速仕事術
読むとできそうだけど、卓越した人向け。実際は難しい。
調査に２～２ヶ月かける。例えばここをデザインシンキングは５日でやるとか。
プロダクトの予測でも使う
正確はなく、色々な組織で様々な形で導入
デザインスプリントは平野レミ
決められた時間内で結果を出す。その場で全部作る。
Map
全体と詳細の理解
まずはチームメンバーで知っていることを全部共有する（なので厳密な調査をしていうわけでもない）
その後、有識者からしっかりと情報を聞く。
「全員が」メモをとる。
5～15くらいのステップに
ターゲットの選定（あとから変えず、ここで一旦フォーカスを絞る）
Sketch
個人で考える。
全員でディスカッションはしない。理由は声が大きい人が引っ張って終わるから
慣れるまでは文字でも良い
なれたら絵をつかって抽象度を高くしておくと良い。
まずはアイディアを出すという行為をプロセスに入れる
Decide
個人の主観でアイデアを即決する
プレゼンや説明するとユーザー目線が無くなり、上下関係や政治に流されることが多いため。
サイレント投票（禅投票）
決定権が強い人には多めにチケットを渡して投票行為のバランスをとる
ProtoType
実際に使える形で検証したいアイデアを形にする
でも、実際の現場ではprototypingをするのは稀
Test
大きな問題のパターンをみつけるにはユーザーインタビュー５人で８５％の課題は見つかる
やるときは1on1で
短く早く、作った人がやるのが良い
他メンバーは各自が別室でメモをとる（メモは全員でとる
気づきは違うし、課題が明確になるのでアクションプランがたてやすい
重要なのは次のアクションが見えることが大事
プロトタイプを修正して再びテストを行うことも
ただし、デザインスプリントは同じ課題にたいして、リテレーション前提にしない。
真剣さを保つ
Google流 desighsprintkit.withgoogle.com
こちらは６つ
DEFINE が追加
UNDERSTANDの次に、ちゃんと問題を定義する
ライトニングトーク（各自５分、２５分
発表者以外はメモをとる
状況理解
エクストリームユーザを考える
リフレーム：状況を違う環境に置き換える
ペインポイント：障害弊害を考える
問題定義
スケッチ（アイディアの芽を箇条書きで
決定
アイデア売り込みするケースもないケースも
プロトタイプ
検証（ほぼほぼやる時間がないのが実情
Voice Action Sprint Frameworkもある
あるある
ポストイットが足りない問題
アイディアは山ほど絞り出してようやく出てくる
ポストイットは写真でとったら捨ててしまった方が良い
覚えていないアイディアはそもそも価値はないし、読み返すこともない
スプリントマスターがいればアイディアがでる？→NO
アジェンダ通りには進まない
フレームワーク軽視 or 依存
日米の違い
VPや事業部長が出てこない。→ゆえに（日本は）決まらない。
デザインスプリントは「その場で」決めることが重要。
やってみたけど、うまくいかないあるある。
チームでやると言いづらい。
意見が攻撃ととられる。これは組織の体質

感想

デザインスプリントというもの自体を知りませんでした。
思った以上に短時間でアイディアの方向付けを確定していく印象でした。
全員がメモを取るというのをルール化しておくことはとても良いと思いました。誰一人お客さん状態にならないのは大切。
良かれと思って言われている意見もなんだかんだいって言われた後に凹むことは沢山ある。逆に相手にもそういう思いを与えることも。分かっているけどなかなか難しい。
忘れる力が欲しい*4。
同じくらい聞く力も欲しい*5。

愛と解釈のコンダクター

広野萌
指揮者は解釈を与えて(提示して)
演奏者はその解釈をそれぞれの個人が解釈を表現する
解釈が一体感を生む
PMで大事なのは「解釈(自分としての)」と「提示（メンバーへの）」
今後、サービスはブランドになるだろう。それがデザインだと思う
チームをプロダクトの犠牲にするのはNG
マネジメントはしないけどコントロールをする
時に感情のコントロールも必要
愛が大きすぎて熱狂してはいけない。
指揮棒を足にぶつけて死んだ指揮者の話
スタートアップあるある
がむしゃらに働けば日の目を見るのではなく、考えて行動も
恋は盲目、愛は瞠目（だから愛が大事
プロダクトと人だったら、私は一緒に働く人を重視する

感想

「恋は盲目、愛は瞠目」は凄く良い表現。
ついつい、気持ちが入りすぎて（恋）になって攻撃的になることも。思い入れや真剣さは大切ではあるけれど、やはりどこかで一歩引いた感覚も大切。少なくとも人と一緒に何かを作るのであれば、そんな風に思いました。
逆にどこかで誰にも気にしないで盲目になれるような人でもありたいなぁとも。

打席に立ち続けられるプロダクトチームを作ろう

DeNA（黒澤隆由
タクシー配車（MOV）
チームの在り方はフェーズで異なる
常に成功をさせるのは難しい。打率を上げることが大事
営業やマーケッタの意見は、それぞれに於いては正しいが、それらをむやみに取り入れられない。
指標が打率
柔軟であること＝専門性＋多様性
何でも出来る人があつまる？
８０点の人を集めて８０点のものを作るのではなく、スペシャリストを集めることも。
その逆に専門家だけだと多様性が足りない
PDMとPJMを役割を分けた体制を作る
PDM：何を、なぜ作るのか。プロジェクトへの妥協はNG
PJM；いつまでに、どのようにつくるのか。リリーススケジュールへの妥協はNG
PDMは足りない。。
PDMに求められるものを定義
→事業目標を達成する人
プロジェクトの価値を明確にする
価値をともなったプロダクトを作る
コミュニケーション力大事
PDMがいないものづくりは存在しない
PDMを専門職として強化する
評価と育成
育成？
デザイナとエンジニアと会話ができるとか
UXがわかっているとかわかっている人をどう育成するのか？
→スペシャリストと協同することで学び成長し合える場を提供する
壁打ちをする場をもうける
個々の強みを伸ばすことでパフォーマンスできる機会を提供する
（全部が出来る人はいない）
失敗できる環境を提供する
（プロトタイプを通じて、メンバーからのフィードバック、ブラッシュアップ）
PDMリーダーズミーティング
執行役員を交えて芽のあるメンバーをバイネームで共有する場を設けている。
Hiring（外部からの採用）も大事

感想

開発者や管理者という体制ではなく、プロダクト責任者を作るためには役員も含めて名指しで共有する必要があるというのは納得。
川口さんの話でもあったけれど、執行役員がプロダクトのビジョンなり方向性なりをきちんと共有する（しようとする）主体になる変化は実際に起きつつあるという感じ？（といっても、いわゆる社歴の長い中小企業とは違うけれども。。）

UXの視点から見るプロダクトマネジメントの倫理と社会的責任

SNSやブログはNG

感想

NGということなので、感想も含めて止めておいた方が良いのかな？

PMはどのようにバリューを出していくのか

プレイド
PMが入るところは新規事業やビジネス要件が強めのところ
ただしプレイドには役割としてPMというものはない
あえていえばフォーカスを充てる主体の具体的な一人の人のこと
すぐにissueにする
週に一回棚卸し。閉じるのも大事。
重要だったらまた上がる
作るべきものを見つけるためのアプローチ
少し先を考える
自社のアセットや強みがいきるもの（強豪がいないのが理想
ペインは、やりたいことと現状の差分。でそれを課題として解決を図る
マーケット規模や動き
第三者レポートと外の繋がりや一次情報に触れる
強豪プロダクトの動き
ユースケースベースで気にするけど、あんまり気にしない
クライアントの課題
CSとも話そう
自社の強みをきちんと振り替えると気がついていないことが沢山ある
事業に関わらず「会社としての強み」がある
価値あるものを見つけて作る
アイディアは組み合わせ
パターンを作れることが大事
深い知見が必要になったら、そこで持っている人を巻き込んでいけばいい
PMは営業やエンジニアのHUBであり、そこを担う責任があるのは大事
無理矢理長期的なことを営業やカスタマーとエンジニア全員で話し合って、共有するのは価値があった
強いメンバー（リーダーシップ＆高いスキル
役割が決まっていない中での人事評価だが、少人数なので今のところ評価制度はない。試行錯誤中。
あえていえば、給与にフォーカスが向かわないものがベストかな？
つまり給与は自分がきめて企業はそれにちょいプラスくらい
大事なのは優秀な人に囲まれ続けるような環境が優先すべきかも
フォーカスの見直し頻度は３ヶ月くらい
長ければ６ヶ月くらいのこともある（短いことも
可視化もしており、２Wくらいに共有する場も設けている
合理的に考えるならヒエラルキーが良いし分かりやすい。（評価もしやすい。
でもそのような統制はよくなくて、思考と意思決定をする文化を持った組織でありたいとして大事にしたいと思っている。
なので人が増えたときはそういうことを共有するためのキャンプをしたりしている
コトにフォーカスするのが大事
ヒットの裏付けを求められることへの対処はない。
例えそれらしいロジックがあったとしてもそんな答えに意味はない
むしろもっと定性的な判断と行動から振り返りをした方が価値があると思っている

感想

企業規模と創立からの期間を鑑みても、これからどうやってその文化を育て続けられるか？というのが次のテーマになりそう。
ベンチャーあるあるにならないための土壌もありそう（定性的な判断と行動から振り返りをした方が価値があると思っている）。
人事評価については、、うーん確かに難しいところ。
「優秀な人」が求めているのは、裁量か収入か（もちろん両方なんだろうけど、あえて言うとしたらという意味で）。
いずれにしても、あるタイミングで離脱することを前提にして常に振り返りなどでプロダクトに知見が集まるように仕組みはある程度あるような印象を持ちました。

CTOやVPoEとプロダクトマネージャーとの理想の関係

パネルディスカッション
松岡剛志＠レクター
組織構造は、１チームで始まり、職能別チームをつくり、事業部制を経る
結果、リードタイムが長くなる
その中では意思決定を自らするチーム（プロダクトチーム）をつくるのが今の流れかも
組織構造による対立はある
職能別だと、自部門の成功が中心となってユーザー目線がない対立
事業部制は職能対立は小さくなるけど事業部間の対立は起きる
組織における理想の関係のベースにはアジリティが重要
意思決定がブレずに早いのがベスト（全部一人がやるのが最短）
でもそうはいかないので分割するとして、CPOとCTO
現実的には自分のロールを達成しつつ横の領域へ前向きに侵食するような取り組みをするのが良いのでは？
まずはJD（job decisions）をつくるところから
役割を決めたとしても、それを振り替えって見直しはするべき（計画をたてる）
ロールを決めたら、ロールを守ることに注力する人もいるでしょう。それだけに終わらないようにするには文化形成かと。
「それが良い！」となった時に推進するはCEO（もしくは偉い人）
なんだけど、それをするためにボトムアップで情報を提供することも大切
議論がKPIとかユーザーに向かっていれば良いだろう。
それが「自分が（我々は）」ということでなければ
PDMからのアプローチとして粘り強さがほしい。「できない」で終わってほしくない
CTOを上回る情熱をぶつけるPDMの意見は通る（通さざるをえないでしょう

感想

「このセッションがパネルディスカッションだったと知っていた人？」と言われたが、はい、知りませんでした（笑）
このセッションはEOFに参加された方が松岡さんの話は聞くと面白いですよ、ということで聴講しました。

綺麗事だけをいうのではないのが印象的でした。
（「まぁ、実際きついよね」とかそういう感じの語り口）
CTOを上回る情熱の話はキーエンスの話を思い出しました。
自己主張だけでは駄目ですが、なんやかんや言ってもそのプロダクトへの熱量に対してCTOは投資してしまうもの。

『突破するプロダクトマネジメント～実践編』

必要な素養みたいなものを話します
クラシルの会社のCxO
一秒でも早く正確に市場評価できる体制構築
起業時：Product Market Fit
グロース期：収穫するのが大事
ユーザーは自分のほしいものがわからない
＝ユーザーインタビューのまま作っても使われないは「あるある」
壁：突破すべきコト
ロードマップで可視化
基盤系やDAU積み上げが後回しにならないように
＝重要度が高いことを取りこぼさないようになる
毎月アップデート
価値を作るという意思をチームで持たせる
100点の基準を合わせる
締め切り＝品質基準がすりあった成果物の納品
週１から２の頻度でプロダクトレビュー。NGな理由を言語化ことが大事
品質を求めるとリソースほしい問題が生まれる。
リソースの壁を突破する
その際に環境の見直しや制度の導入を行う
人が増えてくると権限委譲
１００人の壁の超え方
社長と週１の１on１をしたものを全員に言語化して共有
ストックではなく、フローでカルチャーを作る（Slack
UX課題のほとんどは、アイディア問題ではなく問いの適切さと壁を乗り越えた実現への執着
それがPDMの役割だと思う

感想

ストックではなくフローでカルチャーをつくるというのは、言われてみると確かに大事なことのように思います。
例えばまとめてブログやWikiに書くというのも大事ですが、Twitterで思ったこと気が付いた事をその時にささっと書くというのを比べたときに継続させやすさだとTwitterの方かもしれないという感じで。
実際、ブログの更新は止まっていても、Twitterでの発言は止まっていないケースは多いという感覚はあります。

UX課題はアイディアではなく問いの適切さと実現への執着というのは、クリエイティビティの低い私には心強いアドバイスに聞こえました*6。

面白いプロダクトの作り方と魅せ方（B-Side）

軸がユーザーやメンバーにとって面白い、ワクワクするということをおけば大体うまくいく
魅せ方大事
リアルタイムデータの可視化
嫁の行動の可視化でキャッチーに（朝のゴミ捨て行動を可視化
デモは自分で作る

感想

講演中に電話で呼び出される奥様。
嫌な顔せず対応するの素敵です。データ活用の可視化というと、とかく高尚で難しく考えてしまいがちですが、力を抜けた面白さを目にすることで思考が柔軟になるような気がしました。
とはいえ「面白いことをまじめに考える」のは難しいんだよなぁ。。

プロダクトマネージャが陥るカスタマーサポートの盲点

豊川弘樹
それって自信がありますか？を仮説検証する
全部やらなくていい。
重要度と優先度
大事なのは繰り返し

感想

立ち見だったのでメモ少な目。
CSにメンテナンスができる開発者を数名置くだけでも、サービス品質へのアプローチはかなり良くなるという話。

「何をつくらないか」を考えるリーンプロダクトマネジメント

（立ち見だった＆疲労のピークでメモなし

感想

「何を作らないか」と「何を作るのか」を小さく早く確認する、というアジャイル開発の話。
（力尽きる。。）

さいごに

自分に向けた、もしくは私を知っている方に向けたメモと思っていただけたら幸い。

はじめにに書くべきだったかもしれませんが、参加の切欠はCSM研修で同じグループだった方から教えていただいたからです。
私とは全く違うキャリアでソフトウェア開発に関わっている方で、具体的にはその方は企画やPOといったいわゆるプログラマーとは違う経歴で、SIer経歴の私は出会ったことのないタイプ。私としては現地で再会して研修の場とは違う形でお話できたら学べることが必ずあるしきっと面白そうという思いもあって、語弊を恐れずに言うならば pmconfそのものがそこそこでも、そこに価値はありと判断したというところもありました。結果、両方とも学びがあり面白かったです。

そもそも、SES的な契約形態のフリーランスである私*7にとって、pmconfに参加する意義（モチベーション）は、どこにあるのか（あったのか）というところですが「私が関わる人にとっては必要となるであろう」と思ったからです。私自身が例えばPMとかPOとかCSMとかの主体になるか？というと実際のところ、多分無いでしょうし、今のところそうなることを熱烈に求めてもいないというのが本音です。でも、これからの開発においてその構成員として「普通に満たしてほしい期待値」には応えたいというくらいには負けず嫌いな私としては、相手が求める「普通」について無知であるのは嫌だなぁと。かつて、私は立場としてPLであった期間があり（それなりに長く）、当然チームには様々なメンバーがいました。かつてのPLであった自分からみて、欠かせない人になれるほどの力はなくとも、せめて、自律的に期待値を満たす人ではありたいなぁというのが基準です。

モチベーションというには、あまりにもレベルが低いかもしれませんが、そんな感じでも実際に参加することでスピーカーの熱に当てられるのも悪くはないものです。
あえて今回のカンファレンスのきつかった事を挙げるとしたら、技術がメインのカンファレンスでは基本的にはない「隣の人と３分間話してみましょう！」は、コミュ障な私にとってはかなりシンドイというのは隠さざる本音です。*8

おまけ

ウォーリーを探せ *9

プロダクトマネージャーカンファレンス2019、いよいよ始まりました！#pmconfjp pic.twitter.com/gG3VoPIy9X
— 関満徳@fullvirtue 11/15出版記念イベント開催 (@fullvirtue) November 12, 2019

*1:これ自分でもどういう意図のメモか不明

*2:とはいえ、現実はというのは重々分かってはいますが…

*3:講演者ではないので名前は控えます

*4:いや、成長しろよってね。。

*5:いや、だから聞けよってね

*6:執着心（負けず嫌い）は、人並みにはあるつもり

*7:個人開発をする発想力もなく、SIer企業に所属していないだけでやっていることは全く同じ。昭和なブラック耐性が備わっただけでそこそこの結果しか出せないモブ（笑）

*8:私は色々なスイッチを上げ下げしないと初見の人に限らず人と話すのが難しいのです。それが取っ払われるのは強い好奇心を感じた時と仕事という共通の課題が双方の間にある時とあとは謎の気まぐれが発動した時。我ながら面倒くさい。

*9:晒せではないので悪しからず

はじめに

ブログなど

1Day

Keynote:ORDINARY PEOPLE, EXTRAORDINARY RESULTS

感想

Keynote:Special Session(Kaarel Kuddu)

感想