娘のサマーウォーズ2017を振り返る
子どもたちの夏休みが終わった。
今年の夏休みは小学生の娘にとって特別な夏になったように思う。娘はこの夏、ある「施設」に入り浸っていた。所謂子どものためのMakers Labのようなところで、3Dプリンタやレーザーカッターなどの最新設備を自由に使うことができ、電子工作でもロボット工作でも、布細工づくりでも、ムービー制作でも、とにかく作りたいと思ったものをなんでも作れる場所だ。設備だけではなく機器の使い方を教えてくれるクルーが何人もいて、子どもたちの「こうしたい！」という自由な発想の実現をサポートしてくれる。企業とコラボしたワークショップも多数開催されている。
娘は文字通り毎日この施設に入り浸った。自分でお弁当を作って朝９時に入館し、施設がクローズする１８時まで家に帰ってこなかった。
もともと工作が好きで学校で一番好きな科目は図工、図工がある日は早起きするというぐらいものづくりが好きな娘にとって、この施設はまさに「夢のような場所」だった。（ちなみに夢のような場所というのは娘の表現そのままだ）
モーターとLEDを使って水力発電をする装置、などなんだか色々なものを毎日作っていた。
この夏に開催された施設主催のロボコンやデザインワークショップでは、それぞれ特別賞をもらうことができた。（毎度優秀賞は逃すのだが、発想が独特なので特別賞の対象になりやすい）
自分の発想で何かを作り、それを多くの人の前で発表し、さらに賞賛してもらう。これはたぶん娘にとって人生初めての経験だったと思う。
こうした経験を通して、娘は明らかに変わった。これまでと目の輝きが全く違う。好奇心に従って思いのままに行動すると子どもはこうも変わるのか、と我が子ながら驚いた。
娘は少し変わったところがある。興味がある事はに対しては非常に高い集中力と想像力を発揮するのだが、そうでないものはとことん手を抜く。というか側から見ると適当にやってるようにしかみえない。習字を習っているので丁寧に書けば綺麗な字が書けるのだが、興味のない課題だとミミズのような字で誤字脱字も多い。こうしたことが原因で学校の宿題をチェックした時などに度々親子で衝突することがあった。要は「もっとちゃんとやりなさい」という親が求めるクオリティに対してなかなかそこに到達しない。何を求められるのかピンときていないので「ちゃんと」と言われてもよくわからないのだろう。こんな娘を根気よく指導してくれている学校の先生には本当に頭が下がる思いだ。
そんな娘が個性伸ばせる場所を探して色々と模索してきた。絵画教室に通って見たものの、その時間はそれなりに楽しんでいるようだったがやや「お遊戯的」で、親としても娘としてもあまり意義を見いだせなくてやめてしまった。娘用のパソコンを買い、Scratchなどの初等プログラミングツールの使い方も教えてみた。そういえば一時期はマインクラフトにはまっていた。
うちの子はこういう方向なのかなと思っていたところで、娘が学校の友達から聞きつけてきたのがこの施設だった。今年の3月からオープンしていたらしいのだが夏休み直前まで存在を知らなかった。早速申し込んで参加して見ると娘は大興奮していて、まさにこの施設こそ娘が求めていた場所だと判明した。ちなみにこの場所を教えてくれた友達も個性的で独特の発想をする子のようだ。娘はこの子といつも連んで何か作ってるらしい。
この施設を運営するS社長の講演を聞いたがお兄さんの強烈さとはまた異なる独特の存在感、包容力を感じさせる方で、日本の子どもたちの未来を本当に真剣に考えてくれているようだった。
劇的に変化していく娘を見たことで、子どもの教育だけでなく、自分のキャリア観やマネジメントに対する考え方が変化しつつあるように感じる。
言葉にすると当たり前だが、人は個性を活かし夢中になれる環境でもっとも成長するのだ。そうした環境に自らを置くことができるのか、一緒に働くメンバーにそうした環境を用意できるのか。そんな事を頻繁に考えるようになった。
この施設のビジネスモデルの詳細はわからないのだが、どうやら子ども向けのSTEAM教材のR&D部門という位置付けのようで、施設で活動する子どもたちの反応を見ながら教材開発をしているらしい。事業としても実験的な取り組みであるように見えるし、ビジネス的に継続可能なモデルなのかよくわからないのだが、とにかくこの施設の存在に親として非常に感謝している。仮にこの施設が彼らの事業上の狙いを達成してクローズしたり移転することがあっても、娘はこの夏の経験を原体験にして、何年かかかっても自力でこうした場所を探し出したどり着くだろう。そのための主体的な努力ができるんじゃないかと思っている。
長々と書いたがこのエントリーで何を伝えたいかというと、とにかく施設のクルーの皆さんとこの場所を作ってくれたS社長に感謝したい。本当にありがとうございます。皆さんは未来を作る仕事をしています。
![サマーウォーズ スタンダード・エディション [Blu-ray]](https://images-fe.ssl-images-amazon.com/images/I/61T0u4O7KDL._SL160_.jpg "サマーウォーズ スタンダード・エディション [Blu-ray]")
サマーウォーズ スタンダード・エディション [Blu-ray]
- 出版社/メーカー: バップ
- 発売日: 2010/08/01
- メディア: Blu-ray
- 購入: 8人 クリック: 210回
- この商品を含むブログ (95件) を見る
『価値のインターネット』時代のプロダクトマネージャーへ
先日なにかと話題のVALUに登録してみました。
「プロダクトマネジメントの悩み聞きます（ただし話を聞くだけで悩みの解決はしません🤗 ）」という無責任な優待を公開してみました。現在公私ともに忙しく、時間が作れないので売り出しはしないかもしれませんが、もしこの記事をお読みの方でVALUユーザーの方がいましたらウォッチリストに追加いただけると嬉しいです。VALUerの皆さまを対象に、PM限定サロン、PMランチ会みたいな交流の場をつくる、など無形の価値を提供できたら面白いかも、といったことも考えています。
正直なところVALUについては公開された当初は若干懐疑的に見ていたのですが、時には利用者が想定外の使い方をしてトラブルを起こしながらも、ユーザーが使い方を発明しながらサービスの価値を向上させていくプロセスには、mixiやTwitterが現れた当初のようなユーザー主導の盛り上がりを思い出し、少しワクワクするものを感じます。
VALUの盛り上がりの背景には投機的な思惑を持った人が一定数集まっているという側面もありつつ、お金を持っている持っていないに関わらず、お金の使い道がないという人が増えているということなのではとも思いました。無料で手に入るものでおおよそ満足してしまい、あえてお金を払ってまで手に入れたいモノやサービスが身の回りに少ないということではないか、と。VALUのようなサービスを使う人は、著名人や志のある人に投資し、間接的に世の中を変える、影響を与えることで高次の社会的欲求を満たそうとしているのではないでしょうか。あるいはGoogleで検索すれば手に入る無料の情報では飽き足らず、対価を払うことでのみ得られる特別な情報、特別な経験を求めているのかもしれません。
VALUはビットコインを利用することで、「個人が株式会社のように価値をトレードできる」というコンセプトを実現しています。適法性についてはまだ色々議論の余地があるようです。小飼弾さんがリードエンジニアとしてVALUに参加したとのことで、これからさらなるサービスの発展が期待されます。
ビットコインを始めとする暗号通貨については、投機的な側面に注目が集まりがちだったり、犯罪者が使うアングラマネー的なイメージを持つ人が多かったりするので、身の回りで積極的には話題にすることは避けていました。ただ個人的には昨年から興味を持ちはじめ、技術仕様や歴史的経緯を学びつつ、ブロックチェーンや暗号通貨がもたらす社会的なインパクトについて考えています。
ガートナーが先日発表した2017年版ハイプ・サイクルでは、ブロックチェーンが過度な期待期から幻滅期に位置づけられています。
幻滅期を過ぎると、次は啓蒙活動期です。ということは、恐らくブロックチェーンを使ったアプリケーションがこれからいくつも現れるでしょう。これまで解決できなかったユーザー課題や社会課題を解決し、ビジネスが大きく変わる可能性が極めて高いと思っています。
メッセージングからペイメントへ
さて、LINEやSnapChatなどのメッセージングアプリが一世を風靡しましたが、ユーザーエンゲージメントの中心はメッセージングからペイメントにシフトしつつあります。中国ではキャッシュレス、スマホ決済が進み、屋台でもWeChat PayやAliPayを使って支払いができる、という話をよく耳にします。AliPayは日本でもサービスを開始するようです。
韓国のカカオトークのオンライン銀行業、Kakao Bankが5日間で100万口座を開設したそうです。国際送金のソリューションにRippleを採用するという噂もあります。
もちろんLINEも以前からLINE Payというペイメントサービスを提供しています。
KyashやPaymoなど、日本の法の枠組み内でVenmoのように簡易に個人送金を可能にするサービスも増えています。日本では銀行や消費者を保護し経済の安定性を維持するために、金融・証券についてはかなり厳密な法規制が行われています。個人送金サービスの壁は、AML（Anti Maoney Laundering）のためのKYC（Know Your Customer）、本人確認のプロセスが必要なことです。最近の個人送金系サービスがこのKYCの壁をどう回避しているのかについては、先日新しい発想の株式投資サービスをβ公開した株式会社FOLIO CDOの広野さんが、ブログで非常にわかりやすく解説しています。
友達に寄付（ファンディング）ができるpolcaというサービスも話題ですね。
Kyashで集金してpolcaで出金する、みたいないわゆる三店方式のような現金化のハックを考える人もいて、大人としてはちょっとドキドキしてしまいます。
CASHという「質屋アプリ」も「全力で振り切ったサービス」として話題になりました。
チケットキャンプがビットコイン払いに対応したそうです。チケットキャンプのユーザー層が果たしてビットコインを使うのか、とても興味深いです。そのうちメルカリもビットコイン払いに対応するかもしれませんね。
目先をBtoCからBtoBに変えると、マイクロソフトがAzure上でEthereumベースのブロックチェーンを容易に管理できるフレームワークを企業向けに発表しました。
カナダのブロックストリーム社がブロックチェーンを中継する人工衛星の稼働を開始したそうです。インターネットに接続できないが太陽エネルギーを得られる、赤道直下の砂漠のような場所で暗号通貨のマイニングや取引が可能になるのかもしれません。そういえばモトローラの衛生携帯サービスのイリジウムが過去に破綻したのでは、と思いましたが事業継承されてサービスが継続していました。技術革新によって衛星の開発や打ち上げコストが相当下がっているようですね。
何の話をしているのかよくわからなくなってきましたが、とにかくペイメントに関する技術やインフラ、そして法律が整備され、『インターネット越しに誰かに価値を送るサービス』がこれからも増えていくのでしょう。
Token Salesとユーザーエンゲージメント
ICO（Initial Coin Offering）という、企業が独自に暗号通貨を発行して資金調達を行う手法が話題になっています。
アイデアを簡単にまとめたホワイトペーパーだけでICOするケースも多いようで、かつてのドットコム・バブルを連想してしまいますが、AmazonやGoogleがインターネット・バブルを生き残って巨大企業になったように、ICOバブルから次世代の企業が生まれるのかもしれません。
ICOについては、下記のスライドが非常にわかりやすいです（この資料ではICOではなくToken Salesとあえて表現しているそうです）。Token Salesはプラットフォーマーから搾取される「小作人化したコンテンツ提供者」に適正な利益をもたらす、ということのようです。個人的には『通貨モデル』のAmazonの例がとてもわかりやすいと思いました。
Token Salesが本当にヤバいと思うのは、ポイントやバッジなどのサービス内でのみ流通していたゲーミファイ・リワードが、サービス外での経済的価値と結びつき、最強のエンゲージメント獲得システムになり得ることです。
例えばTwitterが独自Tokenを発行してユーザー間の送金を可能にしたらどうなるでしょう？実はこれはtipmonaというサービスによって既に実現されています。
tipmonaのような仕組みをTwitter自身が提供したら？もともとアットマークで他のユーザー宛にツイートするメンションの仕組みは、Twitterユーザーが発明した習慣が採用されたものなので、ありえないとも言えません。tipmonaはモナコインを送る仕組みですが、tipxrpというXRPを送るサービスもつい最近作られたようです。
例えば、Twitter広告（プロモツイート）の出稿にはトークンが必要で、ブランドのTwitterアカウントをフォローしたユーザーにリワードとしてトークンを配布可能にする、トークンは取引所で時価で売買される、そんな仕組みはどうでしょうか。広告主によるトークン需要により、Twitterトークンの価格は値上がりが期待されます。ユーザーはTwitterトークンを得るためにさらにTwitterを使うようになるかもしれません。既に大きなユーザーベースを持ったTwitterのようなサービスがこうした仕組みを採り入れたらどんなことが起こるのか、想像するだけでワクワクします。
メッセージングアプリのKikがICOでやろうとしているのは、そうしたトークンによるエコシステムの構築のようです。
▼ Kin: A decentralized ecosystem of digital services for daily life.
KikのICOについては日本語版のホワイトペーパーが公開されています。（ただちょっと堅苦しい日本語なので英語の方を読んだほうが理解しやすいかもしれません）
Kikは既に2億人以上のユーザーベースをもつチャットアプリです。サービス内のkikポイントによってスタンプを購入したり、アプリ内のブランドページをフォローするとkikポイントが付与される、といったアプリ内通貨、リワードの仕組みについての実験を過去に行い、実際に多くのポイント・トランザクションを発生させることができたそうです。このkikポイントをkinというサービス外の取引所で時価取引されるトークンにする計画があるようです。
評価経済とブロックチェーン
もちろんワクワクする未来だけが待っているわけではなく、多くのテクノロジーがそうであるように、使いようによっては人々の生活にネガティブなインパクトを与える結果になる可能性もあります。
VALUはソーシャルメディアのフレンド数などをもとにその人の経済的価値を算出する、といういわゆる評価経済の仕組みです。こうした個人のインターネット上の評価や信用情報が、ポジティブ情報もネガティブ情報もあわせてブロックチェーンで管理、共有されるようになるかもしれません。
飲食店の予約を無断キャンセルした顧客の電話番号を共有するサービスが論議を呼びましたが、サービス提供者側に切実な課題があることを考えると、個人の評価を共有するブロックチェーンが作られる、というのもあながち突飛な発想ではないように思えます。
AirbnbやUberなどに代表されるシェアリングエコノミーと、評価経済は地続きです。例えば車や部屋、時間をシェアするといっても信用度がわからない人にはシェアしにくいですよね。できれば信用度の高い人、評価の高い人にサービスを提供したい。そうすると、今はそれぞれのサービス内でのユーザーのレビュー（評価）が蓄積されていますが、いずれサービスを越えて個人の評価が共有されて、評判の良い人ほどより質の良いサービスをより安く受けられる、という世界になるかもしれません。
そもそも世の中というものは人と人との信頼によって成立しており、信頼による格差は既に存在するのかもしれませんが、今後はそれがより可視化され信頼のある人とない人の間で享受できる豊かさの格差がさらに拡大するかもしれません。ブロックチェーン上で管理されたグローバルなレビューシステム上で、未評価だったり評価が低い人は高いコストを払わないとサービスを受けられない、なんて時代が来るかもしれません。
『情報のインターネット』から『価値のインターネット』へ
ところで、デスクトップ用Safariの仕様変更によってクッキーによるユーザートラッキングが困難になりリターゲティング広告が表示しにくくなる、という記事が話題になりました。
ちょっと飛躍しすぎかもしれませんが、これはもしかしたら「無料のインターネット」時代の終わりの始まりかもしれないなと思いました。現在は広告で収益を得ることで無料でコンテンツやサービスを提供することが可能ですが、近い将来コンテンツ閲覧やサービス利用をするたびにごく少額の利用料を徴収するといったことが可能になり、広告モデルではなく超少額課金モデルがインターネットサービスの主流になるかもしれません。
なお、MITメディア・ラボ所長の伊藤穰一さんは「ビットコインは1989年くらいのインターネットなのかなと。まだ足場が固まっていないのに、いろいろ建ってしまっている。もうAmazonを作ろうとしている。」とおっしゃっているので、もしかしたらちょっと先走りすぎかもしれませんが。
Ripple社はIoV（Internet of Value）の実現をビジョンに世界中の銀行とコンソーシアムを組みソリューションの開発を進めており、「価値のインターネット時代のGoogleになるのでは」と期待する人もいるようです。
新しいインターネット時代の到来にそなえる
さて長々と書きましたが、要は『情報のインターネット』から『価値のインターネット』へのシフトが始まっており、私たちプロダクトマネージャーは時代の変化に追従できるよう基礎的な技術を勉強しておいたほうがいいのではないか、ということです。
インターネットサービスのプロダクトマネージャーである皆さんが、かつてWebサーバーやWebアプリケーションの基礎について学んだように、ブロックチェーンの基礎的な技術を学ぶべきタイミングだと思います。ビットコインやブロックチェーンについては縦書きの解説書がいくつも出版されているので読みやすそうなものを選んでまず読んでみてください。例えば大石さんの本はビットコインの仕組みがわかり易く説明されています。
ビットコインはどのようにして動いているのか？ ビザンチン将軍問題、ハッシュ関数、ブロックチェーン、PoWプロトコル
- 作者: 大石哲之
- 出版社/メーカー: tyk publishing
- 発売日: 2014/03/12
- メディア: Kindle版
- この商品を含むブログを見る
コインチェック大塚さんの本は群を抜いて分かりやすいのでお勧めです。
余談ですが、開発者コミュニティを中心に完全な非中央集権の金融システムの実現を目指すBitcoinの支持者と、 営利企業を中心に国際的な送金システムの実現を目指すRippleの支持者は、本質的に相性が悪いようでTwitterなどで激しく罵り合い論争を繰り広げています。彼らの侃侃諤諤とした宗教戦争論争を観察するのも暗号通貨の楽しみの一つです。（嘘です。すみません調子に乗りました）
個人的には技術者としての観点ではBitcoinが、マーケターとしての観点ではRippleがそれぞれ実に興味深いです。つまりプロダクトマネージャーとしてはどちらも非常に面白い、ということです。
初心者向けの本で概要をつかんだら、ぜひMastering Bitcoinを読んでみて欲しいです。僕は本書でBitcoinの技術的な設計の妙に心を奪われました。 コードがある程度読める人にとっては、技術に不案内な人向けにビットコインの仕組みをアナロジーで説明した本よりも、こちらの本の方がわかりやすいはずです。
日本語版は2014年に出版された原著を訳したもので、2016年に出版されています。原著はこの7月に2nd Editionが出版されました。先日のビットコイン分裂騒動の要点であるBIP-9やSegWit、Lightning Networkに関する説明が追加されています。簡易な英語で書かれているので初版の日本語版を読んだ後にぜひこちらも一読をお勧めします。
Mastering Bitcoin: Programming the Open Blockchain
- 作者: Andreas M. Antonopoulos
- 出版社/メーカー: O'Reilly Media
- 発売日: 2017/06/12
- メディア: Kindle版
- この商品を含むブログを見る
ビットコインが通貨としての信用を得るまでの歴史的経緯についてはデジタル・ゴールドが詳しく、読み物としても非常に面白いです。
本書を読むと、ハイパーインフレやデフォルトなど様々な出来事が奇跡的なタイミングでいくつも起こったことで、ビットコインが国家を越えた価値の保存手段として信用を獲得していった経緯がわかります。
さて、思いのままに書き綴ったので長々とややエモい文章になってしまいましたが、ブロックチェーンや暗号通貨、Token Salesが色々と面白いので、インターネットサービスのプロダクトマネージャーの皆さんはぜひ勉強しましょう、というお話でした。こちらからは以上です。
（予告）プロダクトマネージャー・カンファレンス2017を開催します
昨年の10月に第一回目を開催したJapan Product Manager Conferenceですが、第二回目を年内に開催予定です。去年と同じ実行委員メンバーで既にキックオフし、現在企画を詳細化してます。
こちら↓の画像は昨年の登壇者の皆さま。すごいです。第一回目にも関わらず非常に豪華なスピーカー構成で開催でき、多くの参加者にご満足いただいたカンファレンスとなりました。
昨年参加した方は、あの時あの場の熱狂と興奮がよみがえってきたのではないでしょうか。
さて、第二回目ですが下記のようなテーマでセッションを構成することを検討しています。
1. なぜ今プロダクトマネジメントか
プロダクトマネジメントが必要な理由や、プロダクトマネジメントは何かといった全体像の概観。
2. ユーザー理解（インサイトの発見、データ分析）
プロダクトマネジメントの目的の一つであるユーザー課題の解決には、当然ながらユーザー理解が不可欠。定性/定量の両面でユーザーを理解するにはどうすれば良いのか。
3. 良いUXをデザインする
ユーザー理解に基いて、実際にユーザーの課題を解決し良いユーザー体験を提供するために、プロダクトマネージャーとして知っておかなければならないことは何か。
4. 熱狂的チームを作る
プロダクトマネージャーはチームで成果を出す必要がある。創造性と生産性を兼ね備えた「熱狂的チーム」を作るにはどうすればいいのか。
5. 新しいテクノロジー
AI、ドローン、ブロックチェーン、IoTなどハイプ・サイクルでいうところの幻滅期を越え、実用フェーズに入ったテクノロジー。自社のサービスで活かす上でプロダクトマネージャーが知っておくべきこと。
6. PMの採用と育成
プロダクトマネージャーを必要とする企業が多い一方で、まだまだ少ないプロダクトマネジメント経験者。いかにしてPMを採用、育成すれば良いのか。
7. PMに期待するもの
エンジニア、デザイナー、あるいは経営者など、プロダクトマネージャーと共に働く人達は、プロダクトマネージャーに何を求めているのか。
8. ケーススタディ
新規プロダクト開発やグロースハックの具体的なケーススタディ。
はい、かなり盛りだくさんな内容です。どうでしょう？こんな内容のカンファレンスがあったら、すごく参加してみたくなりませんか？僕は参加したいです。
というわけで実行委員では現在、登壇を依頼する方のリストアップを行っているのですが、登壇候補についてはぜひ皆さまのご要望をお聞かせいただきたいと思っております。それぞれのテーマについて「ぜひこの人に登壇して欲しい」「この人の話を聞いてみたい」という方をお教えください。
候補の方はプロダクトマネージャーに限定しなくて結構です。また、プロダクトマネージャーの方から以外のアンケート回答も歓迎です。複数回ご回答いただいてもOKです。
実行委員一同、皆さまと共に良いカンファレンスを作りたいと思っております。ぜひご協力をお願い致します！
GEの復活とプロダクトマネージャー制
GEが「シリコンバレー式」の価値創造プロセスを取り入れる過程を取材して書籍化した本書。めちゃ面白い。
リーマン・ショックを機に金融業から製造業に回帰し、さらに「as a Service」化。断片的にニュース記事で見知っていたことがストーリーとして繋がって、ここまで本当にやったのかと感銘を受ける。レガシー産業をテクノロジーで刷新するxTechが注目されるようになって久しいけど、GEはまさに製造業をITで刷新している。すごく学ぶところが多い。
製品化まで5年かかる自社と、Bulid-Measure-Learnを繰り返して短期間でイノベーションを起こすシリコンバレーのスタートアップを比較して、GEはこのままでは滅びると危機感を持つ。そこから変化していく。リーンスタートアップやデザイン思考に学んでFastWorkという自社独自のフレームワークを作り、社内に浸透させる。
GEがIT企業として生まれ変わるために必要となった人材として、プロダクトマネージャーの話が出てくる。一部引用して紹介。
インダストリアルインターネットを実現するというミッションを達成するために、GEはそれまで社内に存在しなかった新しいタイプの人材の採用も始めた。それがソフトウェアの「プロダクトマネージャー」だ。
プロダクトマネージャーとはシリコンバレーのソフトウェア会社には必ず存在する職種で、ソフトウェア製品の機能を決定し、プログラム開発を指揮して、完成した製品を商品として市場に送り出すところにまで責任を負う。
（中略）
どのような機能を実現すれば本当に顧客を満足させられるのか、それを考えるのがプロダクトマネージャーの仕事だ。必要だと考えた機能が本当に実現できるかどうかを判断するのもプロダクトマネージャーの務めになる。
あのGEが導入したプロダクトマネージャー制、あなたの会社ではまだ導入していないのですか？😎
プロダクトマネージャーなんていらない？
プロダクト開発において「プロダクトマネジメント」は必須だ。ユーザー課題を解決できる、技術的/社会的に実現可能、経済的継続性がある（要は儲かる）、そんなプロダクトを定義して実現し、世に送り出すこと。ざっくり言うとこれがプロダクトマネジメントである。
一方で、「プロダクトマネージャー」という役割が必須かというと、それは状況に依る。明確にプロダクトマネージャーという肩書を持つ人間がいなくても、正しくプロダクトマネジメントが行われる開発プロジェクトだってある。
- 各メンバーのスキルの合計が、プロダクトマネジメントが正しく行われる上で必要なスキルセットを網羅している
- メンバーが自分の職能の領分以外のタスクを実行することを厭わない
- 職能が異なるメンバーが自律的にコラボレーションしている、もしくはコラボレーションを促進するリーダー役がいる
こんなチームだったらプロダクトマネージャーは不要か、かなり限定的な役割になるだろう。あるいは「今回は私がプロダクトマネージャーね」と持ち回り制になるかもしれない。僕が今所属している会社はそういう方向に組織が成熟していくんじゃないか、という気がなんとなくしている。現プロダクトマネージャーの人たちは、事業責任者だったりプロダクトマネジメントを開発チームに定着させるコーチのような役割に仕事が変わっていくのかもしれない。これは悪いことではない。というよりとても良いことだと思っている。
ホラクラシーという組織形態がある。上意下達式の意思決定が行われる階層型組織ではなく、意思決定が組織全体に分散されたフラットな組織形態のことだ。
ホラクラシー組織で意思決定が分散されるように、プロダクトマネジメントがプロダクト開発組織に分散していくケースが増えるのでは、と思っている。プロダクト開発組織の成熟度が増すに従って、プロダクトマネージャーの役割が縮小していく。
ホラクラシー組織は「課長」みたいな中間管理職っていらないよな、という組織だ。ホラクラシー組織の構成員には一定レベルの主体性やスキルが要求されると思われるし、ホラクラシーに移行できる組織ばかりではないだろう。だから当分の間「課長」は必要だ。同様にプロダクトマネジメントをチームで実行する組織がある一方で、そうでない組織もある。メンバーの仕事の範囲が職能の境界を越えないような組織だ（エンジニアはコードを書きたいし、デザイナーはデザインしたい、という組織）。そういうチームではプロダクトマネージャーが必要になる。
で、ここからが本論なんだが、プロダクトマネージャーの仕事は、「なりゆきだとプロダクトマネジメントが行われない組織」において、「プロダクトマネジメントが行われるようにすること」だ。そのためにはどんなスキルが必要か、ということを書こうと思ったんだが長くなったのでまた次回に。
モデリングしてますか？
インターネットサービスは非常に多くの要素が相互作用する複雑なシステム。システムの理解にはモデリングが必要だ。問題というものは定義しないと解決出来ない。同様にシステムはモデリングしないと振る舞いを変えられない。モデル化することでシステムの過去の振る舞いを説明し、この先何が起こるのか予測可能になる。
モデリングとは言わば抽象化。枝葉を取り除いて単純化し、システムの振る舞いを言語化、図式化、数式化する能力。僕は因果ループ図をよく使う。人によってはUMLなどを使うのだろう。
わかっている人には当たり前すぎて今更何言ってんだ？という話かもしれないが、「モデル化」という概念を理解しているかどうかは、筋の良いプロダクトマネージャーかどうかを分ける最初の分水嶺。安易に理系文系論にしたくないけど、文系の人にとってはここに最初の壁があると思っている。
モデルは現実世界を単純化したものであって、現実世界そのものとは異なる。人が関与しないコンピューターシステムはモデル=システムの振る舞いになるが、社会システムはそうならない。たまに経済学や経営学で提唱されるモデルに固執する人がいるが、現実世界が常に正。この前提が食い違ってると議論がややこしくなる。
プロダクトマネージャーに訊く #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経験やサービスの立ち上げ経験のある人がメンターになることが多いので、普段課題と感じていることに対して経験者からアドバイスをもらう機会にもなります。
— プロダクトマネジメントに関わる人にお勧めの本があれば教えてください。
リーンスタートアップやアジャイル関係の本は皆さん読んでいると思いますので、ちょっと別の観点の本をご紹介しましょうか。
「あなたのチームは機能していますか？」はサーバントリーダーシップやチームメンバー間のコミュニケーションについて学ぶことができます。ストーリー仕立てになっていて読み物としても面白い本です。この本は経営メンバーのチームワークに関する話なのですが、どうやってチーム内でコンセンサスを形成して強いチームを作るのかという点は、経営もプロダクト開発も共通です。
もう一つは野中郁次郎先生の「失敗の本質」です。第二次世界大戦のときの日本軍の失敗の原因を考察している共著の本なんですが、開発プロジェクトが失敗する原因とも共通する点が多く、とても面白い。
- 作者: 戸部良一,寺本義也,鎌田伸一,杉之尾孝生,村井友秀,野中郁次郎
- 出版社/メーカー: 中央公論社
- 発売日: 1991/08
- メディア: 文庫
- 購入: 55人 クリック: 1,360回
- この商品を含むブログ (293件) を見る
個人的にハイライトしたところからいくつか引用してご紹介しましょう。
日本軍ははじめにグランドデザインや原点があったというよりは、現実から出発し状況ごとに場当たり的に対応し、それらの結果を積み上げていく思考方法をとった。
日本軍が戦前において高度の官僚制を採用した最も合理的な組織であったはずであるにもかかわらず、その実体は、官僚制のなかに情緒性を混在させ、インフォーマルな人的ネットワークが強力に機能するという特異な組織であったことを示している
こまでやったのだからとか、この人がここまで努力したんだからその人のメンツをつぶさないでやらせてあげよう、といった日本的なメンタリティに流されて、組織の本来あるべき姿を無視してしまう、といったことが状態化していました。
日本軍の失敗の過程は、 主観と独善から希望的観測に依存する戦略目的が戦争の現実と合理的論理によって漸次破壊されてきたプロセスであった
要は問題に対して科学的なアプローチをせずに希望的観測に基いて行動してしまったのです。こうしたことは今日の日本企業でも起こっていることだし、スタートアップであっても起きてしまうことです。
— プロダクト開発プロジェクトのケーススタディとしても読むことが出来ますね。最後に記事の読者へのメッセージをお願いします。
ここしばらく、自社の仕事と並行して、プロダクトマネージメントの認知向上の活動をしています。私は、プロダクトマネージャーが日本を救うとさえ考えています。優秀なソフトウェアエンジニアは日本にも多くいます。ただ、お話したように、良い製品やサービスはエンジニアだけでは作り上げられません。プロダクトマネージャーのような人たちがエンジニアなどとともに、実際に使われる製品を作ることこそが日本に求められていることであり、さらには世界にも貢献していくことになると考えています。
— ありがとうございました。
