スタートアップのCTOのジョブ
たまにはCTOっぽい話を書いてみようそうしよう。
「あなたはCTOに何を求めるか」
対象読者はCEOを想定してみる。
仕事のスコープ
あなたの仕事
「あなたは仕事でなにをやっていますか？」
これは簡単に答えられる場合もあるしそうでない場合もある。例えば、エンジニアの仕事がなにかと聞かれたらわたしは即答できない。開発すること？うーん？会社やチームによってかなり異なるし、どの程度の粒度で答えればいいのか少し迷ってしまう。
わたしが誰かの仕事、すなわちその人がなにをやっているかを知りたいときには、その人は誰とコミュニケーションをとっているかとそのコミュニケーション相手との仕事の境界はなにか、そしてその人は何を決定しているかということを考える。
そのエンジニアは誰と話すことが多いだろうか
プロダクトマネージャー
デザイナー
エンジニア
セールス
カスタマーサクセス
ユーザー
そのエンジニアがプロダクトマネージャーと話すときに、エンジニアはなにを決めて、なにを決めないだろうか。エンジニアなのでおそらく何らかの開発をしていると思うが、上記が分かれば
会社やチームによってかなり異なる
これがわかる。すなわち、その人の仕事のスコープがわかる。
CTOの仕事
「CTOは仕事として具体的になにをやっていますか？」
CTOは技術的な意思決定に責任をもつかもしれない、プロダクトに責任を持つかもしれない、組織を作るかもしれないし、全部やるかもしれない。そうではなく、CEOの右腕になることがCTOの最も価値ある仕事かもしれない。
CxOの本質的なミッションは企業価値を最大化することだから、上記が必要なこともそうでないこともある。また、必要なときと必要でないときがある。CxOがある期間にフォーカスできるトピックは1つか2つだけだ。
これらに左右されずに、コミュニケーションだけでCTOの仕事を定義する方法を考えてみる。要するにさっきの話をCTOに適用する。ここでは、会社の規模を社員が100〜150人程度、エンジニアが30〜50人程度と想定してみよう。
するとCTOの仕事は
微妙な図ができてしまった・・
フォーカス
経営メンバー
エンジニアリングマネージャー
大雑把に言ってこの3つになる。
CTOのジョブ
フォーカス
その人がCTOになるとき、明示的か暗黙的かはともかくおそらくなにかわかりやすい成果を期待される。
スタッフエンジニアにスタッフプロジェクトが期待されるなら、CTOにスタッフプロジェクトが期待されないということがあるだろうか。期待される成果がそのCTOの中長期的なミッション、あるいは最初のフォーカスになる。例えば
プロダクトを成功させる
プロジェクト管理やオペレーションフローを効率化する
開発の組織や文化をつくる
コストやリスクの管理体制をつくる
一方、プロダクトや会社のフェーズの変化に伴って、フォーカスすべき事項が変わることはあるだろう。というよりフェーズが変わるのだからフォーカスも変わるのが自然といえる。
次の12〜18ヶ月で1つか2つ成し遂げるとしたらなにか、これがそのCTOの仕事になる。
経営メンバー
一方、CTOは経営メンバーである。そして、経営チームのスコープは会社で起きること全てである。どうするか。これをCxOで分担する。
例えば、経営チームがCEO、CFO、CTOの3人から構成されるなら、CTOの仕事はCEOとCFOがやらなかったこと全てになる。これはCEOとCFOから見ても同じである。CEOがやらなかったことはCTOの仕事になるし、CTOがやらなかったことはCEOの仕事になる。
全員が一つの目標＝企業価値の最大化に対して行動する。
一人で解決できない問題はチームで解決する。例えば
事業の長期的な方向性
リモートワークあるいはオフィス
給与水準と福利厚生
利益を得るか、投資をするか
一方、現実的な境界は存在する。
これはプロダクトマネージャーとエンジニアの仕事の境界がどこにあるかという問いと良く似ている。境界は事業特性や組織文化、当事者の能力や経験に依存するが絶対の正解はない。
その経営チームにおいてCTOに求められる能力は他のCxOによって規定されると考えると良い。
エンジニアリングマネージャー
組織はVPoEに任せるという方法はあるが、ここでは技術系の経営職がCTOただ1人である場合を考える。100〜150人程度の組織規模において、それに応じたCレベルの成果をあげようと思うなら個人でなく組織で解決する以外に方法がない。これはわかりやすい。
ところで、40以上のエンジニアがいる組織で一人あたりのコミュニケーション量を平均5人程度にしようとすると
3階層目のマネージャーが必要になる。実際にそうするかはともかくとして、それくらいのコミュニケーション複雑度があるという理解はしたい。
この規模のルートのマネージャー（CTO）はエンジニアリングマネージャーのマネージャーのマネージャーである。
？？？
その前に、エンジニアの規模が20人を超えると一人のリードエンジニアがプロダクトの技術状態を完全に把握することはまず不可能になる。だから、プロジェクトや技術領域、チームを任せられる人が必要になる、これがエンジニアリングマネージャーやテックリードとなる。また、プロダクト、技術、組織に対して一貫した方向性を持たせるためにはこれをまとめる人が必要になる、これが2階層目のマネージャーとなる（エンジニアリングディレクターと呼ぶかもしれない）。このポジションは固定である必要はないが、全社の戦略に則って現状を維持したり変更したりできる必要がある、1人で20人を動かすのは普通は難しいのでマネージャーと協同する必要がある。
40人を超えるとマネージャーのマネージャーが限界に近づく。上の図を見てわかるように3階層目のマネージャーをなくして2階層目を1人にすると、1人で8人のマネージャー（とグループ）を見ることになる。若干しんどい。2つに割って、どちらかに優先権を持たせても良いがこれだと3層にするのと大差ない。いずれにしても、規模が大きくなればそれに応じてネットワークを最適化するという話なので、こういうポジションは必要になる。
では、ルートのマネージャーに何が求められるか
率いずとも左の戦場を操られた殿は天才です
多かれ少なかれこれが求められる。中身に直接触れずに状態と出力を変更する。例えば
エンジニアリングマネージャーのマネージャーの採用あるいは育成
組織に働く力学の認識と文化の変更
全ての状況の理解と必要に応じて直接解決する能力
維持する場合はあまり問題ないと思うが、変更する場合にはそれなりのエネルギーを要する。端的に言って、エンジニアと真逆の動作が必要になる。
おわりに
CTOたのしいよ。
CTOはCxOの一人だから、エンジニアがプロダクトマネジメントやデザインを学ぶように、CTOも経営や財務を勉強する。短期と長期の財務と事業と組織を前提にして技術的な意思決定を行なう
階層的な組織かはともかく、規模が大きくなると直接コミュニケーションを取らずにマネジメントする必要性が必ず出てくる。最初は不可能なように感じるが、これも一つのスキルだから訓練すればできるようになる、完璧からは程遠いが
関係あるようなないような過去記事
この記事が気に入ったらサポートをしてみませんか？