エンジニア、PM、デザイナーは仲良くやれるものなのか？　“三権分立で三方良し”を叶える「プロダクトのゴール」の共有

エンジニア、プロダクトマネージャー、デザイナーは仲良くできるのか？

及川卓也氏（以下、及川）：ここでちょっとトピックを変えて、先ほど徳生さんから「簡単に言うとプロダクト事業部みたいなイメージで10個ぐらいのプロダクトがあり、その中でプロダクトの組織とエンジニアの組織とというかたちになっている」と聞きました。

Salesforceさんはその一つひとつをクラウドと呼んでいるという話ですが、これは今のプロダクト事業部みたいなイメージでいいんですかね？

Ken Wakamatsu氏（以下、Wakamatsu）：まさにそうですね。クラウドの中に開発組織のPMとユーザーリサーチとデザイナーとエンジニアが全部入っている1つの組織になっています。

及川：それぞれエンジニアはエンジニアのジョブラダーがあり、プロダクトはプロダクトのジョブラダーがある。そんなイメージですか？

Wakamatsu：そうですね。三権分立といいますか。できるだけどちらにもよせないことによって、お互いの平等性を持つという意味では同じ組織内で同程度でみんな組織の中に入っているけれど、エンジニアリングのCTOがいて、CPOがいてというかたちのラダーにはなっています。

及川：なるほど。ちょっと乱暴な質問をお二人にしてみたいと思います。三権分立とおっしゃっていて。Googleも同じようなかたちでエンジニアはエンジニアでコードを書くという物作りのコアだし、プロダクトマネージャーは全体でプロダクトの責任を取っていくというのと、デザイナーもユーザー体験というので、昨今とても大事になっているという中、ぶっちゃけこの3者って仲良くやれるものなのかどうか。

「プロダクトマネージャーなんかに決められてたまるか。エンジニアが全部決めちゃるぜ、ゴルァ！」みたいなことが現場では起きることもあったり。そんな中、やはりWakamatsuさんがおっしゃったみたいに、最終的に三権分立で三方良しみたいなかたちでいいプロダクトを作っていけるといいと思うんですけれど。

バランスが崩れる時も、苦労することもあると思うんです。物作りの狭義のプロダクト開発のコアである、デザイン系とエンジニアとプロダクトマネージャーの3つがどんなかたちでうまく協調して進めていけるか。ちょっと苦労した話とか、「現実はけっこうドロドロしていますよ」みたいな話があったらできれば教えていただきたいです。

徳生裕人氏（以下、徳生）：そうですね。組織が分かれているのは、たぶん三権分立ということのほかにも、実際にちゃんとマネージャーとして専門知識に基づいてメンターできるか。あとは、開発の方向が変わるたびに組織全体をいじらなくても柔軟に対応できることとか、いろいろな意味があると思います。

ただ、マネージャーやリーダーシップとして気を遣うのは、組織図に関わらず個別のプロジェクトチームの中でちゃんと優先順位が決まっていて、少なくともUXとエンジニアとPMが同じ方向を向いてやっているかということ。

うまくいかない例としては、もちろん職種によって評価基準が違うために組織が分かれているので、エンジニアの中ですごい成果だと認められるものと、PMの中ですごい成果だと認められるものが異なっているためにプロジェクトの方向性が定まらないとか、そうしたことはあると思います。

ただ個人的には、先ほど言った「ユーザーインパクトとかビジネスインパクトにつながるビジョン」を示すのは、PMの腕の見せどころというか醍醐味でもあります。もし現場で合意できなければ、そこは必要に応じてエスカレートして解決すればいい問題かなと思います。

そういう意味でも、やはりチームが構成された段階で各チームの責任とゴールが決まっているのは、非常に大事なことだと思います。あまりドロドロしていなくてすみません。

及川：いえいえ。最初の責任とゴールとおっしゃっているのは、プロダクトの何をゴールとするかをしっかりと組織内で共有することが大事であるという話ですかね。

徳生：そうですね。プロダクトというか、例えばPMとエンジニアとUXだったら、「我々が持っているスコープで何をゴールにするか」をそのトリオで明確にすることが大事じゃないかと思います。

Salesforceはアジャイルコーチ、スクラムコーチも含めてチームで解決する

及川：わかりました。Wakamatsuさんいかがでしょうか？

Wakamatsu：私もスタートアップとか、どちらかというととんがったテクノロジーを扱っている、Adobeのような会社で働いてきました。Salesforceに移って一番驚いたのが、BtoB SaaSでさらにエンタープライズというか、お客さまが大企業だったりすることで、僕が最初に入社した時にはすごくコンサバティブなサイクルだなと思いました。

リリースが年2、3回と決まっていて、実際にコードを書けるのはリリースごとに3ヶ月ぐらいなんですよね。最初はすごくもどかしく感じました。できるだけクオリティを高く保って、さらにイノベーションをするために積極的にコードを書いたりすることが、どうしてもすごく難しいような仕組みになっています。

なので、たぶん組織的にはいわゆる昔のロックスターエンジニアみたいな、超クールで「俺はこれをやるぜ」みたいな。1人でも「これやるよ」と言うエンジニアが、採用の中ではどちらかというと少ないと感じます。

特に初期のシリコンバレーだと、長時間働いてずっと会社にいるというよりも、エンジニア組織の中でもストーリーポイントを付けて、スクラムを付けて（仕事をする）。Salesforceは、全体のストーリーの中で1人のエンジニアがコードを書ける時間を、下手したら6時間ぐらいで計算しています。

なので本当に協調性が強い人材を探していて。軍隊じゃないですが、決まった期間内に決まったクオリティのものを毎回出す仕組みになっています。それには私はすごく驚きました。

でも実際に働いてみると、やはりその中にはちょっとロックスター気質のエンジニアがいて、私もそういう人たちとぶつかったり。やはりそういう方たちって、PMだけではなくエンジニア同士でもぶつかったりすることがあるので。

そこで、対処法として実際にどのように解決していったかというと、チームを分裂して、1番ぶつかる数人を別チームにして、また違う協調性のキャラクターを持っている人たちと一緒に組むことによって、最終的には両方いいチームというか、あまりケンカをしないようなチームになりました。

そういったプロセスをSalesforceではやっています。課題を解決するためのアジャイルトレーナーみたいな方が社内に数人いるのでお願いして。「うち今、うまくいっていないです」と言って、そのプランニングとスタンドアップとレトロに参加してもらってフィードバックをもらってということをチーム全体で行って解決していきました。

及川：おっしゃっているのは、アジャイルコーチ、スクラムコーチみたいなのですか？

Wakamatsu：そうですね、アジャイルコーチ、スクラムコーチですね。

及川：わかりました。

プロダクトに合ったプロダクトマネージャー、エンジニアを採用すること

及川：Kenさんはアメリカの企業でもSalesforce以外にAdobeやCiscoにもいらっしゃって。今おっしゃったところは会社のカルチャーによっても違うんじゃないかなと思いますが、例えばAdobeやどこか過去のところで、ちょっとそれとは違うパターンがあったらそちらも教えていただきたいです。

Wakamatsu：そうですね。私がCiscoで働いていた時は、ハードウェア、いわゆる今でいうGoProに近いようなハンドヘルドのビデオカメラを作っているチームにいました。そこは、ハードとソフトを一緒に作るチームでまたすごく文化が違うので、おもしろいなと思いました。

同じPMでもハードウェアのPMとソフトウェアのPMと、あとはハードウェアのエンジニア、ソフトウェアのエンジニアでは、ぜんぜん素質というか考え方も違います。そこの中でも格差があって、やはりハードウェアの会社ではハードウェアのほうが上ということをすごく感じて。

ソフトウェアはそんなに真面目にやらなくていいというわけではありませんが、工場で何かを作って6ヶ月先、1年先に準備をしなきゃいけないというプロセスがないので、そこを体験したのがおもしろかった。

あとは、Adobeではエンジニアの中でも、どちらかというとちょっとアーティスト気質の人たちがすごく多かったです。なので、すごく文化がおもしろいというか。音楽を作っているチームだったらミュージシャンが多かったり、映像を作っているチームとかアニメーションにすごく興味があって。

そういった気質の強いエンジニアがいて、そこはやはり妥協しづらいところがあるので、やはりPMとしては、非常に気を付けなきゃいけないというか。うまくその個性とタレントを伸ばしながらも、会社としてお客さまが求めている機能にフォーカスしてやっていくというのが、私が一番難しいなと感じたところでした。

及川：わかりました。今のお話からすると、ハードウェアかソフトウェアかであったり、プロダクトが法人向けのtoBなのかtoCなのか。アーティスティックなものなのかによっても向いている人が違うところがあるかなと。

なので、そもそも採用面のところから、しっかりと自分たちが作るプロダクトに合ったプロダクトマネージャー、エンジニアを採用しなきゃいけないなと思いました。

あと、先ほどの徳生さんの話は、やはりいろいろなコンフリクトが起きることもあって、そこをどうにかするのもプロダクトマネージャーの役割であるというお話だったかなと思います。

エンジニアリングマネージャーとどのように協調しているか？

及川：そろそろ第1部をラップアップしなきゃいけません。2つほど聞きたいことがあるので、簡単に回答を2人にお願いしたいです。

今のお話にあったように、人の面ではそれぞれの職のファンクションにもマネジメントがいる。例えばエンジニアで言うとエンジニアリングマネージャーという存在がいるので、そことプロダクトマネージャーが協調していくであろうことが想像できます。そこがどんなかたちになっているかという話。

もう1つは一発で答えられると思いますが、プロダクトマネージャーとエンジニア。もし可能であればデザイナーまで含めて、人数比はどういったかたちになっているか。

これ、よく聞かれるんです。プロダクトマネージャー1人につき10人ぐらいのエンジニアとか、プロダクトのチームによってもけっこう幅があると思うので、ある程度スペクトラムを持たせて言ってもらって大丈夫ですが、この2つをお願いしたいと思います。

もう1回整理をすると、エンジニアリングマネージャーとどんなかたちで協調しているか。もう1つが人数比の話です。徳生さんからお願いしていいですか？

徳生：つまんない答えからすると、人数比については明確に公開するなと言われています。ただ、よく言われる比率と大きく変わるわけではないです。

先ほどもおっしゃったとおり、検索クオリティだとエンジニアの比重が大きいし、新しく立ち上げるものというとPMとかUXとかの比重が大きくなります。ただ、これは世に出ているものと本当に大きな違いではないと思っています。

エンジニアリングマネージャーについては、エンジニアマネージャーをカウンターパートにして議論をすることは非常に多いです。あと、先ほどのWakamatsuさんのお話を聞いていて思いましたが、やはりGoogleはエンジニアカルチャーも強いし、データドリブンでありたいと。

特に検索をどう改善するかというと本当に無限の方向があるので、なにか基準を決めないと、どうしてもどっちの方向が正しいかはなかなか決定できません。そういった意味でも、やはり数字やデータに強いアナリティカルなPMが信頼されやすい部分はあると思います。

また先ほども話したとおり、例え現場でまとまらなくても、チームがうまくスコープごとに構成されていれば、エスカレートして、より高い目で見てどっちに行くべきかという議論をするだけなので、ある意味健全な話なのかなと個人的には思っています。

及川：ありがとうございます。比率についてはコンフィデンシャルということで教えてもらえませんでしたが、検索するとたぶんQuoraとかでいろいろ書かれているのがあって。それとだいたい同じだと徳生さんに言っていただいたので、興味がある方は調べてもらえるといいかなと思います。ではWakamatsuさん、回答をお願いします。

Wakamatsu：最初にSalesforceの人数の比率はマックスが多くて10人。スクラムチーム全体が10人という数字で決めています。もしスタンドアップが15人以内で終わらないようであればそれで減らすという、本当にすごくシンプルなルールになっています。

Salesforceの10人の中に1つ、ふだんよりもエンジニアが少ない理由があって。ドキュメンテーションもリアルタイムで変更していったりするので、ライターも1人つくんです。なので、だいたいPMが1人、UXが1人、ライターが1人とエンジニアが5、6名ぐらいがマックスの大きさになります。それ以上大きくなるとエンジニアをスプリットしていくので、SalesforceはやはりPMの数が非常に多いです。

エンジニアリングマネージャーとのリレーションシップに関しては、やはりスクラムマスターになるんですね。Salesforceはちょっと複雑で、「エンジニアリングマネージャーがスクラムマスターであれ」という（感じで）、そのチームのスクラムマスターがそのチームのエンジニアリングマネージャーになるとは限りません。エンジニアはちょっとマネージャーの人数が多かったりするので。

スクラムチームのスクラムマスターがいわゆるテックリードに近いロールなので、その人とできるだけ目線合わせをするために、最低でも1週間に1回はウィークリーをやりながら、もちろんプロダクト自体の話をするし、チーム自体「ここがうまくいっていないよね」とか「ここは改善しなきゃいけないよね」というところに関しても、本当に定期的によくミーティングをしています。

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

（次回に続く）