Google 、SalesforceのPMは、どう開発の難題に立ち向かう？ 強いプロダクト組織の考え方

※2022年4月に開催されたクライス＆カンパニー主催「クライス汐留アカデミー」より『「強いプロダクト組織の作り方」～プロダクト組織作りの要諦となる採用と育成～』セミナーのレポート記事をお届けします。PM＝プロダクトマネージャーとして記載しています。
前半パートはこちら
後半パートはこちら

Moderator
クライス＆カンパニー 顧問
及川 卓也
MicrosoftにてWindowsおよびその関連製品の開発を担当した後、Googleに転職し、ウェブ検索やGoogleニュースのプロダクトマネジメントやGoogle Chromeのエンジニアリングマネジメントに従事。その後、Qiitaの運営元であるIncrementsに転職。独立後、プロダクト戦略やエンジニアリング組織作りなどで企業への支援を行うTably株式会社を創業。2017年よりクライス&カンパニー顧問。

Speaker
Google LLC　Group Product Manager 
徳生 裕人
2005年に Google 日本法人に入社。2008年からはアジア太平洋地域における YouTube の製品開発責任者として米国 YouTube 本社に勤務、自動字幕機能等を開発。その後、日本法人の製品開発本部長、米国での Google Assistant の製品開発を経て現在に至る。

Speaker
日本CPO協会 代表理事
株式会社metroly CEO / CPO
Sansan株式会社 顧問
Ken Wakamatsu
米国生まれ、カリフォルニア大学バークレー校出身。大学卒業後、エンジニアとしてMacromediaに入社。その後、Kodak、Adobe、Ciscoを経てSalesforceに入社。2016年、Salesforce Japanに出向し、プロダクトマネジャーの責任者としてプロダクトマネジメントチームを立ち上げる。2020年株式会社metrolyに参画し、「Time Insights」の開発。現在は日本CPO協会の代表理事を務める。

ここではセミナーの最後に実施された質疑応答コーナーをお届け。参加者から寄せられた質問と、徳生氏、Ken氏、2名による回答とは――。

トップに技術やプロダクトに対するリーダーシップがない場合、どう対処するか？

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

Ken氏：
まずBtoBのエンタープライズをやっているみなさんであれば、同じような課題を感じる人も多いと思います。

Salesforceでいうと、プロダクト組織と営業組織は全く別の組織になります。

営業組織は全てのプロダクトをまとめた売上目標数値を持っていて、プロダクト組織はプロダクトの売上目標数値と利用目標数値を持っています。

その目標数値は毎年高くなっていますが、そこに集中していけばいい。プロダクト側はプロダクトを作り、イネーブルメントやマーケティングをサポートして、営業側は販売する。やはりそのバランスが重要だと思っています。

Salesforceの中で非常に力を入れているのは「売れるものを作る」ということ。正直なところ、ビジョンはトップダウンでおりてくるものが多いです。そこをうまくマーケティングし、営業がクローズしてくれる。ビジョンの中のものをしっかり作れれば、営業と開発が両立し、結果として数字が出ます。ここが一番重要だと思います。売れる、売れないは市場もあるし、コロナなどさまざまなものに影響される。ですから、プロダクトチームは、一番いいプロダクトを作ることにフォーカスすればいいのではないかと思っています。

徳生氏：
私はBtoCにしか関わったことがないので、いわゆる「お金の数字」に追われたことはないのですが、Googleの恵まれている点は、プロダクト組織のトップは全てエンジニアかPMのバックグラウンドを持っているところ。いかに「ストレッチだけどリーズナブルなゴール」を設定できるかはリーダーシップのスキルだと思うので、人材配置の部分で不条理な数字が落ちてこないようにする、という答えになると思います。

自律性を持ったエンジニアは育成が可能か

質問その2
自立性を持ったエンジニアばかりじゃないと思うのですが、後から自律性を育てていくことは可能でしょうか。

及川氏：
このご質問は、エンジニア縛りでなく、PMやプロダクトを作るコアメンバーで自律性というのは採用時に見なきゃいけないのか。それとも採用後に何らかの形で育ませていくことが可能か。ここをぜひ伺っていいでしょうか？

徳生氏：
プロダクトマネージャーの方の観点で言うと、やはり採用基準や評価基準で担保すべき部分だと思います。採用時にももちろん実績や面接を通してリーダーシップスキルを見るようにはしますが、採用後の評価であれば、最も重要なのはインパクトです。あとは他のチームから見たらピアレビューも評価の中で非常に大きなウエイトを占めます。ですので、実際に数字を出すのみならず、それが他のチームから見ても正しいやり方で行われているか。こういった部分で評価を得ようと考えると、事前にいろいろと調整し、能動的に動かざるを得ません。慣れもあると思いますが、マネージャーの協力、正しい評価基準があれば、リーダーシップの育成はもちろん可能だと思います。

Ken氏：
私もPMの観点から、もちろん後から育むことは可能だと思います。ただ、Salesforceの中だと、どこで自律性を発揮するべきかが論点になります。

例えば、それこそスタンドアップの中で、各々で自分のストーリーが進んでない時に「進んでいません」と伝えられるか。進んでいない場合、新卒など若いエンジニアに対してサポートする仕組みがちゃんと作れているか。プランニングの時に、メンバー自身がストーリーを説明できるようになっているか。「正しい例は、こういう風にストーリーを組んでタスク作りをし、ストーリーポイントの提案をすることでみんなを説得できるよ」と、いい例を見せて学ばせているか。ここをSalesforceは心がけていますので、プロセスをできるだけ平等にし、みんながちゃんと意見を言う。そういった意味の自律性を発揮させることが求められると思います。当然、あまり喋りたがらないエンジニアも中にはいる。ただ、これを言わないとチーム全体の足を引っ張ってしまうといった意識がどうしても出てしまう。そこで徐々に自律性が出てくる場面は非常に多いかなと思います。

事業組織とプロダクト組織のパワーバランス

質問その3
BtoB（Salesforce）とBtoC（Google）では、前者は事業ドリブン、後者はプロダクトドリヴンでプロダクトの意思決定を進めるイメージがありますが、事業組織とプロダクト組織のパワーバランスは両者でどのような違いがあったでしょうか。

徳生氏：
この問題に直接お答えする形ではないかもしれませんが、Googleの検索で言うと、検索のプロダクトがあり、それに合わせて広告のプロダクトがあります。後者は明確にBtoBです。その2つの関係で言うと、まず検索のプロダクトチームは広告のことは考えず、ユーザー本位のモノを作るように、という明確な指示を受けています。

広告のプロダクトチームは検索のプロダクトを所与として、何ができるかを考えていく。ただ、彼らはもちろんパートナーになるセールス事業組織と非常に細かく連携し、仕事に取り組んでいるモデルになっています。

Ken氏：
例えば、以前働いていたAdobeやCiscoといった、どっちかというとプロダクトドリブンなところに比べると、やはりB2Bの方が事業ドリブンというか、顧客ドリブンなところがあるかなと思います。カスタマーが何を求めているか。そこが最終的に事業ドリブンになるという意味で、やはりSalesforceは事業組織にパワーバランスが寄っているとと思います。最終的に何を作るかに関してはエンジニアよりはPMの意見が強いのかもしれません。「作るプロダクトのビジョン」が顧客ドリブン、市場ドリブンでもある。そこに対し、「これを作りたい」と言った時に、エンジニアの意思は顧客のニーズに合わない場合は通りにくいかなと思います。

逆にAdobeやCiscoの時はエンジニアの考え、研究していたテクノロジーをプロダクト化するといった意味だと、非常にエンジニアが強い組織だと思います。

エンジニア組織が非常に評価されているところがあれば、Salesforceは事業ドリブンというよりも、営業が評価される会社なのかなと思いました。これはBtoBの企業における特性の一つかも知れません。

100名のベンチャーで「業務委託エンジニア」とどう組織文化をつくるか？

質問その4
100人規模のベンチャーです。スクラムチームのエンジニアを正社員：業務委託＝２：８の比率で構成しています。自立した組織に変えていきたいものの業務委託エンジニアは一線を引いているように感じられ組織文化をどのように作るべきか悩んでいます。皆さんの組織はこのような悩みがありますか。

Ken氏：
ピンポイントで、この質問に関しては、あまり情報がないのですが、アメリカだと非常に少ないケースですね。特にエンジニアはほとんどが正社員です。ただ、似ていると思うのが、Salesforceは非常に買収が多いこと。買収したチームが連携し、協力して開発することが非常に多くなります。そうなると正社員と業務委託ではないですが、買収した側、買収された側の方のモチベーションの違いがやはりあったりもします。そこをどう高めるか。私の場合、買収した側の方の会社にいたので、そこはすごく力を入れていました。できるだけ気持ち、文化的に寄り添って、モチベーションを上げるようなことをたくさんしようと。例えば、イスラエルに出張に行ったり、そのチームのエンジニアとも積極的に話しかけたり。リレーションシップづくりは非常に力を入れました。

徳生氏：
業務委託について直接のアドバイスはできませんが、Google で似たシチュエーションとしては、USで開発チームを持っていた時に、インドにもチームを立ち上げたことがあり、物理的距離という点では近いのかなと思います。そういう意味でいうと、本当に時間をかけて意識合わせをするしかありませんでした。プロダクト開発の場合は、距離の離れたチームが autonomous（自律的）に動けるように、そのチームだけで完結するスコープを作ってあげられるかが大きなポイントになると思います。

PMのオンボーディング

質問その5
PMのオンボーディングは非常に難しいと受ける身にしても提供する身としても感じます。定着を早くするため、早く戦力になってもらうためにはどのような工夫をしていますか。

徳生氏：
Googleの場合、採用する段階で何らかのPM経験を持っている方が殆どなんですよね。ですので、オンボーディングは、「Googleではどうやってプロダクト開発をするのか」を中心に教える形になるかと思います。マネージャーとしては具体的なスコープとゴールを定めること。あとはコネクション、どのチームと、どういった形で連携をしていくべきか。こういった部分を教えて「自律的に動ける舞台を作る」ようにしていきます。

PMは信頼をあちこちに築いていかなきゃいけない仕事なので、実現可能なスコープを定義し、小さな成功を積み重ねてもらう。ここが一番大事だと思います。

Ken氏：
Salesforceもすごく似ていて、まずできることとしたら、誰と話すべきか、誰がどのナレッジを持っているか、できるだけ早い段階でその人たちを紹介することだとと思います。あとは、ナレッジに、早くアクセスできるようにする。性質的に基本単体で動く仕事なので、できるだけ自律した動き方ができるようなツールを渡す。エンジニアチームで開発して達成感を出すのですが、PMは基本的に孤立している立場ではあるんですよね。チームとしてゴールを達成する意味ではリーダーシップ的なロールですが、孤立している。一時期、PM同士の情報共有プロセスを作り、2年くらい運用したのですが、やはり続かない。結局みんな忙しすぎるんですよね。自分たちのスクラムチームで手一杯で、ミーティングに参加できなくなったり。なので、本当にできるだけ早く、周りのみんなに信頼してもらうようにできるだけ早く動く事が重要なのかなと思います。

複数のチームが1つのシステムを触ることで起こるコンフリクトは、チーム分割で防げるか？

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

Ken氏：
SalesforceではAPIを開発するプラットフォームチームとアプリを開発するアプリケーションチームに大きく分かれています。もちろん一つのコードベースを中心に開発していてAPIファーストがマントラになっています。アプリケーションチームが利用する全てのAPIはプラットフォームチームが作っています。すると、やはりプラットチームにすごく負担がかかるんですね。

開発システム上に依存関係というプロセスがあります。アプリケーションチームが存在しないAPIが必要なストーリーを作った時、プラットフォームチームにAPIをリクエストするストーリーを作って、依存関係を紐付けます。そしてスプリントごとに依存関係を可視化しています。

実際には依存関係を可視化するだけでは開発は上手く進まず、テクニカルプロジェクトマネージャーがスクラムマスタだけを集めて、また別のスクラムを一つ持って、依存関係を管理しています。

複数のチームの依存関係が可視化できて、テクニカルプロジェクトマネージャーが管理すればSalesforceのように無制限にスケールできるようになると思います。

徳生氏：
Google も大きく変わらないのですが、永遠の課題であることは間違いないと思います。ただ Google の場合、例えば共用インフラ的な機能を作るチームは皆、「少しでも多くのチームにうちの機能を使って欲しい」というモチベーションを持っていて、UXも製品間に一貫性を持たせたいと考えていて、そういった水平部門がリーダーシップの後押しを受けて、全社的な連携や方向性の統一を促す場合も多々あります。

あとはそもそもチーム間が競合しにくいように、出来るだけ責任範囲が明確に分割されたチーム作りを心がけていくしかないと思います。

（おわり）

前半パートはこちら
後半パートはこちら

編集 ＝ CAREER HACK