今回のコラムでは、あらためてCTOの役割が会社のフェーズによってどのように変化するか、そしてそれに適応していくためには何が必要なのか、適応していくことがいかに重要か、難しいか、などについてお話したいと思います。
CTOの方にとっては今の会社のフェーズや今後の展開を考えた際に、CTOの役割の変化を認識すること。そして、これから転職を検討される方にとっては転職希望の会社がどのフェーズであるか、それによるCTOやそれに準ずる人の役割がどういう状態かの参考にしていただければと思います。
会社のフェーズとCTOの役割
私はOCTOPASSの講座内で「CTOの役割は会社のフェーズによって変化する」と度々お話してきました。もちろん会社やCTOのタイプによってどのような役割が求められるか、は千差万別です。ですが、どのような会社であってもCTOに求められる役割がフェーズによって変化していくのは間違いありません。まずは、主にTechスタートアップをイメージして会社のフェーズとCTOの役割がどのように変化するかを整理してみましょう。
| フェーズ | 開発チーム人数 | CTOの役割 |
| 創業期 | 1~2,3人 | ひたすらプロダクト開発 |
| 成長期 | ~10人 | 開発環境整備、組織づくり、チームでの開発整備 |
| 拡大期 | ~50人 | 採用、オンボーディング、問題への対処、社内調整 |
| 安定・成熟期 | 50人~ | ビジョン、カルチャー、組織体制、仕組み |
当然すべてのスタートアップがこの成長をたどるわけではありませんし、どこかで停滞したり、スクラップアンドビルドをする時期もあるでしょう。人数も開発する内容によって全く異なります。
ただ、大事なことは、「フェーズによってCTOの役割が変わる」という事です。役割が必ず変わる要因は、次の二つが考えられます
- 開発チームの人数の変化
- 会社の変化
具体的にどのような変化が考えられるか、１つずつ見ていきます。
大変さも含めて何をやっても楽しい創業期
創業期は夢と希望にあふれ、新しく作るプロダクトに心を踊らせつつ、０から開発ができる喜びを噛み締めながらひたすら開発をする時期です。もちろん、不安もあります。本当にうまくいくのか？資金は大丈夫？この創業メンバーとうまくやっていけるか？など多くの「？」がありますが、それを補って余りあるくらい「楽しい」時期です。
そして、CTOとしてはひたすらプロダクトを作ることに最も集中できる時期だと言えるでしょう。いきなり利用者が増えるわけでもなく、技術負債があるわけでもないので、大きな問題も起きにくいでしょう。仕様に関するディスカッションも、まだ何も始まっていない中ではしがらみもなく、ビジネス側メンバーとも衝突することも少ないはずです。
では、このフェーズのCTOはバラ色なのか、と言うともう少し複雑です。「この時の小さな開発における意思決定の誤りが、その後何年にも渡って負債になる」からです。創業期で楽しいからと言って、ゆっくり時間があるとは限りません。少しでも早くプロダクトを完成させる、というプレッシャーの中で開発を進めていく必要があるので、汚いコードをたくさん書かないといけないかもしれませんし、間に合せの実装で進んでしまうことも多いでしょう。それを飲み込みながら創業時のスタートダッシュにコミットすることが、創業期のCTOに求められます。
コアなチームを作れるかどうかが鍵の成長期
ある程度自分ひとりで開発をしてプロダクトを完成させ、（と言ってもかなりミニマムな状態）、メディアであればトラフィックの増加、B向けであればクライアントが増え始める時期です。どこかのタイミングで右肩上がりになりつつある時期を迎えるはずでしょう。それが成長期の始まりです。ここから出てくる問題は「あって当たり前なのに無い機能」をいかに速く実現するかということや、創業時に前提として考えていたことが180度変わってしまう、いわゆるピボットする際にどのように実プロダクトを作り変えるか、などです。
規模が大きくないのであれば引き続きプロダクト開発に没頭しながら対処していけばよいでしょう。しかし多くの場合早いスピード改善が求められます。これらに対処するためにエンジニアの採用も始める事になります。場合によってはフリーランスの助っ人で済ませることもあれば、知り合いを連れてくる、というショートカットもあります。いずれにしても、事業を少しでも前に進めるためには小さくても開発チームを作っていく必要があります。
CTOはまだ手を動かしながらの状態であることが多いでしょうが、平行して人が増えることへの対処が必要です。自分ひとりで開発している状態ならまだよいですが、人が増えるとチーム開発をうまく進めるためのタスクが増えてきます。
- 開発環境の整備
- デプロイプロセスの作成
- タスク管理
- コードレビュー
- テストの担当者
- 進捗管理
などです。
必ずしも、CTOがそれらをすべて受け持つ必要はありません。Tech Leadのようなエンジニアのお手本になり他のエンジニアをハンズオンで引っ張ってくれるような人や、プロジェクトマネジメントやプロセス構築が得意なエンジニアを採用して、任せていくこともできます。
ここで大事なのは、「CTOとしてどこをやるべきで、どこはやらないべきか」を採用するメンバーとのバランスで考えながら進める事です。
「自分はコードを書き続けたい」ということであればチームをうまく機能させることが得意な人を採用すべきですし、そうでなければスキルのあるエンジニアを採用すべきです。
この時期に自分の特性を自分自身で見極めて、コアな人材をしっかり採用できるかどうかが、この後の成長に大きく関わってきます。
CTOの役割が最も変化する拡大期
事業やサービスが成長すると、それに対応するために多くの人を採用することになるでしょう。このフェーズでは最も大きくCTOも役割が変化します。
その要因は次の通りです。
- 採用に費やす時間が増える
- 人が増えると業務効率化のための仕組みづくりが必要になる
- 社内の開発チーム以外の人とのコミュニケーションが増える
1. 採用に費やす時間が増える
これは容易に想像できるのではないでしょうか。エンジニアの採用は最終的にはCTOが責任者です。エンジニアの採用自体も人事やエージェントに任せているだけではまず間違いなくうまくいきません。昨今のエンジニア売り手市場の中では、エンジニアにとって魅力的な環境をつくる必要もあります。それは単に待遇や福利厚生という話ではなく、利用技術や技術的チャレンジ、個人の裁量、他エンジニアとの関係性やレベルなど、開発チーム独特な観点が重要です。
2. 人が増えると業務効率化のための仕組みづくりが必要になる
人が増えるとチームとして機能させるための仕組みが必要になります。開発そのものをうまく進めるための仕組みであればCTOや他のエンジニアもツールの導入、自動化など積極的に取り組むと思います。しかしそれ以上に問題になるのは、チーム間のコミュニケーションや認識の統一、もっと大きな観点ではそもそもプロダクトとして目指すビジョンや方向性などです。これは全体を俯瞰できる立場であるCTOでなくてはできません。
3. 社内の開発チーム以外の人とのコミュニケーションが増える
これは意外と見過ごされがちです。成長期はがむしゃらに成長するためのプロダクト開発や採用を進めますが、いざ人が増えてシステムの複雑度が上がることや、ユーザや顧客の増加、それに伴い事業メンバーとのやり取りも増えてことで、気がつくと社内で組織間の壁や認識のズレが生じていることが多くあります。むしろそれが起きない方が不思議です。
今まではチームが違ってもお互い近くで仕事をし、何かあればすぐ対面で相談をし、ランチや飲みに行く事もしばしば。認識の齟齬や意識の違いはこのようなコミュニケーションで知らないうちに解消されています。しかし、チームごとに人が増えてくると、コミュニケーションの方向が横から縦に変わり、現場メンバーが横同士でうまくコミュニケーションをすること以上に、チーム内、つまり縦のコミュニケーションが重視されるようになります。組織構築においてはそれは必然ですが、十分に意識をして横のコミュニケーションを設計しない限り、チーム間の見えない壁が徐々にできてしまいます。特にエンジニアの会話は、非エンジニアからは全く理解のできない内容であることが多く、それが余計に見えない壁を作り上げる要因になります。
このような状態が続くと、「開発は何してるかわからない」という話が上がってきます。これは、「わからない」ことが問題なのではなく「相互理解する土壌」が徐々に無くなってしまっていることが問題です。「じゃあ定例ミーティングで進捗を、もっと詳細に共有しよう」ということだけではなかなか解消しません。
このような組織拡大期に、どのような仕組みで見えない壁をなくしていくか、などについては多くの事例がありますので、この先のコラムでご紹介します。
役割の変化を知ることが第一歩
創業時にCTOとして参画し、プロダクト開発に没頭していた頃から見て、例えば上記の拡大期に求められるこれらの役割は、おそらくあまり想像していないことかもしれません。
もちろん、開発をするだけではなくこのような組織課題に取り組み、経営陣の一人として会社の成長に貢献できる人も多くいます。しかし、それがあまり得意でない人にとってはこのタイミングでCTOに求められる役割と、自分ができること、やりたいことにギャップが生まれます。一つの解決方法として、いわゆるVPoE（VP of Engineering）やEM（Engineering Manager）のような役職が発達してきています。CTOが引き続き技術やプロダクト開発の指揮を取る役割を担うために、それ以外のマネジメント業務を任せられる人を採用することになります。
また、このようなタイミングでCTO自体をバトンタッチすることも十分に考えられます。それ自体、ネガティブなことではなく、役割の変化を受け入れて、会社の成長にとって何が一番良い選択肢か、という考え方です。このようなチームの変革、役割の再定義も他の経営メンバーからCTOに求められることでしょう。
このようなCTOの役割の変化を知った上で今置かれている状況を見つめ直したり、今後のキャリアを考えていくことができれば、より有意義なキャリア構築ができることと思います。
