モチベーションの違いはリレーションシップ作りで解消する　業務委託エンジニアの“一線引いた”状況への対処法

事業組織とプロダクト組織のパワーバランス

及川卓也氏（以下、及川）：では続きまして、こちらいきましょう。「BtoB（Salesforce）とBtoC（Google）では、前者は事業ドリブン、後者はプロダクトドリブンでプロダクトの意思決定を進めるイメージがありますが、事業組織とプロダクト組織のパワーバランスは、両者でどのような違いがあったでしょうか？」。

これは先ほどKenさんに少しお話しいただいたところもあるかなと思うので、ちょっと重複していいですが、Salesforceではどんなかたちだったかと。

Ken Wakamatsu氏（以下、Wakamatsu）：そうですね。そういった意味で言うと、例えばAdobeとかCiscoがどちらかというとプロダクトドリブンなのに比べると、BtoBはやはりどちらかというと事業ドリブンなところがかなりあるかなとは思います。

事業ドリブンというよりも、たぶんBtoBの場合は顧客ドリブンなところがあると思います。カスタマーが何を求めているかが最終的に事業ドリブンになるという意味だと、やはりパワーバランスはもしかしたらPMのほうが。PMが強いという意味じゃないですけど……。

及川：ちょっとお待ちください。Kenさんの声が聞こえなくなった気がします。その間、徳生さん。ごめんなさい。

徳生裕人氏（以下、徳生）：この問題に直接お答えするかたちではないかもしれませんが、Googleの検索で言うと、検索のプロダクトがあって、それに合わせて「アドワーズ」と言われる広告のプロダクトがあって。それは明確にBtoBなんですね。

その2つの関係で言うと、基本的には「検索は広告のことを考えずにユーザー本意のものを作れ」という明確な指示を受けています。広告のプロダクトチームは、検索プロダクトを所与として、その中で何ができるかを考える。

ただ、彼らはもちろんパートナーになるビジネスチームと非常に細かく連携して仕事に取り組んでいるモデルになっています。

及川：Googleの場合の検索は本当にそこが明確に分かれていて。それは私も記憶にあります。あともう1つ徳生さん、もしわかるようでしたら、最近はGoogleもいわゆるSalesforce的なGoogle Cloudの組織があって、そこもプロダクトを作っていると思います。

例えば今、徳生さんが主に見ていたBtoC系のところ。昔ながらのGoogleのプロダクト組織と、Google Cloudのプロダクト組織って、なにか違いは感じられますか？

徳生：感じられますが、あまり語れるほど詳しくはないです。すみません。

及川：わかりました。大丈夫です。Kenさん、復活しましたか？

Wakamatsu：これで聞こえていますか？

及川：大丈夫です。

Wakamatsu：そうですね、そういった意味だと、やはりSalesforceはBtoBなので、事業組織がパワーバランス的には強いと思います。なので、エンジニアよりはPMが強いというよりも、作るプロダクトのビジョンが顧客ベースというか、市場ドリブンであったりするので。そこに対して「じゃあこれを作りたい」という時に、エンジニアの意思が通るかというと、やはり通りにくいかなと思います。

逆にAdobeとかCiscoの時。エンジニアが以前に研究していたテクノロジーをプロダクト化するといった意味だと、非常にエンジニアが強い組織だと思います。

あと1つ感じたのが、Salesforceに行くと、社内のプロダクトとエンジニアというよりも、営業がすごく強かったです。強かったというか、人数も圧倒的に多いし、それこそアメリカの会社は営業の成功を祝うというか、そういったプロセスが非常に多いと思います。だから、SalesforceとAdobeとは本当に真逆でしたね。

及川：やはりそこは冒頭でもお話ししましたが、どちらがいいというよりも、そういったプロダクトや事業の特性に応じて、どのファンクションの比重が大きいか。もしくはそういう組織になじむようなプロダクトマネージャーやエンジニアが会社には集まる傾向があるのかというお話かと思いました。

Wakamatsu：そうですね。

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

業務委託エンジニアの“一線引いている”感覚をどうするか

及川：次（の質問）も、お二人は直接はこういった環境にはいないと思うので回答が難しいところもあるかもしれないんですがお聞きします。

「100人規模のベンチャーです。スクラムチームのエンジニアを正社員：業務委託＝2：8の比率で構成しています」。つまり、業務委託の方が圧倒的に多いということですね。「自立した組織に変えていきたいものの、業務委託エンジニアは一線を引いているように感じられ、組織文化をどのように作るべきか悩んでいます。みなさんの組織は、このような悩みはありますか？」。

これでいうとたぶんないわけなんですが、似たようなことを考えたり、もしくはなにかアイデアがあればということでご回答いただければと思います。

Wakamatsuさんは、日本のCPO協会で、スタートアップを含め日本だとこういったところがけっこう多かったり、お手伝いしているところでもこういうのはあるんじゃないかと思うんですけども、どうされていますか？

Wakamatsu：そうですね。この質問に関しては、まだあまりピンポイントの情報がないので、次回もし同じような質問をいただければ日本の企業のお話をできるかと思うんですけど、アメリカだとやはり非常に少ないですね。特にエンジニアは、ほとんどの社員が正社員という場合が多いです。

ただちょっと似ているかなと思うのが、Salesforce、Googleもそうだと思うんですけど、買収が非常に多いです。買収したチームが連携して何かを作らなきゃいけないことが非常に多くなってきます。

そうなると、正社員と業務委託ではないですが、やはり買収した側と買収された側のモチベーションの違いがあるので、そこをどう高めるかは、非常に力を入れていて。僕の場合は買収した側の会社にいたので、できるだけ気持ちとか文化に寄り添って、モチベーションが上がるようなことをたくさんしようとしていました。

私もイスラエルに出張に行ったり、そのチームと一緒に実際に面と向かって話したり、チームのエンジニアの人たちとも話して、できるだけリレーションシップ作りをすることは非常に力を入れていました。

及川：わかりました。徳生さんなにか。

徳生：直接の回答はできませんが、似たシチュエーションで言えば、アメリカでチームをやっていて、例えばインドで（別の）チームを作ったことがありますが、物理的距離という点では近いのかなと思います。

そういう意味ではもう本当に時間をかけて話し合うしかない部分もありますし、プロダクトの場合、地理的に離れたチームのために、そこだけで自律的に完結できるような明確なスコープを作ってあげられるかが大きなポイントになるんじゃないかと思います。

及川：わかりました。ありがとうございます。お二人も回答に苦労したと思いますが、基本的にアメリカやテクノロジー企業では、エンジニアは正社員であることが当たり前だと。どうしても業務委託だと、自律性、ここでも自立性という言葉が出てきますが、自律的になりようがないと思うんですよね。

やはりコミットメントが圧倒的に違うと思うので、本当はこの比率を変えていくようにしたり、もしくは業務委託でも正社員に近いかたちでコミットしてくれる方を採用するなりをされるのがいいのではと感じます。

（次回に続く）