前書き
こんにちは。株式会社カナリーで CTO を務めておりますどらです。唐突ですが、
「明日からあなたは CTO です」
と言われたらどうしますか？ 「う〜ん、どうしよう？🤔」 となる方も多いのではないでしょうか。
実際、どうアプローチするのかという部分は人それぞれだと思いますし、その人がどういう受け取り方をするかによって「その人が CTO を務める価値」、つまりクリエイティビティや"味"が出てくるのかなと思います。それによって組織がどの様な方向に向かうのか、どの様な価値基準を持ちどの様な文化になるのか、結果会社がどういったバリューを出していけるか、といった部分が決まってくるのだと思います。
なので一概に何が正解であるとかそういった話ではないとは思いますが、私が考えた事などを共有する事でもしかしたら今後同じ様な状況になった方の参考になるかもしれない、あるいは思想やアプローチに共感して頂ける方に弊社に興味を持って頂けるかなと思い、今回この記事を書いてみました📝🙇🏻♂️
物事は概してトップダウン（抽象度・高→低）でアプローチを探すのは難しいと思います。一方で、思いつくままに手を付けてしまうともっと重要だった選択肢を見落としてしまうかもしれませんし、中長期で見た動きとアラインできてるのか？という疑問に答えづらいものがあります。そこで、今回はあえて抽象度の高いところから落とすというアプローチを取っています。この辺りの経緯と結果としてたどり着いた姿について、以下の様な感じでお話できればと思います。
- 自分としての定義
- 何故この様な CTO 像に至ったか
- 踏まえてどの様な事をやっていきたいと考えているか
※繰り返しになりますが会社や状況によっても必要とするものは違うと思いますので、あくまで参考程度にご覧頂ければと思います🙇🏻♂️
自分としての定義
最終的に辿り着いた姿としては、
事業成長の時間軸を見据え、技術的側面からプロダクトに責任を持つ
というものになりました。ではその心とはなんなのか。どうやってこの様な定義に辿り着いたのかという経緯について、お話ししていきたいと思います。
何故この様な CTO 像に至ったか
「明日からあなたは CTO です」と言われても、では一体 CTO とは何なのかという姿が見えていないと何をしたらよいのかというのも分かりません。一体 CTO とは何なのか？その答えを探るため、我々は情報のジャングルに足を踏み入れました（意訳：世間一般でどう捉えられているのかを調べました）。
- CTOA のアドベントカレンダー2020に載っていた記事
- その他 CTO に関する記事
- 関連する書籍（「エンジニアのためのマネジメントキャリアパス」「マネジメント」等）
あたりをソースとして、インプットを行いました。CTOA のアドベントカレンダーには様々な方が寄稿しておりまさに十人十色といった感じで、非常に参考になりました。その他、ネット上に公開されている記事や関連しそうな書籍もいくつか読みました。
結論としては、おおよそ言われている事は以下の様な事でした。
- やる事はフェーズによって変わる
- 技術を用いて結果を出せる様にしていく
- 事業が成長するために（時間軸見据えて）やるべき事を決める
やる事はフェーズによって変わる
これは当然と言えば当然かもしれませんが、CTO といった立場の人がやるべき事はフェーズによって変わってきます。例えばですが、まだ立ち上がったばかりのスタートアップでエンジニアは副業の人しかいない、そんな状況で「文化が〜」とか言っていたら「いやそんなのいいからとにかく PoC 作ってよ。ランウェイ6ヶ月しかないんだからさ」となると思います。逆に、エンジニアが数百人の規模の会社で「コーディングルールが〜」とか言っていたら「いやそんなの LE に任せりゃいいからグループ全体の事考えてくださいよ」になると思います。
※LE = Lead Engineer
これは極端な例で、実際には組織はもっと連続的に成長していくため自分たちが一体どの辺りのフェーズにいるのかというのは見えにくくなるとは思いますが、少なくとも「自分たちが今大体どのあたりにいて、そのフェーズにはどういった事が一般的に必要だと言われているか」といった事は気にした方がよさそうです。
このあたりの事は、
- 組織規模とCTOの求められる役割の変化に関する雑記
- CTO（Chief Technology Officer）はアカデミックにおいてどのように議論されているのか？
- 新米CTOになってから4年、社員3人から80人を超えるまでのロールの変遷
などを読まれるとよいかもしれません。
すごく簡単に言うと、
- 初期 = 創出
- 安定化期 = 最適化・組織化・採用・QAなど
- 拡大期 = 競争優位性の強化・複数プロダクトの立ち上げ
- 支配期 = 未来を描くための研究開発・ビジョンの浸透
といった様なイメージです。
初期の創出とはすなわちゴリゴリコードを書いてプロダクトをゼロから作り出していくフェーズです。PoC として機能するとにかく最低限のものを高速に作り、価値を示して調達ができなければ数ヶ月で会社はなくなるかもしれない、そんなイメージです。
安定化期は PoC でプロダクトのコンセプトは確認でき、調達もある程度できて顧客を付けてプロダクトを拡大していこう、そんなイメージです。この頃には初期の頃にとにかく速度重視で組み立ててきたものを整理したりスケールできないクエリを最適化したり開発のフローを整理したりそもそも作り手が足りないので採用をしたり、色々なものが整理整頓・拡大されていくフェーズです。
拡大期はそういったフェーズも乗り越えプロダクトは安定的に売上を生み出し、市場での立場を確固たるものにしさらに新規のプロダクトによってシナジーを生み出していこう、そんなフェーズのイメージです。
支配期は各プロダクトも流れに乗り市場でのプレゼンスも確立でき、プロダクトライフサイクルを考えて数年先の未来に向けた投資を考える、そんなフェーズのイメージです。「ビジョン」といった言葉も使われたりする様ですが、そういった大きな目的がないとどこに対して投資していけばいいのかという部分もかなりブレると思いますので、一体会社がどういった事を何故やるのか、改めてそんな事が問われるのかなと思います。
技術を用いて結果を出せる様にしていく
職人にとっては永遠のテーマというか、エンジニアにとっては HOW は極めて重要で「最高の HOW を提供する事がエンジニアの責務」といった側面はあると思いますが、とは言ってもその HOW も最終的には「結果」[1]を出すためのものである事は言うまでもないでしょう。ビジネスとしての「結果」を強く意識して組み立てていく必要があります。
プロジェクトの本来の目的やゴールを見失ってまで最新の技術を追求したり、プロダクトや事業にどの様な影響があるのかも考えずに自分の興味本位で技術選定をしてしまっては、一体何のための技術なのか分かりません。
先程紹介した資料（やそこで引用されていた論文）でも、以下の様に触れられていました。
「技術的なビジネスマン」（technical businessman）
Building R&D Leadership and Credibility
「経営幹部たるべきでエンジニアであることは二の次」
マネジメントキャリアパス
つまり、「結果」を出せる様に技術力を経営にアラインしていく、という様な事だと理解しています。これも会社によって状況はだいぶ違うと思いますので一概に「こういう事だ」というのは言いにくいと思いますが、例えばデリバリーがとにかく遅れまくる、というような状況であれば何故そういう事が起きるのかを調べる、その結果開発のあり方を改善する、技術的な負債を返済する、などもあり得ると思いますし、本番環境のレイテンシーがヤバすぎてユーザーの離脱を招いている、といった状況であればそれを改善する、などもあり得ると思います。昨今、LLM を利用したスタートアップも多いと思いますがそういった場合には LLM の最新動向をキャッチしつつ自社プロダクトに反映していくための可能性を探る、などもあり得るかもしれません。
事業が成長するために（時間軸を見据えて）やるべき事を決める
最終的には結果を出せる様にしていく、つまり事業を成長させていく事が目標な訳ですが、それにあたってボトルネックになっている事というのは会社や状況によって様々でしょう。また、今はボトルネックにはなっていないけれども事業が成長したらなりそう、という類のものも完全に放置していては後手に回ってしまいます。
そういったインパクトの時間軸を見据えて優先順位と力量配分をコントロールして取り組む事のポートフォリオを組む事が必要です。
短期のものに100%集中というのは例えばシード期のベンチャーの様な「生きるか死ぬか」の状態では必要だと思いますが、ある程度調達もできて拡大していこうというフェーズでは少し先の将来を見据えた施策も一定は必要でしょう。逆に、5年10年先の将来を見た施策を今の段階で100%の力を使ってやるというのもバランスが悪いです。この辺のさじ加減をコントロールする必要があります。
例えば、短期的には多すぎるバグを直していく、といったプランを立てるのもよいですが、それだけでは守り一辺倒になってしまいますし、どちらかと言うとそれは「できて当たり前」の部類だと思います。そこからさらに「ユーザーがストレスなく操作できるレベルに高速化する」であったりとか、「顧客の本当に求める UX を実現するために不可欠な技術的要素を開発する」（例えば画像認識であるとか何かしらの自動化であるとか）といった中長期を見据えて攻めの将来像を描く、といったプランもあり得るでしょう。
このあたりも、その人が取り組んだ時の「味」になっていくのでしょう。
つまるところ
これまで述べてきたものを一文で表すと、
事業成長の時間軸を見据え、技術的側面からプロダクトに責任を持つ
という姿になったという経緯です。また、この辺りは会社の組織体制によって責務が広がったり狭まったりといった事はあるかと思いますが、いずれにしても経営層の中でその責務についてはすり合わせておく必要がありそうです。
具体的な取り組み
ここまではやや抽象的な理想像について述べてきました。ここからは、「ではどういった取り組みを考えているのか？」といったもう少し具体的なお話ができればと思います。
事業フェーズ
前提として、今我々がいる事業フェーズはどの辺りなのでしょうか。簡単に言えば安定化期〜拡大期の付近だと考えています。ユーザーの数も増え、売上もある程度安定してきたフェーズですので「最初期」という感じではありません。つまり、一般的には自らゴリゴリコードを書いて創出を行っていくというフェーズは過ぎているものと思います。現状で大きなプロダクトラインは２本ありますが、通過点の1つである上場も見据えさらに非連続的に成長させていく必要があり、プロダクトの拡大を検討しているというコンテキストがあります。
つまり、以下の様な成長を想定できます。
- スケールアップ（各プロダクトの成長）
- スケールアウト（プロダクトラインの拡充）
これに対して、課題になっていそう、あるいは将来的になりそうな部分に対処していく様なイメージです。
成長に対する課題
では各成長に対して、どの様な課題感があるかと言うと以下の様になります。
- スケールアップ
- システムの安定化・安定的な運用（品質の担保）
- システムのスケーラビリティの担保
- エンジニアリング力の強化
- スケールアウト
- コードベースの成長戦略
- プラットフォームの整備
これらについて書き出すと1項目1記事くらいのボリュームになってしまいそうですので😅 いったんここではリストアップに留めさせてください🙏🏻 これらには、経営の方針として予想が付くもの、自身が開発をする中で感じたもの、各エンジニアと会話をする中でヒントを得たものなどが含まれています。
取り組みのポートフォリオ
先程も触れた様にこういった課題について取り組みのポートフォリオを描き、インパクトの時間軸をイメージして優先順位を付けて対応していく必要があると考えています。
- 今まさに必要な事 ⭐⭐⭐
- システムの安定化・安定的な運用（品質の担保）
- システムのスケーラビリティの担保
- 半年〜1年先への投資 ⭐⭐
- プラットフォームの整備
- コードベースの成長戦略
- 1年以上先への投資 ⭐
- エンジニアリング力の強化
といったイメージです。足元の事も大事ではありますが、将来必要になる事、必要になった時に対応を始めたのでは遅い、といったものも一定の力は割いて投資しておくべき、といった考えです。こういったものを折り込むという事自体に、私の「味」が出ているのだろうなと思います。これがいい事だったのかどうかは、どうでしょう、数年後に分かるのでしょうか笑
終わりに
ここまで読んで頂き、ありがとうございます！とても長くなってしまいましたが、何かの参考になれば嬉しいです。
みなさんは「明日からあなたは CTO です」と言われたらどうしますか？その様な視点で思考実験をしてみるのも、ご自身のためにもよい事なのかなと思います。実は私は今年の7月に CTO に就任したばかりの新米です。皆さんから勉強させて頂き、よりよい取り組みができればと考えています。是非皆さんがどの様に考えられたか、コメントで教えてください！
CTO としての取り組みには様々な苦悩や失敗があったりしますが、そういったお話も、いずれできればと思っています。
-
ではここで言う「結果」とは何なのかという話ですが、一般的には CTO という立場の人が見るべき責任範囲としてはサービス・製品のアウトプットの「質」と「量」になると思います。このあたりはビジョナル CTO の竹内さんの記事（CTOの頭の中：技術を財務で表現する）などを参考にするとよいかもしれません。ただ、その先にはアウトカムとしての事業の成果がある事を忘れずに取り組んでいきたいものです。 ↩︎
Discussion