トップが技術やプロダクトに対するリーダーシップがない場合の対処法
及川卓也氏（以下、及川）：こちらも話が尽きませんが、時間もなくなってきたので、みなさんからいただいている質問を見ていきたいと思います。けっこうタフというか、日本ならではの質問もあるようなので、そこも含めて一緒に考えていきたいと思います。
投票が多い順ですが、1問目。「トップダウンとボトムアップのハイブリッドがベストなのはとても理解できるのですが、トップが技術やプロダクトに対するリーダーシップがない場合（数字の縛りだけはちゃんと落ちてくる）は、どのように対処すべきでしょうか？」。
これは私が今日本企業をお手伝いしていて、まあ、あるんですよね。みんな苦労していますが、お二方から見て何かアドバイスがあればぜひお願いいたします。
Ken Wakamatsu氏（以下、Wakamatsu）：BtoBのエンタープライズをやっているので私から先に。これはたぶん多くのみなさんが同じような課題を感じていると思います。
会社、組織によっていろいろ違うと思いますが、プロダクト組織というか、部署の中で開発組織と営業組織を一緒にして、プロセスに対してあまり大きく影響できない仕組みになっているのが、実はSalesforceなんですね。プロダクト組織は本当にエンジニアとプロダクトとデザインだけで、一時、プロダクトマーケティングが行ったり来たりしてはいるんですけど。
営業チームは基本的に全体の数字を持っています。なので、会社としての数字を持っていて、プロダクトとしての数字を持っていません。Salesforceの場合、プロダクトチームはプロダクトの数字を持っています。その数字は、毎年かなり高くなってきます。パーセンテージ的にも「えっ、こんなの不可能でしょ？」というような数字を出してきます。
それを達成するためのことをやっていただいているのは、プロダクト側はプロダクトとしてできる限りのことをやって、営業側が売ることにフォーカスしてくれるというバランスで。
Salesforceの中で非常に力を入れているのは、売れるものを作る。売れるものを作るというよりも、お客さまがニーズとして必要としているものをできるだけ作るというところに力を入れています。そこは、正直なところ、やはりトップダウンのビジョンで来るものが多いので。
そこをうまくマーケティングして、営業してくれて、サポートしてくれるものを作り、結果として数字を出せるようにするということは、一番重要だと思います。
開発チームは営業ができないので、最終的に売れるか売れないかは、やはりマーケットもあるし市場もある。コロナとかいろいろなものに影響されるので、プロダクトチームは一番いいプロダクトを作るところにフォーカスすればいいかなとは思っています。
及川：わかりました。徳生さん、お願いします。
徳生裕人氏（以下、徳生）：僕はBtoCにしか関わったことがないので、あまりお金の数字に追われたことがありません。ただGoogleが恵まれているのは、マネージャーはほぼすべてエンジニアかプロダクトマネージャーのバックグラウンドを持っています。
トラフィックにしても、野心的だけど達成可能なゴールを設定できるかどうかは、リーダーシップのスキルだとは思うので。そもそも「不条理な数字が落ちてこないようにする」という答えになるんじゃないかと思います。
後から自律性を育てていくことは可能なのか？
及川：では次。これはエンジニアという言い方をしてしまっていますが、「自律性を持ったエンジニアばかりではないと思うのですが、後から自律性を育てていくことは可能でしょうか？」と。
これはエンジニア縛りではなく、プロダクトマネージャーや、プロダクトを作るコアなメンバーで、自律性は採用時に見なきゃいけないのか。それとも、採用後になんらかのかたちで育ませていくことは可能かどうかというところ。これは日本ならではだと思いますが、ぜひ何か意見を聞かせていただければと思います。
徳生：そうですね。プロダクトマネージャーの観点で言うと、評価基準とかに絡む部分かなという気はします。Googleの場合、成績評価の上ではやはりインパクトが一番大事です。あともう1つあるのは、ほかのチームから見たピアレビューが評価の中で非常に大きなウェイトを占めるので、実際に数字を出しているだけではなくて、それがほかのチームから見ても正しいやり方でやっているかどうか。
そういったところが評価されるので、それを上げようとすると、いろいろと事前調整をしたり、自律的に動かざるを得なくなります。慣れもありますが、マネージャーの協力や正しい評価基準があれば、自律性を育てることはもちろん可能だと考えています。
及川：Wakamatsuさんはいかがでしょうか？
Wakamatsu：そうですね。私もPMの観点から見て、もちろん後から自律性を育てていくことは可能だとは思います。ただ、Salesforceの中だと、どこで自律性を発揮するべきかという論点になると思うんですが。
例えば、それこそスタンドアップの中で、ストーリーが進んでいないところにちゃんと自分から「進んでいません」とはっきり言う。特に、新卒とか若いエンジニアがさらに進んでいない場合、「じゃあそこをちゃんとサポートするような仕組みができているのか」とか。
あとは、例えばプランニングの時に、自分のストーリーをちゃんと説明できるようになるか。「正しい例は、こういうふうにストーリーを組んでタスク作りをして、ストーリーポイントの提案をすることによって、みんなを説得できるよ」という、そういったいい例をどんどん見せて学ばせるということをSalesforceではすごく心掛けているので。
そのプロセスをできるだけ平等にして、みんながちゃんと意見を言えるといった意味の自律性は、最初はすごくシャイな人や、あまりしゃべりたがらないエンジニアも中にはいますが、時間が経てば、「これを言わないとチーム全体を引っ張ってしまう」という意識がどうしても芽生えるので、徐々に出てくる場合が非常に多いかなと思います。
及川：なるほど、実際に自律性を発揮しないとチーム全体がスローダウンしてしまうという状況を、ある意味、可視化するようなかたちで本人に気づいてもらうというやり方ですかね。
Wakamatsu：そうですね。
（次回に続く）
