2019/11/12-13に開催されたProduct Manager Conference 2019、略してpmconf 2019に参加してきました。
今年で参加は2度目。イベント自体は4度目。
忘れないうちにざくっと気になった内容や感想をまとめておきたいと思います。

pmconf 2019とは

日本におけるプロダクトマネジメントに関わる人やそれを目指す人が集う機会を設けるため、本年も、プロダクトマネージャーカンファレンスを開催する運びとなりました。

プロダクトマネージャーという職種の認知を高め、プロダクトマネジメント業務に携わる人々が情報や意見を交換することで共に学ぶ場を持つことが、創造性や先進性に富んだものづくりを行うには重要です。その場を提供するべく、プロダクトマネージャーカンファレンスは企画されています。

出典: https://2019.pmconf.jp/

プロダクトマネジメントとかプロダクトマネージャーってなんじゃらほいって話なんですが、それの答えは私もよくわかりません。たくさんのヒントは得られたんだけど、結局謎は深まって帰ってきた気もする。

ちなみにpmconfは今回で4回目。今年は1200名集客という去年までの倍以上の集客とのこと。非連続な成長というやつか。

Keynote: ORDINARY PEOPLE, EXTRAORDINARY RESULTS / Marty Cagan

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

今回のpmconfのオープニングを飾るキーノートスピーチ。ほんとにイベントのキーノートというか、このスピーチを受けた内容が各セッションで展開されたな、と思える内容でした。
以下ではこの講演内容を、メモと記憶を掘り起こして、自分の備忘と理解のためになるべく詳細に書いてみました。

何を作ればいいかを考える - プロダクトディスカバリーとプロトタイプ

プロダクトチームの仕事は、「顧客や自分たちの困難な問題の解決」。
そのために何を作ればいいかを考える（プロダクトディスカバリー）とき、プロトタイプを作ることで4つのリスクを避けられる。

売れるか？ - Valuable
使い物になるか？ / 使いやすいか？ - Usable
開発可能か？ - Feasible
事業として継続可能か？ - Viable

※FeasibleとViableは英単語としても意味の違いが微妙なんですが、feasible の語源は「作ることができる」、viable の語源は「生きることができる」。Marty Cagan氏が例示してくれたのは以下のような違いでした。

Feasibility はテクノロジー、スキル、コストなどの観点で「作ることができるか」
Viability は、
- 営業チームが売ってきてくれるか
- マーケティングチームが宣伝してくれるか
- マネタイズが可能か
- 出資してもらえるか
- コンプライアンス的にOKか
  - たとえば Airbnb は日本では feasible だとしても viable ではない

Empowered Teams -（真の）プロダクトチームとフィーチャーチーム

さて、プロダクトチームには2種類ある。フィーチャーチームと（真の）プロダクトチーム。

フィーチャーチーム
- チームは事業のためにある。
- 渡されたロードマップどおりに機能を作るのが仕事。
- Value, viability は気にする立場にない。Usable な機能が作れる (feasible) であればよい。
- プロダクトの提供後の結果に責任を持つ立場にない。
プロダクトチーム

経営がチームを信頼してないから、チームのポテンシャルが発揮できない。

実際、顧客の課題を発見し、プロトを作って確認し、それを解決できるようなプロダクトを作っていくという活動が出来ているチームはとても少ない。
それはチーム自身のせいではなく、そのような仕事のしかたを許されていないケースがとても多くて、それによってチームメンバーのポテンシャルが削がれているのをあまりに多く見てきた。

前から、empowered teams が大事だと言っている人はたくさんいる。例えば、WORK RULES! や START-UP NATION など。
なのに、なぜ会社はチームに権限を移譲しないのか？殆どの会社のチームは feature teams なのが実態。
これは、**要は「チームを本気で信じられていない」から。**例えば「チームは顧客を理解してない」「ビジネスを理解してない」など。

だから、経営がチームに何をすべきか教えてやらねばならないという発想になっている。だけど、その組織モデルには2つの課題がある。

会社が Command & Control の組織になってしまい、スケールしない。
プロダクトチームが「傭兵」になってしまう。「宣教師」になるべき。「宣教師」のパワーは「傭兵」を凌駕する。

でも、プロダクトマネージャー、役割果たせてる？

ほとんどのプロダクトマネージャーはプロダクトマネージャーの役割を果たせていない。経営がチームを信用できない理由はそこにもある。
でもそれは仕方がない。プロダクトマネージャーとして教育されたことがないのだから。
フィーチャーチームばかりだったから、プロ「ジェ」クトマネージャーしか必要とされてこなかった。
プロダクトバックログを管理する程度にプロダクトオーナーの仕事はこなせてるのかも知れないけど、バックログのグルーミングなんてプロダクトマネージャーの仕事の5%くらいだからね。もっと色々やることがある。
プロダクトマネージャーに、人のマネジメントなんてしてる暇はないはず！(後述)

リーダーシップとマネジメント

ここで一旦、リーダーシップとマネジメントの違いについて。

“Leadership serves to inspire people to greater accomplishments, and management exists to motivate them to the objective” - Mike Fisher and Marty Abbott (paypal)

リーダーシップはもっとすごいことを成し遂げたいな、と思わせる。
マネジメントはモチベーションを持たせ、その目標に向かわせる。

プロダクトマネージャーは「リーダー」であるべき。

※ここ、当日は少しもやっとしたままだったのですが、silicon valley product groupサイトのMarty Caganが書いた記事を見てみたら、この引用の続きが書いてありました。個人的にはこの次の一文で一気にピンと来たので、ついでに引用。

In general, we like to think of management activities as “pushing” activities and leadership as “pulling” activities.

マネジメントは背中を押す、リーダーシップはひきつける、とでも訳すと良いかな。
The Art of Scalability という本からの引用のようです。

リーダーシップがすべきこと - Amazon, Apple, Google の共通点

Amazon, Apple, Google、この３社とも私は所属したことがある。
各社とも、素晴らしいプロダクトを生み出している会社だが、文化は全然違った。
文化で言えば、Amazon と Google が両極端で、Apple はその中間。
また、作っているものは Amazon, Google がソフトウェア中心に対して、Apple はデバイスが中心。
これほどキャラクターの違う会社が、これだけの規模に成長しているのだから、会社の文化が重要とだけ言っていてはだめ。もっと深い何かがあるということ。

実は、この3社の共通点は、故 Bill Campbell というコーチ。2年前に亡くなった。
この3社の創業者たちは、すべて会社の最初の10年にこの人にコーチングを受けていた。
存命中は自分は目立とうとせず、コーチングした人たちを目立たせようとしたため全然知られていない人だったが、偉大な人。
彼が何を教えたかというと:

"Leadership is about recognising that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge." - Bill Campbell

メンバーの凄さを認識し、彼らがその凄さを発揮できるような環境を整えるのがリーダーシップ。
プロダクトマネージャーはそれを意識して活動をしなければならない。

なお、Bill Campbellのことを描いた本は1兆ドルコーチとして出版された。

※ちょうどこの講演の翌々日、11/14に邦訳が発売されてます。

リーダーの5つの役割

チームが20人くらいまでのスタートアップの間は、とにかくサバイバルだから同じ方向を向いて走り続けることも難しくはない。
でも、成長しだすと課題が発生してくる。それに対処するために、5つの重要な責務がリーダーたるプロダクトマネージャーにはある。

1. Product Vision

10人弱のチームが25チームあるとする。このチームを全員同じ方向に向かって走らせなければいけない。
そのために必要なのがプロダクトのビジョン。目指す方向を指し示すものとして北極星に例える会社もあるし、さっきは宣教師に例えてみたね。
ビジョンは大体、3～5年くらいの時間軸のもの。

※日本の企業で言えばいわゆる中期計画くらいのスパンですね

2. Product Strategy

こっちは5～10年くらいの時間軸。

3. Product Principles

4. Product Priorities

要件ではなくて、原則に基づいて価値を考えて優先度をつける。
チームにはロードマップではなくて価値観を伝えよう。

5. Product Evangelism

どうやったらこのプロダクトがすごいものなのだと伝えられるか。それを考えるのも責務。

この5つをプロダクトマネージャーはこなさなければならない。
そして、こなした上で、その価値観や方向性をCTOやCEOと共有できるスキルも必要になってくる。

マネジメントがすべきこと

ここでのマネジメントは「人のマネジメント」の話。
プロダクトマネージャーは人の管理なんかしてる暇ないよ！
人の管理は人の管理担当が必要。プロダクトマネージャーにはプロダクトマネージャーのマネージャーが、デザイナーにはデザイナーの、開発者には開発者のマネージャーが必要。

マネジメントの3つの役割

1. 雇用

いい人を連れてくる。これはHRの責務じゃなくて、マネージャーの責務。

2. コーチング

ちゃんと育てる。
これができているかどうかが、会社が強い会社になれるかどうかの一番重要な差。

3. 目的

とにかく目的 (objectives) にフォーカスすることがまず重要。ちゃんと目的を伝える。

これができると何が起こるか

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” - Steve Jobs

「頭の良い人を雇って、すべきことを指示するなんて馬鹿だ。何をすべきか教えてもらうために、頭のいい人を雇うんだ」

スティーブ・ジョブズは実はプロダクトディスカバリーではなく、プロトタイプの評価がすごい人だった。
そう思うとこの引用句の重要さが感じられる。

信頼の根底にあるのは？

それはスキル。実績だったり技術だったり能力だったり。
それをお互い持っていることが信頼につながる。

"No Assholes Rule" - New Zealand All Blacks

バカ（assholes, 嫌な奴、信頼関係を崩す奴）は、「いても無駄」ではなく「いると邪魔」。
No assholesな状態でお互いを信頼しあえる状況をキープするのはマネジメントの責任である。

まとめ: 信頼されるチームへ

すべてのイノベーションはエンジニアが作り出しているのは疑いようのない事実。
だから、エンジニアは誠意をもってプロダクトマネージャーやデザイナーや、何ならCEOともガンガン議論してほしい。
プロダクトマネージャーとデザイナーと、そしてエンジニアの3者が対等に、最大限のチカラを出し合ってプロダクトを作ろう。

次の3つのテストをクリアできるようなチームになってるか、確認してみると良い。

キャラのたった、十分なスキルのやつが揃ってるか？
課題をアサインされるのであって、ソリューションを作るのをアサインされてないか？
顧客やビジネス課題の解決（outcome）に責任を持っているか？

信頼を得るには時間がかかる。がんばって。

次回予告

・・・他の講演についてはもっとサラッと書きます。