小さなごちそう

プロダクトマネジメントや日々の徒然について

(予告)プロダクトマネージャー・カンファレンス2017を開催します

昨年の10月に第一回目を開催したJapan Product Manager Conferenceですが、第二回目を年内に開催予定です。去年と同じ実行委員メンバーで既にキックオフし、現在企画を詳細化してます。

こちら↓の画像は昨年の登壇者の皆さま。すごいです。第一回目にも関わらず非常に豪華なスピーカー構成で開催でき、多くの参加者にご満足いただいたカンファレンスとなりました。

f:id:tannomizuki:20170729215822p:plain

昨年参加した方は、あの時あの場の熱狂と興奮がよみがえってきたのではないでしょうか。

さて、第二回目ですが下記のようなテーマでセッションを構成することを検討しています。

1. なぜ今プロダクトマネジメント
プロダクトマネジメントが必要な理由や、プロダクトマネジメントは何かといった全体像の概観。

2. ユーザー理解(インサイトの発見、データ分析)
プロダクトマネジメントの目的の一つであるユーザー課題の解決には、当然ながらユーザー理解が不可欠。定性/定量の両面でユーザーを理解するにはどうすれば良いのか。

3. 良いUXをデザインする
ユーザー理解に基いて、実際にユーザーの課題を解決し良いユーザー体験を提供するために、プロダクトマネージャーとして知っておかなければならないことは何か。

4. 熱狂的チームを作る
プロダクトマネージャーはチームで成果を出す必要がある。創造性と生産性を兼ね備えた「熱狂的チーム」を作るにはどうすればいいのか。

5. 新しいテクノロジー
AI、ドローン、ブロックチェーン、IoTなどハイプ・サイクルでいうところの幻滅期を越え、実用フェーズに入ったテクノロジー。自社のサービスで活かす上でプロダクトマネージャーが知っておくべきこと。

6. PMの採用と育成
プロダクトマネージャーを必要とする企業が多い一方で、まだまだ少ないプロダクトマネジメント経験者。いかにしてPMを採用、育成すれば良いのか。

7. PMに期待するもの
エンジニア、デザイナー、あるいは経営者など、プロダクトマネージャーと共に働く人達は、プロダクトマネージャーに何を求めているのか。

8. ケーススタディ
新規プロダクト開発やグロースハックの具体的なケーススタディ

はい、かなり盛りだくさんな内容です。どうでしょう?こんな内容のカンファレンスがあったら、すごく参加してみたくなりませんか?僕は参加したいです。

というわけで実行委員では現在、登壇を依頼する方のリストアップを行っているのですが、登壇候補についてはぜひ皆さまのご要望をお聞かせいただきたいと思っております。それぞれのテーマについて「ぜひこの人に登壇して欲しい」「この人の話を聞いてみたい」という方をお教えください。

docs.google.com

候補の方はプロダクトマネージャーに限定しなくて結構です。また、プロダクトマネージャーの方から以外のアンケート回答も歓迎です。複数回ご回答いただいてもOKです。

実行委員一同、皆さまと共に良いカンファレンスを作りたいと思っております。ぜひご協力をお願い致します!

GEの復活とプロダクトマネージャー制

 GEが「シリコンバレー式」の価値創造プロセスを取り入れる過程を取材して書籍化した本書。めちゃ面白い。

GE 巨人の復活

GE 巨人の復活

 

 リーマン・ショックを機に金融業から製造業に回帰し、さらに「as a Service」化。断片的にニュース記事で見知っていたことがストーリーとして繋がって、ここまで本当にやったのかと感銘を受ける。レガシー産業をテクノロジーで刷新するxTechが注目されるようになって久しいけど、GEはまさに製造業をITで刷新している。すごく学ぶところが多い。

製品化まで5年かかる自社と、Bulid-Measure-Learnを繰り返して短期間でイノベーションを起こすシリコンバレーのスタートアップを比較して、GEはこのままでは滅びると危機感を持つ。そこから変化していく。リーンスタートアップやデザイン思考に学んでFastWorkという自社独自のフレームワークを作り、社内に浸透させる。

GEがIT企業として生まれ変わるために必要となった人材として、プロダクトマネージャーの話が出てくる。一部引用して紹介。

インダストリアルインターネットを実現するというミッションを達成するために、GEはそれまで社内に存在しなかった新しいタイプの人材の採用も始めた。それがソフトウェアの「プロダクトマネージャー」だ。
プロダクトマネージャーとはシリコンバレーのソフトウェア会社には必ず存在する職種で、ソフトウェア製品の機能を決定し、プログラム開発を指揮して、完成した製品を商品として市場に送り出すところにまで責任を負う。
(中略)
どのような機能を実現すれば本当に顧客を満足させられるのか、それを考えるのがプロダクトマネージャーの仕事だ。必要だと考えた機能が本当に実現できるかどうかを判断するのもプロダクトマネージャーの務めになる。

あのGEが導入したプロダクトマネージャー制、あなたの会社ではまだ導入していないのですか?😎

プロダクトマネージャーなんていらない?

プロダクト開発において「プロダクトマネジメント」は必須だ。ユーザー課題を解決できる、技術的/社会的に実現可能、経済的継続性がある(要は儲かる)、そんなプロダクトを定義して実現し、世に送り出すこと。ざっくり言うとこれがプロダクトマネジメントである。

一方で、「プロダクトマネージャー」という役割が必須かというと、それは状況に依る。明確にプロダクトマネージャーという肩書を持つ人間がいなくても、正しくプロダクトマネジメントが行われる開発プロジェクトだってある。

  1. 各メンバーのスキルの合計が、プロダクトマネジメントが正しく行われる上で必要なスキルセットを網羅している
  2. メンバーが自分の職能の領分以外のタスクを実行することを厭わない
  3. 職能が異なるメンバーが自律的にコラボレーションしている、もしくはコラボレーションを促進するリーダー役がいる

こんなチームだったらプロダクトマネージャーは不要か、かなり限定的な役割になるだろう。あるいは「今回は私がプロダクトマネージャーね」と持ち回り制になるかもしれない。僕が今所属している会社はそういう方向に組織が成熟していくんじゃないか、という気がなんとなくしている。現プロダクトマネージャーの人たちは、事業責任者だったりプロダクトマネジメントを開発チームに定着させるコーチのような役割に仕事が変わっていくのかもしれない。これは悪いことではない。というよりとても良いことだと思っている。

ラクラシーという組織形態がある。上意下達式の意思決定が行われる階層型組織ではなく、意思決定が組織全体に分散されたフラットな組織形態のことだ。

ラクラシー組織で意思決定が分散されるように、プロダクトマネジメントがプロダクト開発組織に分散していくケースが増えるのでは、と思っている。プロダクト開発組織の成熟度が増すに従って、プロダクトマネージャーの役割が縮小していく。

ラクラシー組織は「課長」みたいな中間管理職っていらないよな、という組織だ。ホラクラシー組織の構成員には一定レベルの主体性やスキルが要求されると思われるし、ホラクラシーに移行できる組織ばかりではないだろう。だから当分の間「課長」は必要だ。同様にプロダクトマネジメントをチームで実行する組織がある一方で、そうでない組織もある。メンバーの仕事の範囲が職能の境界を越えないような組織だ(エンジニアはコードを書きたいし、デザイナーはデザインしたい、という組織)。そういうチームではプロダクトマネージャーが必要になる。

で、ここからが本論なんだが、プロダクトマネージャーの仕事は、「なりゆきだとプロダクトマネジメントが行われない組織」において、「プロダクトマネジメントが行われるようにすること」だ。そのためにはどんなスキルが必要か、ということを書こうと思ったんだが長くなったのでまた次回に。

モデリングしてますか?

インターネットサービスは非常に多くの要素が相互作用する複雑なシステム。システムの理解にはモデリングが必要だ。問題というものは定義しないと解決出来ない。同様にシステムはモデリングしないと振る舞いを変えられない。モデル化することでシステムの過去の振る舞いを説明し、この先何が起こるのか予測可能になる。

モデリングとは言わば抽象化。枝葉を取り除いて単純化し、システムの振る舞いを言語化、図式化、数式化する能力。僕は因果ループ図をよく使う。人によってはUMLなどを使うのだろう。

わかっている人には当たり前すぎて今更何言ってんだ?という話かもしれないが、「モデル化」という概念を理解しているかどうかは、筋の良いプロダクトマネージャーかどうかを分ける最初の分水嶺。安易に理系文系論にしたくないけど、文系の人にとってはここに最初の壁があると思っている。

モデルは現実世界を単純化したものであって、現実世界そのものとは異なる。人が関与しないコンピューターシステムはモデル=システムの振る舞いになるが、社会システムはそうならない。たまに経済学や経営学で提唱されるモデルに固執する人がいるが、現実世界が常に正。この前提が食い違ってると議論がややこしくなる。

tannomizuki.hatenablog.com

tannomizuki.hatenablog.com

プロダクトマネージャーに訊く #9:Increments及川さん

f:id:tannomizuki:20170320083007j:plain

— 今回はIncrementsでQiitaのプロダクトマネージャーを担当されている及川さんにお話を伺います。早速ですがQiitaの概要やサービスコンセプトについて教えてください。

Qiitaはエンジニアのための情報共有コミュニティサイトで、様々なユーザーが技術の習得やトラブルシューティングに役立つ情報を発信しています。Qiitaはエンジニアのためのナレッジベースになっており、多くのトラフィックGoogleなどのWeb検索から流入します。エラーメッセージをキーワードに検索し、Qiita上のページにたどり着いて問題を解決する、といった使われ方ですね。

Increments株式会社は「ソフトウェア開発をよくすることで世界の進化を加速させる」を企業ミッションとしています。その企業ミッションのもと、ソフトウェア開発を支える技術者のための知の共有プラットフォームとしてQiitaを提供しています。

人はアウトプットすることで成長します。自分の知識を人に伝わるように整理することは、自分自身の学びにもつながる。さらに読者からのフィードバックで新しい気づきを得ることができ、それが次の情報発信につながります。こうした情報発信と学習のループが回るプラットフォームの実現をQiitaは目指しています。

書き手と読み手がコンテンツを育てるサービスに

— ブログでも気軽に情報発信できますが、Qiitaを使って技術情報を発信することのユーザーメリットは何でしょうか?

人はアウトプットに対してフィードバックがないと、情報発信のモチベーションが続きません。知名度の高い人でなければ、ブログを開設してもすぐに多くの人に見てもらうのは難しい。一方で既に大きなコミュニティが形成されているQiitaに投稿すれば、ブログに書くよりも格段に多いアクセス数を得られますし、良い記事はストックされて繰り返し閲覧されるようになります。さらに記事へのフィードバックを得やすい仕組みもあります。

— ブログにもコメント欄でユーザーからのフィードバックを得られますが、Qiita独自の仕組みが何かあるのでしょうか?

QiitaにはGitHubのPull Requestのような「編集リクエスト」という機能があり、コンテンツをコミュニティで育てていくことができます。もし内容に誤りがあったり最新情報になっていない場合には、読者が本文の更新案を書いて記事の投稿者にコメント付きで編集リクエストを送ることができます。Qiitaはコンテンツとコミュニティを両輪としたサービスで、読者と投稿者の共同作業によってコンテンツが育っていきます。

技術的な記事を正確に書くのはすごくハードルが高い。そして技術記事は更新して正しくあり続けなきゃいけない。個人ブログは投稿者自身が記事をメンテナンスする必要がありますが、Qiitaではコンテンツをアップデートする役割を投稿者以外でも担うことができます。これがQiitaとブログの違いの一つです。

— 間違っている箇所の指摘だけでなく変更案まで作ってもらえるのであれば、書き手はとても楽ですね。

以前Chromeの開発マネージャーを務めていた時に、自分のブログにWebテクノロジーに関係する記事を書いたことがあります。書いた当時は正しい内容でしたがブラウザのバージョンアップによって、現在では情報が古い記事になってしまいました。そろそろ訂正しなきゃと思いつつも、今はブラウザを作る仕事をしているわけではないので腰が重い。ブログではなくQiitaであれば、誰かが「最新のスペックはこうなってますよ」と書き直してくれる可能性があります。

— 他にもQiitaとブログの違いはありますか?

個人ブログのもう一つの問題は書き手の信用度がわかりにくい点です。例えばTwitterFacebookの場合はフォロワー数を見れば、その人がどれくらい影響力を持つ人なのかわかりますが、個人ブログには同様の指標がありません。

Qiitaでは他のユーザーに「いいね」された記事の数や編集リクエストが採用された数を元に、Contribution(コントリビューション)と呼ばれる数値をユーザーごとに算出しています。ユーザーにとってContributionは技術者としての優秀さやコミュニティへの貢献度を計る指標になっています。

f:id:tannomizuki:20170320084925p:plain

QiitaではContributionとしてコミュニティへの貢献度が可視化される。

— ContributionがQiitaを利用するモチベーションになっているのでしょうか?

情報発信のモチベーションにも繋がっているところはあると思います。CGMサイトでは承認欲求を満たすことがコンテンツ投稿の目的の一つになると言われます。Contributionもユーザーが承認欲求を満たす機会になっているでしょう。

承認欲求という表現に下世話な印象を持つかもしれませんが、人間は誰しも「他人の役に立ちたい」という気持ちを持っています。マズローの欲求5段階説については知っている人が多いと思いますが、実は5段階目のその先に「自己超越」という欲求があるそうです。「人間は人類全体や他者のために貢献することに価値を見出す」というものです。Qiitaをそうした人間が本来持っている高次の社会的欲求を満たせるプラットフォームにしていきたいと思っています。

社内の誰もがプロダクトマネージャーの役割を買って出ることができる

— Incrementsにおけるプロダクトマネージャーの役割を教えてください。

PMの仕事は、ユーザーヒアリングをもとにプロダクトのあるべき姿について仮説を立てる、ロードマップやOKRなどの形式に落としこんでチームで開発を進める、Go To Market Planを作りユーザーに届ける、といったものになります。
参考:Incrementsにおけるプロダクトマネージャーの職務定義

実は1年前に私がPMとして採用されるまでは、エンジニアとデザイナーだけで開発を進めており、実質的にデザイナーがPMの役割をしていました。一般的にデザイナーというと、グラフィック制作やWebのフロントエンド開発などが主な役割になると思います。一方IncrementsではデザイナーがUX全体の責任を持ち、カスタマービジットをしてヒアリングし、課題を発見して解決案を考えるというところまで全てやっていたのです。そろそろ専業でPMが必要なフェーズだということで私が入社することになりました。

現在でもIncrementsではこうした仕事をPMだけがするのではなく、誰もがPMの役割を買って出ることができます。PMではなくても自分の担当業務を通してプロダクトの問題点に気づくことは沢山ありますし、社内で自社製品を使っていれば改善アイデアも自然と生まれます。誰でも「こういうものを作りたい」と起案できて、プロダクトのミッションやロードマップに合致する優れたアイデアはどんどん採用されます。

Incrementsにはプロダクトの要件を整理するPRD(Product Requirements Document)のフォーマットがありPRDにもとづいて開発を進めていますが、PM以外でもPRDを書いて起案できます。最終的にはPMが引き取って意思決定し、不足のないようにPRDを整えて関係者のコンサセンサスを取りますが、誰がPM的な動きをしても構わないというようにしています。実際にここ半年でリリースした機能のいくつかは、PM以外からの起案が採用されたものです。

f:id:tannomizuki:20170320085146p:plain

「Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜」より

— プロダクトマネージャー以外でも起案できる風土というのはいいですね。逆にPMが実装にまで踏み込むことはありますか?

いえ、実装のアイデアに首を突っ込むこともありますが、基本的に実装にはまったく関与しません。ユーザー体験に影響するような実装に対してはきちんと意見を言うし、ある程度のこだわりを持つんですが、そうではない部分はエンジニアに任せています。

— UIについてはPRDを書く段階でどれくらい最終イメージを具体化されていますか?

PRDのフォーマットの中にはUI requirements の項目があり、ユーザー体験としてどういうことを実現しなければならないか書くようにしています。文字面だけで伝えるのが難しい場合は簡単なモックを添えます。モックは既存の画面をベースに自分で描くこともあれば、デザイナーに入ってもらって作ることもあります。ただPRDに描かれたモックの通りに実装されるわけではなく、実装の過程でさまざまなオプションが出てきて、実際にリリースされた機能は当初想定していたものと大きく異なるということはよくあります。

ソフトウェア開発には、エンジニアやデザイナーだけでなくプロダクトマネージャーも必要

— 及川さんはエンジニアからキャリアをスタートされていますよね。どういう経緯でプロダクトマネージャーになったのでしょうか?

プロダクトマネージャーになったのは、最初に入社したDECからMicrosoftに転職したときですね。ちなみにMicrosoftでプロダクトマネージャーは「プログラムマネージャー」と呼ばれています。

大規模なソフトウェア開発では、顧客と話して課題を見つける、開発したものを実際に使ってもらえるようにする、などプログラムを書く以外にも重要な仕事が沢山あります。周囲にはコードを書ける人は沢山いたのですが、そうした開発以外の仕事が得意な人があまりいませんでした。

私は営業サポートからキャリアをスタートしているのですが、その時の経験から顧客とコミュニケーションしながら仕事を進めるプロダクトマネージャーという役割は自分には向いているのではないかと思っていました。

Microsoftではプロダクトマネージャーとしてどのような仕事をされていたのでしょうか?

私がMicrosoftに入って一番最初に担当したのが、Windows Terminal Server Editionという製品の日本語対応です。リモートからWindowsサーバーに接続してクライアント端末上にデスクトップを表示して操作できる、というものです。

インターネットサービスとは違ってパッケージソフトは一度出荷してしまうと簡単には修正できません。あらゆるシナリオを網羅して破綻しないように仕様を決める必要があります。クライアント端末に接続されているキーボードのレイアウト、インストールされているフォント、IMEなど、日本語特有の機能を中心に様々なユーザー環境を想定してスペックを考える、といった仕事を当初やっていました。

— かなり実装寄りの仕事ですね。

Microsoftのプログラムマネージャー、世間一般でいうプロダクトマネージャーはかなり開発寄りなんですね。私が書いたプロトタイピング・コードをもとにエンジニアがプロダクションコードを書く、といったこともよくありました。

— プロダクトマネージャーにはマーケティングに関する知識やスキルが要求されますよね。エンジニアリング以外の分野についてはキャリアのどこで経験されたのでしょうか?

Googleで広報やマーケティングのプロフェッショナル達と一緒に仕事をすることで、エンジニアリング以外の分野についても経験を積むことができました。Googleにはマーケティングチームがあり、プロダクトマーケティングマネージャーという役割の人がいるのですが、製品のプロモーションプランはPMが広報やマーケティングチームと相談しながら作っていきます。

NHKの「プロフェッショナルの流儀」に出演されていましたが、番組で及川さんはエンジニアと紹介されていました。やはりご自身のアイデンティティはエンジニアリングにあるんでしょうか?

アイデンティティ」とはその人なりのこだわりが現れるものだと思いますが、私は技術にこだわりを持っており、自分を「技術者」だと認識しています。

ソフトウェアの分野でエンジニアといえば一般的にコードを書く人をイメージしますよね。だから私は「エンジニア」を包含する概念である「技術者」という言葉を使っています。そして、プログラマーやデザイナーが「技術者」であるのと同様にPMも「技術者」だと私は思っています。

— なるほど。プロダクトマネージャーはマーケティング部門に所属するのかエンジニアリング部門に所属するのかという議論もありますが、技術者であると。

もちろん人や組織によって考え方は違います。IncrementsやGoogleではPMが開発系の組織に所属していますが、他の会社ではビジネス系の組織に所属している場合もあるでしょう。それはそれでおかしくありませんし、実際にはプロダクトマネージャーは技術職とビジネス職のちょうど中間にいる存在です。

いずれにしても、ソフトウェア開発におけるプロダクトマネージャーの重要性を日本で広く認知させる必要があると考えています。

「ソフトウェア開発にはどんな人が必要か」と問われたら、ほとんどの人は「プログラマーやデザイナーが必要だ」と答えるでしょう。でも実際に世の中で使ってもらえるプロダクトを生み出すためには、プログラミングともデザインとも異なる技術、すなわちプロダクトマネジメントが必要です。だから僕は「ソフトウェア開発に必要な技術者」のなかにプロダクトマネージャーも含めるべきだと思っているのです。

プロダクトマネージャーは物事を俯瞰的にみて問題の本質を明らかにせよ

— プロダクトマネージャーになる人にはどんなスキルが求められるでしょうか。

まず第一に論理的な思考ができることです。そして物事を俯瞰して見られること。多少ひねくれたスタンスにも見えますが「一歩下がってものを見る」習慣を身につける必要があります。

先日あるプロダクトマネージャーが「新しいものを作る時は歴史を学ぶ」と言っていました。例えばHealthTechに関わるプロダクトを作るのであれば食や健康、医療についての歴史を学び、時代の流れを俯瞰して見て現代のプロダクトのあるべき姿を考えるそうです。

エンジニアとしてモノを作ることへの思いが強すぎる人は、解決策ばかり考えてしまう傾向があります。「この機能を提供しましょう」「こうすれば実装できます」といったように解決策から考えてしまう。PMの役割は、目の前の現象を一歩引いた立ち位置で見ることで、暗黙の前提になっていることや問題の本質を明らかにすることです。「そこまでこだわる必要ありますか?」「そんな自明なことわざわざ一歩下がって考えなくてもいいのでは?」と鬱陶しがられるくらいまでこだわるほうがいい。

以前、洗濯物をアイロンがけして畳んでくれるロボットが話題になっていました。PMであればそうしたニュースを見てただ面白いと思うだけでなく、「そもそも畳まなくてもいい衣類を作ればいいのでは」「服を着なくてもよい世界にできないか」と後ろに遡って発想する習慣をつけたほうがよいでしょう。

そもそも世の中にどんな課題があるのか、もしくは世の中にどんな価値を提供したいのか、その点をとことんまで考えた上で解決策を導き出すのがPMの役割です。

— 及川さんはもともと俯瞰してみる習慣があったのでしょうか?

僕はもともと性格が多少ひねくれているというか、理屈っぽいんですよ。日常的な会話でも「その言葉の定義は?」なんて聞いてしまう。先日、あるプライベートな集まりで「奥さんと仲が良いか」という話題になった時に、僕は「仲が良いの定義する必要がある」と答えたんですね。

「仲の良さ」の定義には3つのポイントがあります。一つ目はコミュニケーションの頻度が高いこと。仲が良い相手とはコミュニケーションの絶対量が多いはずです。2つ目はコミュニケーションが対称性を持っていること。一方的に伝える関係ではなく、双方で言いたいことを言っている状態です。ただこれだけだとケンカをしていても満たしてしまう条件なので、3つ目の条件としてコミュニケーションの質が高いことも重要です。ですから奥さんとの関係を良くするためにはこの3点を改善する必要がある。例えばこんな風に日常の会話でも理屈やKPIツリーを考えてしまう面倒くさいタイプの人間です。

実はこの会合は哲学ファンの集まりでした。私と同じようなタイプの人ばかりでとても居心地が良かったんですね(笑)。社会のあらゆる事象を言葉で説明しようとする哲学の思考法は、プログラミングやKPI分析で必要な思考法に通じるものがあります。哲学家はすごくPMに向いているんじゃないかな。文系理系のようなステレオタイプで分けたくないんですが、いわゆる文系バックグラウンドのPMはしっかりとした思想を持っている人が多くて、話しているととても学びが多いですね。

— 「論理的思考能力」「俯瞰してみる習慣」の他にPMに求められる能力はあるでしょうか?

身も蓋もない言い方をするとPMにとってもっとも大事なスキルは「人間力」だと思っています。人間力をどう身につけるか、と聞かれるとなかなか一言で答えるのは難しいのですが、「いいものを作りたい」という強い熱意があり、プロダクトをチームで作るために必要なコミュニケーションを楽しめる人はPMに向いていると思います。

コミュニケーションと言っても楽しいおしゃべりができる必要はないのです。要は妥協せずに相手と話そうとすること。チーム開発を進める上で必要なファシリテーションができるかどうかです。

ファシリテーターは一般的に中立的な立場の人が行うことが多いと思いますが、プロダクトマネージャーの場合は当事者ですよね。どうすればうまくファシリテーションできるでしょうか。

PMとしてファシリテーションするときに重要なのは、自説にこだわらないことです。ある程度経験のあるPMなら、ファシリテーションするときに中立な立場を装って恣意的に自分の考えたシナリオ通りに議論を誘導することができてしまいます。

全員で決めたかのようにメンバーの納得感を得られるのであれば、それはそれで非常にハッピーです。ただ、チームでの議論を通じて自分が考えたものよりも良いアイデアが生まれることはよくあります。

自説にこだわって自分のシナリオ通りに軌道修正をかけようとするのではなく、チームメンバーのアイデアの方が優れていると思ったら、「それ採用!」と自分のプライドと関係なく方向性を変えることができなきゃいけない。

プロダクトマネジメントに正解無し。プロダクトが成功すればどんなやり方でも構わない。

f:id:tannomizuki:20170320083203j:plain

— 「自説にこだわらない」のはなかなか難しいと思いますが、及川さんは最初から苦労なくできましたか?

いやいや。私は20代後半から30代くらいまでは「自分が一番だ」という感じでしたからいろいろ衝突しました。幸運なことにMicrosoftGoogleも大きな組織だったので、マネージャー教育がとても充実していました。そこで学んだことが今でも役に立っています。

DECではマネージャーではなかったので、Microsoftで初めて人の上に立ち、マネージャー教育を受けました。その際、「君が一番になっても意味がない。君1人が頑張ったとしても、いつまで経っても一人分の成果しか生まれない。でも自分の意志をチームに共有して仕事を進めれば、3倍、4倍の結果が生まれる」と教えられました。自分のプライドが満たされることに意味はない、最終的にやりたいことがきちんと実現されれば良いのだ、という考え方を叩き込まれたのです。

— PMには一般的なマネジメント能力も必要とされるのですね。

プロダクトマネージャーは「プロダクト」のマネージャーであって、「人」のマネージャーではありません。エンジニアやデザイナーに対する人事権を持っていませんし、持たないほうがいいと思います。でもピープル・マネジメントのスキルが必要な場面も多いんですよ。紆余曲折ある開発プロジェクトの中でチームメンバーをリードして、仕事を前に進めていかなければならない。そのためには人のマネジメント能力も結局必要になってくるんですね。

— こういうプロダクトマネージャーは成功しない、というアンチパターン的なものはあるでしょうか。

PMのあり方にこれが正解というものはないんじゃないかと思うんですよね。結果的にプロダクトが成功するのであればどんなやり方でもいい。

PMの成功例としてスティーブ・ジョブズが挙げられることがありますが、二度と彼の下では働きたくないという人も多い。「人間力が大事」「チームの発想を大切に」という話をしておいてこう言うのもなんですが、たとえどんなに皆んなに嫌われたとしても、最終的に世の中を変える革新的なプロダクトを生み出した人は勝ちなのです。ただ殆どの人はスティーブ・ジョブズになれない。であればチームの輪を重んじた方がいいでしょう。

PMにはサーバント・リーダーシップが必要だと言われますが、そういう意識のないPMもたくさんいます。いかにもトップダウンのリーダーという感じでガンガン指示を出すタイプの人もいる。会社のフェーズや体質によってはそういう人が向いている時もあるでしょう。逆に「この人は何ができるんだろう」と思われるような頼りないPMもいます。「あいつは頼りないからオレ達が頑張らなきゃ」とチームが一致団結することでプロダクトが成功するのであれば、その人は優秀なPMと言って良いでしょう。もしかしたらそこまで計算して動いているのかもしれない。

ですから無数のベストプラクティスはあっても、こういうやり方だと必ず失敗するというアンチパターンは存在しないと思います。良いプロダクトを継続的に出し続けているならば、そのPMの方法論は正しいのです。ただ別の環境や組織で同じ方法が通用するかどうかは別の話ですが。

— チームに合わせて、プロダクトマネージャーのあり方を変えていくべき、と。

そうですね。あえて言うならば「自分のスタイルに固執しすぎてしまう」というのはアンチパターンかもしれないですね。スティーブ・ジョブズでない限りは、その時々で置かれた状況や組織形態に適応していく必要があります。以前PMのコミュニティで話題になったプロダクトマネジメント・トライアングルの記事にもありましたが、「組織に不足しているのはどんな役割なのか」という観点でPMとしての振る舞い方を考えることが大事です。

最近は書籍や勉強会などでも各社のプロダクトマネジメントの方法論を知ることができるようになりましたが、ソフトウェア・エンジニアの方法論と比べるとまだ人それぞれ、各社各様で、正しい方法論が確立されているわけではありません。ですからあまりフレームワークや方法論にとらわれず、柔軟性を持ち続けられることが大事なのかなと思いますね。要はプロダクトが成功すればいいわけですから。

ユーザー価値と事業価値を両立させるサービス設計を

— プロダクトマネージャーにはどのようなマインドセットが必要でしょうか。

「作れるもの」を作るのではなく「使われるもの」を作る、という点にこだわり続けることが大事だと思います。これは当たり前のようで結構難しくて、ついつい作る側の論理で物事が進んでしまうことが多いんです。ただユーザからみると「使えるか、使えないか」「使いたいか、使いたくないか」が全てです。

— ユーザーにとっての便益も大切ですが、ビジネスとしてサービスを提供する以上、収益も重要ですよね。

そうですね。ただ、ユーザーに価値を提供できない限り、事業的なゴールには到達できないと思うのです。ユーザーは提供者の都合が前面に出すぎた利用価値の低いサービスを使おうとは思いません。私はかなりGoogle的な価値観に毒されているところがあるのですが、本来、サービス設計が正しければ、事業的価値とユーザーにとっての利便性は両立するものです。

例えばGoogleの検索結果には検索連動広告が表示されます。水道管が水漏れした時にGoogleで「水道管 水漏れ」といったキーワードで検索すれば、検索結果ページに修理会社の広告が表示される。困っている時にタイミングよく解決方法が提示されれば広告であってもユーザーにとって有用です。Googleのミッションは「世界中の情報をくまなく集め、世界中の人に届くようにする」というものですが、ミッションに矛盾することなく広告という枠組みで自分たちの収益を上げつつ、ユーザーに役立つサービスを提供することができています。同じように事業価値とユーザー価値を矛盾しない形で実現する方法は必ずあるはずです。PMはそうしたモデルを実現することを考えるべきだと思います。

— そうは言っても短期的な売上とユーザーの利害が衝突してしまう場合はあると思います。ビジネスサイドからのプレッシャーに対して、PMはどう対処すべきでしょうか。

そういう場合はCEO、ファウンダーを自分のサポート役につけるべきです。
PMはP/Lを見ながら事業展開を考えなければいけませんが、ビジネスサイドの要求だけに流されてはいけません。そうならないためにはファウンダーから創業時の想いを引き出し、プロダクトの方向性をしっかり握ることです。

PMは他の経営陣や社内のステークホルダーから色々と注文を受けますが、ファウンダーを味方につけておけばいざという時に後押ししてもらえます。会社にとって究極のPMはファウンダーです。ファウンダーが顧客に対してどんな価値を提供し、どう収益をあげていくか答えられないのであれば正直言ってその会社は厳しいと思います。

もちろん会社のステージによってはそうも言っていられないと思います。「3ヶ月間で1億稼がない限り潰れてしまう」といった場合は建前ばかり言っていられない。ただ売上は顧客に提供した価値の対価です。ユーザーメリットより自社の都合を優先する状態がずっと続いている状態はおかしい。

— プロダクトマネージャーがユーザーの代表という視点を持てるかどうかが重要ですね。

もちろんPMはプロダクトがどれだけ事業に貢献できるかという視点を持つ必要があります。ただそれでも最終的にはユーザーにとって価値があるかどうかに帰着します。

例えば広告事業であれば売上はインプレッションに比例します。インプレッションを上げるためには多くの人に何度もサイトを訪問してもらう必要がある。そのためにはサービスの価値を高めて、ユーザーに愛されないとダメなんですね。ユーザーに愛される努力をすれば広告媒体としての価値が上がる、という前提が共有されていれば、ビジネスサイドとプロダクトサイドが衝突することはない。PMがビジネスサイドの目標をプロダクトのKPIに正しく翻訳できれば、そこから先はプロダクトサイドに任せてもらうことができます。

トップダウンでユーザー視点を欠いた機能追加しなければならなかった、といった経験は過去になかったのでしょうか。

私がいた時代のGoogleボトムアップのカルチャーでした。トップダウンで決まることもありますが、その内容はかなり抽象度の高いものが多い。例えばChromeであれば、「パフォーマンスを良くせよ」とか「Google検索とのユーザー体験をシームレスにせよ」といったレベルのメッセージが多いのです。PMは自分たちのプロダクトがそうした方針にどう貢献できるか考え、具体的なプランをボトムアップであげていく、というカルチャーでした。

— 例えば以前、飲食店のレビューサイトで自社のシステムを導入していない飲食店の評価が下がる、という仕様変更が話題になりました。ユーザーの利便性を無視した方向に意思決定が進んでしまった場合、プロダクトマネージャーはどうすべきでしょうか。

詳しい事情がわからないのでなんとも言えませんが、自社システムを導入した飲食店のほうがユーザーは価値を感じるはずだと本当に信じているならば、それは自分たちの信じることをやっているとことになります。

例えばGoogleスマホでWebページを高速に表示することができるAMP(Accelerated Mobile Pages)というレンダリング・フォーマットを発表しましたが、AMPを採用したページはGoogle検索にも良い影響を与えるようになるのではないかと言われています(Googleは公式には検索ランキングに直接の影響があるとは言っていません)。
Webページの表示が速くなれば検索回数が増えてGoogleが得をするからAMP導入サイトを優遇するんだろう、と言われれば確かにそうした側面はあるかもしれませんが、GoogleはAMPが自社の利益だけではなくユーザーの利益になると確信した上でやっています。

自ら発信し、実践することがPM登用への近道

— ソフトウェア開発にプロダクトマネージャーは必須である、というお話がありましたが、どうすれば社内にPMを増やすことができるでしょうか。適正のある人材が見つからずPMをなかなか採用できない、という話もよく聞きます。

先程も言ったように企業にとってはファウンダーが究極のPMなんですね。 Incrementsではファンダーである社長の海野が現在もQiita:TeamのPMをやっています。ただ、組織や事業が成長するにつれて経営者とPMを兼任するのは難しくなってきます。そうなると後任となるPMが必要ですが、ファウンダーの想いを引き継いでプロダクトマネジメントができる人を探すのは容易ではありません。

PM候補をロイヤルカスタマーの中から探す、というのも一つの手です。また社内から素養のある人をPMとして登用するという方法もあります。以前、freeeの執行役員でプロダクトマネージャーの坂本さんが、「自社製品に強いこだわりや愛を持っている人をPMとして登用する」という話をされていました。開発部門以外の人はプロダクトに対して他人事になってしまいがちですが、自らプロダクトに対して色々な改善提案をしてくれる人はPMの候補になります。

— 逆にPMになりたい人は、社内で積極的にプロダクトの改善提案するとPMに登用される機会を得られるかもしれないですね。とはいえ未経験の人がいきなりPMに登用されるのは難しいと思いますが、PMを目指す人はどうやって必要なスキルや知識を身につければいいでしょう。

Startup Weekendのようなイベントに参加してみるのはどうでしょう。Startup Weekendでは顧客開発をするハスラー、機能開発をするハッカー、デザインを作るデザイナーがチームを組んで週末の3日間でプロダクトを作り上げます。ハスラーが所謂PM的な役割になります。

Startup Weekendではプロダクトを作るだけでなく、顧客検証まで行います。例えば駅前で何人かにアンケートをとって、仮説を確かめるところまで3日間の中で全て完結させることを目指すのです。MVPを考えずに作り始めてデモさえできずに終わってしまうこともあれば、途中でピボットして別のプロダクトを作ったチームがうまくいくこともあり、3日間という短期間の中でサービス立ち上げプロセスを凝縮して経験できます。また、Startup Weekendでは知らない人同士でチームを組むことが多いので、PMが直面する人の問題やコミュニケーションの問題について、良くも悪くも経験できてしまいます。

— 社内にこだわらず実践の場を探すということですね。確かにハッカソンのようなイベントに参加すれば短期間にプロダクトマネージャー的な役割を繰り返し経験できそうです。

一般的なハッカソンはStartup Weekendほど明確にプログラム化されているわけではないんですが、時間が限られている中でチームを組んでアウトプットする点は同じなので、他のハッカソンイベントでも同様の経験ができると思います。また、ハッカソンではPM経験やサービスの立ち上げ経験のある人がメンターになることが多いので、普段課題と感じていることに対して経験者からアドバイスをもらう機会にもなります。

プロダクトマネジメントに関わる人にお勧めの本があれば教えてください。

リーンスタートアップアジャイル関係の本は皆さん読んでいると思いますので、ちょっと別の観点の本をご紹介しましょうか。

「あなたのチームは機能していますか?」はサーバントリーダーシップやチームメンバー間のコミュニケーションについて学ぶことができます。ストーリー仕立てになっていて読み物としても面白い本です。この本は経営メンバーのチームワークに関する話なのですが、どうやってチーム内でコンセンサスを形成して強いチームを作るのかという点は、経営もプロダクト開発も共通です。 

あなたのチームは、機能してますか?

あなたのチームは、機能してますか?

 

 もう一つは野中郁次郎先生の「失敗の本質」です。第二次世界大戦のときの日本軍の失敗の原因を考察している共著の本なんですが、開発プロジェクトが失敗する原因とも共通する点が多く、とても面白い。 

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

 

 個人的にハイライトしたところからいくつか引用してご紹介しましょう。

日本軍ははじめにグランドデザインや原点があったというよりは、現実から出発し状況ごとに場当たり的に対応し、それらの結果を積み上げていく思考方法をとった。

日本軍が戦前において高度の官僚制を採用した最も合理的な組織であったはずであるにもかかわらず、その実体は、官僚制のなかに情緒性を混在させ、インフォーマルな人的ネットワークが強力に機能するという特異な組織であったことを示している

こまでやったのだからとか、この人がここまで努力したんだからその人のメンツをつぶさないでやらせてあげよう、といった日本的なメンタリティに流されて、組織の本来あるべき姿を無視してしまう、といったことが状態化していました。

日本軍の失敗の過程は、 主観と独善から希望的観測に依存する戦略目的が戦争の現実と合理的論理によって漸次破壊されてきたプロセスであった

要は問題に対して科学的なアプローチをせずに希望的観測に基いて行動してしまったのです。こうしたことは今日の日本企業でも起こっていることだし、スタートアップであっても起きてしまうことです。

— プロダクト開発プロジェクトのケーススタディとしても読むことが出来ますね。最後に記事の読者へのメッセージをお願いします。

ここしばらく、自社の仕事と並行して、プロダクトマネージメントの認知向上の活動をしています。私は、プロダクトマネージャーが日本を救うとさえ考えています。優秀なソフトウェアエンジニアは日本にも多くいます。ただ、お話したように、良い製品やサービスはエンジニアだけでは作り上げられません。プロダクトマネージャーのような人たちがエンジニアなどとともに、実際に使われる製品を作ることこそが日本に求められていることであり、さらには世界にも貢献していくことになると考えています。

— ありがとうございました。

大人にも読んで欲しい「はじめてであう すうがくの絵本」

子どもが読んでいた絵本にとても感銘をうけたので紹介する。

はじめてであう すうがくの絵本 (1)

はじめてであう すうがくの絵本 (1)

 

本書は足し算や掛け算をの正確さや早さを訓練するような算数ドリルとは異なり、数学的な考え方を身につけることを目的にしている。大人向けのあとがきで、著者は次のように書いている。

もし数や図形を教えるだけなら、ほかにもよい算数の本はたくさんあります。
算数だけでなく、他の学問全般に共通する考え方を教え、発見や想像の喜びを分かちあい、たまには迷路にさそいこんでくやしがらせる、そんなおもしろい本はできないものか、と考えたのです。

この「学問全般に共通する考え方」は社会人に求められる問題解決力の向上にもつながるものだ。機会があったらぜひ読んでみて欲しい。

本書は「なかまはずれ」「ふしぎなのり」「じゅんばん」「せいくらべ」の4つのパートに分かれている。内容を少しだけ紹介しよう。

「なかまはずれ」を探す。

f:id:tannomizuki:20170211095415j:plain

遠くに住んでいる人と「せいくらべ」ができるように、棒の高さで背を比べる。

f:id:tannomizuki:20170211095712j:plain


本書で学ぶ「考え方」には、最近個人的に興味を持っているComputational Thinking(CT)と共通するものを感じた。「なかまはずれ」はCTにおけるPattern Recognitionに繋がるし、「せいくらべ」はAbstractionだ。改めて考えるとCTの考え方の大半は、高校レベルの数学を学び様々な問題を解く過程で自然と身につくものかもしれない。ただAutomation(Algorythm)は数学を学ぶだけでは身につきにくい、CT固有の考え方と言えそうだ。

Algorithm Designを目的にして、必要なDecomposition、Pattern Recognition、Abstractionを行うのが数学的思考と計算論的思考(Computational Thinking)の違いだと考えるとわかりやすいかもしれない。

全3巻だったので、早速残り2巻を注文した。 

はじめてであう すうがくの絵本 (2)

はじめてであう すうがくの絵本 (2)

 
はじめてであう すうがくの絵本 (3)

はじめてであう すうがくの絵本 (3)

 

 

ランニング再開に向けて治療中

昨年の年始からランニングを始めて走ることが習慣としてすっかり定着していたのだが、この3ヶ月一度も走れていない。原因は右足の裏にできたウオノメだ。最初は「素足で歩くとちょっと違和感があるな」という程度だったのだが、放置しておいたら痛くてまともに歩けない程になってしまった。

皮膚科で診察を受けて硬質化した皮膚を削ってもらったが治らない。別の病院で皮膚を軟化させる薬を処方してもらったが効果なし。また別の病院では液体窒素で患部を焼く治療をしてもらったが改善する気配が全くなし。挙句の果てに「患部にダクトテープを貼る」という民間療法?をネットで見つけて試したがやっぱりダメ。そうこうしているうちに症状に悪化して、痛い足をかばって不自然な歩き方をした結果、腰痛と偏頭痛を併発。

困り果ててネットでさらに色々と調べた結果、レーザー治療でウオノメを切除してくれる医院を見つけた。まだ治療中だが、ようやくまともに歩くことができるようにり腰痛や偏頭痛が解消した。あと一ヶ月もすればランニングを再開できるだろう。

自由診療なので治療費は高い。麻酔をするのでレーザーでの患部の切除は痛くないが、麻酔そのものがすごく痛い。症状が進行していたため一度の治療では完治せず、1ヶ月ごとに再治療が必要な状況だ。とはいえ足を引きずらなくても歩けるようになり、腰痛も偏頭痛も解消したので本当に助かった。普通に歩けるって素晴らしい。

昨年の暮に医療情報のキュレーションメディアの問題が話題になったが、医療や健康に関する情報はそもそもネット上に参考になるものが少ないと思う。同じような症状で困っている人に向けて、自分が経験した問題と解決方法を一例として記しておく。