プロダクトマネジメントが難しい7つの理由
企画の承認を得たら要件を整理して共有し、成果物レビューしてリリースされたらプロモーションを行う。言葉にすると簡単だけど、プロダクトマネジメントが一筋縄では行かない理由は何なんだろうか。
- 自分たちが提供できるもの、提供したいものを作ってしまう病（自社都合の引力）
- ユーザー要望の背後に潜む本質的問題を発見しなければならない
- 様々なステークホルダーがプロダクトに対して異なる理想像を描いている
- ユーザーは期待通りに都合よく動いてくれない
- 企画した通りに実装されることはない
- 実はプロダクトだけの問題ではない
あ、7つにしようとしたのに一個足りない。
真の顧客ニーズは何か、競争環境はどう変わるのか、何もかもが不確実で正解がわからない。そんな中で、とにかくPMはいろんな専門家の力を結集してプロダクトを作り、顧客に届ける必要がある。ただ専門家固有のメンタルモデルによるバイアスがあったり、専門家同士の共通言語がなかったりする。さらにはチームに特定のスキルセットが不足していたりもする。専門家同士のの橋渡しをしたり、時には穴を埋めたりといったことをする係がいないとうまく行かない。せっかく発見した市場機会を逃してしまうことになる。
そういう意味ではクロスオーバーするスキルを持ったメンバーで構成されたチームではPMの必要性は限定的かもしれない。
そんな議論に興味がある方はプロダクトマネージャーカンファレンスにぜひお越しください。
プロダクトマネージャーカンファレンス2016を開催します
おそらく日本初となる、プロダクトマネジメントをテーマとした大型カンファレンスを10月に開催します。私も9人の実行委員の一人として企画に参画しております。
先日、登壇者の情報を一部公開しましたが、皆さん第一線で活躍する著名な方々です。
また、第一回目という開催実績のないカンファレンスにも関わらず、多くに企業様に協賛いただきました。非営利のイベントながら、参加者の皆さんの負担を減らしつつ豪華なイベントにしたいと考えており、ご支援ご協力いただいた皆様には実行委員一同本当に感謝しております。
企業の壁を超えたノウハウ共有を促進したい、現場で奮闘するPMを応援したい、企業経営に関わる方にプロダクトマネジメントの重要性を認識して欲しい、プロダクトマネージャーの社会的地位を向上させたい、そして世の中に良いプロダクトが生み出される環境を作っていきたい、などなど様々な思いを込めて企画したイベントです。ぜひ多くの方にご参加いただけると嬉しいです。
プロダクトマネージャー・プロダクトオーナーのためのイベントと銘打ってますが、現在の肩書きや役割に関係なく、良いプロダクトを作ることに関心のある方なら誰でもご参加頂けるイベントです。
「プロダクトマネージャーとして専門性を高めたい」
「顧客に愛されるプロダクトを作れるプロダクトマネージャーになりたい」
「これからプロダクトマネージャーを目指したい」
という方はもちろんのこと、
「コードを書くのは大好きだが、プロダクトを作るのはもっと好きだ」
「良いプロダクトを作れる開発チームにしていきたい」
というエンジニアやデザイナーの皆さんも歓迎です。
また、
「どうすれば市場機会をプロダクトとして狙い通り現実化できるのか」
「プロダクトドリブンの事業運営をするためには自社に何が足りないのか」
とお悩みの経営者や事業責任者の方も是非ご参加ください。
さあ、始めよう日本のプロダクトマネジメント！
プロダクトマネージャーに訊く #7：シャノン堀さん
― 堀さんご自身について教えてください。
株式会社シャノンのCTOの堀です。技術部門のマネジメントをしています。
開発のディレクションと製品企画のディレクションを両方担当していますが、製品企画のほうがウェイトが大きく、7割ぐらいの時間を製品企画側の仕事に費やしています。どんな製品をつくるべきか、どういうプロジェクトチームでいつまでにリリースするのか、といったプロダクトマネジメント全般を他のプロダクトマネージャーと一緒に行っています。
― プロダクトの開発体制を教えて下さい。
現在シャノンの社員数は150人ほどですが、開発部門はQAチームを含めて約25人、インフラチームが約5人、プロダクトマネジメントを行う製品企画チームが4人、といった構成です。上海にも開発拠点があります
プロダクトマネージャーは各スクラムチームのプロダクトオーナーの位置づけで、要件の優先順位の決定やスプリントのレビューを行っています。私自身は各プロダクトマネージャーをフォローしつつ、個別の開発プロジェクトを俯瞰した製品戦略を考えて、MRD（Marketing Requirement Document）を整理するような役割をしています。
テクニカルな内部仕様は開発マネージャーやエンジニアが作成します。設計の方向性が大きく異ると感じた時は指摘しますが、基本的には開発現場に任せており、私はプロダクトマネジメントに時間を割いて製品の競争力強化のプランニングに注力しています。
MBAセミナーで意気投合、大手外資から15人のベンチャーに
― シャノンに入社する前はどのような仕事をされていたんでしょうか？
シャノンには約10年前の2005年の末に入社したのでが、その前は新卒で入社した日本オラクルでエンジニアをしていました。最初の数年は国際化のQAエンジニアを担当して、その後、アプリケーションサーバソフトの不具合に関するエスカレーションをハンドリングして修正パッチを書く、といった仕事をしました。外資系のソフトウェア企業の場合、製品に不具合があって顧客が困っていても本社以外では不具合を修正できないことが多いんですが、日本オラクルの場合は国内のエスカレーション対応部隊がコードを書いて問題を解決することができました。
その時の得たオラクル本社のソフトウェア開発手法とWebアプリケーションのバックエンドの技術的な知識はシャノンに転職してからもすごく役に立ちました。
― ミドルウェアの外資ベンダーから、マーケティングソリューションの会社に移ろうと思ったきっかけは何だったのでしょうか？
より製品開発のコアに関わる仕事をしたいと考えるようになったのです。オラクルでは不具合を改修するパッチを書くことは出来ても、製品そのものを開発するためにはアメリカにいかなければなりません。シリコンバレーのオラクル本社に行くか、日本でベンチャー企業に転職するか、など色々と考えながら情報収集をしていました。当時B2Cでは楽天やライブドアなどのWebサービスのサイトが一般的になってきており、「これからはB2Bでもパッケージ・ソフトではなくWebサービスの時代だ」と思っていました。
また、技術だけでなく経営やビジネスにも興味を持ち始めていて、MBAをの取得も検討していました。ただ、数年間大学院に通うための時間的金銭的コストを回収できるだろうかという懸念もありました。そこで、まずさわりだけでも勉強してみようと思い、MBAで得られる知識の一部である企業価値評価に関するセミナーを見つけて、1泊2日で参加することにしました。
そのセミナーでたまたま隣に座っていたシャノンの現CFOの永島と意気投合して、シャノンに入社することになりました。まだシャノンは15人くらいの会社で、まだクラウドやSaaSのような言葉もなくASPと呼んでいた時代です。「自社でイベントやマーケティングのソリューションをASPで提供していてる。エンジニアも7、8人いるから一緒にやらないか」と誘いを受けて入社することにしました。
― 外資系の大企業から15人のベンチャーに飛び込むことに不安はありませんでしたか？
特に不安はありませんでしたね。グローバル企業で働くなかで、日米でエンジニアのスキル差を感じることはありませんでしたし、トップオブトップのエンジニア達の概念設計スキルは別として、個別のコーディングスキルは日本人のほうがクオリティ高いし負けている感じはしない。うまくやれば海外の企業にに負ける要素はない、と当時思っていました。それは今でも変わりません。
シャノン入社直後は、プロジェクトマネージャーとしていくつかの案件を担当して開発プロジェクトのマネジメントを行っていました。当時は代表の中村がまだ自らコーディングしていたんです。中村がコーディングせずに社長業に専念できる体制をつくるのが最初の役割でした。
以来、開発プロジェクトのマネジメント、開発部門の組織づくり、製品の戦略やコンセプトづくり、仕様策定などを継続して行っています。
― 役割がエンジニアリングからプロダクトや組織のマネジメントにシフトしていくあたって、苦労した点はありますか？
オラクル時代に製品をゼロから作ったり大きな機能追加をしたりという経験があったわけではないので、色々と苦労はしました。特に「企画して開発してリリースする」という製品開発のプロセスと、「世の中に製品を知ってもらって販売する」という営業・マーケティングのプロセスのバランスをとりながら仕事を進めていくのが難しかったですね。今でもここは大きな課題だと思っています。
最初からマーケット・トレンドを広くとらえながら戦略的に製品を企画できたわけではなく、とにかく目の前のお客さんの要望に応えながらどうユーザーを増やしていくかを考えていました。現実的な目前の話と、抽象的な概念の話を行き来しながらあるべき方向性を見出していく、という行為をひたすら繰り返してきました。
再現性の高いBtoBマーケティング活動を実現する
― シャノンさんの製品について教えて下さい。
マーケティングオートメーションを軸とした、マーケティング統合環境を提供しています。マーケティングオートメーション製品はたくさんあるのですが、弊社の場合は展示会などのイベント管理ソリューションから発展した製品のため、オンライン・マーケティングとオフラインのイベントやセミナーを統合的に管理できるのが特徴です。
日本ではイベントやセミナーを重要視する顧客がとても多く、マーケティング活動をオンラインだけで完結できません。むしろオフラインのほうがビジネス上重要だというケースも多くあります。そうした企業様の課題を解決するソリューションを展開しています。プライベートショーや大規模展示会のバックエンドとしても利用できるのが特徴です。
また、BtoBマーケティングで効果をあげるには、ITシステムに加えて営業とマーケティングの組織改革をセットで考える必要があり、ITソリューションとコンサルティングの提供を同時に行っています。
我々は「マーケティング・イズ・サイエンス」というミッションを掲げており、再現性の高いマーケティング活動の実現を目指しています。BtoCを中心としたオンライン・マーケティングは定量的に効果測定をしやすくなり再現性が高くなってきていると思いますが、オンラインとオフラインを統合する必要があるBtoBマーケティングについては、まだまだケースの数も不十分で再現性が高い手法が確立しているとは言えない状況です。
どうすればデータ・ドリブンで再現性のあるモデルを構築して顧客にマーケティング・ソリューションとして提供できるのか、これが私たちのプロダクト開発の中心テーマです。
― 競合サービスとの違いを教えて下さい。
例えば、北米のマーケティング・オートメーション製品の場合、企業と顧客が地理的に離れていることが前提となっています。メールやサイトで資料請求を受け付けて、Webinarでサービス説明をして、ビデオチャットや電話で商談を進める、といったようにオンラインでマーケティング活動や営業活動が完結することを想定した設計になっていることが多いのです。
一方で人口密度が高い日本の場合、セミナーを開催して参加者の名刺を収集し、すぐに営業担当が見込み顧客を個別に訪問して詳細な説明を行う、といったように商習慣やプロセスが全く異なります。マーケティングの効果測定をするためには、そうしたオフラインの活動を含めた活動をトラッキングする必要があります。
私たちの製品は、セミナーの申し込みフォームを作成する、顧客リードに対してメールを配信する、営業担当者の営業活動によってセミナー参加者を獲得する、といったプロセスをトラッキングし、最終的にどれくらい商談に結びついたか分析できる仕組みになっています。
Webサイトやメールなどオンラインのアクティビティと、セミナーや名刺交換などのオフラインのアクティビティを統合してトラッキングできるのが我々シャノンのサービスの特徴です。オンライン広告のアトリビューション測定と同様に、オフライン活動の売上貢献度の測定も誰もができるようにしたいと考えています。
また、海外ベンダーのサービスは「マーケティング・オートメーションはこうあるべき」というベンダー個別の思想にユーザーが合わせるものが多いのですが、弊社の場合はあるべき姿を示しつつ、現状の業務プロセスに適応できる柔軟性をシステムに持たせています。
マーケティング・サイエンスの最初のステップは、結果を数値で見るようにすることです。実はBtoBマーケティング活動の成果について、KPIをしっかり定義できている企業はまだ少ないんです。KPIを定義して測定し、マーケティング活動の内容と結果の因果関係が明確になり、そして最終的にマーケティング活動を自動化する、という３つのステップを順番にクリアしていく必要があります。
― お客さんはマーケティング部門の方が多いんでしょうか？
マーケティング部門以外の方も多いですね。例えば営業部門や経営企画、新規事業部門などの方も多いです。私たちの顧客企業に関わらず、一般的に「10年以上マーケティング担当をやっています」というような方は少数です。「去年までは営業部門にいて、今年から異動でマーケティングを担当することになった」といった方がマーケティング部門には多いのです。BtoBマーケティングのソリューションは、そういった方でも使いこなせるプロダクトであることが求められます。
BtoBマーケティングは、リストにメール配信して終わりではありません。営業と連携してターゲット顧客の定義の認識を合わせながら、成果に結びつくようパイプライン管理する必要があります。そうしたあたりまえのプロセスをきちんと回して結果を出せるようにするのが我々のソリューションです。
ものが売れない時代だと言われて久しいですが、製品を作って営業をすれば売れた高度経済成長期とは違って、プロダクトの価値を正しく伝えて、ソリューションとそれを求めている人を正しくマッチングすることがとても大事です。それができれば企業は新規市場を開拓できて利益を生むことできます。
― BtoBマーケティングにはIT化されていないプロセスが多そうですね。
はい、BtoBのマーケティング活動には、まだまだ人的労力を必要とする部分が多いのです。例えばセミナーを開催するためには、会場の確保、顧客リストを抽出、案内メールの配信、申し込み管理、など様々なタスクの実行が必要です。担当者がそうしたオペレーションで精一杯になり、イベントを開催することが目的化してしまいがちです。その結果、頑張ってセミナーを開催して100人集客したにも関わらず、営業担当からみると全く価値の無いリードになっている、といったことも往々にしてあります。セミナー開催後に営業担当が個別にアプローチしても全く響かない。求めていないソリューションを営業されるお客さんも迷惑ですよね。労力をかけてすごく頑張っているのに誰もハッピーにならない。
オペレーショナルな部分の労力を最小限にすることで、「誰に何を伝えるべきなのか」という本来やるべきマーケティングのコアな部分に注力できるようにすることで顧客が利益を生み出せるようにすることが、一番大事な我々のミッションだと思っています。
顧客のペインポイント、課題を抽出する
― 顧客の課題が解決できるよいプロダクトを作っていく上でどのような工夫をしていますか？
まずは顧客のペインポイントは何か、本当にしたいことは何なのかを理解することです。お客さんと話す時でも、社内で議論するときでもありがちなのが「こういう機能を追加して欲しい」という機能の話が中心になってしまうことです。何を作るかではなく、その機能が必要な理由、顧客が抱える課題の話にフォーカスするように注意しています。
プロダクトマネージャーに相当する人が不在で、事業側の声が大きい人の意見に引きずられていたり、逆に開発チームだけで閉じてしまっているプロジェクトはうまくいかないですね。そうしたプロジェクトでは、どんな機能が必要かという話ばかりが先行していて、なぜユーザーはその機能が必要なのか、ビジネス上のどんな必要性があるのかが曖昧なまま開発が進行してしまう。
また、「本当にお金を払ってまで解決したい課題なのか」を問うようにしています。お金払ってまで解決したいのかどうかで、痛みの深さを大別できます。解決しないとビジネスが回らないほどの課題なのか、今よりちょっとベターになるという程度の話なのかに分類することで優先順位を検討しやすくなります。
― 機能要望から課題を特定するためにはどうすればいいんでしょうか？
単純に「なぜ」を繰り返すことです。その機能がなぜ必要なのか、社内で要望を出した営業担当もわからない、実は要望元のユーザーも言語化できていない。ユーザーの上長に確認して初めてわかる、ということもあります。
顧客へのインタビューを行って、営業スキームや営業部門とマーケティング部門との関係性、部門ごとの課題、サービスの利用状況、などビジネス・プロセスや組織構造の全体像を紐解いていく必要があります。組織的な課題に目を向けることで、要望の背景を理解することができます。
例えば「このデータをCSVで出力できるようにして欲しい」といった要望があった時には、「出力して何をするんですか？」と聞くと、「CSV出力してExcelで集計した結果を営業に渡したい」といったデータ出力の目的がわかります。であれば、営業担当に直接データを共有できるようにしたほうがいいですよね。最終的に実施したいアクションに直結する機能を提供したほうが業務効率がアップします。
全ての要望に対してそこまで深くヒアリングできないので、推測で進めることも多いのですが、課題に関する仮説をたてて仕様やコンセプトを決めることが重要です。
― 堀さんが直接お客さんにヒアリングされることも多いのでしょうか？
はい、定期的に既存顧客へのヒアリングをするようにしています。組織が小さかった頃は商談やアフターフォローに同行することが多かったんですが、最近はそういう機会が減ってきたので、意識して顧客訪問の機会を作っています。
― ヒアリングはどのように進めているのでしょうか。
顧客インタビューについてはAtrasianで利用されているフォーマットが参考になります。
このフォーマットでは、観察結果の伝達、問題の解釈、機会への接続、という３つの項目にわけてインタビュー結果を整理します。
私がインタビュアーになってお客さんに質問して、同行した製品企画部のメンバーがフォーマットに基いてヒアリング結果を整理します。毎回とても気づきが多いですね。自分たちの製品が実際にどう使われているのか、実際の利用シーンでどのような課題があるのか、具体的に見えてきます。
― BtoB製品の場合、営業担当から「大手のA社がこの機能があれば買うと言っている」といった機能追加のリクエストが出ることも多いと思いますが、そうした案件固有の要望に対してはどのように対応していますか？
以前はそうした機能要望にも対応するようにしていたのですが、最近は機能追加をすれば売れるというような案件はすごく減ってきていますし、営業提案でカバーできるものについてはそうしてもらうようにしています。もちろん、大手顧客からのリクエストが他の顧客にも大きく役立つ場合などは前向きに検討しますが、それよりもBtoBマーケティングのあるべき姿を強く打ち出せるような、メッセージ性のある戦略的な機能開発にウェイトが移ってきています。
プロダクト発表イベントから逆算して発想する
― ユーザーヒアリングによって様々な課題が抽出されると思いますが、そこからどのように製品コンセプトに落とし込んでいくのでしょうか。どうやって着想を得ていますか？
最近弊社のプロダクトマーケティング担当が取り入れているのがキーノート・ドリブンの発想法です。例えば1000人の前でプレゼンをするとしたら、どういうビジョンや機能だったら聞き手に響くだろう、と想像して実際に発表資料を作ってみます。冒頭で社長がプロダクトの思想やビジョンを発表して、その後に自分が機能の詳細を説明してデモをする、という具体的なシーンを想像してみます。どんなプロダクトだったら聴衆にインパクトを与えられるだろう、というところから逆算して発想するのです。
Amazonでは製品開発の前にプレスリリースを最初に書く、という話を聞いたことがあるかもしれませんが、それと同様の手法ですね。
プレスリリースでも一度試したことはあるんですが、日本の典型的なプレスリリースのフォーマットだとイマジネーションがわきにくい。キーノートの方が「なぜこのプロダクトが顧客にとって重要なのか」というストーリーを整理しやすいですし、作り手であるエンジニアにもビジョンを共有しやすいと感じています。既存機能の改善ではない、大型の新機能の企画の際にこのやり方をしています。
― 着想を得た後は、どのようなプロセスで製品企画を進めていますか？
製品企画は2ページ程度のMRD（Marketing Requirement Document）からスタートします。Inspiredという書籍で「プロダクトに関する10の質問」という、なぜ今このプロダクトを作るのかを問うチェックリストが紹介されています。
- 製品化によって具体的にどんな問題を解決するのか？ (バリュープロポジション)
- だれのためにこの問題を解決しようとしているのか？ (ターゲット市場)
- 市場の大きさは？ (市場規模)
- 製品化の成功をどうやって評価するのか？ (指標、収益戦略)
- 現在、他に競合する製品はあるか？ (競合の見通し)
- なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか？ (差別化要因)
- なぜ今なのか？ (市場投入の時期)
- どうやって製品を市場に出すのか？ (市場投入戦略)
- 成功のために絶対に必要な要素は何か？ (ソリューションの要件)
- これらを前提とした上で、最終的な提案は何か？（やるかやらないか）
このチェックリストを基にしたMRDのテンプレートを作りました。なぜやるのか、なぜ今か、どの市場向けか、ターゲットユーザーは誰か、開発コストはどれくらいか、といった項目を整理してMRDとしてまとめます。MRDをベースにビジネス的に価値がある企画なのか、経営陣と営業部門、マーケティング部門の責任者、そしてプロダクトマネージャーで議論します。
MRDが承認されたら、ユーザーストーリーの整理や画面設計を行って要件定義をし、アーキテクチャの概要を検討して開発スケジュールのアウトラインを作成して、PRDとしてまとめます。PRDが承認されると初めて実装に着手できます。
以前はMRDを作る前に数十ページに及ぶPRD（Product Requirement Document）を作成していたのですが、最初の一歩を間違えると、また数十ページのドキュメントを書きなおす必要がありました。まずMRDを作成することで、やるかやらないのかの意思決定を短期間でできるようになり、PRD作成の手戻りも無くなりました。
また、プロダクト開発とビジネスを網羅的に考えるフレームワークとして、プラグマティック・マーケティング・フレームワークを使うこともあります。
The Pragmatic Marketing Frameworkより
横軸にストラテジーとエクセキューションの軸があって、上下にボックスが積み上がっていますが、上側がプロダクトマーケティング寄り、下側がプロダクトマネジメント寄りのタスクやプロセスになっています。これをチェックリストとして使うことで、バイヤーペルソナを考えたか、重要な販売チャネルを忘れていないか、デモサイトは用意したか、といったようにマーケティング活動の抜け漏れを確認できます。
― かなりプロセスが整備されているように見えますが、これからより強化したいポイントはありますか？
いくつかありますが、プロダクトが完成した後のプロモーションを企画の初期段階でどう詰めるか、という点はまだ試行錯誤しているところがあります。外向けのプロモーションもそうですが、弊社の場合は営業担当がサービスを販売するので、インターナルのプロモーションも重要です。リソースが限られているなかで、営業担当に新しいプロダクトや機能の魅力をどう伝えるか、企画の初期段階からどう巻き込むか、という点が手薄になりがちなので注意しています。
ゴールイメージを共有し、要件と技術的制約の妥協点をエンジニアと共に探る
― PRDを作成した後のプロセスで気をつけるべき点はありますか？
「プロジェクトだけを見て、プロダクトを見ていない」という事態にならないように注意をするようにしています。プロジェクトの進捗だけ報告を受けて、忙しさにかまけてプロダクトのレビューを怠ってしまい、蓋を開けてみたら想定と全然違うプロダクトになっていた、といった事態は避けたいものです。スクラムを導入していますが、最低でも週次でスプリント・レビューが必要です。
レビューをするのはプロダクトマネージャーだけに限る必要はありません。第三者が定期的にプロダクトを確認することでプロダクトの完成度が大きく変わります。開発に一定のリズムを作って、実際のモノを見るタイミングを作ることが大事です。
― 企画と最終的なアウトプットのずれが生じてしまうのはどうすれば避けられるのでしょうか？
最終イメージを文字面ではなくビジュアルで合意することですね。PMとエンジニアが同じ景色を共有できるようにする努力する必要があります。
エンジニアと企画サイドは言語に違いがあるので共有するのは難しいのですが、ゴールイメージを極力具体的なビジュアルに落として、同じ風景を見るようにすれば、レビューが少なくてもうまくきます。ただ、開発体制が大きくなってくるとそれもだんだん難しくなってきますね。特に弊社の製品はBtoBマーケティングのソリューションですから、エンジニアからすると製品の良し悪しの基準がわかりにくい。自分自身がユーザーになりうるECサイトのようなBtoCサービスであれば、「こういうカートは使いづらいだろう」と自分のユーザー体験をベースにあるべき仕様の議論がしやすいのですが、BtoB製品の場合はそれが難しい。だからこそ具体的にゴールイメージを共有する必要があります。
― エンジニアにゴールイメージを伝える上で、どういう点に注意すればいいでしょうか。
PMが仕様を噛み砕き過ぎてしまうと、エンジニアが「なぜ作るのか」を考えて創意工夫する余地がなくなってしまい、受託開発のようになってしまいます。要件を伝えて仕様はできるエンジニアに限り考えてはもらうようにしています。ただケースバイケースですね。PMが詳細な画面設計までしてしまうこともあります。いずれにしても、なぜやるのか、ビジネス上どんなメリットがあるか、という開発の趣旨をエンジニアが理解できるように気をつけています。
― ゴールイメージを共有した後のPMの仕事は？
要件を満たす上で技術的な課題がある場合は、PMはエンジニアと一緒に妥協点を探る必要があります。ビジネス側の理屈だけで要件を押しつけると、開発する側に負荷がかかって製品開発は滞ってしまいます。
また、将来の拡張性のために抽象度を上げて設計した結果、開発工数が増大してしまう、というのはソフトウェア開発でありがちな失敗です。技術的な観点ではすごく良い仕組みだったとしても、その「将来」というのはたいていの場合予期せぬ違った形で訪れます。会社の戦略を考えると確かにその拡張の可能性はある。でも往々にして次のプロジェクトでは方針が変わって別の要件の優先度が高くなり、拡張するより作りなおしたほうが早い、ということになってしまう。そうした過剰な開発をしないようにPMは開発チームと共に気をつける必要があります。
― どうすれば過剰な作りこみを避けられますか？
開発マネージャーには、今必要な要件にフォーカスをきっちり合わせよう、ただ変更はできるようにしておこうと話しています。抽象度を上げて拡張性を高めるのではなく、CIやテストの自動化によって変更に強い仕組みやアーキテクチャにしておこう、と。
これはシステムの設計上の話だけではなく製品企画も一緒です。「この機能は将来お客さんが必要になるかもしれない」という「いつか使う」系は大抵失敗しますね。
BtoBのインターネット・サービスはこれから益々面白くなる
― PMを目指す人にお勧めの本を教えて下さい。
シャノンに入ってすぐに読んでとても勉強になったのが、「売れるもマーケ当たらぬもマーケの22の法則」という本です。
- 作者: アルライズ,ジャックトラウト,Al Ries,Jack Trout,新井喜美夫
- 出版社/メーカー: 東急エージェンシー出版部
- 発売日: 1994/01
- メディア: 単行本
- 購入: 17人 クリック: 250回
- この商品を含むブログ (61件) を見る
マーケティングというのは、製品機能の戦いではなく、商品の認知をめぐる戦いである。ユーザーのマインドシェアを何％獲得できるかが重要だ、という内容の本です。私はエンジニア出身なので、製品企画に関わり始めた時はマーケティングの知識が不足していました。4P（Product/Price/Promotion/Place）のような基本的な用語を聞いたことはある、という状態でした。この本はマーケティングについて学び始めた時に最初に読んだ本で、マーケティングの本質的な部分を理解するのに役立ちました。
定番ですが、プロダクトマネジメントについては「Inspired」は参考になります。その他には、「キャズム」「イノベーションのジレンマ」「エクセレントカンパニー」などはPMとして一度は読んでおいたほうがいいと思います。
本ではありませんが、新しい概念を学ぶ時にはSlideShareが便利です。調べたい単語で検索してスライドを３つぐらい読むと、短時間でおおよそのポイントをつかむことができます。
― 最後に記事の読者に伝えたいことはありますか？
我々と一緒にやりたい方を継続的に募集しています。日本ではまだまだ少ないBtoBのWebサービスを一緒に作ってくれる人、自分の力を試してみたいという人をお待ちしています。
マーケティングオートメーションの領域は変化も激しくて大変ですが、今すごい勢いで成長している面白いフェーズです。BtoCの世界も非常にビジネスとして面白いと思いますが、既にメガプレイヤーが多くてこれから競争に勝つのはすごく大変です。BtoBのWebサービスはこれから発展する市場なので、自分のアイデアを活かす余地が大きく、やり方次第で世の中に大きな影響を与えられます。ですから、自分の力を試してみたい人にとってはすごく向いている市場だと思います。
私は「何かを変えたい」「世の中に自分の足跡を残したい」と思いながらこの仕事しています。同じように感じていて、自分の思いを実現する場を探している方はぜひご連絡ください。
― ありがとうございました。
プロダクトマネージャーに訊く #6：スマートニュース渡部さん
― まずご自身について教えて下さい。
スマートニュースの渡部です。SmartNewsにはニュースと広告という2つのプロダクトがあります。それぞれ開発体制もサーバーもコードも全く別のプロダクトで、私は広告プロダクトの『SmartNews Ads』の責任者としてプロダクトマネジメントを行っています。
私がスマートニュースに入社したのは、2年ほど前の2014年9月です。当時のスマートニュースはこれからマネタイズをしていこうというフェーズで、私を含めて5人ほどの開発チームで広告プロダクトをゼロから作りました。現在は10人ほどのメンバーでSmartNews Adsを開発しています。
SmartNews Adsの最大の広告配信先はSmartNewsですが、その他の媒体にも広告を配信しています。
― スマートニュースに入社するまでの経歴を教えて下さい。
新卒でNTTコミュニケーションズに入社しました。もともとエンジニアとして採用されたのですが、最初の配属先は営業部門でした。営業の仕事はとても楽しかったのですが、エンジニアのキャリアを歩みたいと思い、転職することにしました。
転職先のグラファイトでは、エンジニアとして受託開発の仕事をしていました。当時グラファイトはまだ規模が小さかったこともあって、自分で営業して案件をとってくるところからが私の仕事でした。その後、ニフティに転職してエンジニア専業の仕事につきました。ニフティ時代にとても良い先輩に出会い、「良いコードとは何か」「チームで良いコードを書くにはどうすべきか」といったエンジニアとしての基礎を叩き込んでもらいました。
ニフティはエンジニアとして成長できる環境だったのですが、インターネット業界の盛り上がりをみて自分もそこで戦いたいという思いが強くなり、GREEに転職しました。
GREEには4年間在籍して、前半の2年は現場のエンジニア、後半の2年はマネジメントを経験しました。最後の1年間は事業責任者兼開発責任者として、新しいブランドのゲームスタジオを立ち上げました。新スタジオではモノづくりとビジネスづくりを両方やらせてもらい、一定の成果をあげることができました。
― スマートニュースに転職したのはどういう理由だったのでしょうか？
マネジメントポジションになると、どうしても複数のプロダクトラインを見る必要がありました。その職務の中で各プロダクトへの予算配分やP/Lのポートフォリオを組むようなことはあっても、自分でゼロからプロダクトやビジネスを作っていくという、GREE創業期の頃のような体験をしてみたいと思うようになりました。
自分でビジネスを作っていきたい、そして、どうせやるなら「私が稼がないと会社が倒産してしまう」というくらい強いプレッシャーを感じて仕事をしたい。そうしたチャレンジができる環境を探している時に出会ったのがスマートニュースでした。
― 渡部さんの役割の範囲を教えて下さい。渡部さんがプロダクトマネージャーで、他に開発マネージャーやスクラムマスター的な人がいるのでしょうか？
全て私が兼任しています。大きな会社だとプロダクトマネージャーとエンジニアリングマネージャーとスクラムマスターを別々にアサインすることが多いのかもしれませんね。SmartNews Adsはプロダクトの立ち上げフェーズだったこともあって、自分がそうした役割を全て引き受けることにしました。
広告もニュースもエンジニアリングが差別化要素になるサービスだというとこともあって、スマートニュースではエンジニア出身者がプロダクトマネージャーをやる方針にしています。私は現在進行形でエンジニアのつもりですし、エンジニアだからこそプロダクトマネージャーもエンジニアリングマネージャーも兼務できます。
― そうすると、今でもコードを書かれているのですか？
プロダクションコードは書いていません。エンジニアリングマネージャーはタスクをアサインする権限があるので、自分自身に技術的にチャレンジングなタスクをアサインしたくなります。ただマネジメント業務とエンジニア業務を兼任すると、どうしても自分がボトルネックになりがちです。
特にインターネットサービスはリリース後に運用しながら改善を繰り返して成長させていくものですし、障害が発生したときに即応できない人間はプロダクションコードを書かない方がいいのです。ですから、プロダクトマネージャーなどマネジメントロールに付いている時は、基本的にプロダクションコードを書かないようにしています。
ただ、コードを書きたいという欲求は強いですね。
― それはエンジニアとしてジレンマを感じてしまいますね。
プロダクションコードは書きませんが、プロトタイプは自分で手を動かして作ります。
最近のインターネットサービスは、カバーしなければいけない技術分野が非常に幅広い。一つのサービスが、AndroidやiOSなどのアプリからサーバーサイドやインフラ、さらには機械学習をはじめとしたデータサイエンスなど、複数の技術によって一つのサービスができあがっています。
私の立場ではそれぞれの技術についてエンジニアと対等に議論できる必要があります。そのため、最新の技術やスマホOSの新仕様にキャッチアップできるように自分でプロトタイピングして、新しい技術で未解決課題を解決できるか確認するようにしています。自分でもうまくいくか確証がないR&D的要素が強い試みの場合は、サーバーとクライアントの両方のコードを書いてみます。プロトタイプが期待どおり動くことを確認した後で、エンジニアチームで開発してサービスに取り入れます。
また、専任のアナリストがいるわけではないので、プログラムだけでなくSQLも自分で書いてデータ分析しています。
― 役割の範囲が広いですね。
プロダクトの成功確率を上げるために必要なことであれば何でもやる、というスタンスです。仕事の範囲を限定せず、良いプロダクトを作るために自分はどういう役割を担うべきか、と考えるのがプロダクトマネージャーの役割だと思っています。
「コンテンツとしての広告」で価値ある情報を届けたい
― SmartNewsというプロダクトを通じて、どのような価値を提供したいと考えていますか？
ニュースサービスとしてのSmartNewsについてはご存知だと思うので、広告プロダクトについてお話ししますね。SmartNews Adsのステークホルダーは大きく分けるとメディア、広告主、ユーザーの三者がいます。それぞれに価値提供できるプロダクトを作っていきたいと思っています。
各メディアにコンテンツを提供いただくにあたり、レベニューシェアの仕組みなども用意していますので、メディアさんに高い収益をお返しできるようにしたいです。今月や来月といった短期的な収益ではなく、長期で見た時のトータル収益ではどこにも負けない、と言えるようにしたいと考えています。
広告主に対しても当然成果でお返しする必要があります。簡単に言うと、広告に1万円投資して1万1000円の利益があがったら出稿し続けてくれますよね。広告費のROIが可視化できて、かつ高いROIを実現できる広告サービスを提供する必要があります。
そしてユーザーに対する価値提供も大切にしています。広告はユーザーから嫌われることも多々あり、特にインターネット広告を邪魔だと思う方が多いように感じます。これは広告に関わる人間として非常に悲しいことです。スマートニュース社内では『Ads as Content』と言っていますが、私たちは広告もコンテンツだと思っています。SmartNewsはユーザーに価値ある情報の発見機会を提供したい。それは広告であっても同じです。もちろん広告であることは表記しつつ、新しい発見に繋がるコンテンツとして捉えていただけるような広告を提供したいと思っています。
ハッとするほど面白くて見入ってしまうような広告クリエイティブもたくさんありますし、広告を通じて「ああこういう商品やビジネスがあるのか」と知ることが個人的にもよくあります。コンテンツとしての側面を伝えつつ、かつユーザーの操作を邪魔しない形式でどう広告を表示するのか、という点には特にこだわっています。
良いプロダクトを作る秘訣は、成功から逆算すること
― 良いプロダクトを作るための定石として意識していることがあれば教えて下さい。業界や分野を超えて、良いプロダクトを作るために共通する考え方はありますか？
一番大事なことは『成功から逆算すること』です。チームにはいつも「当たったら勝てることをやろう」と話しています。麻雀の例で説明すると、「最終局で一発逆転して1位とりたい、でもトップと1万点差がある」という時に5000点で上がっちゃダメですよね。スタートアップ企業だと切実な問題としていつまでに成功していないと事業を継続できない、という期限があります。例えば、１年後に1億円の売上が必要であれば、それを実現するために今何をしなければならないのかを考えます。
ゴールから逆算せずに、「できること」を積み重ねていってしまうと失敗します。「最終的にこういうタワーを作りたい」というゴールから逆算して計画せずに、下から積んでいくとジェンガになってくるんですね。「倒れそうだからここに積もう」「次はこっちに積もう」となって最終的には崩れてしまいます。
マクロな視点で市場を見て、どんなプレイヤーがどれくらいの事業規模で、どれくらいの売上なのかといった調査をすると、目標達成のために１年後にその市場で目指すべき事業規模やポジショニングが見えてきます。そこから逆算してどんなプロダクトが必要なのか明らかにする。これが一番大事なことだと思います。
― でも収益というのは自社にとってのゴールですよね。
もちろん自分たちが作りたいものを作っているだけではうまく行きません。「誰のどんな課題をどう解決するのか？」を明確にすることが大事で、その結果として収益が生まれます。
「広告主はなぜSmartNewsに出稿するのか」「ユーザーはなぜ他のニュースアプリではなくSmartNewsを使うのか」といったように、誰のどんな課題を解決するのか、各ステークホルダーに最終的に提供したい価値を定義することが重要です。
SmartNewsの広告事業の場合、広告配信事業者、メディア、アプリユーザーの三者がいて、さらに広告代理店や広告主がいる。短期的には各プレイヤーの利害相反が起きる場合があります。短期的には三者の利害が相反するようなケースがあっても、自分たちが最終的に提供したい価値が決まっていれば、ステークホルダーの皆さんの理解を得ながら多くの人が満足できる解に近づいていくことができます。これはBtoBでもBtoCでも同じことだと思います。
― ユーザー課題を理解するために日常的に心がけていることはありますか？
色々な人の話を聞きに行くようにしています。例えば「今度こういう機能を考えているんだけどどうだろう？」と自分のアイデアを広告のセールス担当に話すと、「最近はこういう広告商品の方が人気がある」「それならこういう見せ方に変えればどう？」といったように何らかのリアクションがあります。とにかくステークホルダーをアクティブソナーだと思ってPingを打ち、帰ってくるものを確認しながらプロダクトマーケットフィットに近づく方向を模索します。もちろんインターネット上でも情報収集はしますが、そうしたオフラインの声を集めながら、業界やプロダクトを俯瞰して見ることがとても大事だと思っています。
― そうしたアイデアをプロダクトとして実現するために、開発チームとはどのようなコミュニケーションをしていますか？
「成功から逆算する」ということと通じるのですが、「1年後にこうなっているためには、この四半期でここまで到達する必要がある」「こういう機能があればその状態に到達できる可能性が高いと思っている」というように、ゴールから逆算して今何を作るべきかを開発チームに正しく伝えるようにしています。
そのときに大事なのが「How、WhatじゃなくてWhyを書く」ということです。エンジニアはコードのコメントには「Whyを書け」と言われます。何をするか、どうやってやるかはコードに書かれており、良いコードはコメントで説明しなくてもそれは分かります。一方で「なぜこの処理をここで必要なのか」という背景情報はコードからは読み取りにくい。
同様に、プロダクトマネージャーは「なぜこの機能をつくるのか」を説明する必要があります。例えば、「売上を10％上げる必要があって、この機能は売上を5％上げる可能性がある」「その理由は、○○というお客様のニーズが増えていて市場のトレンドともマッチしている。」「だから☓☓というサービスを提供すれば対価を支払ってくれるだろう」といったロジックを整理してドキュメントにして共有します。その上で「本当にそうなのか」「仮説が間違っていないか」などエンジニア全員で納得行くまで議論します。
― 議論の過程で渡部さんがたてた仮説が変わることもありますか？
仮説は頻繁に変えます。エンジニアにも「朝令暮改を恐れないようにしよう」と言っています。「ここまで作ったのだから」とか「ここまで議論したのだから」という『サンクコストの呪縛』にとらわれてはいけません。
今日の自分は昨日の自分が知らなかった情報を得ているのですから、少し賢くなっているはずです。決断した翌日に問題に気づいたとして、その時すぐに方針を変えれば1日分しかロスで済みません。これが1週間様子を見て「やっぱりダメだった」ということになると、1週間分のロスになってしまう。だからダメだと思ったらすぐに変えるようにしています。
判断ミスをしたら減点されてしまうカルチャーの組織もあるかもしれませんね。でも私たちのようなスタートアップは、プロダクトが成果を出さなければ、会社が立ち行かなくなるかもしれない。そういう緊迫感のある環境を求めてこの会社に集まっています。より良いプロダクトを作るためであれば、方針を変えることに納得してくれます。
ただ、自分の判断ミスについては素直に謝ります。昨日の自分がベストな答えを出せなかったのは事実ですから。もちろん失敗続きだと「また変えるのか、この前も途中で変えたじゃないか」と信頼を失ってしまいますから、成功確率をあげていく必要はあります。
プロダクトでビジネスを成功させることでエンジニアを幸福にしたい
― 渡部さんがマネジメントの重要性を意識するようになったきっかけは？
GREEでマネジメントを経験したことが大きな転機になりました。
昔は「技術で食っていくんだ」という強い拘りがあり、頑張って技術を磨いていました。「技術で突き抜けていくのが一番格好いいんだ」と思っていたのです。そんな中、GREE時代にアメリカに赴任してグローバルなゲームプラットフォームの開発に携わった際に、向こうのエンジニアと一緒に机並べて働いてみて大きな衝撃を受けたんです。
日本にいた時はシリコンバレーに対して漠然とした憧れを持っていて、「アメリカのエンジニアはきっと相当レベルが高いんだろう」と思っていたんですが、私の目からみるとあまり大きな差がない。日本にもシリコンバレーのエンジニアより優秀な人材がたくさんいるんだということを再発見して、「あれ？」とちょっと拍子抜けしました。
ただ、プロダクトがリリースされた後に商売がうまく回る確率はアメリカのチームのほうが高いように見えました。これは何なんだろう、と不思議でした。アメリカ人の同僚や友人でマネジメントに関わる人達と話してみると、エンジニアとしての能力は負けていなくてもマネジメントのスキルがすごく高い人がいることがわかりました。彼らと話すなかで、「一部の優秀なエンジニアが頑張れば、良いプロダクトを作れる」と考えていた私も、組織として成果を出すにマネジメントが重要であることに気づきました。
― 技術力以外の要素の重要性を実感したのですね。
はい。GREEで痛感したことが2つあります。一つは、エンジニアリングによるアウトプットで商業的に成功しなければ、関わったエンジニアはハッピーにならない、ということです。頑張って作ったプロダクトでも、事業としてうまく行かなければ努力は評価されないし、悔しい思いをすることになる。エンジニアリングやプロダクト・アウトで勝負するのは、事業としてはオプションの一つでしかありません。プロダクトで成功できなければエンジニアを取り巻く環境は悪化していきます。
もう一つは、エンジニアが商売を作れないとエンジニア組織の代弁者としてエンジニアの主張を通すことはできない、ということです。インターネット業界はダイナミックですごく面白い業界です。そのインターネット業界を支えるエンジニアをもっとハッピーにしたい。でも「エンジニアがより良いものを作れる環境にしよう」と主張しても「それでどれだけ売上があがるの？」という問いに答えられないと会社を動かすことはできません。
― プロダクトによるビジネスの成功とエンジニアの幸せは直結しているということですね。
そうです。プロダクトによってビジネスを成功させた体験の中でこそ、エンジニアは成長できると思っています。ですから一緒に働くエンジニアのためにもプロダクトを絶対に成功させたい。
私のチームのエンジニアは皆んな優秀ですから、フリーランス・エンジニアとして興味を持った案件だけを選んで稼ぐこともできるのです。だからこそ、個人で仕事をするよりも成長に繋がる環境を提供して市場価値を高められるようにしないと、彼らにとって私の存在価値は無いと思っています。
エンジニアのキャリアとしてのプロダクトマネージャー
― 渡部さんは何度かの転職を経て、大きくキャリアが変遷して行ってますね。
そうですね。エンジニア出身のプロダクトマネージャーとして、私がエンジニアの皆さんに伝えたい事は「積極的に次のキャリアを考えてみませんか？」ということです。私がエンジニアを始めた頃は、Webの申込フォームを作る仕事でお金を稼げていたんですが、そういう仕事ってもう存在しないですよね。エンジニアが生き残っていくには、専門的で高度な技術を突き詰めていくか、事業会社の中で事業貢献に繋がるアウトプットが出せるか、どちらかの方向で成長し続けるしかないと思っています。
事業貢献志向のエンジニアの方は、プロダクトマネージャーを目指してみてはどうでしょうか。私は今でも本職はエンジニアのつもりですし、自分の一番得意な分野は技術マネジメントだと思っています。得意領域でさらに成果を出すためにプロダクトマネージャーや事業責任者をやっています。
― 渡部さんご自身はプロダクトマネジメントをどう学ばれたのですか？
プロダクトマネジメントはまだ体系的に整理された分野ではないので、実際のプロダクト開発のプロセスの中で身に着けていきました。GREEで幸運だったのは、エンジニアがプロダクトを考える文化だったことです。エンジニアは企画されたものを作れば良いというわけではなく、どんなゲームがユーザーに受けるのか考えながらプロダクトを開発していました。尊敬できる優秀なゲームデザイナーと議論しながらプロダクトを開発していたので、そうした過程でプロダクトマネジメントについて色々と学ぶことができました。
また事業責任者として企画をレビューするために、競合プロダクトについて相当研究しました。GREEのプロダクトはゲームでしたから、有名タイトルは一通り徹底的にプレーしました。ユーザー視点でプレーしつつ、作り手の視点でそのゲームの戦略や技術的に優れている点を分析するのです。
新規プロダクトは不確実性が高く、どれが当たるかはわかりません。ただ、企画の評価や競合の研究を繰り返していると、「こういう方向性は失敗する」とか「この企画は絶対うまくいかない」といった避けるべきパターンは見えてくるようになります。
― プロダクトマネージャーにはそうしたパターンを見抜くためのセンスが求められますね。
私は「センスとは磨くものだ」と思っています。ゲームであれば上位タイトルを全てプレイする、メディアサービスであれば良いコンテンツに触れ続ける。こうしたことを続けていく中で、センスは磨かれていきます。業界が変わればユーザーの要求も変わるので以前と同じパターンは適用できませんが、新たなパターンを勉強すればいいのです。
― エンジニアのなかでもプロダクトマネージャーに向いている人と向いていない人はいるのでしょうか？
できない人はいないと思いますが、できないと思い込んでいる人は多いかもしれませんね。
エンジニアは知識を積み重ねていくことでスキルを向上させることができます。ある程度は努力に比例した見返りがある。一方で、知識量ではなくクリエイティビティで勝負しなければいけない分野になると「自分にできるだろうか」「自分にはセンスがないんじゃないか」と不安に思うエンジニアも多いんじゃないかと思います。ただ先ほども言いましたがセンスは磨けばいい。
エンジニアとして難しい技術を体得するための頭脳があって努力ができる人であれば、プロダクトマネジメントも当然できると思っています。もちろん、その人が最終的にどういう立ち位置で仕事をしたいのか、という価値観によるところはあります。
― 渡部さんのアメリカでの経験のように、価値観が変わるタイミングがあるのかもしれませんね。
エンジニアリングのアウトプットでビジネスに貢献することが、事業会社におけるエンジニアの存在価値です。ただ、エンジニアとしての実力が一定以上になると、1年後に倍のエンジニアリング力を身につけるというのは現実的に難しくなってきます。そうした時、上位のエンジニアになればなるほど、エンジニアリングの力を最大限活かして良いプロダクトを作るにはどうすればいいのか、という発想をするようになる。より事業に貢献するにはどうすればいいのか、と考えるようになります。そうした人にはプロダクトマネージャーを次のキャリアの選択肢として考えてみてもらいたいですね。
ただ、エンジニア出身のプロダクトマネージャーは、実装方法にばかり意識が向いてしまいがち、という弱点もあります。だから私は、どういうフィーチャーを作るべきかをて考える際には、逆に一切技術的な実現方法を考えないようにしています。さもないと自分の技術の幅がプロダクトの幅になってしまう。
とはいえ「技術的にはこんな事もできる」という知識の積み重ねが新しいサービスのアイデアを生むことはあるので、技術に関する勉強はし続けるべきです。プロダクトマネージャーはゼネラリストであることが求められますが、自分の強みを磨きスペシャリティを持ち続けることも重要です。
― これからプロダクトマネジメントに関わる人におすすめの本があれば教えて下さい。
マネジメントに関するお勧めの本を聞かれた時に紹介するのが、『プロフェッショナルマネージャー』という本です。今日僕が話したことは、だいたいこの本に書いてあります。
プロダクトを考える上で勉強になったのが『ライト、ついてますか―問題発見の人間学』という本です。私の師匠であるGREE CTOの藤本さんがお勧めされていたので読んだのですが、とても良い本です。同じ現象でも見る角度によって異なる解釈ができます。複数の視点で問題を理解することの重要性が分かる本です。
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (190件) を見る
― 最後に告知などがありましたらお願いします
当社では技術を突き詰めたいエンジニアも事業を作りたいエンジニアも募集中です。また、エンジニアとして実績を積んだ後でプロダクトマネージャーになりたい、という方も大歓迎です。
私のポジションを奪ってくれるような人が来てくれたら頼もしいですね。私は「こいつには敵わないかもしれない」と思う相手がいると闘志がわくタイプです。自分のポジションを脅かすような優秀な人が来てくれると、さらに仕事が楽しくなるだろうなと思っています。
― ありがとうございました
2016年7月号：注目記事まとめ
プロダクトマネジメントに関係する記事で、7月に話題になった記事、気になった記事をピックアップしてご紹介。
コンセプト・メイキング
↑ クリエイティブ・ディレクションのIdeationプロセスを分解して解説。こうあるべきという哲学や情熱がスタート地点になるわけですね。
要件定義
↑ 開発要件のフォーマット例。開発の背景やゴールを最小限の工数で適切に伝えられるように工夫されたフォーマットです。
チーム開発、組織
↑ 開発プロジェクトのマネジメントを外部に依託することでエンジニアがコードを書くことに集中できるようにした、という事例。この発想は面白いですね。同じ発想で考えると、プロダクトマネジメントを受託するフリーのプロダクトマネージャーというのも需要があるかもしれませんね。
↑ チケットキャンプのリニューアルをケースとしたデザイナー主導のチーム開発について。ある意味、ひとつ前のスライドにあったようなマネジメントの外部依託の事例のようにも見えます。
↑ こちらもひとつ前のスライドと共通するものが多く、合わせて見ておきたいスライドです。
↑ デザイナー主導のチーム開発からスクラムまで色々なスライドが紹介されています。どれも一見の価値あり。
↑ 職能別組織にするのか、事業別組織にするのか。これはデザイナー以外のエンジニアやPMの組織にも共通する話ですね。
PMの役割
▼ pmjp#4に出席して分かったPMとPMMの違い – aomeganeビジョン | 五反田で働くプロダクトマネージャーのブログ
↑ プロダクトマネジメント担当とプロダクトマーケティング担当は兼任すべきか、という問題。これは担当する人の能力次第ではないかと思う。プロダクトマネジメントのExecutionとプロダクトマーケティングのExecutionを同時に担当するのは結構大変なんじゃないかという気がしています。
↑ PMはSQLを使えるようにすべし、というのは私も何度か言及していますが、その理由が明確に示されています。
SQLを覚えて仮説設定し分析することは、エンジニアリングのバックグラウンドのないPMが計算論的思考を身につけるきっかけになるのではないかと個人的には思っています。
ところで記事中で紹介されているre:dashは本当に便利。
成長企業が知っている人材採用の秘密
ウィルス進化論という学説がある。ウィルスの遺伝子が感染した宿主の遺伝子に逆転写され、それが生物の非連続な進化をもたらす、というものだ。一般的に認められた学説ではないが実に興味深い。
ウィルス進化説とは異なる話だが、生物の細胞内のミトコンドリアは、原始真核生物が細胞内に取り込んだ細菌だといわれている。ミトコンドリアは酸素や糖をエネルギーに変える。太古の生命はミトコンドリアの取り込みによって、大きなエネルギーを獲得しより活発な運動が可能になった。
急成長するネット企業に2年と少し在籍して、強く意識するようになった事がある。それは「成長する企業は、外部から優秀な人材を積極的に採用し、新たな組織のDNAとして取り込みながら進化する」ということだ。まさにウィルス進化説やミトコンドリア取り込みと同様である。
ただ、多くの企業はその事実に気がついていない。採用とは、たまたま求人に応募してきた求職者を企業が「選考」するプロセスだと考えている。
採用とは自社に関心を持っていない、もしくは存在すら認知していない優秀人材を発見し、自社への共感を獲得していくプロセスに他ならない。もちろん選考が不要なわけではない。ただ、自社の発展に貢献する人材であるとひとたび見極めたならば、働く者にとっての自社の価値（Employee Value Proposition）をアピールし、意向と共感の獲得に全力を注がなければならない。
採用を担う人事の仕事は、マーケティング業であり、セールス業であり、接客業なのだ。それに気づいていない企業は、人材獲得競争の勝者になることはできない。
ネット企業では、カスタマージャーニーマップを作成して自社のサービスに対してユーザーがどんな体験をしているのかトレースし、サービスの問題発見と改善に役立てる。昔、初めてジャーニーマップを作った時、あまりの負の体験の多さ、離脱ポイントの多さに愕然としたものだ。
「良い人材が集まらない」と感じている経営者の方は、求職者の視点で「採用プロセスのカスタマージャーニーマップ」を作成し、優秀な人材を獲得できるプロセスになっているかチェックしてみてはどうだろうか。初めてサービスのジャーニーマップを作った私と同様に、負の体験の多さに愕然とするかもしれない。
人材採用に対する考え方を変えた企業が勝つ。もしかしたらそれは経営者の能力や事業モデルよりも、企業にとって重要な要素かもしれない。
ウォー・フォー・タレント ― 人材育成競争 (Harvard Business School Press)
- 作者: エド・マイケルズ,ヘレン・ハンドフィールド=ジョーンズ,ベス・アクセルロッド,マッキンゼー・アンド・カンパニー,渡会圭子
- 出版社/メーカー: 翔泳社
- 発売日: 2002/05/18
- メディア: 単行本
- クリック: 6回
- この商品を含むブログ (5件) を見る
プロダクトマネージャー オフ会#4 @GMOペパボ イベントレポート
プロダクトマネージャーのコミュニティ、Product Managers Japan (PMJP)のオフ会レポートです。
今回も80人の参加枠が告知後数十分で埋まってしまいました。前回と比べて女性の参加者が増えたかも？会場提供いただいたGMOペパボ株式会社さん、ありがとうございました。
前回からプレゼン/LTタイムが設けられましたが、第4回目になる今回も充実したプログラム内容でした。チームの作り方、開発プロセス、PMの役割、グロース実例、など一線で活躍するPMの皆さんならではの発表内容で、とても勉強になりました。
以下は皆さんの発表資料です。
Fablic ninjinkunさん『スマートフォンアプリ開発における共創的な開発チーム』
GMOペパボ 山本としやさん 『強いプロダクトを生み出すチームづくり』
Increments 及川卓也さん 『PM++ 〜QiitaにおけるPMの役割〜』
ヴイエムウェア 桂島航さん 『プロダクトマネジメントとプロダクトマーケティングの違い〜米国インフラソフトウェア企業の経験から』
GMOペパボ 千葉誠さん『チーム全員でお申し込み数を2倍にした話』
当日のツイートのまとめはこちら。
▼ pmjp.slack.comオフ会#4 - Togetterまとめ
pmjpではslack上のコミュニティでプロダクトマネジメントに関する情報交換をしています。プロダクトマネジメントに関わる方は誰でも参加可能ですので、下記からご参加ください。オフ会情報もこちらで告知されています。
▼ Product Managers Japan (PMJP)
前回のオフ会レポートはこちら。
