強いプロダクト組織の作り方
～プロダクト組織作りの要諦となる採用と育成～

皆さんこんばんは。及川と申します。お二人の登壇者と共にイベントを進めていきます。

私はこの業界に30年以上おりまして、2017年よりクライス＆カンパニーの顧問をしております。

本日はよろしくお願いします。Google日本で8年、Googleアメリカで4年、日本のスタートアップで４年と16年間、プロダクトマネジメントの仕事をしてきました。

数年間カリフォルニアにいましたが、Google日本で大きな仕事をすることになり、2年間の予定で日本に赴任します。本日はさまざまな組織を経験した観点からお話しできればと思います。

日本CPO協会の代表理事を務めており、Sansan株式会社の顧問も務めています。

アメリカで生まれ育ち、大学卒業後にマクロメディアにエンジニアとして入社。PMに転向して、AdobeやCisco、Salesforceで働いてきました。2016年にSalesforce Japanに出向し、プロダクトマネジメントチームを立ち上げた経験があります。

ご紹介いただいた通り、徳生さんはGoogleを中心にスタートアップにもいらっしゃったので、複数の組織を見た観点からお話しいただければと思います。

Wakamatsuさんはご自身の会社があったり、外資であるSalesforceやAdobeなどでの経験もあったり、さらにはSansanの顧問やCPO協会となど、さまざまな視点をお持ちです。日本および米国という視点でもご意見をいただければと思います。

本日のアジェンダは三つです。

・強いプロダクト組織の作り方とは

・プロダクトマネージャーの採用と育成について

・参加者様からの質疑応答

まず、強いプロダクト組織の作り方について、お二方にお聞きします。

プロダクトマネージャーはプロダクトチームにおいて中心的な役割を果たすわけですが、プロダクトが強い会社の中では、どのような形のプロダクト組織が典型的なのでしょうか？

私がここ10年働いたSalesforceでいえば、プロダクト組織の強さは、スケールの大きさと速さにあります。

例えば、私がいたSales Cloudのチームは、5年でチームが3～4倍ぐらいの大きさになりました。そして、年に３回同じタイミングでリリースする関連するマルチプロダクトのチームを、同じ目標のゴールに向かってビジョンを統一させ、実際にプロダクトを作っていくリーダーシップが、Salesforceの組織の最も強い点です。

Salesforceでは、自律性の高いスクラム（チーム）がアメーバのように分裂して大きくなることで、4つのスクラムチームが8にも16にも増えていきます。その実現のためにSalesforceが心がけていたのは、プロダクトマネージャーの育成と、チームが分裂したときナレッジが平等に行きわたるようにチームを構成することです。もっとも苦労する点でもあり、Salesforceの強さの秘訣でもあります。

Googleはどうでしょうか？

Googleのプロダクト組織は、YouTube、検索というように大きなプロダクトごとに組織が分かれています。プロダクトにはリードが1人いて、その下にPMやエンジニアなど、その他の組織がファンクション毎に分かれています。

PMにとって理想的なのは、自分のカウンターパートのエンジニアが誰か、UXのカウンターパートが誰か、ストラテジーがチームで何を追求するかがはっきりしている状態です。こうした環境をつくるために、ストラテジーを全体の組織にマップしていくことが、リーダーシップが非常に苦労している点でもあります。

また、Googleは、非常にボトムアップな会社で各自が強い意見を持っていることが特徴です。ストラテジーを作るときは、トップダウンではなくトップとボトムを往復しながら、みんなが満足するストラテジーの構造を作れることが、非常に肝になっています。

Googleでは、最小のプロダクトチームの数や開発のメソドロジーは共通化されているのでしょうか？

10人や20人ほどのチームが多いです。性質や問題のスパンがプロダクトによって異なるため、必ずしもスクラムを組んでいるわけではありません。

そして、他チームとの連携が重要であるため、さまざまなチームが能動的に連携をとったり情報収集したりしながら、有機的に繋がる努力をしています。

Googleは、「OKR」によって、トップダウン・ボトムアップのハイブリッドを行い、全体が同じ方向に向かっています。OKRは強いプロダクトを作るうえでも、重要な役割を果たしていますか？

そうですね。OKRそのものより、OKRの前段が非常に重要です。Googleでは会社として解決したいユーザープロブレムやビジネスプログラムを個別に分けて、マップした組織を作ることを考えています。そのため、スーパーバイズしなくても、各チームがOKRを設定できるようになっています。

Salesforceでは「V2MOM」が有名ですが、どのように運営されているか教えていただけますか。

SalesforceのV2MOMは、ビジョン・バリュー・方法（Method）・障害（Obstacles）・基準（Measures）の5つの要素でできています。元々は創業者であるマーク・ベニオフが会社のために作ったものでした。

クラウドのV2MOMも作っています。

個人の一年の目標もV2MOMに書くなど、Salesforceではさまざまな使い方をしています。例えば、PMなら「マンスリーアクティブユーザーをこれだけ増やすために、この機能を作ります」など、具体的で現実性のあるゴールを設定します。

Salesforceの大きなテーマとして「AI」が掲げられたら、「Salesforceの営業管理ならAIを活用して、このようなプロダクトを作ります」と各PMが提案できるため、完全なトップダウンではない、やりがいを感じられるプロダクト作りができます。

やはりトップダウンとボトムアップのハイブリッドなのですね。カンパニーOKRの抽象度が高いため、各組織に所属するメンバーが自らの意見を入れられるという点に、Googleとの共通性を感じます。

おっしゃる通りです。例えば、「YouTubeの視聴時間を増やすこと」が当面のゴールになったら、チームがそれぞれ目標を立てます。例えば、ユーザーフォーカスのチーム、動画を作るクリエイターにフォーカスするチーム、マネタイズに集中するチームがそれぞれ自分たちにできることを追求していくのです。

そして、各人が「自分がこれを実行することで、視聴時間を増やせる」とわかっている状態になります。

なるほど。

Salesforceのクラウドはプロダクト事業部という認識でよろしいですか？

そうです。クラウドの中に、開発組織のPMと、ユーザーリサーチとデザイナーとエンジニアが所属している一つの組織で、三権分立のように平等性をもっています。

三権分立ということなのですが、プロダクトマネージャーとデザイナー、エンジニアの三者はぶっちゃけ仲良くやれるものですか？

組織が分かれている理由としては、三権分立以外にもマネージャーとしてメンターできるか、柔軟性を保つなどの意味があると思います。

マネージャーやリーダーシップとして気を使うのは、優先順位が決まった一つのチームとして、UXとエンジニアとPMが同じ方向を向いていることです。

そこはPMが「ユーザーインパクトとかビジネスインパクトに繋がるビジョンはこれだ」と示す必要はある。そこがPMの醍醐味でもあり、解決していかなきゃいけない問題だと考えます。

私はスタートアップや尖ったテクノロジーを扱っているAdobeで働いてきましたが、Salesforceで一番驚いたのは、大企業を対象にしたBtoBのSaaSプロダクトという性質上、リリースのサイクルが年に3回と決まっていたことです。

1サイクルは実質3ヶ月ほどしかなく、クオリティを保ったうえでイノベーションを起こすために、積極的にコードを書くことが難しい状況でした。初期のシリコンバレーにいたような、超クールで「俺は1人でもこれやるよ」というロックスターのようなエンジニアは少ない環境です。

コードを書ける時間が1日6時間ほどしかない状況で、決まった期間内に決まったクオリティのものを出すような仕組みになっています。

また、少数ながらロックスターエンジニアがいて、私もぶつかったことがあります。そうした場合の対処法は、よくぶつかる数人を別チームに分けて、協調性のある人たちと組み合わせることで、最終的に衝突の少ないチームにしていくことです。

どうしても問題が起きる場合には、社内に数名いる課題を解決するアジャイルコーチに相談し、解決してもらうこともあります。

WakamatsuさんはSalesforce以外にAdobeやciscoにもいらっしゃいましたよね。他の会社ではどうでしたか？

Ciscoで働いていたときは、今で言うGoProのような小型のビデオカメラのチームにいました。ハードとソフトを一緒に作るチームだったため、面白い文化でした。

ハードとソフトでは、PMやエンジニアの考え方はまったく違います。そして、ハードウェアの会社ではハードウェアエンジニアの方が上という格差は感じましたね。

また、Adobeの場合はアーティスト気質のエンジニアが多くて面白い文化でした。音楽のソフトを作っているチームはミュージシャンが多く、映像を作っているチームはアニメーションに関心のあるエンジニアがいて、プロダクトづくりに妥協しない傾向がありました。

PMとして個性とタレントを伸ばしながらも、お客様が求めている機能にフォーカスしてやっていく難しさも感じていました。

2点ご質問です。

エンジニアリングマネージャーとプロジェクトマネージャーはどのように連携していますか？

プロダクトマネージャーとエンジニア、デザイナーの人数比はどういった形でしたか？

人数比は公開できないのですが、一般的に言われている比率と大きく違いはありません。

検索のクオリティならエンジニアの比率が高く、新たなプロダクトを立ち上げる場合は、UXデザイナーの比率が高い傾向があります。

テックリードであるエンジニアリングマネージャーをカウンターパートにして議論することは非常に多いです。Googleはエンジニアカルチャーが強く、データドリブンでありたいと考えているため、データ分析力の高いPMが成果を出しやすい部分はあります。

Salesforceでは、スクラムチーム全体で10人という上限が決まっていました。

チームの比率としては、PM1人、UX1人、ドキュメンテーションをリアルタイムで変更するライター1人、エンジニアが5～6人ぐらいがマックスの組織です。

チームマネージャーとのリレーションシップを行うのはスクラムマスターで、いわゆるテックリードに近いロールです。目線合わせをするために、ウィークリーでミーティングを行い、「プロダクトやチームのここがうまくいっていない。ここは改善しなきゃいけない」などを話します。

次に、2つめのテーマである、プロダクトマネージャーの採用と育成についてお話を伺います。

まずはプロダクトマネージャーの採用からです。

プロダクトマネージャーに求めるスキルは企業によって異なり、そのスキルの確認方法にも違いがあると思います。そこで、プロダクトマネージャーの採用の方法や工夫している点を教えてください。

PMの採用は非常に難しく、一番多いのはリファラルで、競合での経験がある人を採用することも多いです。シリコンバレーでは会社を移る人が多いので、そのタイミングを見つけることが重要です。

Salesforceの場合は社内異動もあります。エンジニアやプリセールスエンジニアがPMに転向することも多いです。

また、Googleも同様だと思いますが、夏休みの期間は長期的なインターンを多くの大学か大学院から受け入れています。みっちり3ヶ月間、人によっては毎年来てくれることもあるので、そうした方々とはリレーションシップを築いて採用につなげようとしています。

Wakamatsuさん自身も、Salesforceにリファラルで入社されましたか？

リファラルではなかったです。Salesforceの場合はLinkedInで所属している人たちの勤続年数や職歴などを確認しました。Salesforce以外はほぼリファラルで転職しました。

Googleでは、PMの採用でどのような工夫をしていますか？

採用においては、製品開発の発想力やデータ分析能力などを重視しますが、他にも重点をおいているものの一つが「Googleyness」と呼ぶもので、ユーザー第一であるか、チームワークがあるか、ゴールが不明確な時でも成果を出せるか、現状を疑ってかかることができるかなど、Google が大切と思う特性を捉えようとしています。

入社のパスは3つあり、もっとも一般的なのはPMによるインタビューです。私はアメリカにいるときは週に一度はインタビューしていました。

なぜならPMの採用を判断できるのはPMしかおらず、また優秀な候補者たちに、より Google に興味を持ってもらうためにも PMがインタビューするのが最適だからです。インタビューはPMの重要な仕事のひとつといえます。

2つめは、Google社内の別部門からの異動です。今はPM以外の業務をしていても、プロダクトのビジョンや強み・弱みを理解していて、地頭のいい人材は沢山いるため、他部門からのPMへのコンバージョンはよく行われています。

3つめは、年間40人限定でコンピュータサイエンスを勉強した新卒を採用し、いきなりプロダクトマネージャーとして2年間経験を積ませるというAPMプログラムです。

最大の目的はPM採用のプールを拡大することですが、PM経験者の中途採用ばかりをしていると男女比が崩れる傾向がありがちであるため、新卒を採用することでより適正な男女比率で採用できるというメリットもあります。

現在ではAPMプログラムの育成は非常に成功していて、PMになった人材がVP（Vice President）になっています。将来、GoogleのCOOはAPMから出てくるかもしれないと言われているほどです。

現在はSalesforceにおいても、Google出身の者がまったく同じプログラムを運営していて、非常に優秀な方がPMとして活躍しています。

APMはどのようなOJTプログラムなのでしょうか？

まず入社後に1年間、Gmailや検索などの主要製品のPMを担当させます。もちろん非常に優秀なマネージャーをつけて、注意深くOJTができるようにしています。

入社早々に、癖のあるエンジニアリーダーや広報・マーケティング部門など、さまざまな部門とやりとりしてリーダーシップを発揮する必要があるため、非常に速習効果があるんです。

1年が終了したら「APMトリップ」という2週間で4カ国を回る旅に出ます。目的は、さまざまな国の企業やテクノロジーに触れる機会を得ることで、視野を広げることです。そして、また1年別のプロジェクトのPMを担当し、PMジェネラリストのスキルを養成していきます。

APMプロジェクトを40名としているのは、人数が多すぎると速習効果が得にくいためです。

採用で重要なのはPMによる候補者へのインタビューであるとお話がありました。インタビューではどのような質問がされるのでしょうか？

Salesforceでは採用プロセスが長いです。まず電話インタビューに始まり、過去の経歴などをインタビュアーもしくはマネージャーが行います。日本においては採用を人事がリードするイメージですが、アメリカでは所属するチームがリードするんですよね。

協調性があるかを重視しているので、エンジニア、デザイナー、ライターなどさまざまなメンバーからインタビューされます。

しかし、実際に働いてうまくいかないケースが増えてきたため、課題を提示してスクラムチームにプレゼンするというプロセスが増えました。具体的には、「このような新機能を作ってください」というプロダクトプランのテンプレートを渡し、2週間ほどでプランの目的やどう成果を測るか、テストケースやバグテストケースなどを想定します。

このプレゼンにおいては、デザイナーやテックリードやQAなどから突っ込んだ質問されたときに、どれだけ冷静に論理的に説明ができるかを見ています。

実際に入社すると、SalesforceのPMはさまざまな立場の人から、突っ込んだ質問をされるため、その状況に耐えうる人なのかを見ています。実際の現場に非常に近いインタビュープロセスの一つです。

Googleの採用プロセスは、45分ほどのインタビューを4～5回行います。過去の経歴は参考程度に聞く程度で、「Googleマップで駐車場を簡単に見つけられる機能をつくるとしたらどうするか？」など製品開発の質問をします。その問いに対してクリアに考えて、問題を分解して、データに基づくアプローチをとって考えられるかを見ています。

あと、実際サービスを作ったら、どのぐらいのパフォーマンスがあり、どこにボトルネックができるかなどのテクニカルな要素を含んだ質問をすることもあります。

質問内容は人それぞれですが、最終的には全面接担当者のフィードバックを見て採用の可否を決める形になっています。

また、英語での面談を心配する方が多いかもしれませんが、ネイティブである必要はなく、ゆっくりでもクリアに答え、要点を伝えられれば大丈夫です。

Salesforceでは、プロダクトマネージャーの育成はどのようにされていましたか？

Salesforceは入社して3日間、ブートキャンプのような研修がありました。インフラからアーキテクチャー、プロダクト作り、スクラムの仕方、オートメーションの作り方などを学びます。

その後はバディシステムに移行するのですが、バディである先輩社員が忙しすぎてあまり機能していない傾向があり、自分で何とかしなくてはいけない場面が多いです。

スキルトレーニングについては、パブリックスピーキングやアジャイルなどのクラスを受けることができます。

一番面白かったのは、ディレクターになったときのリーダーシップトレーニングです。リーダーシップを発揮する人たちを集めて、クロスファンクショナルなメンバーで、Salesforceを会社として運営するシミュレーションを行います。

ゲームのようになっていて、「新機能を開発するようにアナリストから言われました。エンジニアやQAをつけますか？マーケティングのバジェットやITにはどのくらい投資しますか？」という問いが出たりします。トレーニングを通じて、どうコミュニケーションをとってリーダーシップスキルを発揮しているかが評価されます。

私から付け加えたいことがあります。「Googleは大きな会社なので、さまざまなPMと話す機会が多くて大変だ」という人もいますが、私はそれこそがGoogleで働く大きな魅力だと考えています。

他の部署のPMやVPと働き、彼らが自分のビジョンをどう説得力ある形で伝えるのか、どうリソースを見つけてくるのか、どのような場面でNoと言うのか、などを間近で見ることには非常に多くの学びがあります。学びのある環境だからこそ、OJTでもPMが育っているとも言えるのではないでしょうか。

Googleに限りませんがが、大きな製品開発部門のあるワールドクラスの会社で働くことは、PMとしても非常に学びが多いと思います。

たしかに、実践力はOJTやバディ、メンタリングなど、さまざまな人と実際に関わることでの学びが大きいと感じます。

みなさんからの質疑応答を受け付けまして、聞きたい方が多かったものから質問していきます。

「トップダウンとボトムアップのハイブリッドが出るベストであることはとても理解できます。トップが技術やプロダクトに対するリーダーシップがない場合（数字の縛りだけはちゃんと落ちてくる）。こういった場合はどのように対処すべきでしょうか？」

私自身、日本企業をお手伝いしていて、このような苦労をしている方が多いと感じます。何かアドバイスがあればぜひお願いいたします。

企業向けのビジネスの場合、多くの皆様が抱える課題ですよね。

Salesforceの場合、営業組織はプロダクトとしての数字を持たずに、Salesforce全体の営業の数字を目標としています。

そして、開発チームはプロダクトだけの目標数字をもち、その数字は毎年高くなっていきます。プロダクト側は、お客様が必要としているものを作ることに注力しています。

私はBtoCの経験がなく数字に追われた経験がないのですが、Googleのマネージャーはほぼエンジニアかプロダクトマネージャーのバックグラウンドを持っています。

野心的ながらも非現実的ではないゴールを設定できるかは、リーダーシップのスキルに起因するのではと思います。

では次の質問です。

「自律性を持ったエンジニアばかりではないですが、後から自律性を育てていくことは可能なのでしょうか？」

エンジニアだけに限らずPMやプロダクトを作るコアメンバーにおいて自律性は重要ですよね。自律性を採用時に見るべきなのか、採用後に育くむことは可能なのか、ご意見をお聞かせください。

PMの自律性という観点は、マネージャーの協力、正しい評価基準があれば育てられるのではと思います。

Googleの場合、評価において他チームから見たピアレビューのウェイトが大きいため、他部門からの評価を上げたいと考えると、事前調整をするなど能動的に動かざるを得なくなります。結果的に自律性も育っていくのではないでしょうか。

私も後から自律性を育てることは可能だと考えます。例えば、スタンドアップの場で、自分の業務が進んでいないと自ら話せるか、話したときにサポートしてもらえる仕組みにしておく。

プランニングで自分のストーリーをちゃんと説明できなかったときに、「こうストーリーを組んでタスク作りをして、ストーリーポイントの提案をすれば皆を説得できる」といい例を見せて学ばせることもSalesforceでは心がけています。

こうしたプロセスをなるべく平等にしていけば、みんながちゃんと意見を言うといった意味での自律性は育っていくと考えます。

入社当初、シャイな人はあんまり喋りたがらないですが、仕事を経験していくことで「意見を言わないと、チーム全体の足を引っ張ってしまう」という意識が芽生えてくることが多いですね。

自律性を発揮しないと、チーム全体がスローダウンしてしまう状況が可視化されることで、本人が気付くということですね。

では続きまして、こちらです。

「BtoBのSalesforceは事業ドリブン、BtoCのGoogleはプロダクトドリブンで、プロダクトの意思決定をするイメージがあります。両社の事業組織とプロダクト組織のパワーバランスにはどのような違いがありますか？」

私が経験したAdobeやciscoはどちらかというとプロダクトドリブンでしたが、BtoBのSalesforceは事業ドリブンであり、事業組織のパワーバランスが強かったです。

プロダクトのビジョンが顧客や市場ドリブンであるため、「これを作りたい」というエンジニアの意思は通りにくい印象でした。

逆に、Adobeやciscoはエンジニアの考えや研究していたテクノロジーをプロダクト化することもあり、非常にエンジニアが強い組織です。

また、Salesforceで感じたのは、プロダクトとエンジニアというよりも、営業の影響力がとても強いと感じました。人数も圧倒的に多く営業がとても評価される会社でした。BtoB事業を行う企業の特性のひとつかもしれません。

Googleの検索を例に出すと、検索のプロダクトはBtoCですが、検索と関連するアドワーズという広告プロダクトは明確にBtoBです。

検索プロダクト側は「広告のことを考えず、ユーザー本位のプロダクトを作れ」という明確な指示を受けています。

そして、広告プロダクトは検索プロダクトを所与のものとして、何ができるかを考え、パートナーであるビジネスチームと非常に細かく連携して仕事に取り組んでいます。

パワーバランスについては、プロダクトや事業の特性に応じて違うようですね。

次の質問です。

「100人規模のベンチャーです。スクラムチームのエンジニアを【正社員：業務委託＝2：8】の比率で構成しています。自律した組織に変えていきたいものの、業務委託エンジニアは一線を引いているように感じられ、組織文化をどのように作るべきか悩んでいます。」

お二方の組織では、このような悩みはおそらくないと思いますが、何かアイデアがあればご回答ください。

この質問に関してはあまり情報がないです。次回もし同じような質問いただければ、日本の企業についてお話ができるかと思います。

アメリカでは、エンジニアはほとんどが正社員だからです。少し似ている状況としては、買収した企業のチームと連携してなにかを作る場合です。

買収された側はモチベーションが低くなりがちなので、どうモチベーションをあげるかが重要です。私は買収した側にいるケースが多かったのですが、できるだけ気持ちや文化に寄り添って、モチベーション上げようとしてきました。

買収先企業のあるイスラエルに出張に行くなど、なるべく対面でリレーションシップ作りをするようにしていました。

直接アドバイスになるかわからないですが、USのプロダクトチームがインドにサブチームを作り、物理的な距離や時差で連携に苦労することはよくあります。

そういった場合は、リレーションづくりには時間をかけること、長期的にはサブチームだけで日々の開発が完結する体制とスコープ作りが重要なポイントになると思います。

アメリカではテクノロジー企業のエンジニアは正社員が当たり前なので、お二方とも回答に苦労したと思います。

業務委託の場合はコミットメントが圧倒的に違うため、自律的になりようがない部分があります。

そのため、正社員の比率を高める、業務委託であっても正社員に近い形でコミットしてくれる方を採用するなどがよいのではと思います。

次の質問です。

「PMのオンボーディングは非常に難しいと感じます。定着を早くするためにもらうために、どのような工夫をしていますか？」

Googleの場合、入社した時点で何らかのPM経験を持っている方が多いので、Googleの中でどう動いていくかを中心に教える形です。基本的にはマネージャーが具体的なスコープとゴールを定め、どのチームと物事を進めるべきかを教えます。

日々プレゼンを見るなどはもちろんありますが、実現可能なスコープを定義して、小さな成功を積み重ねてもらうことが重要だと思います。

Salesforceも同様に、物事を一緒に進めるべき人たちを紹介し、ナレッジであればどうアクセスするかを伝えます。PMは基本的に単体で動く仕事なので、自律した動きができるようなツールを渡すことを優先します。

PMのオンボーディングにはSalesforceも課題を感じています。エンジニアであればグループで開発することで達成感を得られますが、PMは孤立している立場で直接レポートする場合も少ないです。

しかし、プロダクトチームとしてゴールを達成するという面では、リーダーシップ的なロールでもある。

SalesforceではPM同士の情報共有をする組織を作り1～2年運用しましたが、PMが忙しすぎて続きませんでした。

やはりPMのオンボーディングは、なるべく早く周囲から信頼してもらえるよう、働きかけることが重要なのかなと思います。

PMが信頼を勝ち得るために、マネージャーを中心にメンバーがサポートするという感じなのですね。

では、最後の質問です。

「複数の人が一つのシステムを触ることになると。意思決定や実装面でもコンフリクトが起きてしまうことが多い印象なのですが、チームを分割しながらそれを実現できますか？」

Salesforceの中でも永遠の課題です。

Salesforceはひとつのコードベースを中心にしていてAPIファーストであるため、他チームが使うAPIもすべてプラットフォームチームが作っています。

プラットフォームチームが社内で一番大きなチームではあるものの、コンフリクトが起こりやすく負担がかかる構図になっています。

月に1度、各クラウドのPMが構想を持ち寄り、エンジニアが参加する場でプレゼンをします。

システム上に依存性を作り、ストーリーを作ったときに他チームの機能が必要な場合には、そのストーリーを探して紐付け、「自分がやりたいストーリーはこのストーリーが終わるまでできない」ことを可視化しています。

「このプロジェクトで何月何日までにこのストーリーが終わっていないと、私達は進められません。このプライオリティは正しいですか」というのを、「スクラムオブスクラム」というスクラムマスター同士のスクラムで管理しています。

管理には非常に時間がかかりますが、管理ができていると無制限にスケールできるようになると思います。

Googleでも永遠の課題であることに間違いはありません。他の企業さんで参考になるかわかりませんが、Googleの場合は規模も大きいので、共用のインフラを作っているチームが沢山あり、そういったチームが「さまざまなチームに使ってもらえるように」というモチベーションを持っていたり、リーダーシップがそういったインフラの重要性をわかっていることで助かってる部分もあります。

ただ他のチームの方針を変えられないことは多いので、うまく合意が取れない時は、敢えて別の方法を使う方向で合意をとるのか、待つのか、諦めるのか、決断を明確にしていくしかないのかなと思います。

今日は時間が足りなくなるぐらい、さまざまなことをお聞きできました。最後にお2人にお言葉をいただければと思います。

及川さんとGoogleの徳生さんから、さまざまな企業のエクスペリエンスをお聞きして、私自身ＰＭとして活用できる情報やアドバイスをいただきました。本日はありがとうございました。

及川さん、Wakamatsuさん、お越しいただいた皆さん、ありがとうございました。

プロダクトチームには多様な職能が必要だと思いますが、いわゆるゼロイチで新規プロダクトを立ち上げるとしたとき、最もコアな職種としてまず採用する職種をご自身のほかに3つ（3人）あげるとしたら、どこから確保されるでしょうか。

プロダクトの領域（ドメイン）によって異なります。もし、そのプロダクトが特定ドメインを強く志向するものだった場合は、そのドメイン関連の職種を採用します。例えば、デザイナー向けのプロダクトであれば、デザイナーやデザイン周りの技術に長けているソフトウェアエンジニアなどです。ソフトウェアエンジニアを対象としたプロダクトであれば、ソフトウェアエンジニアを複数名採用するなどもありそうです。

プロダクトの立ち上げでどこが一番難しいかによっても変わってきそうに思います。例えば、デザインに非常に凝ったものであれば、デザイナーとデザイン周りを実装するWebフロントエンドのソフトウェアエンジニアとかスマホアプリのソフトウェアエンジニアだったり、機械学習が鍵となるものであれば、機械学習エンジニアとかです。

一般的には、プロダクトのMVPを定義し、そのMVPを実現するのに必要な職種を採用するのが良いでしょう。もし、そのMVPがMVPでだけ必要とされるものであれば、外部に委託することも可能でしょうが、MVPの意味合いを考えるとそのようなケースはほとんど無いでしょう。

MVPに関しては、先程の領域（ドメイン）とも関連しますが、ソフトウェアが必須となるプロダクトでは、ソフトウェアエンジニアが最低1名は必要でしょうし、ユーザー体験の出来が重要となる場合はUXデザイナーが必要でしょう。法人営業が必須となるバーティカルSaaSでは営業が必要になりますし、教育系のプロダクトならば、トレーナーや講師のような人間が必要となるかもしれません。

また、ゼロイチフェーズにおいては、メンバーはマルチタレントであることが望まれます。どのような職種であったとしても、他の職種の領域をカバーするマインドセットとスキルが必要となります。例えば、ソフトウェアエンジニアで言っても、いわゆるフルスタックエンジニアと呼ばれるように、一通りのことは一人でカバーできるような人が必要です。プロダクトによっては、簡単なWebデザインもできることが期待されるかもしれません。プロダクトマネージャーがマーケティングや営業を兼ねることもあるでしょう。

ストラテジの意識統一は「トップダウンとボトムアップのハイブリッド」ということでしたが、ボトムアップ方向の浸透/吸い上げにはどのような方法が有効でしたか？　例：ボトムアップ目的のMeeting設計など。

実際の手法を考える際に重要となるのが、 ストラテジーは余白を残した状態とすることです。すべて決まった状態で上意下達的にメンバーに意識統一を求めることはマイクロマネジメントですし、メンバーの自立を阻害します。指示待ち人間を量産することになります。

ストラテジーのようなものは一般的には抽象度が高いものとなります。その抽象度の高いものをメンバーが行う日々の実務に紐付ける際に、そこに解釈や意思が入ります。そこにまでもトップから強い指示を出すことは避ける必要があります。

また、人は他人から言われたものでなく、自らが考えたものに対して強いモチベーションを持ちます。そのため、もし具体的な施策にまでアイデアがあった場合でも、あえてそれを明かさずに、メンバーからそれらを引き出すようにします。色々な情報を与えて、結果的にメンバーが自らその考えにたどり着いたならばしめたものですし、もし異なる結果になったとしても、それがあなたの考えた当初案よりも良いものならば、さらに良いでしょう。

ミーティングにおいては、全員に発言の機会を与えるようにします。しかし、学校教育や場合によっては社会に出てからも、意見を出すことが求められたことが無いメンバーもいるかもしれません。その場合は、意見を出すための心理的障壁を無くすことから始める必要があります。

馬鹿なことを言っても良いし、失敗しても良いことを理解してもらうのが良いでしょう。まず、リーダーからこれを実践してみましょう。また、失敗を許容する文化を作るには、失敗とは成功のための重要な実験であることを伝え、常に失敗から学ぶことを実践し続けるのを示すことです。定例ミーティングなどで、前回のミーティングからの失敗とそこからの学びを全員で共有するなどは効果的です。

また、ミーティングで発言するようになっても、他者の発言に対する質問や意見を出すのにはまた別のスキルが必要です。思い出してみると、学校教育でも全員の前での発表は行いますが、発表した人に対しての意見やコメント、質問などはあまり求められません。無ければ無かったで、しゃんしゃんと終わってしまうことも多く、我々はあまりコメント力や質問力を鍛えられていなかったのではないかとも思います。

そこで、ミーティングでは出席者に1人1つはコメントや質問をすることを求めるようにしてみましょう。声に出すのに抵抗がある場合には付箋紙に書き出してもらっても良いでしょう。オンラインミーティングでしたら、チャットに書いてもらうのも有効です。

ミーティング以外で、ストラテジーを浸透させるのに必要なことは、ストラテジーを形骸化させないための工夫です。トップやマネジメントは繰り返しストラテジーを伝えます。ポスターを作り、社内のあちらこちら（トイレなどにも）掲示すると良いでしょう。

また、マネジメントは日々のアクティビティにもストラテジーを参照します。要所要所の意思決定の拠り所としてストラテジーを使うことも大事です。もし、OKRを用いて目標管理をしているならば、ストラテジーはOKRのObjectivesに直結します。メンバーが日々の活動の判断軸としてストラテジーが使われるように工夫してみてください。

プロダクト、デザイン、エンジニアの評価観点を教えて下さい。

どの職種においても必要となるのは、その職種特有の専門スキルを評価できる人を評価者に置くことです。エンジニアの評価はエンジニアリングがわかる人が行わなければなりません。デザイナーも同様です。プロダクトマネージャーも同じですが、プロダクトマネージャーの場合はその会社の定義するジョブディスクリプションに応じたスキルを見る必要があります。

メンバーシップ型雇用の会社などでは、ジェネラリストとしてのキャリア構築のために、定期的なジョブローテーションが行われ、エンジニアの上司に営業出身のマネージャーが配属されたりすることもありますが、このようなマネージャーの評価は部下をジェネラリストとしてしか評価できず、この進化が著しいITの世界で専門性が極めて重要となったエンジニアを活かすことは不可能です。

このように、評価において重要なことは専門職は専門がわかるものが評価者となることです。

これ以外の具体的な評価手法については、英語でそれぞれの職種と”Performance Review”として検索して頂くと、色々な手法が見つかりますので、参考にしてください。

スクラムガイドの役割では、PO・スクラムマスター・開発チームが定義されており、UXデザイナーは定義されていないと思いますが、UXデザイナーはスクラムチームにおいてどのような形でコミットするのでしょうか？　スクラムマスターとUXデザイナーの関わり方も気になります。

こちらの記事では、UXデザイナーがスクラムチームに含まれていない場合の問題点とその解決方法を提案しています。

>>Scrum and UX-design

また、こちらの記事ではRuntasticが自社の例を用いて、OKRやデザインスプリントと組み合わせて解決したことを紹介しています。

>>Scrum: How to Design in an Agile Environment

小規模のベンチャーなどでは限りある候補者を他社と取り合うようなケースが多く、GoogleやSalesforceのように多くの採用ステップを用意することが難しいように思います。

そのような場合に、できる限りコンパクトなプロセスで、優秀でチームにフィットするPMを見極めるにはどうしたらよいでしょうか？

基本的には、小規模ベンチャーであっても、必要なプロセスを省略すべきではないと考えます。優秀な人を間違えて落としてしまったり、他社に採用されてしまうことは避けられれば避けるべきですが、優秀でない人を間違えて採用してしまうよりは全然ましです。

プロセスを簡略化するよりも、現在のプロセスを見直して、プロセスを加速できる部分がないかを見るのを優先させるべきでしょう。

例えば、採用面接のフィードバックを記述するのに1日かかっているようであれば、採用面接の後に30分から1時間の時間を確保するようにし、その場でフィードバックを記述して貰いましょう。採用面接を5回行うのが別々の日に設定されていたならば、候補者の可能な範囲でできるだけ同日に行うようにしましょう。採用の意思決定に時間がかかるならば、それを短縮しましょう。必要なことは妥協せずに、かかる時間を短縮することを考えるのが良いと思います。

構成：久保 佳那