スタートアップにおけるCTO採用

前回、スタートアップにおけるCFO採用という記事を書いたので、今回はその続編ということでCTO採用について書いてみたいと思います。

テクノロジーを競争力の源泉とする昨今のスタートアップにおいて、CTOは必須の重要ポジションとなっています。

CTOがいなければ良いアイデアがあってもうまくプロダクト化することができず、またVCからの資金調達でも優れたCTOが経営チームにいるかどうかで評価が大きく変わってきます。

しかし、技術のバックグラウンドがないCEOの場合、CTO採用は困難を極めます。CFO採用と同様に、CTOも距離が遠いポジションですよね・・・。

さらに、優秀なエンジニアは人材市場において超売り手市場。エージェントへの紹介フィーはどんどん高騰し、カジュアル面談という名のゼロ次面接が当たり前となり、有名スタートアップからメガベンチャー、大手までの熾烈な争奪戦となっている状況です。

シード・アーリーのフェーズでは、そんな環境のなか、お金も知名度もない状態でCTOポテンシャルがある優秀人材を見つけてこなければなりません。

スタートアップをやりたいけどCTOが見つからないのではじめられない、という方もけっこういるんじゃないでしょうか。

今回は、CTOとCEOの気持ちが両方わかる元CTOのCEOとして、スタートアップにおけるCTO採用についての記事を書いてみたいと思います。（課題感が強いであろう、シード・アーリーに寄せて書いています）

CTOはなぜ必要か？

そもそも、CTOって本当に必要なんでしょうか？

CTOという経営ポジションではなく、コードを書けるエンジニアをメンバーで何人か採用するだけではダメなのか。もっというと、世の中に多数あるシステム開発会社に外注したらいいのでは、と思うかもしれません。

既存パッケージなどを販売して営業やコンサルで勝負する、という会社では必要ないかもしれませんが、既存のものにない新しいプロダクトで勝負するスタートアップであれば、CTOは必須のポジションとなります。

プロダクト開発は建築に似ています。手早く作れる小屋を積み上げていっても、大きな高層ビルをつくることはできません。

建築現場を見るとわかりますが、高層ビルを建てるのであれば、まず深く基礎を掘るところからはじめなければいけません。建物を建てた後からでは、基礎を作り直すことはできないのです。

CTOはただプロダクトの機能を実装するだけではなく、将来のプロダクト構想に耐えうる最適なアーキテクチャを設計します。

選択したアーキテクチャによって、開発効率やメンテナンス性、組成する開発チームのスキルセット、サーバーのコスト構造が大きく変わってきます。

こういった技術戦略の意思決定は将来の会社の成長を大きく規定することとなり、まさしく経営判断となるため、CTOという経営チームとしてのポジションが必要となるのです。

また、もう1点。開発の完全外注は絶対にオススメできません。

CTOやエンジニア採用が難しいため、我慢できずにプロダクト開発を外部に委託するスタートアップをよく見かけます。

「知人がいる開発会社と意気投合して・・」「仕様はイメージできてて、後はつくってもらうだけだから・・」などの話を聞くのですが、スタートアップで開発を外注して成功した会社をいまだ見たことがありません。

発注先のシステム開発会社がイケてなかったのでは？ということではありません。そもそもインセンティブの構造に無理があるのです。

システム開発会社は、依頼された仕様を満たすプロダクトを完成させることで売上となり、そこがゴールとなります。一方、スタートアップ側はプロダクトの完成がスタートとなり、そのプロダクトを使うユーザーへ価値を生み出すことがゴールとなります。

クライアント自身がユーザーであればまだいいのでしょうが、システム開発会社は開発するプロダクトがユーザー価値を生むかよりも、クライアントの意向を満たすかに意識が向いてしまい、この食い違いが致命的です。

システム開発を外注する場合は、レベニューシェアにしたり、資本参加してもらうなどインセンティブの構造を揃えないといいプロダクトをつくることは難しいと思います。

CTOを採用する3つのポイント

それでは、重要度が高いが採用難易度も高いCTOを採用するにはどうすればいいか。ポイントを3つにまとめてみました。

• ともに成長できる人を

• 整ってないを武器に

• 技術に理解あるカルチャーへ

それぞれ、説明していきます。

ともに成長できる人を

まず、どんなCTOを採用したいと思っていますか？

優れたCTOというと、高い技術力を持ってて、十分なビジネス理解があって、優れた開発組織をつくれる人、という要件をイメージしている人が多いのではないでしょうか。

しかし、そんなCTOはほとんどいないのが現実です。そもそも技術自体が専門性が高く、高い技術力を維持するには相当量の時間を費やす必要があり、さらにその上でビジネスや組織マネジメントのスキルを身につけることは困難です。

ですので、そんなスーパーCTOをはじめから採用するのではなく、要件をぐっと落としつつもポテンシャルを見極め、会社とともに成長できるCTOを探すのが良いと思います。

具体的にいうと、シード・アーリーのフェーズにおいては、組織規模が小さいのでマネジメントのスキルは高くなくても構いません。また、CEOが直接全員と会話することが難しくない規模なので、CTO自身のビジネス理解が浅くても大丈夫でしょう。

少人数でPMF(Product Market Fit)まで高速に走りきる必要があるシード・アーリーにおいて重要なのは、とにかく高い技術力や実装力です。そして、ビジネス理解や組織マネジメントに関しては、そこを伸ばせるポテンシャルがあるかを見極めましょう。

もちろん、会社のステージが進み組織規模が大きくなると、CTO自身がビジネス理解をしてプロダクト戦略を描く必要がでてきますし、規模が大きな組織の採用や組織戦略を実行する必要がでてきます。

それを見越して、会社とともに経営チームとして成長していける人を採用するのが良いと思います。

整ってないを武器に

激しい争奪戦となるCTO採用において、有名スタートアップやメガベンチャーにとても勝てないと思うかもしれません。高い報酬、大きな規模のビジネス・プロダクト、優れたカルチャーやブランド、どれも勝てそうにありません。

しかし、シード・アーリーのスタートアップにも大きな武器があります。それは、整っていないことです。

有名スタートアップ、メガベンチャーが提示できない、CTOを目指すエンジニアにとって最も刺さるポイントは「技術アーキテクチャを自分で決められる」ことです。だって、まだ決まってないのですから。

何のプログラム言語を使い、どのフレームワークを採用し、ミドルウェアやインフラで何を選択するか。これをプロダクト特性、ビジネスモデルにあわせて設計し、実装していくことはアーキテクチャが好きなCTOを目指すエンジニアにとって大きな喜びです。

「こういうプロダクトを考えてて、こんなことに困ってるユーザーに絶対刺さると思うんだけど、あなただったらどんなアーキテクチャにしますか？」と面接で聞いてみて下さい。

嬉々としてアーキテクチャを語るエンジニアに出会えたら、ぜひそれをつくってください！とアトラクトしましょう。

技術に理解あるカルチャーへ

エンジニアのほとんどの人が経験したことがあり、嫌っている組織カルチャーがあります。それは、エンジニアがビジネスサイドの下請けとなっているような会社です。

仕様決定のプロセスに関わることができず、決まったこととして要件が落ちてきて、納期ばかりを気にされ、動いて当たり前で不具合があれば責められる。。

エンジニアはこういう会社をできるだけ避けようとしますので、プロダクトに強い会社をつくるには、技術に理解あるカルチャーの会社である必要があります。

シード・アーリーな会社にとっては、会社のカルチャー=CEOのパーソナリティとなりますので、CEO自身の技術理解が重要となってきます。

可能であればオンラインのプログラミングスクールなどに通って学ぶなどをオススメします。エンジニアになるというよりも、一通りWebアプリケーションの開発プロセスを経験することで、エンジニアのカルチャーを理解できるようになることが重要です。

少しでもコードを書いたことがあるならばあなたはもうエンジニアであり、エンジニアとの面接の手応えが大きく変わってくるはずです。

---

あわせて、この記事に関連する他の投稿もどうぞ

エンジニアのタイプを技術が好き・プロダクトが好き・組織が好きの3つに分けるとキャリアや採用を考えやすいという記事です。CTOや技術組織の理解を深めるご参考になれば

CFO採用について書いた記事です。CTO同様、採用が難しいポジションであるCFOについて、採用のタイミングや方法、3つのタイプ分けなどについて書いています

最後まで読んでいただきありがとうございました。
↓❤️スキをクリックしていただけると継続する励みになります！🙇🏻‍♂️