CTOは技術選定において何を考えているのか？　CTO/VP of Eになれるエンジニア、なれないエンジニア - Part2

VPoEを置く理由

及川：もう1個、2行目に書いてあるんですけれども、「CTOと対比して」ということで、昨今「VPoE（VP of Engineering）」というものを置く会社が増えてきています。つまり、CTO以外にVPoEを置く会社が増えています。

「VPoEを置かれたことがあるか？　もしくは置くことを考えたことがあるか？」というところから、「VPoEって何をやる人なのか？」「もしVPoEがいた場合は、CTOとどういうふうに職務を分担するのか？」を考えたいなと思います。VPoEについてはどういうふうにお考えになりますか？

南野：弊社は今、VPoEを置いています。元々置いてなかったんですけど、私が代表になった時にVPoEを設置しました。

役割分担としては何をしているかというと、CTOとVPoEの役割としては、CTOは技術の戦略を立てます。「こういう技術スタックでいきます」「この事業にはこの技術がいいと思います」みたいなところまでしっかり見て、技術で引っ張っていくような役割です。

VPoEは、その組織のことであったり、「どういうチームで、どういう採用計画でやりますか？」「どういう評価制度でやりますか？」「組織をどう活発にしていくか？」「組織をどう強くしていくか？」みたいな役割分担でやっています。

なぜ置いたかというと、リソースとして自分が時間を使えない状態になってきたので、その部分は一定で任せていくと。そういったかたちで置いたのが大きいです。

及川：VPoEはCTOの南野さんにレポートしている？　VPoEは南野さんの部下ってかたちなんですね？

南野：そうですね。現状、僕が代表であるので、そういうレポートラインになっています。

でも、今、CTO候補みたいな人もいます。今3人でやってるんですけど、技術の戦略はそのCTOと一緒に作る。VPoEのところはその人と作るみたいなかたちで、今は3人でうまく回していけないかみたいな新体制でやっています。

CTOと役割を分ける

及川：わかりました。舘野さんいかがですか？

舘野：はい。もう南野さんばっちりの回答をしてくれたと思うので。

及川：（笑）。

舘野：僕も、前職ではVPoEがいて、今のWAmazingでは絶賛募集中です、とここでアピールをさせてもらいます（笑）。

ベンチャー初期というのは、どうしてもCTOだったり、当時のいる社員の中からエンジニアリングのマネジメントを、ある意味「片手間」で両方をいろいろやっている方が多いと思うんですよ。

組織が大きくなっていくと、南野さんが話したように、やはりエンジニアリングのマネジメントや人事組織の活性化、エンジニアがどういうふうに活性化するような組織を作っていくんだろうという実行するときに、そこを専任としてできる方、専任のトップという方がいるほうが裁量や権限でもしっかり分けられますよね。

あと、人が増えていくと、その部分を1人で全部持っちゃうとどんどんずさんになっていくというのがあります。役割分担としてエンジニアリングマネジメント、組織全体を活性化させるというところのポジションの方がいると、組織全体が非常いい方向に進むんじゃないのかなと思っていますね。

そういうところでCTOとの役割を分けて、VPoEの方は本当のエンジニアの人事組織のトップみたいなところでいろいろ活躍します。前職でも活躍してくれてたかなと思いますし、現職だと私自身ですが、さっきも話したとおり、中国のほうも見ていて中国出張とかも多いんですね。どうしても国内で見きれないところがあったりするので、その部分は絶賛募集です。

CTOとVPoEで情報の非対称性をなくす

及川：組織を見る人と技術を見る人、極端なこと言うと、別の人にしましょうっていう話じゃないですか。でも、日々日々のところで、組織と技術って分かれないところもあり、かつ評価っていうのは技術軸でやりますと。

「技術のディレクションは私は見ません。だけれども、その人の評価をしてください。もしくはメンタリングやコーチングはちゃんとしてください」というところで、難しいことを達成しなきゃならない。

例えば、ある技術の方向性で意思決定しなきゃいけないときに「これは僕じゃないから」ってVPoEが言って「CTOが意思決定者です」というふうにするのも、本来なかなか難しいところじゃないかと思うんです。そこはないですかね？

南野：それはめちゃめちゃ大事な話で、僕らだと「お茶会」というかたちで3人が集まって話す時間を必ず設けています。情報の非対称が高いと、お互いに違うことを言ったり、あるいは情報が浸透していないと、間違えた意思決定がなされていくので、常にその情報をシンクして業務を回していくところはすごい意識しています。

そうしないと、CTOが決めたことを、VPoEが違うこと言ってますみたいな感じで、段々と「組織がうまくいってないんじゃないですか？」みたいなネガティブな反応に見えてくるので、そこはすごく意識しているところです。

やっぱり、勝手なみんなイメージで話しちゃうのでドキュメント化をします。CTOとしては技術をどうしていくのかというメッセージを、週次で定例があってメンバーに伝えていくのと、それをドキュメント化してみんなを同じ状態にちゃんと保つというのをできるだけ精度高くやっていくってことを、FiNCでは取り組んでおります。

及川：なるほど。

CTO室の役割

舘野：南野さんがいい話をしてくれたのであれなんですけど。

及川：（笑）。

舘野：南野さんの言うところもそうだなというところがあります。私の場合は、個人的な話をすると1年半周期ぐらいでいろんな飽きがきちゃうんですね。そうすると、エンジニアリングの組織を作るというのも……。「いや、飽きんなよ」って話なんですけど、基本的にできる人に委譲するんですよね。

僕の場合は、VPoEの方がいると今のおっしゃったように意思決定の考え方のズレが起きちゃって「CTOとVPoE、言ってることぜんぜん違うじゃん」みたいなことになっちゃうんです。だけど、定期的にしょっちゅう1on1とかコミュニケーションを取りつつ補正をしていきながら、基本的に現場はもう「そこで決めていいよ」というかたちにしています。

僕自身がその時に思っていたのは、CTOだからこそ経営のほう、経営のことをいろいろメンバーと話すことが多い。「経営視点でどういう方向に走っていくんだ？」は自分の責任だと思っているので。そっちのほうに重きを置いていたので、ある意味「現場のしっかりした大事なところのマネジメントはもうVPoEが基本決めていいからね」と委譲しちゃってたというところがあります。

及川：要はVPoEというのも、単に組織を見るだけじゃなく、もちろんCTO的なところで技術のディレクション決めというところをやっていくと。ただ、CTOレベルが決めなきゃいけないものとある程度もう委譲してというところにまだそこに差があり、本当に経営に大きく影響を与えるようなところの技術の選定うんぬんのところはCTO判断になるところが多いです、というようなイメージなんですよね。

舘野：そうですね。あとは、今振り返ると、僕の中でほかに持っていたのが「CTO室」といういわゆるリサーチをするような部室と、あとはセキュリティ関係ですね。

セキュリティ関係って経営上、本当になにかの問題が起きるとめちゃくちゃ被害が大きい。ただ、問題が起きないとまったく問題がないというなかで、現場を見てる側とすると、やっぱりそこにはそこまで……。とくに営業系というとちょっと言い方があれなんですけど、現場の稼がなくてはいけない部隊だと「とはいえ、先に進めようよ」という圧力が働いてしまいます。

ある意味、そこが分離されていることで「いや、ここって今はセキュリティを担保しなくちゃならないので、ちょっと足並みがゆっくりになるかもしれないけど、万が一のところを考えると……」みたいなところ、セキュリティ関係のところとかはけっこう持ってきたりしたいなというところがあります。

CTOはコードを書いているか？

及川：わかりました。では、次にいきます。「技術的な仕事は何をどこまでやっていますか？」というところなんですけど、これちょうど質問でいいやつがありまして。これなんですけれども。

先ほど「コードを書いてますか？」、おニ人「Yes」っておっしゃっていました。コードだけじゃないと思うんですけど、この次の「技術に触れる時間が短いと、技術選定をすることが不安にならないですか？」というところがポイントかなと思うんですね。ですから、ここで新しい技術の習得とか、ちゃんとアンテナを張る。

もう1つ難しいのは、単に情報として知るだけだと、自分の中できちっと咀嚼するのが難しいと思うんですね。経営に対して意思決定するときに、単に「誰かが言っていた」「ニュースに書かれていた」「これいけそうだ」というふわっとした感覚だけじゃ危ないわけですから、そこを自分の中で咀嚼できるレベルまでには消化しないといけない。そこをどのようにしてやられているかというところをぜひ聞きたいなと。では、舘野さん側から。

舘野：僕自身の判断としては、大きい組織のCTOみたいな立ち位置からすると、基本的に委譲できる人をけっこう探していたというのがあります。

やっぱりすべてにおいて万能なスキルを持つって無理なんですよね。そうすると、なにかのスキルに関しては「この人のほうが自分自身が意思決定するより絶対的確だろう」というメンバーを社内から探して、そのメンバーが意思決定した部分の技術のアーキテクチャを見て、「これが一番いいんじゃないのかな」と技術で信頼できるメンバーに委譲するのは意識的にやっていました。

ただ、そこの部分、じゃあ技術に触れなければいいのかというとそうでもないです。逆にCTOだからこそやれる部分がいくつかあると思っています。

例えば、リサーチ系のことですよね。本当に新しい技術が出てきたと。実際に肌感覚を持たないと意思決定できないと。そういうところは、現場は現場で3ヶ月・半年・1年とかのプロジェクトをいろいろやっているなかでそこができるかというと、なかなかそこはできないと。

でも、CTOの場合だとその部分のリサーチが非常にやりやすく、どんどんできるので、その部分のリサーチを含めて、自分自身でコードを書いたり「実際それが起きると、うちの会社、うちの事業だとどんなことができるんだろう？」と検討する、手を動かすというところをやったりしています。

現状、WAmazingという会社ですと、だいたいエンジニアは10名前後で、そうするとすべてがすべて委譲できるところがあるわけではないので、この部分は自分自身でなにか判断材料とか「危ないかな」と思うところは、率先して開発も含めてやっています。

例えば、最近だと中国で非常に使われているWeChatのWeChat内アプリに「mini program」と呼ばれているものがあるんですけれど、それの開発とかを中国のエンジニアと僕が率先してやっていたりします。その部分って本当に技術的にようわからんものだったんですよね。

ようわからんものだと、「実際にじゃあそれがどれだけ難しいのか難しくないのか、リスクってどこにあるのか？」みたいなところを意思決定して判断しなきゃならないので、そのためにはある程度自分で手を動かして肌感覚を掴むっていうのも大切かなと思いました。なので、そこの開発は僕自身一緒になって現場のエンジニアと開発をした、みたいのがあったりします。

そのあたりの誰かに委譲できるようなところがあるものに関しては委譲する。わからないけど、手を動かさないといけないものに対しては、できるかぎり手を動かすことにしているというのが今なのかなという感じです。

コミットメントの仕方

及川：リサーチ系のところは正直、多少ペースダウンしようが、しばらくやらない時期があったとしても、経営には影響を与えないじゃないですか。でも、中国事業のほうは、ある程度「ここまでに立ち上げたい」というスピード感も必要だったりするなか、自分が実際にハンズオンの戦力として入ると。

でも、経営的なところでその時間を取れなくなることもあり、要はタイムコミットメントができないことが多いじゃないですか。そこのバランスってどうやって取られましたか？

舘野：そこのバランスにおいては本当に言うとおりで、自分自身がボールを持っちゃうと物事が進まなくなります。

なので、例えばさっき言ってたWeChatの開発ですと、最初は僕とそのもう1人のエンジニアがやっていたんですけど、自分自身が「あっ、意思決定ができるぐらい知識が増えたな」という一定のタイミングで、徐々にそっちのエンジニアがメイン開発をするように譲渡していくというところがあったりします。

おっしゃるとおり、本当に自分自身が全部持っちゃうと何事も前に進まないので、そこのところはむしろ「どういうふうにやったらうまく委譲できるのかな？」みたいに、その委譲タイミングを見計らって渡すみたいな。

及川：じゃあ、ある程度「期間限定です」というかたちで動くんですね。

舘野：そういうことになります。

外部のCTOとの情報交換

及川：なるほど。わかりました。南野さんはいかがですか？

南野：そうですね……後攻のときあれですね 。全部言われてる感じが。

（一同笑）

南野：僕がもう1個やっていることとしては、外部の人とうまく付き合うのを意識してやっています。もちろん内部で信頼すべき人とかそのプロジェクトに詳しい人を作っていくというのはあるんですけど、僕はけっこう外部にもそれを目指していくみたいなことをやっています。

CTOネットワークとか、いろんな技術に詳しい人、FiNCに大事な技術に詳しい人のリストを自分で作って、日々それを洗練させていくみたいなことをやっています。

なので、どこが難しくてどこがリスクがあるかみたいなところをしっかり判別していくところが大事だと思っています。「ここハマるんで」「ここ危ないよ」というのをいろんな人から情報を収集していくことはけっこうやっていますね。

僕1人でやるより、同じCTOの人何人かでやったやつのほうが意思決定の精度が上がっていくと思うので、そういったことで精度を上げています。

及川：なるほど。たしか最初に私が南野さんの会社を手伝い始めたときって、エンジニアがまだ20人いなかったぐらいですよね。その時、南野さんが「ここがちょっとエンジニア足りないので、私がメインでプログラム書いてます」ということが普通にあった。今のエンジニアが70……？

南野：現在、約70人ぐらいです。

及川：ですよね。そうするとやっぱり自分自身手を動かさなくてもいい組織になっているなかで、「何をやるか」という判断は、いま舘野さんが言ったところがありますよね。

あと、FiNCはいろんなアドバイザを抱えていて、要は自分の持っていないところはもう専門家から教えを請うということをやられていましたよね。それもなんか今言われたところの証左ですね。

南野：そうですね。うちのもう1人の代表でCFOが、元々ゴールドマン・サックスのゴリゴリのビジネスマンなんです。いかに自分の時間にレバレッジをかけるかというのをひたすら毎日教え込まれます。

「お前の1分をタダで100にできる」、「それは外を動かすことだ」、「もちろん内部も動かす」、というような指導を受けてましたので、それで意識がたぶん根付いてきたというのはけっこうあります。

事業サイドの人っていうのは、底がしっかりした意識を持ってある意味当たりが強い感じの人たちがいると思うんですね。でも、やっぱり開発技術のトップとして当たりに負けちゃダメじゃないですか。そこをどういうふうに対峙してきたかなと。

意見の強い人たちなので、それはまずバイアスを除くというのが1個と。事業を早く進めたいことがみんな同じ目標だと思うので、目標を同じところにセットしていくみたいなところがあります。

「なんでそれやりたいんですか？」「これやる事業の意味ってこうですよね？」みたいな。すると、回り回って「長期的に見たときにこうしたほうが絶対効率いいので、オポチュニティにしましょう」みたいな議論を交わしていくというか。

主張を全部箇条書きにしてあげて、「あなたはこういうこと言ってます」、「ROI的には、技術の面を含めると、これが一番選択肢としていいので」みたいなオプションを出してあげるとかというかたちで、選んでもらうようにしたり。

及川：なるほど。

南野：僕らの会社には意見の強い、引かないタイプの人が多くて。オプションを作ってあげて、いいオプションを探るみたいなこともけっこうやったりします。

及川：確かに、その経営陣っていろんな得意不得意がある方で、技術系のトップに求められるものは今言った論理の部分、ロジックの部分かなと思います。例えばデータで説得をするとか。

技術のトップとして経営陣とどうコミュニケートするか

及川：舘野さん、そういう経験ありますか？　気が強いというか、経営陣いろんな人がいますと。そのなかで技術のトップとしてきちっと意見を交わす秘訣みたいものとか。

舘野：今の会社は幸いにして、どちらかというと技術系の判断が必要なのは僕のほうに委ねてくれるので、これができるかどうかという意思決定は僕にやらせてもらっていて、そのところはあんまりっていうのがあるんです。

ただ、いちエンジニアからどんどんいろんな人と話しながらいろいろやってきたなかで、やっぱりちゃんと説明できることが大切かなと思ってまして。

いわゆる事業サイドで「どうにかして早く進めたいんだけど」という話が来たときに、技術者側からすると「結局それって短期的にはできるかもしれないけど、中長期で見たときに破綻するじゃん」というところをどういうふうに言語化して伝えられるのかというところを、いろいろ説明することができると基本的にほとんどの人って納得してくれるんですね。

納得するか、「自分はこうやりたいんだけど、そういう考えもあるんだったら、ちょっとそっちに任すよ」という話をしてくれて。ここを説明ができないと向こうとしては「えっ、何で早くできないの？」という話になります。

きちんとしっかりと、何でこれができないのか、何でこれをやるべきでないのか、「トレードオフとしてはこういうことができるよ」というところの対話ができると、ほとんどの方は納得してくれます。

できる・できないのところはけっこう気をつけていて、いわゆる「本当にちゃんと対話をする」というところはけっこう心がけていたというのはありますね。

及川：確かに技術者が苦手なところは、技術がわからない人に説明するのが非常に大変なので、どこかで諦めてしまうところがあり、「じゃあいいですよ。やります」とやっちゃったほうが早いとかってなりますよね。ただ、それをやったらやはり負けであり、常に説明し相手に理解してもらうっていうところを心がけていくってことですね。

たぶん私がお手伝いしてる会社でも、ちょうどそのCTO、創業者の人と技術陣の間にみたいに入ることが多くて、だいたい通訳をやるかたちのことが多いですよね。

なので、その通訳も、言うならば経営のほうの言葉を技術陣にわかる言葉にし、技術の人たちの言葉を経営にわかる言葉にして「橋渡し」しているなと思うことがあります。今おっしゃった「説明して相手に理解してもらう」というところを諦めずに続けていくというところは、確かにあるなと思いましたね。

経営状況に基づいた技術選定をどう考えるか

及川：ここで質問に戻ってみて、どういった質問が来てるかを見たいですね……これ3票入っています。

「経営状況を理解した上で技術を選定すると、必ずしも新しい技術が適切でない場合もあるかと思っています。現在自分が所属している会社が上記の意思決定をしている。つまり、必ずしも新しい技術が適切でない。そういう場合、技術に対してモチベーションの高いエンジニアは仕事のやりがいが下がり、離職につながっています。上記のような課題はどのように解決されていますか？」。

南野：まず、僕はいつも……長期的な視点を持つべきだなと思っています。

エンジニアの採用というのは、経営にとって最重要課題だなと思っています。もちろん、エンジニアがめちゃくちゃ大事な、エンジニアをスケールさせていくことが企業にとって最も大事な会社もありますし、事業的にエンジニアがそんなに強くない会社も、いらないというかちょっとだけでいいよという会社もあると思うんですけど、FiNCの場合はすごいエンジニアが最も大事なリソースになっていきます。

そのなかで採用というのは最も大事なことです。もちろん採用とリテンションが大事なんですけど、そこを高めていくときに、1個の経営状態というか、経営に対する意思決定をしたときに、「エンジニアが本当にこれでイケてるのか」「イケてる技術を選定してるの？」というのは1個の経営のKPIに入ってくる思うんですよね。なので、そういうかたちを含めて意思決定をしていくといったことが大事かなと思っています。

及川：なるほど。

南野：ただ、自分が責任者をしていて「これイケてるの？」と思えるものを選らんでいかないと、「なんであなたが技術の責任者やってるんですか？」という質問に対して、「なんかちょっとわからないんで……」とかだと恥ずかしいなと思います。あとは自分が恥ずかしくない意思決定や判断をするかどうか。その2点かなと。

新たな技術を採用するときに考えること

及川：舘野さん、いかがでしょう？

舘野：こちらなんですけど、新しい技術というところはよく言われる話で、「本当にその技術って必要なのか？」みたいなところっていうのはあったりします。

やっぱりその部分って、本当に尖ったエンジニアであるほどやっぱり新しい技術というところ、いい意味での新しい技術をどんどん取り入れていきたいと。でも、そこの部分で会社が受け入れる土壌がなかったら、けっこうすごくミスマッチになっちゃうんですよね。

そうなってその人が辞めていくというのは組織の意思決定上仕方ないことだと思います。むしろそこを許容することで、逆にいびつになっていってしまいます。よくある話だと、新しい技術を取り入れたけど、逆にその技術が社内でしっかり学習できていないので、誰もいじれないものになっていってしまった、みたいなケースもあります。

そういうところを全体のバランスで考えるように意思決定をするときに、新しい技術をその人のモチベーションアップだけで取り入れてしまうと、短期的にはその人は満足かもしれないけど、「中長期で考えるとどうなんだろう？」と考えた上で厳しい意思決定をするというところも1つでしょう。

あとは、できるエンジニアの方って、やっぱり自分自身が技術を使ったことによってどのように会社に貢献できるかを考え、アーキテクチャを考えてくれます。つまり、いわゆるアーキテクト的な役割だと思うので、逆にそこを考えず意思決定をしているだけだと本当に新しいものを使いたいだけになってしまいます。

そこの部分というのは見定めて、例えばアーキテクト的な決定をしていって、その解が「将来いいかたちで置けるよ」というかたちだとすると、「確かに新しい技術を取り入れてもいいかな」というふうに判断する場合もあります。一方で、やっぱり総合的に中長期で考えたときに「今取り入れるべきではない」と判断するとモチベーションが下がっても、やはり全体最適というのがある程度肝になってくると、やらなくてはならないというフェーズが出てくるとは思います。なので、そこは本当に見極めながらの意思決定になるのかなと思ってます。

及川：これは「新しい技術」というのが何を指しているかによってだいぶ違うかなと。

逆に言うと、古い技術を採用し続けるリスクは確実にあるじゃないですか。採用が難しくなるのもそうだし、そもそもオープンソースのフレームワークならもはやメンテされなくなったものも出てきてしまうので、どこかで常に新しいものに入れ替えていくことをしないと、経営上のリスクにもなるところがあります。

一方で、最先端のものを取り入れたとしても、今言われたみたいに、本当に組織でそれを使い続けられるかというところですよね。その技術自身が一瞬注目されているけれども、今後も多くの人・企業に使われ続けるかどうかというところの判断もあります。

「新しい」とひと言で言ったときに、古い技術を使い続けるリスクはあってどこかでモダンなものにしなきゃいけない。だけど、どこまで最先端のリスクを取るべきかどうかというところは、本当にそれが必要とされているかどうかって、今おっしゃったところに関係してくるのかなと思いました。