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

— 今回は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とブログの違いはありますか？

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

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

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以外からの起案が採用されたものです。

「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点を改善する必要がある。例えばこんな風に日常の会話でも理屈やKPIツリーを考えてしまう面倒くさいタイプの人間です。

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

読書メモ: 教育者のための「計算論的思考」入門ガイド

先日発売したComputational Thinking(CT、計算論的思考)の入門書を早速購入。著書の一人は以前このブログでも紹介したキキ・プロッツマン氏。 

Computational Thinking and Coding for Every Student: The Teacher’s Getting-Started Guide

• なぜCTが必要なのか
• Computer Science(CS)との違いは何か
• ExcelやWordの使い方を習うのはCTではない
• CTの基本4要素、Decomposition、Pattern Recognition、Abstract、Automation(Algorithm)とは

などが平易に解説されている。うちの娘の小学校にもコンピュータークラスがあるのだが「パソコンの使い方」の域を出ていない。日本におけるCT普及のためにも日本語版をぜひ出して欲しい。

CTの4要素はエクササイズがいくつか用意されていて実際に子供に教える際に参考になりそう。ただ大人に教えようとするともう少し日常的な課題や実務につながるような例が欲しいところ。

CTとはいわばコンピュータを使って問題解決をするために必要な考え方。ソフトウエア領域でプロダクトマネジメントに関わる人にとってはシステム思考と合わせて必ず身につけるべき思考法だと思われる。

読書メモ：スノーピークのプロダクト開発とマネジメント

アウトドア・ブランドのスノーピーク、山井社長による著書。 

スノーピーク「好きなことだけ！」を仕事にする経営

  「私達は自らもユーザーであるという立場で考え、 お互いが感動できるモノやサービスを提供します」

これはスノーピークのミッション・ステートメントに含まれる一文だ。

社長自身が熱心なアウトドア愛好家であり、プロダクトの企画には社長である著者自身が全て目を通す。ユーザーとして使いたいと思わないプロダクトの企画は承認しない。
著者自身が本書中で尊敬する経営者としてスティーブ・ジョブズを上げているが、かつてのAppleと同様に社長自身が大プロダクトマネージャーとしてプロダクト開発の舵取りをするタイプの企業のようだ。

ユーザーから価格の高さと販売店での品揃えの悪さを指摘されたのをきっかけに、問屋経由から直接取引に変更して流通コストをカット。さらに品揃えやショップ体験の改善のため、全国に250店の正規代理店網を構築する。

スノーピークはユーザー同士のつながりの強いコミュニティブランドで、本書中では類似ブランドとしてハーレーダビッドソンがあげられている。高価格商品である、コミュニティブランドである、ショップ体験を重視する、ユーザーイベントを定期開催する、ファンによるクチコミが新規顧客を増やす、など色々とハーレーと共通するものを感じる。

本書を読んで、スノーピークのテントをバイクに積んでキャンプに行ってみたくなった。今年の夏に挑戦してみようかな。

読書メモ：Harley Davidson Japan（HDJ）のマネジメント

昨年、10数年ぶりにバイクに乗ったところ思いのほか楽しく、勢いで大型二輪の免許を取得してしまった。ドラマ「Beautiful Life」でTW200に乗るキムタクに感化されて普通二輪の免許したので、教習所は15年ぶり。以前乗っていたのが120kg程度のFTRだったこともあり、200kgを超える大型の重量になかなか慣れなくて苦労した。（ちなみに普通二輪免許を持っていれば、12回の実技教習/10万円程度で大型二輪の免許が取れる）

そんな経緯で大型バイクを色々と物色しているなかで、Harley-Davidsonの正規販売店を訪問した。店舗の雰囲気はこんな感じ。

ガジェット好き向けに一言で説明すると、Apple Storeっぽい。バイク本体だけでなく、アパレルやグッズも販売していてすっごくオシャレ。

その場でハーレーを試乗。エンジン音と体に伝わる鼓動、軽くクラッチをつないだだけでずるずると前に引きずられるトルク感にぐっと心を鷲掴みにされた。実はハーレーは「革ジャンを来たアウトロー」のイメージが強くて、ファッション的にはDucati Scramblerに惹かれていたんだけど、販売店での経験ですっかり関心が移ってしまった。

興味を持った勢いで車体以外についても色々と調べてみたところ、Harley Davidson Japan（HDJ）のマネジメントがとても面白かったのでメモ。

日本におけるハーレーダビッドソンの状況

• 751cc以上の二輪市場におけるハーレーのシェアは24.2%で首位（2002年当時）
• モノを売るのではなくコトを売るライフスタイル・マーケティングを実践
• 二輪市場が縮小するなかで（1982年に328万台→2002年には77万台と減少）、販売台数を伸ばす（1982年に1099台→2002年には10,869台と10倍に）
• ハーレーオーナーの平均年齢は37歳を維持している。これはバイク保持者全体の平均年齢よりも10歳若い。若い層を新規顧客として獲得できており、ユーザーの高齢化が進んでいない

プロダクトについて

• ハーレーは実用ではなくレジャー用途のバイク
• オートバイを売るのではなく、ライフスタイルを売る
• ハーレーのプロダクトコンセプトは「Look,Sound,Feel」であり、「走る、曲がる、止まる」ではない
• ハーレーの耐用年数は50年以上。一生同じハーレーを乗り続けるオーナーもいる。買い替えではなくカスタマイズで売上を伸ばす必要がある。よって販売した後に顧客と関係を継続する必要がある。
• HOG（ハーレー・オーナー・グループ）というオンライン/オフラインのユーザーコミュニティ

マーケティング戦略

• HDJはマス広告を出稿しない。店舗とイベントを顧客接点として新規顧客を獲得している
• イベントはブルースカイヘブンを代表に年間多数開催。現オーナー以外も来場し、見込み顧客獲得の機会になっている。
• 付き添いでふらっと入店した客が一目惚れして購入を決めてしまうこともある
• 接点をもった見込み顧客の情報をDB管理してナーチャリングする。

HDJの販売店改革

• 元々バイク店の多くは町の自転車店だったため、以前は店内は薄暗く作業場のような雰囲気だった。
• ハーレーの価格は平均200万円以上する高級品。高級品を購入する雰囲気ではない。女性も入店しづらい。
• 「息子が店を継ぎたくなる、彼女を連れてきたくなる店に」
• リテールエンターテイメントを標語に販売店を改革。バイクだけでなくアパレルも販売。

HDJにおける営業部門の役割

• HDJの営業パーソンは販売代理店の経営コンサルタントとして、販売店の経営と業務の改善を指導する。
• HDJは販売店の財務諸表を把握している。
• 販売店を管理するSFAと、顧客を管理するCRMの二本立て
• 認知、来店、試乗、見積もり、購入のプロセスを管理する。
• 購入が少なければどのアクティビティを増やせばよいのか考える。
• 値崩れの原因となるため販売店に対してインセンティブマージンを設けない。

このメモは以下の書籍を元にまとめた。 

ハーレーダビッドソン ライフスタイル・マーケティング

ハーレーダビッドソン ジャパン実践営業革新

なぜハーレーだけが売れるのか (日経ビジネス人文庫 ブルー み 2-3)

 販売店での試乗で経験したのはまさに「Look,Sound,Feel」の体験。

そういえば通っていた教習所でもハーレーの試乗会が開催されており、確かにリアルな接点を意図的に作って新規顧客の獲得機会にしているようだ。

見積もり時はローンプランも提示して手に届く感を与える、「ハーレーはゆったり走って楽しむ乗り物」と説明して配偶者を安心させる、などの本で書かれていた通りの接客も経験したが、まさに狙いどおりの効果をもたらしていると実感したｗ

はてなブログでブログを書いているオーナーの方もいるが、とても楽しそう。

ケーススタディは当事者にならないとなかなか身にならないつまり仕掛ける側か顧客側かを経験すべきだからとりあえずXL883Nを買うことにした。

ちなみに883のデザインはダイス・ナガオさんという日本人が手がけている。こういう動画も僕から見るとAppleのジョニー・アイブのビデオっぽくってブランドとの距離が近づいてしまう。

www.youtube.com

Product Principles（製品の原理原則）とは

（この記事はProduct Manager Advent Calendar 2016の24日目のエントリーです）

Product Principles（製品の原理原則）とは、プロダクトの方向性を決める意思決定の基準となるものだ。Inspiredの13章で解説されているものを超ざっくり要約すると下記のような感じだ。

• プロダクトに関する信念や意図を宣言したもの
• トレードオフや優先順位の判断に役に立つ
• 機能リストではないし、具体性を持ったものではない
• 例えば映画サイトにおいて「映画コミュニティの意見は専門家のレビューより価値がある」という原則を定めたとする
• 制作会社から「専門家の映画評を載せたい」とリクエストされたときに容易に可否を判断できる 

Inspired: 顧客の心を捉える製品の創り方

 確かにプロダクトのコンセプトとしてターゲットや提供価値を明確にしていても、プロダクトマネージャーとして判断に迷ったり、チームの意見が割れたりする局面がある。

例えば、競合の新機能は評判が良いと聞いた、大口の見込み顧客から要望を受けた、といった状況で「際限のない機能追加の誘惑」にかられたりする。スポーツカーとファミリーカーとトラックの特徴をもった自動車を作るのは難しいが、物理的な制約がないソフトウェアの場合、「やらない判断」をせずに次々と機能を付け足していくことができてしまう。

そんな時は、「プロダクトが大切にすべきこと」が言語化されており、原理原則として共有されていれば議論になったり迷ったりすることなく判断できる。

こちらのスライドの説明もわかりやすい。

• 会社にはミッションステートメント（理念）がある。
• ただ交渉なミッション・ステートメントを具体的なプロダクトのあり方に翻訳するのは難しい
• 例えばEtsyのミッション・ステートメントは「より充実感があり持続的な世界に貢献するビジネスのあり方を再考する」
• 果たしてこのステートメントは、レビュー機能の設計指針を考えるのに役に立つか？
• Product Principlesはミッションステートメントを実践可能な形にするもの

具体的にこうした原理原則を定めているサービスの例を探してみたのだが、ちょっと適当なものが見つからなかった。

下記はGoogleのミッション・ステートメントだが、具体的でProduct Principlesに近いように感じた。

1. Focus on the user and all else will follow.
2. It’s best to do one thing really, really well.
3. Fast is better than slow.
4. Democracy on the web works.
5. You don’t need to be at your desk to need an answer.
6. You can make money without doing evil.
7. There’s always more information out there.
8. The need for information crosses all borders.
9. You can be serious without a suit.
10. Great just isn’t good enough.

下記の記事ではTrelloのProduct Principlesが紹介されている。

もう少しわかり易い例が見つかったらまたこのブログで紹介でしてみたい。

参考

下記はそれぞれFacebookとAsanaのDesign Principles（Product Principlesではない）。
▼ Facebook Design Principles
▼Developing Design Principles - Our Design and Product Experience Goals

Design Principlesについては下記のサイトで色々なサービスのものがまとめられていた。
▼ Design Principles FTW