会社が4人->44人になって、CTOがやるべきこと、捨てるべきことを考える

背景

3年前くらいにCTOっていう肩書きをもらったわけだけど、さてそこからCTOとして何をしたんだろう？って考えると、そもそもCTOってなんなの？という疑問が湧いてきて、小規模ベンチャーにおけるCTOとは何かという大きいお題でまとめてみたくなった（まとめきったとは思わない）

自分はというと、従業員4人の時からエンジニアとして働いていて、今従業員44人という規模まで成長した会社の一先ず肩書上はCTOの人。
部下は20人という状態まで成長してきて、さて自分のポジションと未来はどうあるべきなのか？と考えている人。このコンテキストの人、世の中に結構いるんじゃないかなと思っているので、そういう人の思考の足しになれば。
まとまった文章というよりは脳から切り出したメモの断片。

きっかけ

内的要因

• なんとなく最新の技術出てきたときに「我先に」感が失われた実感があること（まだまだがんばるけど）
• 数学ができる優秀なエンジニアに挟まれて、自分の立ち位置とかなんなのかなって思ったこと（文系エンジニア的なあせり）
• 自分なりのやり方を貫いてみたらメンバーは割とついてきたなと思えたこと（マネジメントの成功体験）

外的要因

• 忠実で信義に厚いリーダー格のメンバーが部下になったこと
• 会社全体で離職者が多い
• 最近話す機会があった方でCRO（R&D）っていう人がいて、この人と自分は何が違うんだろうなということ
• vp of engineer って言葉を知ったこと

今の守備範囲

• インフラ、フロントエンド、サーバサイド、DB、ios/androidアプリ
• プロダクトの設計、プロダクトマネジメント
• R&D、ランダムフォレストなどの機械学習
• SEO/ASOのコンサルの技術サポート
• エンジニアのマネジメント

＋αで現在CTO＋部門長という立ち位置なので

• コンテンツマーケ部のマネジメント
• システム運用チームのマネジメント
• 社内ネットワーク（これは小規模ベンチャーあるある）

小さい会社の経営から求められる職務としてのCTOとは

• vs経営

  • 技術戦略の責任者
    • 困ったことがあったら相談に乗る人
  • 経営に対する技術のインプット
    • 技術とビジネスの中間の立ち位置、長期ビジョンにおける技術ポジションの提案とか
  • エンジニアリング資源の最適化
    • どこにどれだけアサインするかとか

• vsメンバー

  • 憧れのエンジニア（テックリード?）
  • 得意な分野でリスペクトされ続けること
  • マネジメント
    • 勤怠とか成長とかキャリアパスとか

• vs組織全体

  • 会社のテックビジョン
  • プロダクトマネジメント

• 視点

  • 技術50% ビジネス50%
  • プロダクト（モノ）50% マネジメント（ヒト）50%
  • 最新技術50% 枯れた技術50%

漠然とこんな感じで捉えている

じゃあCTOのアクションは？

• vs経営のアクション

  • 技術戦略の責任者
    • 会社で扱っている技術についての管理と把握、経営陣との適切なコミュニケーション
  • 経営に対する技術のインプット
    • 薄い感じじゃなく、触ってみて書いてみて理解したものを伝えていく必要あり
  • エンジニアリング資源の最適化
    • チームとして何を作るか、作れるか、将来的に作るためにどこに投資するかなどの提案

• vsメンバーのアクション

  • 憧れのエンジニア
    • ソースコードで語れ的な、背中を見せる必要がある
  • 得意な分野でリスペクトされ続けること
    • 同上
  • マネジメント
    • ヒトとしての魅力: 憧れの先輩と働くみたいな側面
    • チーム/組織としての魅力: 10%ルールみたいなチーム/制度作り
    • アウトプットのコントロール: こんなかっこいいプロダクト作ってます

• vs組織全体

  • テックビジョン
    • 情報発信
  • プロダクトマネジメント
    • 何をいつどうリリースするか、その技術的基盤はどうするかなどを管理

結局小さな会社のCTOにとっては、ソースコード書く＋qiitaみたいな行為が全方面でつながっている？
-> だから小さい会社においてはCTOってのが存在しやすい？

上記からでてくる疑問

• 技術50% ビジネス50%

• 最新技術50% 枯れた技術50%
  これはバランスの問題なのでセンスと努力でカバーできる
  労働集約ではない

• プロダクト50% マネジメント50%
  こっちは労働集約されるので、人が増えてきたらプロダクト50% マネジメント100%みたいになってしまう。
  物理的に50%のパワーでマネジメントすることが不可能な問題。
  ->これの解決方法が VP of Engineering？

VP of Engineering(VPoE)

VP of Engineeringとは
VP(Vice President) of Engineeringとは一言で言うとエンジニアリング組織の全体を成功に導く最高責任者です。CTOが組織やサービスに最適な技術戦略、技術方針を描くのに特化しているのに対して、VP of Engineeringには採用、育成、評価などを含みエンジニア組織が最大のパフォーマンスを発揮するためのあらゆる役割が求められます。(VP of Engineeringという役割が存在しない組織においては、CTOや現場のエンジニアリングマネージャーがそういった役割を兼ねていることが多いかと思います)
(引用： https://developers.cyberagent.co.jp/blog/archives/12429/)

忠実で信義に厚いリーダー格のメンバーが部下いるので、彼をここにあてよう
彼は制作系のメンバーでエンジニアではないが、

VP of Engineeringには採用、育成、評価などを含みエンジニア組織が最大のパフォーマンスを発揮するためのあらゆる役割

このミッションは達成できるのではないか。
これは一つの試みではあるものの、エンジニアをエンジニアが束ねる必要はないと思っている。
会社としてエンジニアを評価するには、技術軸と、もう一つプロダクト軸が必要で、技術軸はCTOが、プロダクト軸はVPEがやればいいのではないか。

VP of Engineering(VPoE)が存在するチームにおけるCTO

• vs経営のアクション

  • 技術戦略の責任者: CTO
  • 経営に対する技術のインプット: CTO
  • エンジニアリング資源の最適化: CTO?VPoE?

• vsメンバーのアクション

  • 憧れのエンジニア: CTO
  • 得意な分野でリスペクトされ続けること: CTO
  • マネジメント
    • ヒトとしての魅力: CTO
    • チーム/組織としての魅力: VPoE
    • チームのアウトプットのコントロール: VPoE

• vs組織全体

  • テックビジョン: CTO
  • プロダクトマネジメント: VPoE

ミッションとしてのCTOを分割して2名(CTO/VPoE)で担当できるのは大きなメリット

自分ができていること

• vs経営のアクション

  • 技術戦略の責任者: まあまあ
  • 経営に対する技術のインプット: ちゃんとできる
  • エンジニアリング資源の最適化: まあまあ

• vsメンバーのアクション

  • 憧れのエンジニア: ちゃんとできる？
  • 得意な分野でリスペクトされ続けること: ちゃんとできる？
  • マネジメント
    • ヒトとしての魅力: ちゃんとできる？
    • チーム/組織としての魅力: まあまあ
    • チームのアウトプットのコントロール: まあまあ

• vs組織全体

  • テックビジョン: あまりできない
  • プロダクトマネジメント: あまりできない

経営陣とはきちんとコミュニケーションは取れていると思っている。
エンジニアリング資源の最適化についてもかなり厳しめにいき、メンバーの自主性とかも引き出せていると思う。
1エンジニアとしての魅力はどうだろう。。　OSSとかに出てないのはマイナスかもしれないけど、大抵の質問には即答できるだけの技術力は見せているつもり。
アウトプットは。。。まだ自分の技術力不足で「あたり」のプロダクトがないので難しいところ。
ビジョンは、いうのはできるが、飽き性ですぐ次ってなってしまうので難しい・・

まとめ

• VPoE万歳
• CTOはテックに生きる
• VPEはテック＋マネジメントの間
• ソースコードを書くことは重要なマネジメント手法の一つ

CTOの負荷が上がってきたら、経営から求められるCTO的な役割を分割してCTO と VPpE にわける。
分けた上で、自分の適性から選択して、もう片方の適任を探すのがいい？