Google、Salesforceは「強いプロダクト組織」をこう作る！第一線のPMが語る秘訣とは？

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

後半パートはこちら

目次
・Salesforceにおけるプロダクト組織の強さ
・Googleのプロダクト組織
・Salesforceにおける「V2MOM」の役割
・プロダクト開発の「三権分立」は成り立つか

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」を開発。Sansan株式会社 顧問。

Salesforceにおけるプロダクト組織の強さ

及川卓也氏がモデレーションを務めた同セミナー。「典型的な強いプロダクトチームとはどういった組織か」といった質問で開始した。

Ken Wakamatsu氏（以下、Ken氏）：
最初に、ここ10年ほどの間で働いたSalesforceのお話をすると、Salesforceにおけるプロダクト組織の強さは「スケーラビリティ」にあると思います。

私が働いていた「Sales Cloud （セールスクラウド）」チームは、在籍していた5年間でチームが3～4倍ほどに増えました。最初は6個ほどだったスクラムチームが15～20個になったのです。

チームが増えるとプロセスが複雑になり、コミュニケーション力が必要となるのでスピードが遅くなります。新プロセスに対応しながら、関連するマルチプロダクトを同タイミングで年3回リリースしていく。大量のスケールのチームが同じ目標のゴールに向かう。ビジョンを統一し、リーダーがそれらを率いてプロダクトを作っていく。ここがSalesforceという組織の強さであり、今後も参考にしたいと思います。

「凄い勢いのスケールに耐えうる組織になっていること」「ビジョンのもとに巨大化した組織でも同一の方向性で作っていける」この2つを実現する秘訣はどこにあるのだろう。

Ken氏：
「スケール」という意味で、まず一番重要なのは、自律性の高いチームが存在すること。そして、チームをいかに上手くクローンできるかだと思います。クローンというのは、アメーバのように、同じ規模、もしくは少し小さいチームに分裂し、それらをどんどん増やしていく。これができれば、4個あったスクラムチームを8個、16個と増やせます。

Salesforceが心がけていたのはプロダクトマネージャーの育成、そして、チームが分裂する時、できるだけナレッジが平等に行きわたること。スクラムチームのなかに、例えば、リードがいて、新卒に近いエンジニアがいて、中間になるエンジニアがいたら、バランスを考えて新しいチームを作る。ここがやはり強さの秘訣だったかなと思います。

Googleのプロダクト組織

続いて、徳生氏からはGoogleでのプロダクト組織について語られた。

徳生裕人氏（以下、徳生氏）：
Googleでは、まずは大きなプロダクトエリアごとの組織に分かれています。YouTube、検索という形です。各プロダクトエリアに多くはPMバックグラウンドのリードが一人いて、その下にPMの組織、エンジニアの組織、UXなどの他の組織とファンクションごとに分かれています。

PM組織のゴール、または、理想として、各PMのカウンターパートのエンジニアやUXが誰か、プロダクト全体のストラテジーの中でどのような役割が求められているか、全てはっきりした状態を作ること。

それがうまくいけば、各PMからすると、やっていることは小さな会社とあまり変わらないと思います。リーダーの方は、いかにストラテジーを全体の組織にマップしていくかが非常に大きな苦労だと思います。

もう一つ、Googleの特徴だと思うのは、非常にボトムアップな会社であること。現場のPMやエンジニア各自が強い意見を持っていて、みんなが本当に納得するストラテジーやチーム構造が作れるまで何度も上下往復しながらストラテジーを作ります。ここが非常に肝になっている気がします。

Googleでは、例えば「プロダクトチームの最小人数」など、開発のメソドロジーは何か共通化、標準化されているのだろうか。

徳生氏：
やはり効率的なサイズはあると思うので、全体では10人とか20人とかそういったサイズの最小単位のチームが多いと思います。ただ、全チームがスクラムをやっているかといえば、そういうわけでもありません。

プロダクトの性質がそれぞれ非常に大きく異なるので、例えば、検索クオリティをやっているチームと、 YouTube の UIをやっているチームだと個別プロジェクトの粒度やタイムスパンなどがいろいろと違います。

あと個別のチームが出来るだけ自律的に動けるよう組織設計する一方で、Googleは一つ一つのプロダクトが大きいので、プロダクト内の他のチームのプロジェクトとどう連携するか、方向性を合わせられるかが非常に重要になります。各チームが自分のゴールに集中する一方で、他のチームの動向を理解して、能動的に連携することでより早く結果が出せる場合も多いです。

“ストラテジー”という言葉を受け、及川氏は「GoogleではOKRが強いプロダクトを作る上で非常に重要な役割を占めているのではないか」と指摘。徳生氏はGoogleでのOKRについて語った。

徳生氏：
OKRは四半期ごとの現実的なゴールを共有し、日々の優先順位を明確にする要素が大きいと思います。ただ会社レベルのOKRは極めてハイレベルで、それを各チームや個人のOKRに落とす上では、どこにターゲットを絞って、どのような個別の問題に分けていくかというストラテジーの話や、それを実現するための最適な組織構成等が重要になると思います。その上でOKRを各チームが設定できるようになる。そういったOKRの前段が非常に大事になると思います。

Salesforceにおける「V2MOM」の役割

Salesforceではいわゆる「ストラテジー」をいかに実行に落とし込んでいるか。及川氏の「V2MOMが役割を果たしているのではないか」という問いに対し、Ken氏が「V2MOM」の解説を交えて答えた。

Ken氏：
Salesforceの「V2MOM」は、ビジョン（Vision）、価値（Values）、方法（Methods）、障害（Obstacles）、基準（Measures）、この5つの頭文字からできています。

創業者であるマーク・ベニオフが、会社のビジョンに対して社員の意思統一を図るために作ったものです。

それを、Salesforceの中では、いろいろな使い方をしています。例えば、個人における1年のゴールも「V2MOM」に書きます。毎年、マークから部下へとおりてきて、実際に自分のビジネスゴールを書きます。エンジニアだったら「このプロダクトに対してここを学び、これを作る」とか。PMだったら「プロダクトエリアのマンスリーアクティブユーザーをこれだけ増やします」「この機能を作ります」とかですね。

「V2MOM」の方法（Method）はユーザーストーリーに紐づいていて、完了するとV2MOMの基準（Measures）の測定が完了する仕組みになっています。具体的、且つ現実性のあるゴールを設定し、目標を達成していく。Salesforceは各プロダクトを「クラウド」と呼ぶのですが、「クラウド」の「V2MOM」もあります。各クラウドで「今年はこれだけの売上をあげます」「これだけのエンジニアを増やします」など、ゴールを設定しています。

先ほど「ストラテジー」の話がありましたが、それらも1年間のゴールとして組み入れます。例えば「今年のSalesforceのテーマはAIです」となった時には、マークをはじめ、創業者たちから「各クラウドにAIを導入してください」といったように大きなテーマがおりてきます。テーマに対して、「営業管理だったらどういうAIが作れるか」「サポートだったらどういう AIサービスが作れるか」とクラウドがストラテジーを考える。「こういうものを作ります」という提案を各プロダクトチームが提案して、作っていくイメージです。

トップダウンではありますが、PMとしては「何を作るか」提案して、リーダーを説得してもらう機会があるのでやりがいがあります。

このSalesforceの組織について及川氏は「トップダウンとボトムアップのハイブリッド」と表現。徳生氏と共にGoogleとの類似性に触れた。

徳生氏：
10数年前の例になりますが、 YouTubeであれば、「動画の総視聴時間、すなわちウォッチタイムを当面のKPIゴールにしましょう」という話があって。当時でいえば「動画を見るユーザー経験に集中するチーム」「動画を作るクリエイターに集中するチーム」「マネタイゼーションに集中するチーム」が作られました。「総視聴時間が増えるようなプロダクトの改善をする」という大きなテーマに対し、各チームが「じゃあ私たちのチームは一体何ができるだろう」と考えていく。最初は当然、トップの視点と現場の視点でせめぎあいはありますが、最終的に方向性が合致して、各人が「自分がコレをやればプロダクト全体のゴールに確実に寄与できる」とわかっている状態にすることが非常に大事だと思います。

プロダクト開発の「三権分立」は成り立つか

プロダクトごとのチームになっているGoogleに対し、Salesforceも似た組織体系になっているという。

Ken氏：
プロダクト＝クラウドの中に独立した「開発組織のPM」と「ユーザーリサーチとデザイナーのUX組織」と「エンジニアの組織」がまとめられています。育成や評価は各組織で行なっています。エンジニアにはエンジニアのジョブラダーがあり、プロダクトはプロダクトのジョブラダーがあるイメージ。３つのロールがどちらにもレポートしないことでお互いの平等性を持つ、三権分立です。

ここで及川氏から「やや乱暴な質問」と前置きのもと「プロダクト開発（狭義）のコアであるエンジニア、デザイン、PMは、どのような形でうまく協調して進めていけるか。ぶっちゃけこの三者は仲良くやれるのか」と質問がなされた。

徳生氏：
組織（のなかでジョブラダー）を分けるのは、おそらく三権分立ということの他にも、マネージャーが専門性に基づいてメンターできるか、プロジェクトの方向が変わっても組織が柔軟に対応できるかなど、いろんな意味があるのだと思います。

ただ、マネージャーやリーダーが気をつかうのは、組織の各階層で、各プロジェクト毎に担当のPMとエンジニアとUXのトリオが明確で、彼らがチームとして同じ責任とゴールを持っているかどうか。

もちろん「エンジニア組織の中で成果と認められやすいもの」と「PM組織の中で成果と認められやすいもの」にギャップがある場合などもあります。

個人的にそこはPMの責任において「本当に大きなユーザーインパクト、ビジネスインパクトを生み出すためのビジョン」を示さなきゃいけないと思います。まさにそこがPMのウデの見せどころですし、醍醐味でもある。現場でうまく行かなければ、必要に応じて各組織でエスカレートすれば良い。

そういう意味でもやはり組織の各階層で「責任とゴール」が明確になっていることは非常に大事なことだと思います。それが明確であれば、PMとエンジニアとUXが何をどの順番ですべきかは合意できると思います。

Ken氏：
私はいろいろなスタートアップや、尖ったテクノロジーを扱うAdobeなどで働いてきました。Salesforceに移って一番驚いたのが、コンサバティブな開発サイクルだったこと。B2B SaaS、さらに多くのお客様が大企業です。リリースが年に3回と決まっており、リリース毎に実際にコードを書ける期間は実質3ヶ月くらい。このペースは初めはすごくもどかしく感じました。

コンサバティブな一面はエンジニアにも適用しています。「超クールな機能を思いついたので一人で作るよ！」のようなロックスターエンジニアは少ないと思います。

また、初期のシリコンバレーだと長時間働いて、ずっと会社にいるのが美徳なところもありましたが、Salesforceはそうではなく、エンジニアがストーリーポイントをつけるので最初から無理な計画は立てません。また、エンジニアがコードを書ける時間を1日6時間で計算しています。計画性と実行力が高くチームの協調性を守る人材が求められています。決まった期間内に、決まったクオリティのものを毎回出していける仕組みになっています。

ただ、実際に働いてみるとロックスター気質のエンジニアもおり、そういった人とは私自身も少しぶつかることもありました。もちろん、そういった気質の人は、エンジニア同士でもぶつかる傾向がある。

どう解決したかというと、やはりチームを分裂し、一番ぶつかる数人を別チームにし、また違う協調性のキャラクターを持つ人たちと一緒に組む。

こういったプロセスを踏む上で、アジャイルコーチが社内に数名います。プランニング、スタンドアップ、レトロに参加して、フィードバックをもらい、プロセスを向上していきます。

続いて、及川氏が質問したのは「それぞれのファンクションと、エンジニアマネージャーによるマネジメントの関係性はどのような形態になっているのか」そして「PM、エンジニア、デザイナー含めた人数比率」とはーー。

徳生氏：
つまらない答えになってしまって恐縮ですが、人数比については開示するなと言われています（笑）ただ、よく言われる比率とそんなに大きく変わるわけではないです。もちろんプロジェクト次第で、検索クオリティでいえば、エンジニア比率が高いです。また、新しいものを立ち上げるものだとUXやPMの比重が大きくなります。これは本当に世の比率とそんなに変わらないと思います。

プロダクトの方向性については、もちろんPMが勝手に決めるのではなく、「エンジニアリングマネージャー」なり「テックリード」なりをカウンターパートにし、議論することが非常に多いです。

Googleはエンジニアカルチャーも強いですし、データドリブンでありたい。また一言に検索を改善すると言っても無限の方向性があります。どのKPIを動かしたいのか、といった議論の基準を決めないと、実施した後に正しかったのかどうかも検証できない。そういった意味でも、特に検索の場合、数字に非常に強いPMがエンジニアに好かれやすい部分はあると思います。

現場で意見がまとまらなくても、組織がきちんと設計されていれば、エスカレートして、より高い視点で「どっちに行くべきか」という議論が起こる。これはある意味、健全なプロセスだと思っています。

Ken氏：
Salesforceではスクラムチームは10人までと決まっています。または、スタンドアップが15分以内で終わらないようであれば次のリリースで人数を減らします。その10人の中に、通常よりもエンジニアはやや少ないのには、理由があります。一人ライターがつき、リアルタイムでドキュメンテーションを変更していく。PMが1名、UXが1名、ライターが1名、そしてエンジニアが5〜6名ぐらいが平均的です。SalesforceではPMはチームを兼任することが少ないので、チームを分裂するとPMも増やすので数が非常に多くなっていきます。

PMと「エンジニアリングマネージャー」とのリレーションシップは、「スクラムマスター」が取ることになります。スクラムチームの「スクラムマスター」が、テックリードに近いロールになります。PMは「スクラムマスター」と目線合わせをするために時間を最低でも1週間に1回ミーティングをします。プロダクトの話以外にも、「ここは改善しなくちゃいけない」とチームの進捗や課題についても話すので頻繁にミーティングをしています。

後半パートはこちら

編集 ＝ CAREER HACK