私が想うCTOのやりがい、そしてなぜそこに至ったのか。
はいどうもー。クドウマサヤ(@masaya_dev)です。
先日「After YAPC::Hiroshima 2024 LT Night」というイベントにて「CTOの楽しさ」についてただひたすら語るLTをやらせていただきました。
改めて自分が想うCTOのやりがいを言語化してみて、自分の中で新しい発見というか、キャリアの点が線に繋がっていたんだなという気付きがありました。当日聞いていただいた方からも「CTOという役割の解像度が上がった」という嬉しいコメントもいただきまして、せっかくなのでnoteにも記しておこうと思います。
CTOの楽しさについて考えたきっかけ
先月行われたYAPC::Hiroshima 2024にてLayerX CTOの松本さんのセッションを聞きとても共感しまして、自分なりにもCTOという役割の魅力を伝えてみようと思ったのがはじまりでした。ちなみに私は現在iCAREで昨年8月からCTOを務めさせてもらっており、過去にもシード期のスタートアップで3年ほどCTOを務めていたので、トータルで約3年半のCTO歴となります。
私が想うCTOの楽しさ
やりがいは人それぞれであり、あくまでも私の考えとしてのCTOの楽しさですが
「エンジニアリングスキルをもって事業成長を最大化させ、そして組織が描くビジョンの実現に強くコミットできる」
そんな役割だからと今は考えています。
ただ、もちろんキャリア1年目からこんな考えを抱いていたわけではなく、少しずつやりがいが変化していき、その背景には様々な経験もありました。
エンジニアとしてのやりがいの変遷
ちょうど今月でWebエンジニアとして働き始めて丸14年を迎えることになりましたが、以下のように段々と仕事で求めるやりがいが変わっていきました。
もちろん今でもコードを書くのは楽しいですが、その喜びを求める先はどちらかというとライフワークに変化。仕事でプログラミング・エンジニアリングを行う上では、それを通じてどのように事業へ寄与できるかが自身のやりがいとなっています。
なぜやりがいが移り変わっていったか
STEP2からSTEP3の変化、エンジニアとして事業に目を向けるようになったのはエンジニア4〜5年目あたりの経験が大きく影響しています。
これ以外にも苦い経験がいくつかあります。せっかく作ったものが使われないのは寂しいですし、サービスがクローズになるのも寂しいものです。
こういった経験を通して、システムをどう作るかのみを考えるだけではなく、ビジネスモデルを考えること、事業のフェーズ・戦略から逆算して開発投資を考えること(≒経営にコミットすること)の重要性に気づきました。
組織にCTOがいる意義
一般的にプロダクトの開発及び運用は、安価そして容易に継続できるものではないと考えています。特にプロダクトの自社開発を行っている企業において、開発投資および開発における不確実性は必然的に経営へのインパクトが大きくなります。
経営におけるリスクを最小化・リターンを最大化するため、事業・組織の状態を見ながら技術投資・開発投資の最適化を担う人がいないと、企業とそこで働くひとにとってアンハッピーな未来が訪れるリスクが高くなってしまいます。新機能開発や開発組織拡大のアクセルを踏むべきなのか、もしくはブレーキをかけて質を高めるべきなのか。それはUターン可能(可逆的)な技術的意思決定なのか、などなど。
こういった事業・組織・技術のバランスを取り経営判断に関与することが組織にCTOがいる意義のひとつと考えています。事業フェーズや組織規模によってCTOの業務が変わることはあれど、この意思決定を担い続けるというのは普遍的なものではないでしょうか。
数年前、泉さん(現UPSIDER VPoE/当時はラクスルCTO)が登壇された勉強会に参加したときに「CTOはその企業における経営者の中で最も技術に詳しくて、技術者の中で最も経営に詳しい人」といった旨の発言をされていたのが印象に残っていて、今でもCTOの在り方として意識しているポイントです。
手掛けているプロダクトが多くの方に届いて欲しいですし、ともに働くメンバーにとっても幸せな未来が訪れて欲しい。技術者であり経営者として、そこに全力で向き合えるというのはCTOのやりがいだと思っています。
CTOという役割に興味を持ち、エンジニアリングスキルを持って経営にコミットしたいという同志が増えたら嬉しいですね。最近、あらたまさん・藤村さん・だむはさんによる対談がアップされていて面白かったのでそちらも是非。
CTOに興味があるけど、具体的にどういった知識をつけていけばいいのかわからない、具体的にどういう仕事をしてるんだろう…?という方はぜひカジュアルにお話しましょう。お気軽にDMください!ではではー。