見出し画像

1 年を通して理解した CTO としての職務

めもりー

はじめに

みなさん，こんにちは。めもりーです。株式会社トラーナで執行役員 CTO になってから 1 年が経過しようとしているので，来年の所作も踏まえて，そろそろ記事にしようかなと思っています。

1年間 CTO としてどうだったか

正直，CTO という職務が何をするべきか，常々悩んでいます。

上記の記事のように私の中では CTO の職務というのは "技術資産を常にフル活用できる状態にすること（意訳）" だと定義しました。

もちろん，会社によっては CTO は「技術のプロフェッショナルでテックリードの上に起つ存在である」であったり「ボードメンバーの一人として，経営に携わり技術的な意思決定をする」であったり「課題を洗い出し，技術的にどのように解決できるかのリードをする」といったり，十人十色だと思っています。

その中で，私自身の答えとしては，上記の技術資産の活用であると導きだしているものです。

CTO は事業計画に沿って，その数字を達成するためにエンジニアリングとして何をすべきか，その課題のために何を技術選定するか，その技術選定をすることでどれくらい生き残れるか，その課題を解決するために，どういったエンジニアを何人雇用すべきか，などを考える仕事であるということが，今年の後半くらいに，ようやく鮮明になってきました。

もちろん，会社によっては大きく違うと思います。技術者の頂点と位置づけるのであるならば，おそらく今後の技術的な動向は対して常にアンテナを張らないといけないでしょう。

スタートアップにおける CTO の役割

CTO が求める役割や期待されるものについては，会社自体からのもの，ジュニアからシニアまでのエンジニア達からのものと，異なるものです。

「あなた明日から CTO として働いてね」と言われた時，CTO としての初仕事は，今勤務している会社から CTO として求められているものを言語化し定義することだと考えます。

期待値が異なる者同士からの折衝というのは，軋轢を生みかねません。

CTO は事業を成功させるために，会社が立てた事業計画に基づき，その時折で最適な技術と採用の意思決定を行い，事業計画を達成できるような，もしくはそれを大きく越境できるような組織に作り上げていくこと。

その時折とは「会社のフェーズ」「事業のフェーズ」「組織のフェーズ」といったところでしょうか。ファイナンスがどれくらい進んでいるのか，どれくらいの目処があるのか，内部で持っている LTV や ARPU，GMV などの KPI 指標はあと，どれくらい達成するのか，来年には数字はこれぐらいになり得るから，技術選定をどうするか，組織についても，どれくらいの人数であれば余剰人員が出ないのか，もっと活躍できるフィールドを増やせるか，などとブレイクダウンして考えて行く必要があります。

そして，未来，事業の課題を解決するに際しゴールはどこであるかを定義するということも大切な役割であると考えます。

よって，CTO は「未来の技術を見越して選択をする」という役割よりかは「その時折で，正しい技術を選択できるかどうか」といった役割のほうがより要求されるということで，私自身は腹落ちしています。

もちろん，未来の技術を見越して選択する役割も必要ですが，プログラミング言語やライブラリであれば，コードの隅々までみて仕組みを理解するといった具体的な話よりも，抽象的に捉えて，このライブラリが今目の前の事業やプロダクトがスケールしたときに起こりうる課題に対してどういったペインを解消できるか，といったところに着目することが大事だと考えています。

「技術は手段で何でも良い」と思っていた時期はあります。「技術は手段」というのは今でも考えは変わっていませんが「何でも良い」という考え方は改めるようになりました。技術は事業上の課題解決をするための手段であり，課題解決というのは密接に採用戦略にも紐付いており，技術の選択は採用の選択といっても過言ではないと思っています。

エンジニアの採用戦略

採用戦略というのは企業によってマチマチであるかなと考えます。
例えば湯水のようにキャッシュが湧き出る会社もあれば，そもそも少額のキャッシュの中で検討しなければいけない会社もあるはずです。

湯水のようにキャッシュが湧き出るのであれば，組織づくりにも大きなお金を投下できますし，目指したい組織像の実現に対して近道になりえるかなと想定するには容易いです。

一方で，少額のキャッシュの中でやりくりをするということは，言い換えればランウェイを伸ばしている一方で，資金ショートへのカウントダウンは変わらず起こっているということです。その中で，事業をスケールさせて，トップラインもボトムラインも伸ばし続けなければなりません。スケールできるような投資ができないと資金が底を尽きるだけです。

他方で，ランウェイを短くしてでも，プロダクトのスケールに大きく投資しハイリスクハイリターンで挑む経営方針もあるでしょう。

つまり，採用戦略というのは経営方針に直結しているものであり，いくつかのシナリオを考える必要があるということです。

採用戦略を練るためには，経営方針に加え現状のプロダクト分析も必要になってきます。どういったポジションで，どういった期待値をもって，何人エンジニアを採用したいかを検討していかなければなりません。

「人手が足りないからとりあえずエンジニア採用しよう！」と始まりますし，初期はそれくらいでも良いかもしれません。

しかし，ある程度会社のフェーズが進むと「エンジニアにどれくらい投資するべきか？」を考える必要が出てきます。なぜなら，複数の投資家が入ってくることで，自分たちのお金が適切に運用されて大きいリターンになってくれることが期待されていくからです。投資家の期待に答えるためには，投資に対する費用対効果を高くし続けていく必要があります。

そのためには，採用ができなかった場合のシナリオ，採用がある程度できた時のシナリオ，採用が思った以上にできたシナリオの 3 種類ほどは用意しておき，それぞれ事業計画にどれくらいのインパクトがあるかを証明していく必要があると考えます。そのために要員計画の予実管理も CTO の業務の一つになりえると考えています。

採用は，時期，市場，経済動向によって大きく変わるもので，名もなきベンチャー企業やスタートアップが少ないキャッシュで戦う必要があるときに，現在の事業に求めるスキルを持ったエンジニアたちを採用できて確実にヘッドカウントを埋められるかというと，そういうわけでもないはずです。

普通に考えれば資金が足りないのであれば，エクイティなりデットなりのファイナンスをするべきですが，経営戦略上バリュエーションや経営陣の持ち株比率にも大きく影響してくるため，闇雲にファイナンスもできないのが実情であります。

そのため，少ないキャッシュで事業をグロースさせたり，プロダクトをスケールさせながら戦っていくには，いわゆる強いエンジニアを採用する必要があります。一方で，そういった強いエンジニアが名もない会社に行きたいと考えるか，と顧みたときに，エンジニア採用は難易度が極端に高く，企業に対して苦境を強いるものです。

これらを乗り越えるためには，大量の資金を用意し，市場にあった給与テーブルに変更する，求めるスキルや人物像などのグレードを下げる，プロダクトで使う言語を，採用のしやすい言語にする，などが手段としてありえます。

上記の様々な方法を仮説検証から繰り返し模索して，戦略を実行していくのも CTO の仕事の一つとなると考えています。

組織課題の解決

エンジニアリング組織は，特に課題の芽が生えてきやすい性質を持っていると強く実感しています。一つ例として挙げられるのが，ポータブルなスキルを持っているということです。ポータブルなスキルを持ったエンジニアは，会社のしがらみに束縛されるものではなく，本人がフィットしないと感じれば，転職をするという選択肢がありえます。

そのような前提で組織を設計しているものの，一方で他部署は，上記のような前提で設計をしていないため，軋轢が生まれやすくなってしまいます。

結果として，軋轢がひどく退職を選択するエンジニア，他部署のメンバーが増えてきてしまい，組織崩壊に陥るのは言うまでもないと思います。

同じ職責・職務ではないドメインであるのに，平等を過度に目指そうとするとそれは公正・公平ではないことが起こりえるだろうと考えます。例えば，規律・福利厚生・管掌範囲・目標設定・給与テーブル・昇格基準などを同じように当てはめると，それは平等でありますが偏りが発生するため，公正・公平ではないと言えます。

左から平等・公平

引用元: https://interactioninstitute.org/illustrating-equality-vs-equity/

平等と公平は言葉遊びに近いようなニュアンスのあるワードですが，会社によっては，図のようなものが顕著に現れたりするものです。

例えば，営業系の会社であれば数字が正義となり，数字にコミットしづらい・間接的なコミットという面では，エンジニア職はただ人件費がかかっている対象と見られてしまうし，逆にエンジニアが開発するものが直接数字にコミットするような会社であれば，エンジニアが優位になりやすいと言えます。

これは，ビジネスモデルや経営方針に対して起こりやすい事象であると考えられますが，CTO はエンジニアの立場や他部署の権衡を鑑みて，組織の求める姿を描く必要があります。

つまり，エンジニアの立場が優位であれば，他部署と権衡を保つような形に持っていくべきだし，エンジニアの立場が低いものであれば，高めるように尽力する必要があるということだと考えています。

技術課題の解決

エンジニアから CTO というキャリアを歩むにあたって想像しやすいものとしては「所属企業の技術課題を解決する」だと思われます。

しかし，抽象的すぎて一体何をすればよいのか…と悩むものであるかなと思っています。実際に私自身は悩んでおりました。

1 年考えてきて私の中で腹落ちした答えとしては「開発チームのスループットを高め，顧客に価値を提供するために障壁になっている技術課題を排除して常に価値を届ける」です。

例えば「特定の SaaS を入れることで開発効率が何 % 上昇する」といったことを言語化し証明，そして導入までのプロセスを踏む，であったり現場のテックリードと協業し「デプロイが 1 週間に 1 回しかできていないので，課題を洗い出し解決し，1 日に数回できる状態にするロードマップを建てて実行する」であったり「コードの品質が会社にとって何が最適かを言語化し証明しそれを維持する仕組みを整える」といった職務が多くなるのではないかと考えます。前述の通り，これは例です。

一方で，これらを解決した先には「多岐に渡るビジネスのスケールに常に耐えられる状態」へ持っていくことが求められるのだろうと考えています。
例えば「これ今やればトップライン 5% 伸びるけど，時間が経つにつれて伸びるはずのトップラインが下がってくる」という状態であれば，5% 伸びるような選択肢を本来取りたいはずです。しかし，技術的な課題によってそれが達成できない状態だと事業は遅れを取ってしまうことになります。それを未然に防ぐ必要があるということです。

他方で，これを今週中までにやらないと資金がショートしてしまう可能性が高まるということであれば，品質を捨ててまで，開発をせざるを得ない意思決定をすることになりえますが，そうすると近い未来に技術負債の返済を行うための人的コストがかかってきます。

未然に防げればよいですが，時と場合によって苦渋の決断を迫られることがあるので，迫られても品質をなるべく担保できる状態を維持し，技術負債の借入を極力減らせられるように技術ロードマップを描いていく必要があると言えます。

技術によって（それが）未解決であったときに本来かかるコストを技術によって減らす，企業運営を技術で最適化し，常にスピード感を持ってお客様や他従業員へ価値を届けられる状態に居続けるられる状態にすることが CTO としての振る舞いであると自分自身の結論に至りました。

求められるプレゼンス能力

経営層や他部署へのエンジニアリングについて説くために，プレゼンス能力は往々にして必要になってくるという実感があります。

具体例で言えば，ミドルウェアの更新や，CI/CD の改善，開発体験の向上などは一見して，事業への数字にコミットしているとは見えづらいため，おざなりになってしまう傾向があったり，ビジネスサイドへの釈明が困難であると言えます。

しかし，システム開発では，事業計画へスピード感を高めてコミットするための重要なファクターであることは間違いがなく，全社的にそれを受け入れられるような組織体制にしなければなりません。

技術負債の借入が続くと，やがてメンテナンス不能な事象に陥り，特に IPO 後など監査フローが厳格化し，返済するために多大な時間を要してしまいます。また，企業売却をイグジット戦略として置いている企業であればシステムデューデリジェンスに響いてくるものでもあります。

技術負債の返済の目的は，エンジニア本人たちの開発体験の向上だけではなく，企業がよりグロースするために必要であるということを唱える必要があるのです。

そのため，技術負債を減らす取り組みは，企業価値を高める行動であることを言語化し，証明し解答するためのプレゼンス能力と知識を CTO は常々求められるものであると感じています。

私自身がエンジニアとしてキャリアを歩んでいた時は，技術負債の返済は自分自身へ恩恵が強い（開発しやすい）という点で視点が向いておりましたが，CTO という職務を担うにあたり，上記のような考え方に次第に変わってきました。

CTO というキャリア

エンジニア時代よりもエンジニアリングがなぜ企業にとって必要であるかを，CTO として業務を担っていて常に思料するようになりました。

一つ一つの行動がなぜ必要なのかを求められた時に，うまく想像や解答に至らなかった時期が今までの経験の中でありました。

例えば，会社がなぜ MVV を作るのか，なぜエンジニアを採用するのか，なぜプロダクトの品質を常に高めなければならないのか。

MVV の存在意義がわからないが，会社が言うなら…，であったり，そんなにエンジニア増やしてもやることないでしょ…。とか，品質が高ければ良いはずだ，という認識から，なぜ存在しているのか，なぜ増やさなければいけないのか，なぜ高くなければいけないのか，言語化が次第にできるようになってきている所感です。チームメンバーには，エンジニアリング各種の業務が，なぜ企業価値を向上させる取り組みであるのか，言語化し常々伝えていきたいとも考えています。

業務における行動の 1 つ 1 つに意味付けをし，理解をし，深く考えるようになってきたというところでしょうか。

CTO という職種でも求められるものはビジネスモデルや企業カルチャー，経営方針によって多様多種であると感じます。

まだ，こういった視座の言語化しかできてないですが，会社の目指す未来が日本から APAC へ，そしてAPAC からヨーロッパへ，ヨーロッパからグローバルへと変貌を遂げる時，CTO として求められる所作や行動も変わってくるのだろうと考えていますが，今はまだそこまで見えていないのが現状です。

例えばグローバルに活躍しているビッグテックがなぜ，様々な業務・領域に手を出しているのか，今はまだ「トップラインを伸ばすため」であることは確かだとは思うものの，その選択がなぜ正しいと言えるのか，なぜそれでトップラインにインパクトを与えられると判断しているのか，言語化しプレゼンスを求められても，定量的なデータの提示や納得感のあるレスポンスを返すのが難しいと感じています。

そういう意味では私自身の CTO というキャリアはまだ歩き始めたばかりであり，まだまだ研鑽の余地はまだあるんじゃないかなと考えている次第です。


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