bon now

ずらずらと社内向けに書いたら自分の思考の整理にもなったのと、あまりに膨大な情報がつまっているため、自分への備忘録がてら 一部リファクタリングして公開することにした。 1つにまとめたので今までのレポートでは最長になるため正直読んでくれないと思うので、要点だけ先にまとめる。 また、この記事内では僕が普段「マネジャー」とか「マネージャ」と書いているカタカナ英語を「マネージャー」で統一する。

まとめ

• プロダクトマネージャーは信頼が大事なので作り上げよう
• プロダクトの幹となる「なぜ」やコアバリューを定義しよう
• 数字と訂正表現を使い分けよう
• 誰よりも熱いプロダクトへの情熱を持とう
• プロダクトマネージャーはそのプロダクトのCEOとしての矜持を持とう
• プロダクトマネージャーの役割は組織によっても変わるのでみんなで考えよう

全体を通してプロダクトマネージャーとプロダクトおよび組織との関わりみたいな話はとても多かったが、 開発プロセスや手法(アジャイルやその中のスクラムとか)との話は僕が聞いたセッションではあまり語られなかった。 そのため、プロダクトマネージャーがうまくアジャイルの中で立ち回るとき他社はどうやってるのかという部分が確認できてない。 (懇親会やブースで聞けばいいじゃんと思うだろうが、空気に飲まれてコミュ障っぷりを発揮してしまったので難しかった)

あと雰囲気で感じたのはプロダクトマネージャーは外なる顧客のマネジメントをやり、 エンジニアリングマネージャーは内なる顧客のマネジメントをやるってのが役割分けの１つの解なのかなということだった。 ちなみにここで言う顧客はエンドユーザーかもしれないし別部署の担当者かもしれない。 いわゆるプロジェクト/プロダクトのステークホルダーになる人々を指している。

ORDINARY PEOPLE, EXTRAORDINARY RESULTS

資料： https://www.slideshare.net/Productized/empowered-achieving-extraordinary-results-with-ordinary-people-by-marty-cagan

INSPIREDの著者Marty Cagan氏の基調講演。 プロダクトチームは顧客のために製品を作っていくことが最終的な目標であり、時には機能を諦めるという選択肢も存在しうるという話に、 組織の内側だけの議論ばかりではだめだなと改めて思った。 また顧客、開発、他部署などとの信頼関係を築くことは一番大事という当たり前のことも心に響いたセッションだった。

AmazonもAppleもGoogleはアメリカの世界有数のIT企業として有名だが、それぞれ企業文化は全く異なる。 しかし、創始者はみなビル・キャンベルという偉人のもとで学んでる点は共通する。（彼は自を絶対に書かないことで有名。HARD THINGSには彼がどういう人物かだいぶ詳しく出てくるので知りた人は1兆ドルコーチと合わせて読むことをおすすめする） ビル・キャンベルは優れたリーダーシップを有し、シリコンバレーの信頼をすべて集めた人間である。 彼の言葉から学ぶことは多くある。(ここでは割愛)

ところで「信頼」で最近一番それを体現できていたものといえば、ラグビー日本代表ではないだろうかと僕は思う。 ラグビーはチームワーク（特に役割分担）が重要な競技である。例えばウィングと呼ばれる両サイド端の選手は、パワーよりもスピードや瞬発力が必要とされる。 相手のブロッカーを交わさなければならないが、それには味方がどれだけ相手メンバーをウィングから引き離すかが重要になる。 こういう細かい連携プレイが得点を生む競技である。刻一刻と変わる状況に応じて臨機応変に指示や戦略をリーダーあるいは個々のメンバーが判断する場面も多くある。 そもそもアジャイル開発に利用されるスクラムの語源もラグビーであるように、ラグビーはアジャイルの文化に近い戦術を要求されるスポーツだ。
日本代表は決してラグビー強国として知られた存在ではないが、練習や試合を通してやメンバーの特性を活かしてそれぞれの役割やチームとしての方針を全体統一していったことで、 強いチームへと変貌していった。また、メンバーももともと日本国籍外のメンバーが集まることで多様性が生まれ、 個人を尊重する精神=信頼関係の明確な築き方が育っていったのではないかと私は思ってる。 （とはいえ海外ではニュージーランド代表のALL BLACKSを例に挙げたのほうが説得力があるらしく、発表スライドもそれだった）

そんなわけでこの講演では、未来を見据えたプロダクト戦略、チームの信頼関係の構築、役割と権限の譲渡、正しい自由の使い方あたりが重要だと思ったのであった。

Product Manager in TransferWise

資料： なし

TransferWiseという企業のプロダクトマネージャーのトップのKaarel氏のセッション。

TransferWiseは海外送金をメイン事業とした企業。アメリカのPayPalの競合企業かな？ たった2人で起業し、8年で社員数は1200人になった超ユニコーン企業。東京拠点もあるらしく、もしかしたら採用もしてるかもしれない。

彼らは顧客視点でプロダクトの発展を考えることで最適なスピードを維持することに注力してきたという。 具体的に言うとサービスのローカライズを考えるうえで、マイクロサービス化ならぬマイクロチーム化を適用していったそうだ。 セッションではアルゼンチンチームの例が取り上げられた。顧客に近いところのチームにほとんどの裁量（経営から会計までほぼすべて！）を移譲することで、 その地域特有のサービスの成長を適切なタイミング・スピードで行うことができるという。 実際アルゼンチン進出を決めたのはラテンアメリカ拠点で構成されたチームであり、そこに本部の意思は全く介在していなかったという。 ただ、なんでもかんでも自由を与えるというわけではなく、「意思決定の自由には、責任が伴う」ということを反芻してもらう必要があるとのこと。大事。

また、プロダクトマネージャーは会社のその後を管理するという側面も持っており、要するにそれは経営に等しいので採用は慎重におこなう必要があるということだった。 製品としてはPrice、Speed、Convenience、Coverageの4本柱のバランスを定量的/定性的に判断していくことが重要とのことだった。 これは企業によっても変わると思うので、どういう比較項目を用意するかは経営とプロダクトの方向性を考えて詰めて行くことは大事な気がする。

LINEにおけるお金とユーザーのジレンマ

資料： https://speakerdeck.com/line_developers/money-and-user-dilemma-for-line

LINEにおけるプロダクトマネージャーについての話。

プロダクトマネージャーは多分会社の数だけ役割とやることと求められることがバラバラなんじゃないかという前提でスタート。 あるときはビジョナリスト、あるときはテクノロジスト、またあるときはビジネスアナリストなどなど開発の局面で求められる人物像が異なるみたいなことも多々あるのではないだろうかという話。 たしかにそう。というか役割の都合上こぼれたボールを拾うかかりなのはしょうがない気がする。そのくらいやらないとプロダクトに100%の責任もってると言えないだろうし。

ただ、ここはもっとシンプルに自分たちのプロダクトを成功させる、そのために何を作るか決めてリリースするということにフォーカスして頑張ればとりあえずプロダクトマネージャーだよね、 ということだった。そしてこの発表でも信頼大事ということが述べられた。 それは人を巻き込むために必要だったり、仕組みを作ったときにメンバーが不安に思わない/強制されたと思われないような環境作りに必要だったりする。 さらに言えば外の顧客と内なる顧客(人、部署、組織)に対して未来を想像して対処を考えることのできる妄想力も重要とのことである。

LINEの場合ユーザーファースト、画面ファーストみたいなところがあって数字よりもUIの直感、ユーザーの操作性などをプロダクト開発には重要視されるという。 それでいて経営的な数値目標(売り上げや利益)も追わなければならないので、このバランスを「決める」ことがPMの役目ということである。 ここのバランスのとり方は正しいコミュニケーション手法が必要になるのではないだろうか。 (正しいとは、相手と自分とでどちらかが有益になるとわかっていたとしても、害を被る側に対してWinとなる条件を提示できるような柔軟な発想力と交渉力を指す)

このような観点から、プロダクトマネージャーの仕事はジレンマの解消=クリエイティブな仕事といえるということだった。 Product Manager in TransferWiseのセッションでも挙げられていたとおり固定観念に縛られているとプロダクトのローカル展開時にうまく行かないこともあるので、 そこにあるジレンマも現地で確認できるような多様性の容認を最初からできるくらい心を広く視座を高めることが大事かもしれない。

つまり、プロダクトマネージャーすごすぎ。これに尽きる

保育現場に寄り添うプロダクト開発

資料： https://prezi.com/view/68c0fQgrH3lAMR9WoWs0/

途中から聴講。登壇者の所属するユニファという企業は、全国の保育園に対して保育士の手間を軽減するようなサービスを展開中。

例えば赤ちゃんのお昼寝タイムにおけるねがえり。過去なんどか赤ちゃんが死亡してしまうというニュースが取り上げられたこともあるくらい人命に関わる仕事でありながら、 5分起きに1人の保育士が10名程度の赤ちゃんの寝姿を確認し、記帳しているという大変アナログかつ面倒な作業を毎日行っているのが現状。 これをユニファではIoTデバイス(服につけるパッチのようなもの)を使うことで、赤ちゃんが今どのような体勢で寝ているのか、 呼吸は浅くなっていないかなどを瞬時に通知できるようにし、大幅な作業効率化に成功した。(人命に関わるので見回り自体は続けなければならないだろうが、 少なくとも手で何かをするということはなくなる)

その他保育士マインドを取り入れてサービスの改善に取り組んでいるということで、プロダクトはまさしくユーザーと二人三脚での発展という体をなしている。 これはそもそもエンドユーザーの負荷がサービスを導入することで増えるようであれば意味がないという前提のもと行われているようである。

LINEのPM、ぶっちゃけどうなの座談会

座談会。

大企業あるあるネタとしてはエンジニアに裁量が与えられているとはいえ、意識決定のプロセスがトップダウンだけという見え方をすると、 エンジニアとしては不満しか溜まらないのでそれは良くないという話。 プロダクトマネージャーというか、マネージャーとしてそのへんの意思決定のボトムアップ具合をどう仕組みで作っていくかは1つの課題かもしれない。

また、最終的にはプロダクトのポリシーが製品のジレンマ解決のための意思決定に寄与することはあるというも言われていた。これはそうだと私も思う。

採用の話も一部でてきて、例えば面接に来る人の成果や内容から自助努力でやったのか、協力を得てやったのか、人に成功を与えたのかを確認するとか、 自分で決めて行動することができるかを問うといいかもという回答だった。

“失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -

資料： https://note.com/diskdusk/n/na74688ed344c

登壇者はもともとFF11の効果音を作っていた人。

この発表は多くを語るより、以下のnote記事を見てもらったほうが早い。実は僕も最初にこの資料を読んだ上でセッションを聴講した。 https://note.com/diskdusk/n/nfbefe8d9e762

僕がエン・ジャパン（登壇者の所属企業）のエンジニアの方と企業ブースで会話させてもらったとき、 このテクニカルスキルのペンタゴナルチャートは上手くいってるのかという直球ストレートな問に、 「上手くいってるとことそうでないところがある。まだ走り始めた段階」というこれもまた直球の回答を得ることができた。
たとえどんなに便利そうな仕組み、見える化されたデータであったとしても、 それをプロダクト開発ひいてはチームマネジメントに活かしていくかどうかはリーダーおよびメンバーの相互努力と協力が重要であり、 そこを議論の1つとして自分たちのチームをどうやっていきたいかみんなが能動的に関わっていく環境を作っていくことが大事だなと思った次第である。

登壇者は企業文化を上述したようなものに変えるために、SQL社内勉強会を開始したりTableau使ってもくもく会やったりした結果、 エンジニアのスキルアップに対するマインドが向上し、退職者も減ってきたとのこと。 また、エン・ジャパンのサービスにもテコ入れしていくつかの新サービスの展開も久しぶりに行うことができ、企業としても成長できたということだった。

ここまで成功事例を並べられるとすごいなと思う反面、苦労した点があればなおよかったかなと思った。

プロダクトマネージャーはminiCEOという話がここでも出てきた（当日の初手は多分基調講演だったと思う)

Keynote Session(Zoom)

ZoomはCEOが遠距離恋愛(片道10時間)をしていたとき「遠距離をもっと身近にするためのソリューションに関わりたい」という想いを懐きつつ1997年にwebexへ入社し、 当社がCiscoに買収されてしまったあと「もっかい自分で作る」という意思の元2011年に創業した企業&サービス。 つまりCEOは一貫して遠距離という物理的な問題に向き合ってきた第一人者ということになる。

Zoomでは「従業員の体験がすべての企業での働きに関わってくる」ことをプロダクト開発の根源としている。 年間200超の機能追加をやったこともあり、2018年-2019年では累計のビデオ通話時間を2倍にすることに成功したという。

そんなスピード感あふれるプロダクト開発を支えた3つの柱はそれぞれ「パフォーマンス」「信頼性」「エンゲージメント」。 このうちのエンゲージメントの例として、自席CTIへの着信を会議室にあるビデオシステムに投影するまでのロードマップだった。 導線をシームレスにすること（Zoom以外の余計な連携やアプリの利用などが発生しない）ことでユーザー体験の価値を向上させ、 さらに他の製品でも操作を統一させ体験を同じくしたことも注力したとのこと。これによりユーザーのエンゲージメントは他の会議システムよりも高くなり、 Zoomへ移行するユーザーが圧倒的に多かったというのは数字でも表れている。

またプロダクトマネージャーに必要な能力として業務知識、カルチャー適応性、チームとの協調性、情熱が挙げられた。特に情熱は大事なよう。 誰よりもプロダクトに情熱を注げる人、それがプロダクトマネージャー。
そして楽しみながら仕事をすること！が大事という話で終了。努力にまさるものは、やっぱり情熱と想いの強さだと僕も思ってる。

---

ここからDay2

PMが学ぶべき、最低限のデータ活用スキルとは

公式ブログ： https://medium.com/@hakali/thanks-pm-conf2019-3059968aaaba

セッションの前提として定性的な会話では、会話の認識が揃わないのでデータを活用して会話しようという話が述べられた。 登壇者はリクルート → ビズリーチ → きりんカルテ → Hakali創業という流れのCEO。

もともとデータサイエンス寄りのキャリアを築いてきた登壇者からは、体重計を見える化して定期的に測定することでダイエットに効果的であることと同じように、 見える化はビジネスにも効果的な側面があるが、一方でKPIに反映するデータが正しいものでないと正しい成長ができないとうまっとうな話があった。 例えばきりんカルテでは、CSが毎回見込み顧客にデモをして回っていたらしく、 その数値をKPIに導入する&営業管理（ちきゅうというツール）をして見える化したところ、受注率が3倍になったそう。

ビズリーチではTVCM1期に出演していたというこぼれ話もあった。 (ビズリーチ！というだけのカットをTAKE20くらいやったらしい。リンク先動画右端の人)

また、指標を考える上で大事なのは踊る大捜査線のアオシマ刑事さながら「現場」とのすり合わせも大事ということだった。 その方法として取り上げられていたのがOODA。 OODAはアメリカ空軍で生まれた現場で刻一刻と変わる状況を捉え最善の行動を全軍で取るための手法であったが、 現代のビジネスの速度に鑑みてどっかの誰かが「これ使えるわ」ということで持ち込んだのではないかと私は考えている。 具体的な取り組み方はリンク先を参考にするなり実践してみるなりしてほしい。

プロダクトマネージャしかり、マネージャはこの現場感覚と生のデータをどっちも見ながら課題に取り組むことが必要で、 その起点はユーザー視点であるとのことだった。そういう意味では統計や集計されたデータよりも RDBに格納されたデータやExcelにまとまったデータを眺めるほうが判断しやすい場面があるという。 これは確かにそうだと僕も思っていて、最近だとGDP成長率だけで物事は語れないというものがTwitterでも流れていた。 このことからたとえ定量的であったとしても、数字を扱う側もしくは受け取る側の認識のズレを埋めない限り議論は多分前に進まないとも言える。 そういう意味で現場感覚と生データのすり合わせは確実に必要なフローであると感じる。

これらを踏まえ課題を解決するためには以下のような感じで取り組むといいのではないだろうか。

　・議論できる情報をまとめる 　・それらをチームで合意する 　・ステークホルダーの欲しがってる情報の粒度に揃える

他にもリクルートでは有名な「リボン図」を改良して「パオーン図」を作りましたみたいな良いネタや、 速度はKPIになりづらいがめちゃくちゃ大事な要素という話もあった。 また、ミクロとマクロの観点で視座の高さを調節することで施策のインパクトを正しく計測することも重要とのことだった。

なおこのセッションでもSQL大事！分析できる基盤はいろんな部署の人に提供して使ってもらいましょう！という話が出てきてて、 昔＠ITで「SQLはすべてを解決する高級言語なり」と宣って炎上しまくってた生島氏は(ある意味)正しかったんだなと思った。

太平洋をまたいで手をつなごう：日本におけるグローバルプロダクト開発

公式ブログ： https://mercan.mercari.com/articles/18234/

登壇者はアメリカミシガン州出身だが日本語ペラペラだった。すごい。

アメリカでの「コカ・コーラ」は、実は州によって呼称が異なるということからスタート。 ある州では「POP」、ある州では「ソーダ」など全然違う。(そもそもアメリカではペプシのほうが圧倒的シェアという事実も判明) そういうわけで、グローバル展開は、「郷に入っては郷に従え」ということ。これはTransferWiseのセッションと同じ。 登壇者も「日本の書店で本を買うと突然カバーを付け始めてNo!No!と断った」という経験からカルチャーギャップを認識したという。

例えばメルカリではアメリカ国内ではFedEXは速いとう認識だったのにメルカリの配送サービスを誤認識して使ってしまう (FedEX使ったのに遅い)という事案が発生していたそうで、アメリカの環境に合わせて配送サービスのUIを配送速度と価格がわかりやすく選択できるよう変えたという。 それからメルカリUSではユーザーインタビューに取り組んだり、日本でプロダクト開発してるメンバーをアメリカに呼び出したりして対応してるとのこと。 インタビューは日本の会議室とつないでやることもあるという。そして製品の「良いところ」は相互に輸入し合うこともやっていて、 例えばアメリカで生まれた「価格交渉」機能はそのまま日本に持ち込まれ、逆に日本の配送システムは先述どおり若干形を変えた上でアメリカに輸入されている。

別件ではリモートの課題も色々あって、そのへんは議事録を書く&共有すること、期待を明確に伝えること、良い意味で根回しすること (人として覚えてもらうとか、チームが何をしているのかとかを何かしら自分からアピールすること)が大事ということだった。

また、日本は今高齢化社会という局面を迎えており、日本は世界のどの国よりもこれについてはアドバンテージを持っている(他の国より未来にいる)ということだった。 この問題をどう解決していくかによっては、日本がまた世界の最先端になる日もくるのではないだろうかとの提言 (例えば点字ブロック、これは世界中を見ても日本のインフラが断トツで普及している）。
ここでYoutubeの事例として、当時ガラパゴス化してたガラケーの日本の普及率がとても高く、Youtubeモバイル版の利用者は日本が大半だったことが語られた。 そのためYoutubeモバイル版は日本の利用者に合わせた形でプロダクト開発するために、日本拠点で開発チームを形成したとのこと。 結局これがグローバルのYoutubeモバイル版に成り上がったので、他のクラスタよりも先を行く環境でプロダクト開発することの好例となった。

他にもアメリカは州の端から端がとんでもなく遠いので、国内送金も2、3日かかるのが当たり前だったがために、 これを瞬間的に実施するために作られたInstant Payが爆発的ヒットを収めることになったということも語られた。 (Instant Payは最初プロダクトの名前だと思っていたが、ここではPay系サービス全般を指してると思われる)

まずは自分が「これは解決したい課題」と感じた目の前のものに取り組んでみるのもありじゃないかなとこの発表からは感じた。 もちろんそれが正しいのか、本当に価値があるのか、アプローチは間違えていないかなどを検討するフェーズは必要だけど、 最初の行動は自分の直感でもいいじゃん、みたいな部分もあるんじゃなかろうか。

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

パネルセッション。ファシリテーターってほんと難しいよなと傍から見ていて思った。

倫理観と社会的責任が必要な背景としては、データがクラウド化してきたことで管理する事業者もいろんな人の個人情報をみることのできる環境が今世界各地で広がっている。 そんな中で、アーキテクチャやアルゴリズムによる制約のゆるい場所ではそういう観点で物事を語ることがないのではないかと登壇者は警鐘を鳴らしていた。

例えばトイレの石鹸の話で、アメリカで導入されたとある自動せっけん液排出器みたいな日本のトイレの洗面台にもあるアレが、 黒人では反応せずに出なかったという事例が問題となり、アメリカの国内事情にも重なりユーザー視点の欠落という問題が人種問題にまで発展したというものがあったらしい。

日本でもフェミニズムなところでいうとレストランでレディースセットを頼もうとしたおっさんが店側に 「お前はおっさんだろ」と断られたとか断られてないとか、もしかしたらあるかもしれない。 この典型的な事例だと最近では中国の共産国家体制によるモバイルとIoTを駆使した人民総監視な仕組みづくりだろう。

このことから言えることは、ユーザー（利用者）と作る側との相互理解が大事ということだった。 (例えばレコメンド商品についてもユーザーが「なぜこれをレコメンドしているの？」と疑問に思えば、 それは押し付けであって倫理観が欠如していると捉えられてもしょうがないみたいな）

ではユーザー側がどうやってこの辺の倫理観を社会的に守ろうとすればいいかというと、 例えばEFFへ参加するという手段も1つの手。 第三者的な立ち位置の事業や団体を作るのも公平性や倫理観を守る1つの方法かもしれない。

話は人類永遠の課題「正しさとは」に入っていき、もはや収集つかない状態になったけど、 最終的にはTVのサブリミナル演出がNGになったように、今後アプリやサービスでも何かに傾倒したコンテンツってのはだめになる可能性はある とか信頼大事っていうあたりまえの話に帰着し終了。

エンジニア界隈だと意外とOSSについて知らない人も多くて、例えばGPL3.0とAGPLとの違いを述べよみたいなのもまぁ知らなきゃ答えられない。 でもそれって使う側は作った側の意図をライセンスから汲み取って理解を示す必要が最低限の礼儀だと思うし、 そのライセンスが付与されている背景を知ることもまた大切なフローじゃないかなと感じる。

倫理観の欠如は意図して起きているわけじゃなく、単純にそれが手段として意識しなくてよい場所にあるというところが課題なのかもしれない。

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

こちらもパネルセッション。

おもいやりFMというポッドキャストがあるらしい。 それをやってる人が登壇者の1人。あともう人方はレクターという会社のCEOの方。 (後日、最近聞き始めたEM.FMを聴いていたら、ちょうどこのポッドキャストとのコラボ収録のエピソードが再生された)

事業間対立はよく発生する。ただその対立自体は同じ方向を向いていることが多い。それを解決するためには？みたいなところから話はスタート。 例えば市場の変化が激しかったり競合の製品リリーススピードがやたら早かったりするときは、リードタイム短縮のための施策を考える。 その点で組織をどうこうするということをメインに考えることはないが、手段として必要であればやるという判断をすることはあるとのことだった。 また、施策そのものが「誰のための理想」というのは疑問として挙げたほうがよく、現実的にはアジリティが重要にはなるという。 だからCTO、VPoE、プロダクトマネージャーが1人の人間だったら意思疎通の速度は最速になるので、正直それがベストプラクティスではあるということだった。（そりゃそうだ） これができないのであれば、役割を明確化して権限を移譲するしかない。が、会社によってCTOのやるべきことやプロダクトマネージャーのやるべきことっていうのは統一されておらずこれは会話して決めるしかない。そのときに大事なのは役割別に「やらないこと」を決めることではないかという話も挙がった。 (なおCTOのやるべきことについては日本CTO協会がいい感じにまとめてくれるのではないかという淡い期待をこの場では述べられていた。 ちなみにこの協会の代表理事はレクターのCEO。つまり発言者本人)

で、「やらないこと」を決めると今度は「誰もやらない範囲」が明確に出てくる。そこを相互の役割のメンバーが協力して拾っていくことが大事。 ただ、「やらないこと」を決めるのはめちゃくちゃ大変なことであり、終わりのない旅に出るようなもの。 振り返りと合意形成の機会を定期的に用意して自分たちの立ち位置や市場の状況をみながら変えていくことも大事。

あとは組織の文化形成とかは偉い人が推進していくしかないと言う話も上がっていて、 ボトムアップ型は最初から機能しないということだろうなと思った。 これについては山本五十六の「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」や、守破離の話にも通ずるのではないだろうか。 最初からボトムアップで自ら何でもやって文化形成できる人材がいるのであれば、その人に適切な権限を与えて偉くしたほうが早いってのも理にかなってると思う。

また、プロダクトマネージャは0→1を体現する人なんで大変だという前提で、コミュニケーションは粘り強く、 議論を敢えて生んで対立の中からベストな選択肢を抽出するとか修羅の道を自ら歩むことも必要ではないかと言われていた。 そんなことやってたら心が持たない気がするので、やっぱりプロダクトマネージャーは人一倍の情熱が必要だなと感じた。(最終的には熱意で乗り越えるしかない）

プロダクトの強い軸を作るプロダクトマネジメントフレームワーク

資料：https://www.slideshare.net/kumikokoshiro/ss-192896028

及川卓也氏の提唱するフレームワークの一部をかいつまんでの発表。

プロダクト開発サイクルという「何を作るか > どう作るか > どう売るか > どう改善するか > 以下ループ」をベースに考える。

そもそもプロダクト「何を作るか」に躓いたら終わりとのこと。なのでまずはプロダクトを「Core > Why > What」の階層化された定義を考えるといいそうだ。 まず最初にプロダクトが不明瞭な初期段階では「Core」の定義を考え、モノが出来上がってくるにつれて「What」を考えるという流れ。また下層で生じた上層とのギャップや誤りはそのまま残しておくと問題にしかならないので、手間でも一旦上層に戻って言葉や意味の定義をし直すことが重要とのことだった。

Coreを考えるにあたっての手法としては「PRD、リーンキャンパス、インセプションデッキ、OnePager」あたりが使えるとのこと。(インセプションデッキはWhatにも使える) Whyではペルソナを使うといいらしい。ペルソナは定義 > グルーピング/タグ付け > 深堀り(バリュープロポジションキャンパスを利用) > アウトラインの発現 > フィードバック というサイクルを繰り返すことで精度を高めていく。この際にCoreとのギャップを比較し、埋めていくことも大事。 個人的にはペルソナはあくまで想像なのであまり定義しても結局マーケットフィットしないばパーンもあるんじゃないかと思うし、 それならこの時点で本当のユーザーへのヒアリングとかプロトタイプからのレビューとかもやっていいんじゃないかと思ったが、 多分時間の都合上端折ってあるだけだと思うので特に突っ込まない。 ペルソナを練ったあとはそれを利用したWhatの部分、「ユーザーストーリーマッピング」を検討する。 これもまた、ギャップが有るようであればペルソナの定義からまたやり直してみることが必要とのこと。 これらを繰り返すことでCoreに対する完璧なWhyとWhatを用意することができる。

具体的な事例では、pmconf2019当日会場に用意されていた「プロダクトマネジメント質問コーナー」という物理的な企画が取り上げられた。 これは真ん中に紙があって、そこに誰かが質問を書いてボードに貼り付けておくと、 回答者が質問に対して黄色の付箋に書いた回答をペタペタと貼るというもの。 さらに回答者の黄色の付箋には丸いシールを貼ることができ、SNSでいうところの「いいね！」の印を他の参加者がつけることができるようになっていた。 この、「いいね！」機能を考えたとき、CoreとWhyとWhatが明確であれば100%必要という回答ができる。今回の事例では以下の観点で必要といえるそうだ。 　Core:　 ワイワイ感を可視化する 　Why:　 質問者だけでなく閲覧者もターゲットにする 　What:　回答者のモチベーションを保つ

正直このセッションは言葉で説明するよりも資料を見てもらったほうが早いので見てほしい。 まとめとしては抽象度の高いもの（解像度の高いもの）から低いものまでで議論やプロダクトのフェーズを分けてコミュニケーション取れる土台を作って言語化しましょうということだ。 結局イメージできないものは言葉にしか思いが現れないので、エンジニアもプロダクトマネージャーも文字で「なぜ」や 「なにを」を表現することはこの業界では何よりも大事だと言える。(ソースコードそのもの、あるいはコメント行もその1つである)

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

資料： https://speakerdeck.com/mariosakata/he-wotukuranaika-wokao-erurinpurodakutomanezimento

Pivotal Labsの人の登壇。ブースの番人をしつつ聞いてたのであまり覚えていない。

リーン開発の話が出てきて、それは失敗のリスクを減らす努力のことであるというのは認識した。 Pivotal Labsの開発チーム(日本)では、物理壁に付箋でリスクの優先度付をして対応したとのこと。 付箋も課題の難易度によって色分けをして、仮説検証のサイクルを回して確実性の高いものを取捨選択していったそう。

リーン開発もそうだが、アジャイルでも付箋は大活躍するし、物理壁はみんなの意識を一斉にそっちに向けることができる点でシステムよりも強力である。 そういう意味では1拠点の小さなチームには、でっかいホワイトボードをプレゼントするほうがいいよなと思った。一体感も生まれそう。

Rebuild the Industry 〜産業の半自動化を実現するプロダクト開発手法〜

資料： https://speakerdeck.com/mizushimac/pmconf2019-rebuild-the-industry-chan-ye-falseban-zi-dong-hua-woshi-xian-surupurodakutokai-fa-shou-fa

ラクスルの発表。

最初に質問を募集したがセッションが長引いて回答できなかった質問に対してあとからすべて回答するなど大変聴講者思いの方。 話は自動化の話。

ラクスルでは企業1社に対して供給業者を1社アサインするということをやっているが、依頼側がN、供給業者がMとなると最悪N*Mのケースが生まれる。 これらすべてにおいて属人的作業が必ず発生するとした場合、人をスケールしないと事業もスケールしないという問題が発生する。

ラクスルの場合例えばオペレーター。オペレーターはとても作業が煩雑で、いろんなことを属人的にやってたために、 事業が成長すればするほどオペレーター個人に負担が増えるという状況が発生していた。 そのため、事業の成長にはオペレーターの数を増員するしかない！みたいな解しかなかった。よくある。

そこで半自動化の出番である。なぜ全部自動化しないのかといえば、そもそもできないという前提がある。 弊社のサポートでもすべての問い合わせを自動化することはできないように、ラクスルの業務フローでも自動化できない部分はあったのだろう。 時代が解決するかもしれないが、現在では自動化できる部分を推進し効率化を図ることが1つの最適ソリューションだと思う。

もちろんこの自動化を推進していくことで最初は顧客満足度がとても悪くなったものの、長期的視点では改善するという結果が出ているそうだ。 また、自動化されることで結果的にオペレーターが人員過剰になったりややりがい搾取したりみたいなことも発生するので、 そこは自動化によって影響のでる対象の組織の人たちとコミュニケーションを取って「価値を出す部分」について徹底的に議論し理解して貰う必要があるとのことだった。

なおラクスルの組織構成はマイクロサービス化されていてドメイン(担当する業務や業界や機能)で別れており、 例えば印刷・広告事業の人は物流事業のことを全く理解できないということも多々発生するという。 これは、業界特有の用語や市場特徴、プロセスなどが原因で、そもそも共存させることが不可能という背景もあったそうだ。

現代のAIはまだまだ自動化やBotの域を超えてないソリューションも多いけれど、そのうち人間のコントロールできる部分がどんどん減っていき、 最適解を最終的に判断するだけになる世の中は一部の業界では必ずやってくるだろうなと思う。 そうなったとき、既得権益のある部分に対してどうWin-Winなままでいい感じに退いてもらうかみたいな人間臭いところも、 意外とAIがバサッとやってくれたりするのかな？なんて考えると、最終的に仕事とはなんだろうみたいな壮大な話になりそう。

PMから起業家へ。ゼロイチから40億円の資金調達まで

資料： なし

ヤプリCEOの話。一番（ネタとして）面白かったが、メモ取れてなかったのでTogetterみてください。 https://togetter.com/li/1432511

流れだけ端的にまとめる。

• スノボやりたくてスノボ関連の電子雑誌アプリ作った
• 売れたんでアプリ開発行けるじゃんと思った
• 実際に作ろうとしたとき2年かかるようなプロダクトはやるべきじゃないと悟った
  • 機能が複雑になりやすい
• 製品はないのにサイトはある
• 製品はないのにFacebookページはある
• 開発合宿は上海
• 定例は六本木ヒルズ最上階で豪華にミーティング
• 会社すらないのにドメイン取って運用
• 極めつけは製品ないのに受注する
  • ジョブズ、ゲイツもびっくり
• プロダクトは8割できるけどリリースまで行かない印象
  • 残り2割は現実歪曲で突撃
• 売れない時期もある(虚無期)
• プロダクトのマーケットフィットを考えることは大事
  • ヤプリも途中で「みんながかんたんに作れる」ではなく「大手の人の運用効率を上げる」ことに舵を切った
• 4年位は真面目に努力することが大事

最後にアンディ・グローブ（Intelの創設者）の言葉： Only paranoid survive. この言葉はそのまま本になってる。 また彼の本でいうとアメリカでもHIGH OUTPUT MANAGEMENTが有名。

結局笑ってこのセッションを開催できるのも、事業がうまくいってるからだよなぁとおもうと、 起業の良さとつらさをいっぺんに味わうことのできたセッションだった。夢を持つって素晴らしい。