見出し画像

新米 CTO 半年目

みなさん、こんにちは!めもりーです。
2020 年 4 月に株式会社トラーナに入社して、はや 2 年。
そして、2022 年 1 月に執行役員 CTO として昇格し半月が過ぎたので、そろそろ記事にしていこうかなと思います。


どういう経緯で CTO になったのか

2021 年 10 月頃に、代表の志田さんから CTO にならないか、といった打診が 1on1 の際にありました。当時私自身はまだ 27 歳で、私自身がマネジメント方向に進むのか、スペシャリスト方向として進むのか、強い希望が特に無く、ただスキルと経験でお金を稼いでいたいと思っていたところ、自分自身のコンフォートゾーン外のオファーが来たことに驚きが隠せませんでした。

正直 CTO は私が 40 歳になったとき、もしくは、もっとそれ以上の年齢になったときにふとキャリアとして思い描くものだと思ってました。

自分自身がコードを書いて得ていた報酬が別のベクトルでコミットメントを出すということで報酬を得るように変わるということもあり、果たしてコードを書いているときのようなコミットメントを出せるかというと、そうではないと感じ、当初はオファーを断っていました。

ただ一方で、会社全体としてのファイナンス状況とビジネス戦略、そこに対してどう技術的なアプローチをしていくかを考えるように次第になっており、コードを書いているだけで刺激が足りないとも感じていました。

他方で、エンジニアから PdM や PjM といったプロダクト戦略やスケジューリングのプロフェッショナルというキャリアも今思い返せばあったなとは思いますが、LTV や ARPU を上げるといった数字的なミッションを達成するよりも、より技術的な方面に舵を切りたいと思考を重ねるうちに確信的になってきました。

なぜ CTO になろうと決意したのか

普段から早く CTO を採用してください、と志田さんに 1on1 で伝えていました。CXO の採用は結局どんな会社でも非常に困難であることも分かっている上で、明らかに自分が責任を負わないようなポジションでこういった発言をしていたのは、今思えば恥ずかしい限りです。ただ、CTO の存在はエンジニア採用に大きく影響を及ぼすとは思っており、CTO の人格や経歴というのは、採用時のファクターになるものだとも私は思っています。私が転職活動をするときは、面接や面談を受ける先の会社に CTO がいる場合は、過去にどういった経歴を積まれているのか必ず調べます。CTO が居なければ CEO です。これは、その会社がどれだけテックに対して意欲が高いかを見るものです。テックへの理解はないが、DX を推進しているような会社には私は入りたいとは思えないのです。そういった私自身の求める期待値は下げたくなかったというのもあるのでしょう。

過去、SEO の結果が目標設定に組み込まれるエンジニア組織に居たため、季節的な変動があるような数字や、(スタートアップだと尚更)マーケティングのための予算が少ない中で、ユーザー主導のもと、思考を凝らして ROI を高めるような施策を熟慮することが自分自身では非常に苦手だと感じてました。とはいえ、その数字が達成しなかった場合の虚無感も実際に SEO のための活動を数年に渡りやっていたため、相応に辛いこともわかり得るものです。

そういった数字の責任を追うのではなく、自分のプログラミングスキルを生かした、より技術的な責任を追うポジションに居たいというのがキャリアパスを考えていたときに強く思えてきたものです。

志田さんからの熱いオファーは相変わらずだったのですが、前職では CTO が現場のコードを書いていたり、前前職はそういうロールが存在しなかったり、いわゆる CTO の業務知識が私の中で得た知識だけという状況でした。

日常に飽き飽きしていたのも他方で事実で、ただ与えられた戦略に沿って、ある程度メンテナビリティを担保したコードを書いて、いい感じにデリバリーして、至らないコードがあったら治したり。そういった行動はただ自分のコンフォートゾーンの中でしかないなと、ある日突然ふと感じ、CTO として腹をくくる覚悟ができたので 2021 年の 11 月頃に CTO としてやるということを伝えました。

当初の思い描いていた CTO とのギャップ

ステークホルダーからの期待は「株式会社トラーナをいい感じのテックカンパニーにしてください」だけでした。

当初、「CTO の職責はプロダクトを技術的にいい感じにする」と解釈していたこともあり、これを遂行しようとしていました。

プロダクトを技術的にいい感じにするというと、プロダクトをいい感じにするためには、良い組織が必要で、良い組織を作るには、良いチームメイトが必要で良いチームメイトを採用するには、採用のチューニングが必要で… といったことを思い描いていたのですが、今思うとこれは CTO としてのレイヤー外のことだったなと感じています。

最初にぶち当たった壁は「これ VPoE の仕事なのか CTO の仕事なのかわからん」です。

例えば新しいチームメイトを良い環境で迎える仕事をするのは CTO なのか VPoE なのか。IT ガバナンスやコンプライアンスを遵守するのは CTO なのか CIO/CISO なのか。そういった定義の曖昧さに苦しめられてきました。

CIO と VPoE と CTO の仕事って一緒では…自分いらない子なんじゃ…と思い始めたり、何をしていいのか、全く道筋が立てられないでいました。

次にぶち当たった壁が弊社の「プロダクト企画部と業務が被る」です。

結局プロダクトをいい感じにするのは「プロダクトのマネジメント」や「適切なスケジューリング」が必要になってきます。ここが、業務としてかぶってしまっており、結局 CTO として何をすればよいのかわからないまま、暗闇のトンネルを半月近く彷徨い続けてしまいました。

そして、これらを結局言語化できず、そして自分自身でも消化できず、ただ日々 CTO の業務とは何か考え、自分自身の視座の低さに絶望し、それでも会社は回っている状況から、自分自身は CTO としての責務を果たせていないのではと考え苦悩する日々を過ごしていました。半年も。

このまま CTO として続けていても自分の報酬に対してペイできていないなとさえ思っていました。

CTO として視座が高まった

弊社には、実は最近、技術顧問として BTO さんが加わってくれたのですが、会話を重ねる内に、CTO として視座が上がってきたのです。

特に興味深かった内容は、以下の記事を提示してくれて、わかりやすく噛み砕いてくださったことです。

そして、この記事を書いてくださった Takeuchi さんには感謝してもしきれません。この記事があったからこそ、今何をすべきか、明確にわかるようになったのです。

CTO の業務は会社によっては定義が異なるので、一概に「こうであるべき」と言えるものではないと思っています。テックリードの最上級役職が CTO であると定義している会社もあれば、経営陣の 1 人として CTO を定義している会社もあります。結局何が自分、会社にとって腹落ちできるか、報酬に対してペイできるかを考えて行く必要があるんだろうと思います。

CTO の業務は自分なりの答えとして技術資産を活用してもらうために、会社の FCF/PL/BS をモニタリングし、いま現時点で最適な技術資産の積立、技術資産を作る工程で生まれた負債、もしくは過去の技術負債の返済をプロダクト戦略担当と事業戦略担当といった他部署の担当と協議して戦略し執行していくことだと腹落ちしました。

技術資産や技術負債と呼ばれるものには様々なファクターがあり、これらをいい塩梅にしていくことが求められるんだと解釈をしました。

画像5

画像6

画像1

画像2

上記は私が頭の中を整理する際に作った資料です。

このエンジニアリングリソースを管理・調達するのが VPoE の仕事であり、エンジニアリングリソースをモニタリングし、技術資産構築の戦略を立てるのが CTO であるとすると、管掌も綺麗に分かれるので、私の中での業務レイヤーのイメージがつきやすくなりました。

次に CTO はどういった情報を収集し、モニタリングを継続していくべきか

画像3

上記のように様々なファクターをモニタリングし続ける必要があると考えています。CIO/CISO 周りは定義できてないので、適当ですが、少なくても CTO が見る範囲じゃないよなとは思っているところです。

CTO として今何をしているのか

弊社は「プラットフォーム開発チーム」「ユーザーサービス開発チーム」「SRE チーム」の 3 チームに分かれています。

現状のコミュニケーションパスが、他事業部から直接各チームへ依頼されるようになっていたので、私自身がどういった技術資産が生み出されているのか、意思決定が経られているのか分かっていない状況でした。

そのため、まず、コミュニケーションパスの見直しを各事業部と協議し、全社的にどういった業務やエンジニアチームに依頼したいものが生まれてくるのか全容を把握するため、全員のカレンダーを覗き、片っ端から「この予定入れてください」と情報収集からはじめました。

画像4

一方で、エンジニアチームのチームヘッド(チームリードと同義語ですが、弊社だとテックリードと英字省略した際に被ってしまうため便宜上チームヘッドとしています)と対話をする時間を増やし、エンジニアチームとして何をやりたいかヒアリングを始めようとしています。

そこから、技術資産形成と技術負債返済を戦略立ててスケジュールに組み込んで行く想定です。何がコストパフォーマンスがよく、現時点で技術投資がペイする見込みが高い施策であるかをプライオリティを付けながら、進めていこうとしています。

次のキャリア

「CTO を引退した後は、ねこカフェでも経営して余生を暮らしたい」と適当なことを考えていたのですが、上記の松岡さんの記事を読んで、そんな悠長なこと言ってられないなと思いました。

次のキャリアパスが上手く描けているかと言うと私自身そこまで考えられておらず、結局自分はどうなりたいのか、もう少し考える時間は必要だなと考えています。即席麺ではないので、時間をかけて、ゆっくり丁寧に。

多くの方が CTO から Individual Contributor になったという記事もいくつか拝見している中で、じゃぁ私はコードが書きたいかと言うと、プライベート(OSS 活動)だけでいいかなと思っている節もあり、これは年齢によって変わってくることなのだろうか、とも思ったりキャリアを思い描けない以上、逆算して何か自分の行動に変異を起こすというのも難しい話だなウーン。

みたいなのを考えています。ただ、今はまだ CTO として業務に全うできているかというと出来ている気が 1 μ もないので、奔走してから次のキャリアを考えるのをスタートしても悪くないかなと思っています。



この記事が気に入ったらサポートをしてみませんか?