プロダクトマネージャーに訊く #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経験やサービスの立ち上げ経験のある人がメンターになることが多いので、普段課題と感じていることに対して経験者からアドバイスをもらう機会にもなります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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