サイトアイコン tracelog@UCLA

CTO Material

kosuket

この前友人のhirogwaさんと話の流れで、
最近のMBAでよくある、
テック経験のない人の始めるテックスタートアップの
CTOのイケてない確率の高さについて雑談したので、
その辺を主にMBA関連の人向けに説明してみようと思います。

注1: ただの独断と偏見です。笑

注2: 基本的に、エンジニアリングのバックグラウンドがない人が
MBA在籍中に始めたSoftware/Internet Service系のスタートアップ
を想定して書いてます。

注3: 知ってる人の数的にアメリカ中心で持った印象です。

注4: エンジニア等テックバックグランドのある人には
多分当たり前過ぎるので「あるあるー」と共感してもらった後に
rebuildのこのエピソードを聞いたり
この辺の記事を読んだりしてください。笑

MBAでよく見かけるCTOの選び方

1. テックのトレンドをたくさん知っている

たまにテック企業のMBA採用も(ビジネスサイドは)
初めのHRスクリーニングでこんなこと気にしてる会社もありますが 笑
CTOをこの観点のみで選ぶと多分終わります 笑
このタイプの人達はフィージビリティを考えないまま
あれこれ最新のツール/ソリューションの提案をしてきます。
多くの場合、
最新のツールを使う＝イノベーティブ＝いいこと
というのが彼らの使うロジックなので
エンジニアは振り回され疲弊します。

2.コードがすごい書ける

これも1.と同様で基準の一つとしてはよいのですが、
これだけでCTOを選ぶと多分苦労します。
CTOの仕事のメインは、(スタートアップ超初期を除けば)
コード書くことではないので、
コードがすごい書けるけどCTOのコアの仕事をしたことがない人だと
CTOとしては正常に機能しないかもしれません。

こういう選び方をしてしまう背景には

ウェブサービスやソフトウェアプロダクトを作るということ
＝コードを書くこと→コードが書ける人がCTOがいい！

作るプロダクトをイケてる感じにする
＝最新のトレンドを使う。→最新のトレンド知ってる人がCTOがいい！

という発想が、CEOの頭の中にあるからなんじゃないかなーと思います。
こう考えてしまうのは、ボクが思うに
プロダクトを作るというのはどういうことを意味するのか
に関しての理解がないことに起因してる気がするのですが、
経験なしにプロダクトを作ることがどういうことなのか
想像するのは至難の業です。
そして、それがテックバックグランドを持ってないファウンダーが
CEOをやる時に叩かれる根本的な原因だと思います。

が、バックグラウンドがあろうがなかろうが、
やりたくなってしまったものは仕方がないことので 笑
とりあえず下記は知っておいた方がいいと思います。

ソフトウェアエンジニアリング

プロダクトを作るという作業で一番イメージしやすいのがコーディングですが、
プロダクトを作ること＝コーディングではないです。
ソフトウェアエンジニアリングについてちゃんと書こうとすると
スーパー長くなってしまうので、そういうのはまた今度にしますが、
ハイレベルなところだけ超簡単に書くと
ソフトウェアエンジニアリングは大きく分けて

というタスクがあります。
世の中には色々な開発手法があり、
開発手法によってそれぞれのタスクをまわすサイクルが違ったり
タスクの単位が違ったりしますが、
製品/サービスを作って世に出してユーザーに使ってもらう
という過程で、エンジニアサイドではこの5つはほぼ必ず通ることになります。なのでCTOは上記全てのタスクについて体で分かっている必要があります。
全てのタスクについて分かっていないと、例えば
「この設計をすると運用フェイズでこういうことが起こった時に問題が起きそう」
といったタスクを跨いだ潜在的な問題に気付けないです。

CTOの仕事

では、CTOは何する人なのか、ですが、
CTOは基本的にはエンジニアサイドの物事を決める人だと思います。
大企業で言うところのTech PM+PMOの職務兼任的なイメージです。
システムの全体デザイン(どういう仕組みで動くか)を決めたり、
開発体制/手法を決めたり、
運用保守の仕組みを決めたり。
プロダクト全体の要件定義もCEO等他のステークホルダーと恊働ですが、
CTO主導で行われるべきだし、
設計もエンジニアと恊働ですがCTO主導だと思います。

スタートアップの超初期ではCTOもコーディングすることが多いですが
それはCTOの職務だからではなく、
単純にエンジニアリングのリソースが足りないからです。
別にそれ自体は全くもって悪いことではないですし
むしろ普通のことですが、
近視眼的にコーディングスキルだけ注目してCTOを採ると
どこかのタイミングで運用まわらなくなったり
すごい複雑な仕組みのわりに
ユーザーのメリットがいまいちないプロダクトになってしまったり
中長期的に困ることになる可能性が多分にあるので、
気をつけた方がいいです。

じゃあCTOにどんな人を採ればいいのか

CTO as Tech PM + PMO

ソフトウェアエンジニアリングを全部経験した人を採りましょう。
コーディングも最新のトレンドも
自分達の作ろうとしてるプロダクトのビジョンを理解してシステムデザイン/開発手法等の全体像に落とし込んだ上で
そのコードやトレンドが
その中のどのピースになるのか/ピースとしてどういう意味があるのか
考えて意思決定できる人がCTOになるべきだと思います。
あと個人的には
プロダクトライフサイクルの各フェイズも
経験している必要があると思います。
スタートアップだからといって新製品開発に特化した人だと
ライフサイクル後期に露見する問題を設計段階で予見するのは
難しいかもしれません。

またエンジニアリングチームをリードする際、
エンジニア経験のない人が「〜することに決めたから」
というと、たとえそれが正しい決断だとしても
エンジニア達からは
「え〜、あいつやったこともねぇくせに何言ってんだよ〜、
これだからトップがエンジニアじゃないってダメなんだよ〜」
と言いたくなりがちですが、
エンジニア経験のある人が同じことを言った場合は
「あ〜、まぁあの人が言うんだから
きっとこっちのチャレンジも織り込んだ上での決断だろう」
と思われやすくなります。
(…まぁもちろん人柄とかエンジニアとしてのスキルとか
色々他にも影響与える要素はありますが)

ちなみにエンジニアの中にも色々なタイプがあって
例えばコーディング等特定のタスクを専門でやってきた人、
大企業で既に確立しているプロダクトをやった等の
プロダクトライフサイクル後ろ側だけやってきた人、
その逆でローンチフェイズのスタートアップを渡り歩いて
プロダクトライフサイクルの前側だけやってきた人等々。
なので同じエンジニアでもしっかり見極める必要があります。
で、こういうこと言うと
「そんなの全部やってきた人なんていないよ〜」
と思われるかもしれません。
まぁ実際数は少ないと思いますが 笑
別にその全部について
スーパースターエンジニア並に出来る必要はなく、
その全部について、意思決定(上述の人がついてくるとこまで含めて)
が出来るだけの能力があればよいかと思います。

CTO as Communication Bridge

ビジネスサイドが分かる人を採りましょう。
ソフトウェアエンジニアリングの中で全部のタスクが大事ですが、
その中でも特に要件定義と設計は大事です。
要件定義/ロードマップ作成は
ビジネスとしての重要性とエンジニアリングの大変さ
のバランスをとりながら行われるべきで、
CEOがビジネスのことしか分からなくて
CTOがエンジニアリングのことしか分からないと
議論は平行線を辿ります 笑
またシステムデザイン等いろいろな意思決定のJustificationも
それぞれがビジネス的にどういう意味があるのか
きっちり伝えられる人じゃないと、
予算やその他のリソースの振分の議論ができません。
例えばQA(テスト)チームを作るタイミングの話をする時に
1)バグのもたらすユーザーとビジネスへの潜在的なインパクトと
2)QAチームを置くことによってどの位回避できるのかの試算と
3)QAチームを置くコストが分からないと
QAチームを置こうかどうか判断できないと思いますが
ビジネスバックグラウンドしかないCEOが分かるのは
せいぜい3)だけで
CTOが1)と2)の答えを出す必要があるのですが、
テックバックグラウンドしかない場合は
1)のビジネスへのインパクトまでは分からないかもしれません。

ちなみに
CEOがMBA仕込みのコミュニケーション能力で打破する
というのは相当非現実的だと思います。
まず現実にそういうことができている
ビジネスバックグラウンドオンリーのCEOを
未だかつて見たことがないのと 笑
どんなに相手からものを引き出すのがうまかったとしても
引き出すものがそもそもない場合は引き出せないからです。

ということで実際あんまりCTOに適した人って
そこらへんにゴロゴロいる感じではないと思います。笑
なので、もし見つけたらしっかり捕まえるのが大事なのと
あるいは足りない部分を意識的に育てる感じでやっていくのも
いいかもしれません。
スタートアップは時間が勝負のことが多いので
あまり悠長にはやってられないかもしれませんが。

モバイルバージョンを終了