「強いプロダクト組織」はどんなかたちをしているのか？　GoogleとSalesforceの“組織づくり”と“チームの秘訣”

スピーカー自己紹介

司会者：本日のスピーカーを紹介いたします。まずはクライス＆カンパニー顧問、Tably株式会社の及川さん。続いて、Googleの徳生裕人さん。そしてCPO協会のKen Wakamatsuさんにご登壇いただきます。それでは及川さん、みなさま、よろしくお願いします。

及川卓也氏（以下、及川）：みなさま、こんばんは。クライス＆カンパニーの顧問をしている及川と言います。これから1時間半ぐらいの時間になりますが、残り2人の登壇者と一緒に今日のイベントを進めたいと思います。

では、スタートします。「強いプロダクト組織の作り方～プロダクト組織作りの要諦となる採用と育成～」ということで進めていきます。

まず、私の自己紹介です。この業界に30年以上いて、先ほどお話したように、2017年よりクライス＆カンパニーの顧問をしています。及川卓也と申します。よろしくお願いします。では、残り2名の登壇者の方もご紹介していきたいと思います。まず、Googleから徳生裕人さん。自己紹介をお願いします。

徳生裕人氏（以下、徳生）：徳生です。みなさま、今日はよろしくお願いします。先月まで数年間カリフォルニアにいましたが、今回日本のGoogleで大きなプロジェクトがあるということで、2年間の予定で日本に赴任することになり、家族で引っ越してきました。

（スライドを示して）経歴は見てのとおりで、これまで16年間プロダクトマネジメントの仕事をしています。8年がGoogleの日本で、残りの4年がGoogleのアメリカ、残り4年は、日本のスタートアップでそれぞれプロダクトマネジメントをやっていました。

もちろん私がGoogleのプロダクト組織を作っているわけではないので、そういう意味ではおこがましいですが、そうしたいろいろな組織を見た観点から今日はお話ししていきたいと思います。よろしくお願いします。

及川：よろしくお願いいたします。では続きまして、Ken Wakamatsuさん。お願いします。

Ken Wakamatsu氏（以下、Wakamatsu）：みなさん、こんにちは。Ken Wakamatsuです。日本CPO協会の代表理事を務めていて、最後にSansan株式会社の顧問をしています。

私はアメリカで生まれ育って、大学卒業後にMacromediaにエンジニアとして入社し、そこからPMに転向して、AdobeとかCiscoとか、Salesforceで長年やってきました。

2016年に日本に出向し、そこでSalesforce Japanのプロダクトマネジメントチームを立ち上げて、今はmetrolyという会社で「Time Insights」というアプリケーションの開発をしています。よろしくお願いします。

及川：よろしくお願いします。今お二方からご紹介いただいたように、徳生さんはGoogleを中心にスタートアップなどにもいらっしゃったので、そういった複数の組織を見たいろいろな観点からお話しいただければと思います。

Ken Wakamatsuさんも今お話しされたように、ご自身の会社、スタートアップを持っていらっしゃるという立場もあれば、日本から見ると外資であるSalesforceとかAdobeとかの会社の経験もあり、さらにはSansanの顧問や日本CPO協会で代表理事もされて、いろいろな視点を持っていらっしゃると思うので、日本およびアメリカというところでも意見をいただければと思います。

Salesforceのプロダクト組織のすごさは「スケールの大きさ」

及川：今日のアジェンダは3つです。強いプロダクト組織をどう作ればいいかという話。次に人に焦点を当てて、プロダクトマネージャーをどう採用したらいいか、育成したらいいか、評価したらいいかという話。最後に質疑応答です。

では、さっそく本題に入りたいと思います。まずは「強いプロダクト組織の作り方」というところで、お二方にいろいろ聞いてみたいんです。すごく抽象度が高い質問からします。

プロダクト組織、私はよくプロダクトチームという言い方をしますが、プロダクトマネージャーが中心的な役割を果たすであろう中、どんなかたちのプロダクト組織が、プロダクトが強い会社の中では典型的なのかを教えていただきたいと思います。まずKenさんから口火を切って説明いただいていいでしょうか。

Wakamatsu：最初は私がここ10年働いていたSalesforceのお話をします。Salesforceのプロダクト組織の強さというかすごさは、私はまずスケールの大きさだと思っています。

例えば、私がいたSales Cloudのチームは、私がサンフランシスコで開発を行った5年間にチームが3、4倍ぐらい大きくなって、スクラムチームも最初は6個ぐらいだったのが、15個、20個ぐらいになるような感覚でスケールしていきました。そのスケールの早さ、対応していく早さ。

あとはやはり「年に3回リリースする」という大量のスケールのチームのビジョンを、リーダーシップが同じ目標のゴールに向かって統一させて、実際にプロダクトを作っていく。それがSalesforceの組織の最も強くて、今後もいろいろなところでコピーできたらいい組織作りだと思いました。

Salesforceの強さの秘訣は自律性の高さと“クローンできる”こと

及川：なるほど。今お話いただいたところには、2つポイントがあるかなと思いました。1つは、すごい勢いでスケールしていくのに対して、それに耐えうる組織になっているという話。あと、最終的に巨大化した組織においても、きちっと同一の方向性を向いて、同一のビジョンのもとに作っていけるというところがあると思います。その秘訣って何なんですかね？

Wakamatsu：まず一番重要なのが、スケールといった意味だと、やはり自律性の高いチームが存在していて、そのチームがクローンできる。

クローンというよりもアメーバのようにチームが分裂して、同じ規模かそれよりもちょっと小さいものがどんどん大きくなっていくことができれば、スクラムチームが4個あったのが8個になったり、16個になったりできるようになります。

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

及川：わかりました。ありがとうございます。

みんなが満足するストラテジー構造を作れるかどうかが肝になる

及川：もうちょっといろいろ後で聞きますが、次にGoogleなどではどうだったかというところで。徳生さんに同じく、プロダクト組織はどんなかたちになっているのか、どんなかたちが強いプロダクトを生み出せる組織だと思われるかを聞かせてもらえればと思います。

徳生：Googleのプロダクト組織は、YouTubeや検索というかたちで、今は大きなプロダクト10個ぐらいに組織が分かれています。そこに一応1人のリードがいて、その下にPMのチーム、エンジニアのチーム、その他のチームがあってと、それぞれファンクションごとに分かれています。

Wakamatsuさんがおっしゃったかたちにすごく近いと思うんですけども、実際に働いているPMの観点から見ると、理想の状態は、やはり自分のカウンターパートのエンジニアが誰か、UXのカウンターパートが誰か、それがすべてはっきりしていて、かつストラテジーも、そのチームの中で何を追求するかというのもはっきりしていて小さなチームとして日々の意思決定ができることだと思います。

それがうまく行っていれば、日々働く側から見たら、これだけ大きな会社になってもやっていることはそんなに大きくは変わらない。その裏で、リーダーがいかにストラテジーを組織全体にマップして、各チームが個別に動ける状態を作っていくかは非常に大きな苦労だと思います。

あと、これはGoogleの特徴かもしれませんが、非常にボトムアップな会社で、各自が強い意見を持っています。もちろんどこの会社でも全部トップダウンではやっていないと思うんですが、トップの意向と現場のアイデアの間で往復をいろいろしながら、みんなが本当に満足するストラテジーの構造を作れるかどうかが非常に肝になっている気がします。

Googleで標準となっているプロダクトチーム人数、開発のメソドロジーは？

及川：ありがとうございます。Wakamatsuさんのお話で、スクラムが6個から15個とか20個に増えたということで。Wakamatsuさんにはプロダクトマネージャーカンファレンスでもスクラムのあり方をご説明いただいたんですが、スクラムって一種の組織にも如実に表れるかたちになっていると思うんです。だいたい1つのスクラムチームって、Amazonじゃないですけど、「2つのピザを分け合えるぐらいに」ということで、6人から十数人に分かれています。

Googleの場合、最小のプロダクトチームの数とか、そこでの開発のメソドロジーというか。そういったようなものは共通化されていたり、標準みたいなものがあったりするんですか？

徳生：先ほども言ったとおり、やはり効率的なサイズがあると思うので、全体では10人とか20人とか、そういったサイズの最小単位のチームが多いんじゃないかと思います。

そこが全部スクラムをやっているかというと、そういうわけでもなくて。というのは、私が見た範囲の中でも、プロジェクトの性質が製品によって非常に大きく異なるので。検索クオリティをやっているチームとYouTubeをやっているチームだと、問題解決の内容やタイムスパンなどいろいろ違います。（なので、）必ずしもスクラムを組んでやっている感じではないかもしれないですね。

あとは、Googleならではの大きな成果を出すためには、やはり関係するチームとの連携とか、社内のほかのチームでやっていることをどう利用するかという話が非常に大きい。各自がいろいろなチームと能動的に連携を取ったり、情報を収集したりと動ける人がいると、長い目で見ればプロジェクトが早く進む気がします。

そういう意味では、チーム内でスクラム的に動く部分はありますが、けっこう有機的に他のチームともつながる努力をしながら動いているようなイメージだと思います。

強いプロダクトを作るうえでOKRは非常に重要な役割を占めている

及川：わかりました。あともう1点。ストラテジーという言い方をされていたんですが。GoogleはOKRというやり方で、トップダウン・ボトムアップのハイブリッドかつ、全体として同じ方向性に向かうというところがあると思うんですけれども。やはりOKRがこの強いプロダクトを作るというところでも非常に重要な役割を占めているかたちですか？

徳生：それはそうだと思いますね。あと、OKRというとやはり、クォーターごとの現実的なゴールを決めて、多少ぶれようが優先順位に従ってやっていくという、進捗管理的な要素が大きいと思うんですけれども。その前段にあるのがストラテジーで、組織としてどんなユーザープロブレムやビジネスプロブレムを解決したいかという話があって。そこをどういった個別の問題に分けていって、それにマップしたチーム構成を作れるか。

そうすることで、各チームが各自の問題について、あまりスーパーバイズしなくてもOKRを設定できるようになっていける。そういうOKRの前段の部分も非常に大事になってくるんじゃないかと思います。

Salesforceの“V2MOM”の目的と運営方法

及川：なるほど、わかりました。ちょっとKenさんに聞きたいんですが、先ほど「だいぶ大きなスケールになっても同じディレクションに向かう」という話がありました。Salesforceでは“V2MOM”が有名ですが、ディレクションを同じにするところを具体的にどうやっているかという話と、もしV2MOMが大きな役割を果たしているようでしたら、V2MOMはどういったもので、どのように運営されていたのかも教えてもらえると。

Wakamatsu：ありがとうございます。SalesforceのV2MOMは、Vision、Values、Methods、Obstacles、Measuresという5つのピラーでできています。もともとマーク（マーク・ベニオフ氏）が会社のために作ったものなんですね。

Salesforceという会社がこういうビジョンで作って、こういうバリューを持って、それをこういうふうに達成して、それに対するオブスタクル。「これを成し遂げるためにこういうことに気をつけなきゃいけないよね」というのと。最後に、じゃあ実際にそれをやれたかどうかのメトリクスを測るシステムになります。

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

Salesforce内では、例えばユーザーストーリーやエピックを完了するとV2MOMが完了になるという仕組みまで作っています。なので、本当に具体的な現実性のあるゴールを設定して、それを実際にやり遂げるというふうになります。

Salesforceは各プロダクトを“クラウド”と呼んでいますが、そのクラウドのV2MOMを作っています。なので、「各組織内で今年はこれだけの売上やエンジニアを増やします」というゴールを設定して、それを1年間の単位で分けています。先ほどストラテジーの話もあったと思いますが、そこの中に1年間のゴールとしてストラテジーを組み込みます。

例えば「今年はSalesforceの大きなテーマとしてAIをやりたいです」と言った時に、ストラテジーとして、マークやパーカー（パーカー・ハリス氏）などの創業者の方たちから、「じゃあ来年はAIをみなさんにやってもらいます」という感じで、大きなテーマをいただいて。

それを「じゃあSalesforceのいわゆる営業管理だったらどういうAIが作れるか」「サービスだったらどういうAIを作れるか」を各クラウドに任せるというストラテジーの組み方をして。「こういうものを作ります」という提案を各プロダクトマネージャーが持ってきて、それを最終的にアプルーバルを待って作っていく。

そういったゴール設定を作ることによって、完全なるトップダウンではなくて、テーマをもらって、「こういうことをやってみたい」と提案して。トップダウンではありますが、PMとしても自分が作りたいものを作れるやり甲斐がある。

あとはもちろんビジネスのマッチングもありますが、そういった組織作りをすることによって、非常にやり甲斐のあるプロダクト組織になっていると思います。

及川：やはり、トップダウンとボトムアップのハイブリッドなかたちになるんですね。おそらくGoogleのOKRもそうじゃないかなと思いますが。カンパニーOKRは比較的抽象度が高い。マイクロマネジメント的に「微に入り細に入り」のところまで具体的な指示が下りてくるわけではなく、その部分は各組織がより細分化していく時に、所属している人たちが自らの意見をどんどん言える。そんなモデルかなと思うので、今聞いていて非常に似ている、類似性があるなと感じました。

徳生：おっしゃるとおりだと思います。Googleは、最近の例をあまり出せない会社なんですが、10年前とかそういった頃の例であると、たぶんどこかで既に公開済みになっているし出しやすいと思います。

例えばYouTubeであれば、初期にはウォッチタイム、動画の総再生時間をどんどん増やしていくことを当面のゴールにしましょうという話がありました。当時はプロダクトチームが3つあって、1つは動画を見る人たちをターゲットユーザーとしていて、1つはクリエイター、動画を作る人をターゲットユーザーとして、最後の1つはマネタイゼーションや広告主に集中していました。

Wakamatsuさんがお話されたことに近いと思いますが、各チームがウォッチタイムを増やそうとなった時に、「じゃあ俺たちのチームはいったい何ができるだろう？」と考えられるようになります。

そうしたことを考えて、その中で当然上下のせめぎ合いがあるんですけど、それがどんどん回帰的に下まで連なっていって、組織の全員が「自分がこれをやることで一番上のゴールにこうつながるんだ」とわかっている状態は、非常に大事だと思います。

及川：ありがとうございます。

（次回に続く）