序文

　今年の2月にノバセル株式会社はラクスルから分社化し、そのタイミングで CTO に就任いたしました、戸辺と申します。CTO になるのは9年ぶり2度目であり、前回とは就任の経緯も違いますし、会社も別ですし、フェイズも異なります。また、以前に比べ自分の考え方も大きく変化しています。今年は「CTO ってなにしてるの？」という意図の疑問を、セミナーのテーマや、採用面接の候補者からの質問、それにメンバーとの 1on1 などで多く頂きました。今日はそれらについて自分なりに考えたことを、Advent Calendar の 1枠でお話したいと思います。

　今日の内容は以下の方向けに書いています。

将来 CTO になりたいと考えている方
これから CTO になる機会が訪れそうな方
スタートアップにおいて最初の CTO たるエンジニアを採用しようと考えている方
自社の CTO が何をしているか知りたい方

CTO とは、事業を加速させる存在

　いきなり結論から書きますが、CTO とは事業を加速させる存在です。こう定義づけると、CTO がなにをしているか、また何をすべきかを理解しやすくなると思います。これについては今年の4月に行われた DAY ONE という日本 CTO 協会主催のイベントでもお話しておりますので興味のある方は是非アーカイブを御覧ください。

www.youtube.com

　以下、この原理原則に従って、今年多く聞かれた質問に回答していこうと思います。

CTO はコードを書くべきか？

　これは今年もっとも多く頂いた質問かもしれません。これについては、一言では回答できません。なぜならば、回答に必要な条件が不足しているからです。つまり、当然時と場合によるのです。これも、CTO がコードを書くことで事業を加速させることができるか、という観点で答えることができます。例えば、その CTO が一人目のエンジニアで、その人がコードを書かなければプロダクトが開発できず、プロダクトができあがらなければ事業が進捗しないのであれば、当然コードを書くべきです。この例は非常にわかりやすいと思います。　次に、人数が5人くらいになったときのことを考えてみましょう。ここからはさらに他の条件を勘案する必要があります。

CTO がもっとも技術力が高く、他のメンバーよりコードを書くことで事業進捗を最大化できる
- コードを書くべき
他のメンバーもコードを書くという面では CTO と遜色がなく、コードを書くということがいちエンジニアと変わらないバリューしか発揮できない
- コードを書かずに、他のことをやるべき
採用タスクなど、他のメンバーではできないが自分にはできるということがある場合
- コードを書かずに、他のことをやるべき

この思考実験の回答には、人数というファクターが入っていないので、実は人数を n に拡大していっても通用します。実際には、人数が多くなればなるほど、1 点目の状況がおこりにくく、自然とコードを書かないことが合理化されていくと思われます。

例えば、メンバーの中でもっとも優秀なエンジニアより、CTO のほうが 1.5 倍サラリーをもらっているとしたら、そのメンバーより少なくとも 1.5 倍以上のスピード or クオリティでコードを書けない限り、CTO のほうが ROI の悪い存在になるということです。

CTO が採用に時間をかけすぎてもいいのか？

　これは明確に Yes です。事業進捗を加速させるために、いわゆるヒト・モノ・カネというリソースのコントロールが重大な関心事になるのは自明です。そのうちの最もコントロールが難しいのがヒトであり、難易度の高い課題に CTO が向き合うというのは大切だからです。もちろん「採用がとても得意なメンバーがいる」などの条件が整っている場合は、そのメンバーに委譲するのも重要ですが、そういう意思決定も含めて、採用に向き合うのが大事だということです。エンジニア採用については、前職時代に note を書いているのでこちらもご覧いただければと思います。コーポレートの採用チームとエンジニアが、どのように連携して採用に向き合うのがベストかということを書いております。

[NewsPicks 時代に書きました]NewsPicks流エンジニア採用の極意

タイトルはこうありますが、どこのエンジニア組織でも使える普遍的なお話になっていると思います。

技術選定に CTO はどう関わるのか？

　これは結構抽象度が高くて難しい問いだと思います。「事業を加速させる」という原理原則に沿って考えてみたいと思います。技術選定というのは基本的に誰がやってもよいものだとは思います。しかし、そこにはなぜそれを使うのかという論理、または、それを選択する人のスタンスをしっかり見ることが重要だと思います。短期視点だけでなく中長期の視点が含まれているか、その考えの論拠がおかしくないか、最後は CTO がその意思決定に責任をもてるか、あたりがポイントだと思います。

　例えばノバセルで採用した新しい技術として、昨年は Snowflake 、今年は Rust があげられます。Snowflake を採用した意思決定プロセスについてはここで書くと長くなってしまいますが、これは CTO として僕自身が選定、意思決定まで行っています。結果的に Snowflake では、それがないときとは比較にならない生産性の向上が実現できましたし、今年に入ってからは Snowflake がなければできなかった形でのサービス提供も可能になり、事業進捗が大きく加速しました。

　Rust については、技術ダイバーシティの向上を意図して採用いたしました。ノバセルは従来は Rails でサーバサイドを作るのが一般的でしたが、例えば、採用市場において Rails の魅力は年々下がってきております。また、Rails では解決できない課題があったときに、別の言語をそのタイミングから導入するのは後手に回ってしまっていると言わざるを得ません。そういう考えから、言語の特性的に Ruby とは遠い位置にあり、かつ、エンジニアが気持ちよく開発できる言語として Rust を採用しました。Rust はまた、実行時エラーが極めて少なくなるように設計されている言語であり、耐障害性も高く、長い目で見ると生産性にも寄与するものとなります。高い生産性、組織の技術が陳腐化することの防止、採用市場における魅力づくり、内部のエンジニアのモチベーション向上、これらを考慮し、短期での生産性の低下(いま目の前にある要件を満たすだけならおそらく Rails のほうが早い)とのトレードオフでも十分価値があると判断し、採用にいたりました。

　書いていて思いましたが、技術選定の案は多くのメンバーから幅広くいただきつつ、中長期で視座高く意思決定をするのは CTO がやりきるほうが良いかもしれません。責任を取るのも CTO ですし。

まとめ

　他にも今年は、CTO 一年生という立場にありながらたくさんの質問をいただきましたが、基本は「事業を加速させる」という大目的に最短距離で近づけるか？という抽象度の高いところから考え、個別具体の意思決定に降りてくると、比較的すっきりと回答がだせたかと思います。目的思考というのは非常に大事であるという話でもあるかもしれません。

　大きな意思決定だけでなく、普段の細かい言動、Slack への post ひとつとってみても「何の目的でそれをするか」というのを立ち止まって考え「期待通りの結果が得られるか」ということを考え、実行し得られた FB から次の言動を考える、という訓練を繰り返すのが、目的思考を鍛える上で重要だと思います。

　目的思考を鍛え「事業を加速させる」という目的のために自分はなにをすべきか、それをひたすら考え続ける1年だったかと思います。　CTO はこういうことを考えているという参考になれば幸いです。