スタートアップ初期のCTOの役割
はじめに
こんにちは、@soyanchuです。
2017年4月〜2018年10月頃までスタートアップでCTOをしていました。
CTOをしてる間は、右も左もわからない中ですが、沢山のことを経験させてもらいました。
自分がCTOだったときに思っていたのが、CTOの役割って何？、この程度の技術レベルで大丈夫なの？、◯◯のスキル無くて大丈夫？ といったことを不安に思っていたことです。
周りのCTOの方にアドバイスをいただいたり、記事を読んだりして手探りでやっていましたが、もっと色々な人のまとまった話があれば、参考になるのに・・ というのを感じていました。
そこで、今回は自分の振り返りと過去のCTOに成り立てだった時の自分のために、スタートアップ初期のCTOに求められる役割は何か？ というのをまとめました。
まず、CTOに求められると思われる役割やマインドについて書いた後に、その後スキル面について記していこうと思います。
これから共同創業してCTOになる方や、CTOに興味のある方向けに参考になるようとなれば幸いです。
目次
- 対象読者
- 前提
- 結論： 初期のCTOの役割は、プロダクトの自分ごと化 × 最速でプロダクトの仮説検証をする開発責任者
- 求められる役割① プロダクトの自分ごと化
- 求められる役割② 最速でプロダクトの仮説検証をする開発責任者
- 【スキル：インフラ】 初期はPaaSを活用して、アプリケーションの開発に集中する
- 【スキル：RDB】 RDBの知識はマスト。設計には時間をかけるべき
- 【技術負債】技術的負債を出来るだけ作らないように意識。将来的な拡張も見据えておくこと
- 終わりに
対象読者
- 初期のスタートアップでCTOになったエンジニアの方
- 今後スタートアップで働く事に興味があるエンジニアの方
- CTOがいないスタートアップのCEOの方
前提
まずはじめに、CTOに求められる役割は組織のフェーズごとに大きく変わるのと、会社の事業内容やプロダクトによっても前提条件が変わると思うので、先にどういう条件で働いていたのかを整理しました。
<前提>
- 0→1での開発と、 1→10での開発の両方を経験
- 規模は10人以下。シードラウンド~シリーズAの手前まで在籍
- エンジニアの人数はフルタイムが私1人。月40h程度の業務委託の方が1~2人程度
- プロダクトの最終的な意思決定はCEO、技術に関する責任はCTOという役割分担
- 私自身はほぼ創業メンバーでCTO
- Webサービスを運営。技術スタックは、Vue.js / Nuxt.js / Ruby / Ruby on Rails
結論： 初期のCTOの役割は、プロダクトの自分ごと化 × 最速でプロダクトの仮説検証をする開発責任者
結論、初期のCTOに求められる役割は、最速でプロダクト・マーケット・フィットさせるために、プロダクトに関わるすべてを自分ごとで考えることと、その上で開発責任者として、最速で仮説検証サイクルを回すことに時間を割くことだと考えています。
CEOはプロダクトの最終的な意思決定をするいわゆるプロダクトマネージャー的な役割だとすると、CTOはそれをどうやったら仮説を早く実現できるのか？という点に主眼を置く方が良いのかなと考えています。
注: プロダクトマーケットフィット（Product/Market Fit）とは、顧客の課題を満足させる製品（プロダクト、サービス）を提供し、それが適切な市場に受け入れられている状態のこと。略称は「PMF」。
https://makitani.net/shimauma/product-market-fit より引用
求められる役割① プロダクトの自分ごと化
エンジニアリング以外の様々な業務にアンテナを張る
まず第一に、プロダクトに関わるすべてを自分ごとで考えることです。
これは、つまりエンジニアリングはもちろんのこと、ユーザーインタビュー、デザイン、マーケティング、カスタマーサポート、分析などすべての領域全てにアンテナを張っておくことと考えています。
どうすれば顧客が喜ぶのか？、顧客はどういうことを考えているか？ ということを常に考えながら、必要なことは全部やる！ という意識が大事です。
大事な理由は、最低限のコミュニケーションで最速で実装まで進められるためです。
スタートアップ初期は単純に人が少ないしお金も大抵ないので、数人の段階は、そもそも何やってる会社？ となることがほとんどです。
新しい人を集めてくるのも難航します。採用活動は別で当然やるべきですが、少ないうちはどうしても兼務が求められます。
そんな中例えば、自分は開発の部分だけやればよくて、KPIを追っていくのはビジネスサイドにまかせておけばいいや… となってしまったらどうでしょうか？
エンジニア側だからこそ分かる、KPIを出すことを踏まえたテーブル構造にしなかったり、意思決定のために重要なログを取り残したりする可能性があるかもしれません。
もしそうなってしまうと、余分なコミュニケーションコストがかかってしまう原因になってしまいます。
もし、エンジニアが全体感を捉えた上で仕事をしている場合は、都度の依頼が減り、余計なコミュニケーションをかけすぎずに、阿吽の呼吸でスピーディに仕事ができます。
プロダクト責任者から見ると、コードの細部まではエンジニア出身でない限りは分からないため、CTOからガンガンこうしたほうがいいんじゃないか？というのを提案していくのが望ましいと思います。
全体感を掴むため、実際にエンジニアリング以外の業務も行う
私は実際に以下のようなこともユーザーのニーズや運用上の課題の把握のために行っておりました。
- 営業に同行して、顧客の課題をヒアリング
- 顧客へのカスタマーサポートへの対応をし、運用上の課題の洗い出し
- ユーザーインタビューに実際に参加した後に、改善点をまとめてすぐ実装
勿論、全部主業務として行う必要はないですが、週に1回ほどエンジニアリング以外の業務にも向き合ってみると、全体感を捉えるサポートになるとおもいます。
求められる役割② 最速でプロダクトの仮説検証をする開発責任者
仮説検証に必要なことは何でもやる
もう一つ大事なのは、最速で仮説検証サイクルを回すことです。
前述の通り、顧客の課題を中心に考え、その部分に責任を持つのはCEOだと思いますが、CTOはそれをいかに最速で検証できるかに責任を持つべきだと考えています。
そのため、検証したい課題仮説は、CEOとCTOを中心に、優先度をつけた上で、優先度が高いものから順に対応していくのが望ましいです。
この時大事なのは、立てた仮説が本当に合っているか？であり、コードを書くことが目的ではないということです。
というのもエンジニアの人員は限られているので、コードを書かなくてもいいのであればそれに越したことはないです。スプレッドシートやAirtableをはじめとしたツールを使うことで、早く検証することができます。
実際、前開発していたプロダクトだと、企業向けの管理画面を開発するのに1週間ほどかかりそうだったので、スプレッドシートで実現したこともあります。
議論はほどほどに。究極的には作ってみないと分からない
時には、CEOとCTOで意見が衝突することがあるとは思いますが、究極的にはやってみないとわからないので、すぐ実現できるのであれば、まず実装してしまうというのが大事だと思います。
KPIやユーザーからの反応を見て駄目なら切り戻してしまえばいいと思います。
Facebookのザッカーバーグの言葉で、Code wins argumentsという言葉がシンプルに的を射て好きです。
【スキル：インフラ】 初期はPaaSを活用して、アプリケーションの開発に集中する
続いて技術的な話にうつります。
まず大抵の場合、スタートアップは開発人員が少ないので、インフラがよっぽど重要なサービスでない限り、HerokuのようなPaaSを使うのがいいのではないか？と考えています。
実際、私が開発していた時も、SPAのフロントエンドとバックエンドの開発で手一杯だったなというのを実感していました。
インフラ側でエラーが起きて、サービスが使えなくなってしまうと、その間はユーザーに全く価値を届けられないことになってしまう一方で、対応したからといって何かプロダクトが一歩前進したかというとそうではないというのが辛いところです。
実際、HerokuをAPIサーバーで使っていましたが、デプロイや設定周りも簡単で、大きく使いづらいところはなかったので、アプリケーションの開発に集中できたのがよかったです。
※ 料金は少し高かったですが、専任のインフラエンジニアを雇うよりは遥かに安いです。
【スキル：RDB】 RDBの知識はマスト。設計には時間をかけるべき
スキル面でいうと、RDBの設計はマストでできたほうがいいと思っています。
なぜかと言うと、データ構造によって実現できることが変わったり、後からリファクタリングするのが辛かったりするためです。
そのため、どういうプロダクトにしていきたいのかというのをCEOと会話しながら、テーブルの設計段階で拡張性高く考慮しておくことが大事です。
ここがガタガタで全く正規化されてないコードだと、どんどん辛い感じになってくるとおもいます。
最悪、アプリケーションのコードは全部書き直せますが、RDBの設計には時間をかけすぎるに越したことはないと思っています。
Jokerさんのツイートが同じような趣旨のツイートだったので、貼っておきます。完全に同意です。
RDBの設計やモデリングのおすすめの書籍も貼っておきます。
【技術負債】技術的負債を出来るだけ作らないように意識。将来的な拡張も見据えておくこと
前提、技術負債は時間が経つにつれて、溜まって行くものだと思いますが、明らかに可読性や拡張性がないコードを書くのはNGだと思っています。
超短期的にリリースして終わりというプロダクトであればまだしも、運用は続いていくものなので、読みづらいコードを書いた後に苦しむのは1ヶ月先の自分です。
人間はすぐ忘却してしまうものなので、設計やコードの意図が分かりづらいものを書くと、後々これなんだっけ…と考えるコストのほうがかかるなと感じます。
私の場合は、要件を踏まえて、ある程度拡張性高く作っておいたり、重要な部分のユニットテストを書いておいたり、最低限lintのツールを入れておいたり…ということは最低限やっていました。
とはいえ仮説検証のスピードが優先なので、過度にガチガチの設計をする必要はないとは思いますが、最低限の品質のコードは書くべきです。
技術的負債はこちらの記事が分かりやすいです。
【開発マネジメント】 あえて細かい管理手法は使わないのもアリ！目的に沿った手法を選ぶことが大事
私の場合は、あえて細かいチケット管理などは行わなかったです。スプレッドシートで課題表だけ作って優先度をつけて上から開発していくくらいでやっていました。
というのは、元々ははじめは細かく要件を決めて、スクラム開発のような手法を導入しようとしていました。しかし、試しにやっていくうちに、少ない人数の割に、手間暇がかかりすぎたので、途中でやめました。
チケット管理ツールなども色々使っていましたが、結局スムーズに使えてお金もかからないスプレッドシートで管理するようにしていました。
数人で開発してるうちは特に大きな課題は発生していなかったです。
ここで伝えたいのは、どの開発手法でやるかはあくまで実現するための手段であって、目的はPMFすることやいいプロダクトを作ることです。
チームとでスピードを出せて、最速で成果が出せる手法を選択するのがベストだと思います。
終わりに
初期のスタートアップで大事なのは、事業が成長するために必要なものは何か、特にプロダクトを伸ばすために顧客と対話することに時間を使うべきだと思います。
特に初期のCTOはプロダクト・マーケット・フィットさせるために、プロダクトの仮説検証サイクルを回すことに時間をつかうべきだと感じます。
逆に言えば、プロダクトへの関心度が高く、事業をエンジニアリングを使って伸ばしていきたい！そのためにはなんでもやる！ という方は初期のCTOの適正があると思います。
今回の記事で、創業期のCTOを考えられている方や起業されてCTOを探されている方の参考になれば幸いです。
Discussion