PMのオンボーディングの工夫
及川卓也氏（以下、及川）：これがもしかしたら最後の質問になるかもしれません。「受ける身にしても提供する身としても、PMのオンボーディングは非常に難しく感じます。定着を早くするため、早く戦力になってもらうためには、どのような工夫をしていますか？」という質問です。徳生さんからお願いしていいですか？
徳生裕人氏（以下、徳生）：Googleの場合は、採用する段階でなんらかのPM経験を持っている方が多いので、その経験をGoogleの中でどうやって適応させていくかを中心に教えるかたちになるかと思います。基本的に、一義的にはマネージャーの責任で、マネージャーとしては具体的なスコープとゴールを定めること、あとはコネクションを助けることです。
どのチームと物事をすべきかを教えて、自律的に動ける場を作るということですかね。その後、日々のプレゼンとかを見たりはもちろんありますが、やはり実現可能なスコープを定義して小さな成功を積み重ねていってもらうことが一番大事じゃないかと思います。
及川：私がGoogleに入った時、もしくはその後に部下をエンジニア側で持った時だったかもしれない。ちょっと記憶が曖昧ですが、最初にウェルカムドックみたいな。なんていう名前か忘れましたが……。
徳生：ゲッティング・スターテッド・ドキュメントですね。
及川：そんな感じのやつですね。最初のスタータープロジェクトみたいなものもそこに書いてあったと思いますが、そういうものは今でもやっているんですか？
徳生：ドキュメントは作る時もあるし、やらない時もある感じです。お話されたように、やはり小さなサクセスを積み重ねて、信頼をあちこちに築いていかなくちゃいけない仕事なので、最初に小さな成功をしてもらうためのスコープを定義するのが1番大事なことだと思います。
及川：わかりました。ありがとうございます。Wakamatsuさん、いかがでしょうか？
Ken Wakamatsu氏（以下、Wakamatsu）：Salesforceもすごく似ています。ほかの会社もたぶん似ていると思いますが、まずできることとしたら、誰と話すべきか。誰がどのナレッジを持っているかを、できるだけ早い段階で共有して、その人たちを紹介したり。
あと、そのナレッジがどこかにあるのなら、そのナレッジへのアクセスをできるだけ早くする。やはりPMの仕事は基本単体で動く仕事なので、そこからできるだけ独立した自律した動き方ができるようなツールを渡すのが、たぶん一番できることかなと思っています。
Salesforceもこれはすごく課題に感じていて。特にSalesforceの中でも、エンジニアはグループでみんな動いてなにかを開発して達成感を出しますが、PMは基本的に孤立している立場ではあるんですよね。部下もいないし、チームとしてゴールを達成するというところではリーダーシップ的なロールではありますが、やはり孤立しているので。
Salesforceでは一時期、PM同士の情報共有のプロセスという組織を作って、1年か2年ぐらい運用しましたが、やはり続かないんですよね。結局みんな忙し過ぎるんですよ。
自分たちのスクラムチームで手一杯になって、ミーティングにも参加できなくなったり。正直、ここはOJTをできるだけ早く周りのみんなに信頼してもらうように、自分たちが早く動くことが重要なのかなと思います。
及川：なるほど。同じように早く成果を出して信頼を勝ち得るために、マネージャーを中心にメンバーがサポートするような、そんな感じですかね。
Wakamatsu：そうですね。
及川：わかりました。
複数のチームで意思決定や実装面でコンフリクトを起こさない方法
及川：ほかにもいくつか質問をいただいていたんですけれども、そろそろクロージングの時間となりますので、質問を受け付けるのはここまでにしたいと思います。
司会者：ちょっと時間が短いですが、よかったらもう1つぐらいいかがでしょうか？
及川：わかりました。ではこちらにしましょうか。「複数のチームが1つのシステムを触ることになると、意思決定や実装面でもコンフリクトが起きてしまうことが多い印象なのですが、チームを分割しながらそれを実現できるコツはありますか？」。
Wakamatsu：私が最初に。これはSalesforceの中でも永遠の課題になっているところです。Salesforceは、もちろん1つのコードベースを中心にやっていますが、さらにその中でもAPIを提供するAPIファーストがマントラになっています。セールスクラウドやサービスクラウドとか、ほかのチームが作るアプリケーションはプラットフォームチームが作るAPIが元になっています。
そのため、プラットフォームチームにすごく負担がかかるんです。もちろん社内でも一番大きなチームではありますが、やはりそこでコンフリクトが起こりやすいので、月に1回、各チームの大きなイニシアティブが何なのかを、各PMが8分間持って、クラウドのプロダクトのリーダーの人たちを含めて、PMやエンジニアも複数参加しながらプレゼンをします。
あとはシステム上にディペンデンシー、依存性みたいなものを作って、ストーリーを作った時に、もしなにかほかのチームのAPIや機能が必要になった場合には、そのストーリーを探して紐づけて。「自分がやりたいストーリーは、このストーリーが終わるまでできないです」ということを可視化しています。
「このプロジェクトで何月何日までにこのストーリーが終わっていないと私たちはできませんよ」「このプライオリティが正しいですか」ということを、間にテクニカルプロジェクトマネージャーがいて、それをスクラム・オブ・スクラムズという、スクラムマスター同士とはまた別のスクラムを1つ持って管理しています。
これができないとスケールができないので、管理にに時間がかかりますが、できるようになると本当に無制限にスケールできるようにはなると思います。
及川：ありがとうございます。
徳生：Googleでも大きくは変わらず、永遠の課題であることは間違いなくて。ただちょっとほかの会社で参考になるかわかりませんが、大きな会社の場合、インフラを作っているチームは多く、彼ら自身も「いろいろなチームに使ってもらえるように」というモチベーションを持っていて、UXも製品間に一貫性を持たせたいと考えていて、そういった水平部門がリーダーシップの後押しを受けて、全社的な連携や方向性の統一を促す場合も多々あります。
あとはそもそもチーム間が競合しにくいように、出来るだけ責任範囲が明確に分割されたチーム作りを心がけていくしかないと思います。
及川：ありがとうございました。時間になりましたので、質問の回答はこちらまでとします。
クロージング
及川：今日は時間も若干足りなくなるぐらい、いろいろなことをお聞きしましたが、クロージングの一言ということで、参加している方々に向けてお二人からお言葉をいただいて締めたいと思います。Wakamatsuさんから、またお願いします。
Wakamatsu：本日はGoogleの徳生さんと及川さんの、いろいろな企業やエクスペリエンスを聞かせてもらい、今後のプロダクトマネージャーとしても私もいろいろ活用できる情報やアドバイスをいただきました。本当に本日はありがとうございました。
及川：どうもありがとうございます。徳生さん、お願いします。
徳生：及川さん、Wakamatsuさん。あとお越しいただいているみなさま、ありがとうございました。ちょっと広告になってしまいますが、今GoogleでもPMを募集しています。PMの仕方、英語の勉強にも非常に役に立つし、女性にとっても働きやすい会社だと思います。
もし、今日出席された方で「興味あるんだけどちょっと」という方は、個別に連絡いただければいつでも質問にお答えするので、ぜひ教えてください。ありがとうございました。
及川：どうもありがとうございました。
