CTOとVPoEの役割と定義
こんにちは、Semiya Software EngineerのRiddleです。
こんにちは、Niddle Software Engineerのひびのです。
このポッドキャストでは、2人でIT業界のキャリアや困ったことなどをいろいろ話して、
IT業界のリアルを皆さんに届けていこうという趣旨の番組です。
届けます。
今日のテーマが、メンバーがCTOやVPoEに求めること。
僕、このテーマを見て、何というか、これまでの職場にVPoE、Vice President of Engineering、略称だけ覚えてる。
VPoE、そういえばいなかったんです。
自分のイメージでも、IT企業の中でも社員数が多めのところにいるイメージだなと思ってて、それこそM3とか。
確かにいらっしゃいますよね。
ちなみにRiddleさんの今の会社、この収録時点でRiddleさんは新しい職場にジョインされているんですけど、
Riddleさんの今の職場にはVPoEいますか?
いません。CTOもいません。
CTOもいない?
明確にCTOって言われる人はいないと思う。
技術のCTOのリーダーみたいなのもいるけど、CTOはいないです。
なるほど。何というか、開発部長的な人がいる感じですね。
まあまあ、そういう感じです。
確かに。僕の今いる職場ではCTO、言ってしまうと吉野さんという方がいるんですけど、まずVPoE、CTO、そもそも僕が何というかどういう人か理解できていない状況から、何だろう、それぞれのCTO、VPoEに求めること、難しいな。
でもスカフトも今、その子会社に出向してて、直立の上司はCTOですね。
そうですね、そうだ、説明が漏れていた。僕は今、都内の某Mから始まるIT企業にいて、
捨ててないでしょ。今まで捨ててなかったでしょ。なんで君捨てたの。
まあまあ、その中のPから始まる子会社、M&A、去年M&Aされたスタートアップ企業に出向していて、
その会社のプロダクトのグロスを支援しています。そして自分の出向先での直続の冗長は、CTOと言われる方ですね。
じゃあCTOに詳しいですね。
詳しいは、そうですね、出向先のCTOとは本当に、週一でワンオンしてるのと、
あと本当にお互い会社にいれば何かしら話すくらいの頻度では話しますね。
が、親会社Mの方のCTO、一回も話したことないなと。
面接では話してない?
面接は話してないです。多分リドルさんは開発本部っていう横串のエンジニアリング組織にいらっしゃったから、
言おうと話す機会があったと思うんです。
僕は入社したときも事業部のエンジニアとしての上院だったので、
面接のときはそこの部署のエンジニアと、最終面接は事業部長だったかな。
そうなんだ。
そうなんですよ。逆に何だろう、最終面接が事業部長ってことで、
この会社は結構部署にそういうハイアリングの権限もしっかり委ねられてるっていうのはいいなと思って、
入社時に心よく思ったっていう。
なるほど。
それこそ会社の大きさにもよりますけど、割とハイアリングはエンジニア組織が責任持ってるとか、そういうところも多いは多いじゃないですか。
そうですね。そういうのも多いです。
リドルさんは最終面接はCTOでしたか?
そうですね。当時のCTOでしたね。
当時の、そうですね。多分僕らが在籍していた、これまでしている間にCTOが1回変わったんですよね。
そうですね。
ちなみに氷野さん、CTOとVPOEは結局それぞれどういう関係なんですか?
どういう役割というか、ポジションというか。
そうだ、これ今日リドルさんから、なんだろう、僕が勘弁をもらっているので、じゃあ説明させていただきますね。
説明してください。
CTOの定義、CTOはチーフテクノロジーオフィサーですね。
これまず、そうだな、CTOとVPOEの違いとして、まずそれぞれ視点というか視座というか、何というか見ているところが違うという定義があるらしいです。
CTOについては、まずミッションとして、企業のビジネス目標を達成するための技術戦略、技術ビジョンを策定し、方向性を示す。
VPOEのミッションとしては、技術戦略を高可能な開発計画に落とし込み、エンジニアリング組織をスケールさせる。
なるほど、定義。違いはありますよね。それぞれ外向きか内向きか。
そうですね。CTOって経営層の面なので、どちらかというと会社の育成を決めるというか、数年かけてこっちの方向にシフトしていきましょう、ここにかけましょうみたいな感じの舵取りをする人だと思っていて、
VPOEはその決定の下、その決定がちゃんと実際に実施できるように、いろんな人を採用したりとか、組織のカルチャーを作ったりとか、技術的な投資をしていったりみたいなことを、実動部分でバックしたのかなっていう、今自分の中でイメージしています。
フォーカス領域の違い
なるほど、なるほど。
なんかそう言われるとあれですよね。たぶん明確な上下はさておき、明確な上流下流は存在する感じです。
そうですね。CTO、経営層が上流にいて、その指示を受けてとか、流れを汲んで動くみたいな、VPOEが動くみたいなイメージですかね。
なるほど、わかりやすい。そしてこの説明だと、VPOEっていうのは言ってみたら、エンジニアリングマネージャーの文脈というか、言ってみたら同じ種類の仕事ですよね。
傾向的にはそうですね。自分の理解だと、エンジニアリングマネージャーがやっている仕事がいろいろあると思うんですけど、それをやりやすくするための土台を整える仕事だと思ってて、
例えば、日比野さんもEMというかマネージャーやってると思うんですけど、この人を雇うときにどういう基準で雇うかとか、雇ったときにどういうグレードを適用するのかって、グレードみたいな概念が用意されてないと無理じゃないですか。
そうですね。
それを各エンジニアリングマネージャーが個別に定義するのは難しいので、それだったら組織全体でこうあるべきみたいなのを決めて、EMが動きやすくしてくれるみたいなのをVPOEが責務として持ってるのかなっていうですね。
なるほど、組織全体で共通で使えるというか、エンジニアリングの指標みたいなところですかね。
そうですね。だから、アルチャーレッキーだっけ、エンジニアリングの採用の際に使うスライドとかあるじゃないですか。こういう人を採用したりですみたいな。
はい、ありますね。
プロダクトベースのところは、もちろんプロダクト側のエンジニアリングマネージャーが作ると思うんですけど、もっと会社全体のやつとかは、人事が作ってるのか、VPOEが作ってるのか、VPOEから指示を受けた誰かが作ってるのか分からないですけど、全体的なのでVPOEのタスクっぽい気がしますね。
なるほど。じゃあそこのなんというか、エンジニア向けカルチャーデッグの責任者というか、そういうところも兼ねているっていうことですね。
たぶん本当にいろいろあるんじゃないですかね。全社で統一的に使うノーションみたいなツールだったり、社内のブログ記事を管理する仕組みだったりとか、社内イベント、いろいろやって情報交換をかせてかせてよみたいな、こういうのも含めて全部だと思います。
はいはいはいはい、なるほどなるほど。言ってみたら、でかつなんか今の話を聞いてると、僕のイメージとしてはやっぱりエンジニアリングマネージャーのマネージャーみたいな位置付けのこと?
確かに、まあそうですね。会社の規模によって一段上かもしれないし二段上かもしれないしみたいな感じですよね。
なるほどなるほど。あとそうか、VPOEがいる会社っていうのはそれこそ何というか、CTOなり開発部長なりがそこまで一人で見切れなくなるタイミングで、そのCTOとVPOEが分かれるみたいな感じなんですかね。
いやーどうなんですかね。理想はそうだけど、例えばミクシーの場合ってCTO一人しかいなくてVPOEっていないじゃないですか。でもエンジニアは数百人で規模いるわけで。
そうですね。
そうなるとCTOがよくやるっていうのは現実的じゃないですよ。
確かに確かに確かに。
だからミクシーのCTOは大変そう、大変そうっていうか大変だっていう話をコミュニに挟みました。
いやまあ話したことない僕から見てても常に忙しそうな気はしてますけど、これは主観ですよもちろん。
いや忙そう。
まあそれで言うとミクシーはもしかしたらあれ、ミクシーって言っちゃった。ミクシーはもうそろそろVPOEっていう役職が求められているフェーズかもしれないですね。事業機構で。
そうですね。
とはいえなんか事業部で結構カラーが違ったりするから、事業部ごとに作ってもいいかもしれないですね。
確かに。これこそあれですよね、ミクシーだとその事業部ごとにエンジニア組織がしっかり組成されてて、そこごとにカルチャーがあって、
なんならもうそこだけでルール作っちゃって、うまく運用できてるんで横展開しますねみたいな動きのままありますもんね。
見てねとかそんな感じじゃなかった。
結局なんか名前ないけど、役職としてVPOEって名前がないけど、それに近い仕事をしてる人は各組織きっといるんだろうなって感じですね。
これは一理ありますね。なるほど。
そんな感じでCTOやVPOEのなんとなくの区分けというか役割みたいなのは見えてきましたね。
はい、見えてきました。そしてせっかくリドルさんからまあまあ詳細な勘定をいただいておりまして、他にも紹介できそうな項目があるので説明させていただきますね。
次じゃあCTOとVPOEの違い2つ目。
これフォーカス領域の視点で主な役割責任を述べると、
まずCTOの方は長期的な技術ロードマップ、R&D、アーキテクチャー選定、技術リスク管理、デザインセキュリティー、方針。
なるほど、こういうところをフォーカスして業務に取り組んでいますよ。
一方でVPOEはプロダクト管理プロセス、品質管理、リソースアロケーション、人の配置とか、組織の配置とか、あとは培養育成、評価制度に関することだったり、組織文化に関すること。
なるほど、確かにそうですね、多分技術リスク管理、アーキテクチャー選定とか、それからVPOEの品質管理みたいなところって共通する領域もあるとは思うんですけど、
会社全体もしくは業界に向いているか、それとも社内の実際の実土舞台に向いているかみたいな違いがありますね。
そうですね、多分最近ので分かりやすい例で言うと、最近SaaSの企業がのきなみにAIエージェントをやってきますみたいな、このままヤバいですみたいなのを意思決定してると思うんですけど、
あれは多分CTOからの発案だと思うんですよね。
そうなのかな。
もちろん、スタンドコロがいいCEOの方とかがやるケースもあると思うんですけど、
CTOの役割と責務
基本的にはCTOの方が技術管理が一番高いはずなんで、このままやると経営的にまずいし、AIエージェントの可能性は今これぐらいで、中長期的にはこれぐらい行きそうだから、
こっちにシフトしていかないとまずいよね、みたいなことを多分思いついて、それを経営会議とかにあげて、
全員の合意、全員か分からないですけど、過半数以上の合意を得て、そっちにシフトするみたいなのを経営戦略として盛り込むみたいな、そういう活動されてるんじゃないかなと思いますね。
確かに、経営会議の場でGitHubが最近こういうサービスを出して、オープンAIからはこれが発表されそうでみたいなことを話せるのって多分CTOだけですもんね。
そうですね。そういった意味で経営としてどっちに舵切るかみたいなのを、技術の側面からいろいろあれやこれやっていうのをするのがCTO。
よく言えば技術を使って経営を推進していくみたいな感じですかね。
そうですね。
なるほど。
わかる。
わかりますね。
だからアーキテクチャって言ったら、個別部隊的なサービスのアーキテクチャとかではないはずなんですよ。ある程度大きい会社のCTOだったら、それは現場に任せてるというか。
もちろんプロダクトがまだ小さくて、そのプロダクトを半分プレイングしてるようなCTOの方もいらっしゃると思うんで、そうなると全体のアーキテクチャを決めるみたいなのもCTOとしての責務だったりすると思いますけど。
そうですね。
全社としてこういうクラウドを使っていって、会社としてAWSに対してパフォーマンスを示せるようにするみたいな、ネゴシエーションの部分とかはCTOの領域な気がしますね。
なるほどなるほど。確かに。わかりやすい。
VPoEの役割と組織運営
VP用意なんですか?
VP用意は、主にそれこそ現場だったりとか開発チームに関することで、開発プロセス、品質管理、チームの配置だったりとか、採用に関することとかですかね。
じゃあさっきのAIエージェントの例で言うと、AIエージェントやるって決まったから、それに向けて組織再編したりとか、人材の採用の組織変えたりとか、AIの人材を置くとか、そういう感じなんですかね。
なるほど、確かに。動いているチームの中で、この人たちにAIを推進するという役目を与えましょうとか、これくらい効果が出たから、採用の幅をこれくらい減らしたり、または増やしたりしてもいいんじゃないかとか、そういうところになってるってことですね。
そうですね。じゃあここまで分かったところで、CTOやVPOに何を我々は求めていきたいのかっていう、1ファイルとして。
1社員として。
じゃあまずわかりやすいCTOからいきますか。
難しいなぁ。いやでも、求める、いや、求めること。
CTOからしましょう。
求めること、いや難しいっすね。
個人的にはCTOには、なんか決断力と、我々が知らない、いろんなセンシブな情報に社内外問わずアクセスするので、それをベースにした角度の高い意思決定力って、求めたいっすね。
そうですね。
あとそれをちゃんと現場にきちんと説明できる説明能力も欲しい。
はいはいはい、そうですね。
例えばですけど、いや我が社は明日からブロックチェーンにフルベッドしますみたいなことを急に言われた時に、え?みたいな話になるじゃないですか。
そうですね。それはおっしゃる通り。
私今働いてるんだけど、今後はブロックチェーンで生きていくのか、それなんかキャリアとか考え直さないといけないかもしれないみたいな話になるから、
そうなると、ブロックチェーンがなぜ今収録すべきで、それは皆さんの生活にこういうふうに生きてきます、皆さんのスキルアプリもつながりますみたいなことを、なんかきちんと説明していただけると非常に嬉しいなと思いますね。
そうですね。おっしゃる通り。
そこで明確に何というか、全社員に対して理由が説明できれば納得できるかもしれない。かつ、その後VPOEが動きやすいかもしれない。
そうですね。あとどれくらい本気で行こうとしてるのかみたいなのも教えてほしいかもしれない。
そういう意味では、たぶんCTOが発表するってことは、主に技術戦略とかそういったところだと思うんですけど、何というか、CTOが技術戦略を発表するってことは、それすなわち何というか、経営会議の意思を代弁しているというか、
なんかそういう意味ではやっぱり、CTOの言っていることは経営層の判断だっていうことで、やっぱり納得できる回答、説明は欲しくなりますね。
そうですね。やっぱ欲しいですね。割とどこの会社も経営とその下の従業員は乖離していることが多いので。
そうですね。特に大きい会社になればなるほど距離が遠いですもんね。
そうですね。
なので、いろいろたぶん考えた上で、たまの良い人たちが上にいるはずなんで、それたちがもう熟慮に熟慮をかかんじ出した答えなんで、我々がね、パッと考えつくようなものじゃないと思うんですけど、
同じ答えだったとしても、そこのロジックをしっかり教えてくれると嬉しいな。
確かにそうですよね。
あと他にありますかね。
他に、そのCTOに求めることですよね。
そうです。CTO。
何というか、今説明した定義ってまあまあ大きい会社。僕らが在籍している、していたいくらいの規模だと思うんですけど、それこそVPVがいるから。
ただ、僕も今の会社でさっきCTOと話したことがないっていうくらい距離だと思う。
逆に、説明能力と推進力くらいしか求めることがないなっていうのが、今のところの正直な感想なんですよ。
逆にディドルさんは何というか、CTO直下の都市にいらっしゃったじゃないですか。
他に何かありますか。
ちょっとこれ、VPを言いながらCTOなのかちょっとわかんないですけど、会社のブランディング向上みたいなところ、やっぱり欲しいなと思っていて。
やっぱりどうしても人ってどこの会社にいたかみたいなところでアンダーすることも多いじゃないですか。
それは転職活動もそうなんですけど、それ以外にもタイミングであると思っていて。
その時に名前が売れている企業とか、所属していることが売りになるような企業であればあるほど嬉しいと思うので、自社のブランディング向上。
これCTO一人押しすぎても良くないかもしれないですけど、それに引いれてるとより嬉しいなと思いますね。
確かにそうですね、おっしゃる通り。そうなると圧進力だったりとか、ブランディング能力。
自分はいるだけなんだけども、どんどん会社が有名になっていく。
あれ、逆にね、そんなに大きな会社だったら、あれ、そこにいたの?みたいな思われちゃうかもしれないけど、まあそれは良いでしょう。
そうですね、一方でここからはVPOEに求めたいこと。
それこそ多分さっき話があったように、主に経営層の技術戦略、ビジョンだったりを現場に反映させる役がありますよね、最初に。
そうですね。
そういうところで現場に浸透させる実行力というか推進力というかは欲しいですよね。
確かにそういうリーダーシップというか旗振って、こうです、私たちって決めてくれると気持ちいいですね。
CTOとVPoEに求めること
多分、組織が大きくなればなるほどチームの数が増えて、ここではこれくらい浸透してるけど、ここでは数値で表せたら何十パーセントだね、みたいなところもあると思うので、
そういう時に、それでいうと状況を細かく確認して、現場を見る力と現場をフォローアップする力、みたいなのをVPOEには求めてもいいんじゃないかなと思います。
どういうフォローアウトが欲しいですか?
具体的な。
マネージャーとしてどういうフォローが欲しいですか?
マネージャーとして、そうだな、なんかそれこそVPOEとマネージャーの違いで言うと、マネージャーって自分のチームだったり自分のグループだったりに基本的には注力してるものじゃないですか。
他のチームと比較してとかだったり、他の組織ではこういうことがあって実際にうまくいっているから、みたいなチーム間での横展開を推進する。
あと同時にVPOEはリソースアロケーションの権限も持っていることが多いとされている。
それによって柔軟に例えばこの人を1人こっちにも派遣すれば、もしかしたらうまくいくかもしれないみたいなところを考えて提案してくれたら嬉しいかなと思いますね。
確かに。ちょっとバイネームまで覚え切るのはちょっとVPOEが何人まで見れるかわかんないのであれですけど。
でもなんかいろんな手札を持っておくというか、今ここはこういう仕事が空いてる。それだったら紹介できるけどみたいなのは柔軟にやってもらえると嬉しいですね。
そうですね、おっしゃる通り。そういう意味では手札の数とか対応力、打ち手を幅広く考える力。
そこはどうしても、もちろん1つのチームを見ていて出てこない視野みたいなのは欲しいですね、やっぱり。
あと、どうやって計測するか全く想像つかないんですけど、チーム力みたいなのもあると思うんですよ。
プロダクツとしてはあんまり成長できてないかもしれないけど、チームとしては結構力がありますよねみたいな。
もしくはプロダクツとしてめっちゃ成長してるんだけど、チームとしては結構ガタガタじゃないかみたいなのもあると思うんですよ。
ドメインによってだいぶ違いますし、状況とかにも違って。そういうものを単なる売上とか利益じゃなく、何かしらで高評価、VPOEができればチーム別の表彰じゃないけど、
いいチームのエッセンスみたいなのを他のチームに入れていくみたいな。
おっしゃる通り。
できるのかな、そんなこと。
でもそれこそVPOEは複数のチームが配下にあるという立場ではありますもんね。
そうですね。
確かにそれをやることについては、もしやるとなったら最も適切な人なんじゃないかなとは今思いました。
やっぱりそうなると、全体の方針を示して強く旗振ってくれつつも、現場のことを隅々と見てくれる。
そういう人みたいですね。
確かに、人を選びそうですね。
そうですね。
エンジニアリングマネージャーを本当にマネージメントロールのみでやってる人とかは、もうちょっとでかい規模で見たいって人いると思うんですよね。
今ってエンジニアリングマネージャーっていう組織設計っていうよりはチーム設計ぐらいなことが多いと思うんで、チームじゃなくて組織を作りたいっていう人もいていると思うんで。
そういう人にとってはエンジニアリングマネージャーから次キャリアアップの時に見据える職種ではありそうですね。
VPOEの役割と課題
新人VPOEに厳しいかもしれないんですけど、経験のないVPOEが入っていきなり謎の組織改変とかやられたもんね。
いろいろめんどくさいじゃないですか。
何か知らんけど名前変わったんだなとか、組織偶然じゃなかったんだなみたいな、何の意味あるんだこれみたいな。
それが組織改変って変えてピンポイントな効果が出るまでにどれくらい変われたとか全然わかんないですけど、経験が少ないとやった時の効果とか本人もわかんないじゃないですか。
どれくらいインパクトあるのかとか。
そうですね。
プライベートそういうのは経験有だからちょっとやってもらいたいなっていう。
何というか言葉にするなら、組織の振る舞いをわかっている人?
そうですね。すごい組織の作り方を知っている上で、経験とともに作れてきて。
どう選ぶな本当に。
しかも組織によっては別に垂直の指揮命令権が上に上に行くタイプじゃない組織もあるじゃないですか。
ホモロジーだったかな、特定のマネージャーやリーダーになって相互にどうのこうのみたいな。
はいはいはい、ありますね。
聴いている組織とかそういうのもいろいろあると思うんですけど、そういうのを考えると別に単純に自分が全部を見るみたいな感じじゃない組織設計もあるから、どれにするかって自由だと思うんですけど。
でもね、何も知らない人がいきなり来て、今からマネージャーという制度をなくしますかいきなり言われたら現場混乱みたいなね。
でもそういう大きな話ってどっかで試さないと一生試せない。
なんかそういう意味ではあれかもしれないですね、新任のVPOEっていうのはVPOEのロールを得るのは最初は元々現場にいてそこから同じ組織でVPOEになるが、なんというかスムーズに動きそうですね。
そうっすね、そうじゃないっすよね。
僕も転職活動の時にビズリーチ使ってた時にめっちゃいっぱいなんかVPOE候補みたいなオファー来て、無理やわと思った記憶があります。
無理無理。
こんな3ヶ月ぐらいいた部署でVPOEなんてやれないよ。
まあそうっすよね。
あとはラダーの話なんですけど、ラダーっていうのはあれですよね、評価基準の話ですね。こういう評価を満たしたら上に上げるよ。
あれも結構職種によって全然違うから、まあ用意してあっても結構何ですかね、抽象度が高いケース多いじゃないですか。
そうですね。
それをいろんなエンジニアの職種ごとに現場でアレンジして使ったりとか、マネージャーごとにいいように解釈して、もう上げたり下げたりとかね、横行すると思うんですけど、どこの会社は。
それをきれいに整理してあつ職種ごとに。
例えばエンジニアとしてもモバイルなのか、その中でもゲームなのか、そうじゃないのか、いろいろあると思うんですけど、そういうのにちゃんと対応していくつかやってくれると。
確かに確かに、あと本当に大きい組織になってチームが大きくなったら逆に各マネージャーのその現場に向けての調整を中央で監視するというか。
特典の事業だけなんかのきなみ評価低いみたいなのはおかしいはずなんで、その訂正とかになると特に。営業とかはなんか売上とかにもかかってくるからあれですけど、能力種はね、普通になんか平均的になるはずじゃないですか、普通に考えたら。
そうですね。
だからマネージャーの探し加減で変わってしまうのは、うまくこうご意見をいろいろ監視してほしいと。
そういう意味でも本当に組織間、チーム間の比較を常にし続けるみたいなところは求めたいですね。
CTOとVPOEの違い
そうですね。
ちょっとじゃあまとめますか。
CTOとVPOEはそれぞれまず役割が違うよっていうことをお話ししたね。
具体的に言うとCTOは技術、戦略を考えて経営層として、一方でVPOEは方針に基づいて現場を動かすトップであるという。
それぞれCTOにはビジョンを説明する力だったりとか。
あとはいろんな選択肢の中から何が今一番必要なのかみたいなことを正しく選び取る力とか。
そうですね。
案外的なブランティングの向上とか。
そうですね。それはテック企業として。
一方でVPOEは何でしたっけ。
技術の実行に関する役割なので、その技術的な戦略をもとに現場全体に反映させる実行力だったりとか。
本当にチーム組織を比較して細かいフォローアップをするだったりとか。
組織ごとに戦略が浸透していくことを推進することを求めたいですね。
はい。ありがとうございます。まとめ。
慣れてない。
はい。ということで今回はこれで終わろうと思います。
このポッドキャストはハステルITで皆様からの感想やコメントをお待ちしております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。
ありがとうございました。
ありがとうございました。
