スタートアップCEOがやってしまいがちな失敗するCTOの付き合い方

社内でCTOを雇いたいんだけど、どんな人が良いかな・・？

CTOがいたんだけど、最近辞めたいと言い出して、、何が原因かわからない・・

最近、CTOの動きが悪い気がしてて、給与に見合ってないと思うんだけど、、

という、スタートアップから少しして社内にCTOを抱えるようになった時によく生まれる

スタートアップCEOxCTO、付き合いの悩みについて本日は書いていこうと思います。

スタートアップCEOが出会いがちなCTOとのトラブル3選

1つ目：CTOを雇ったけど、期待するアウトプットが出てこない。

この悩みを聞く場合には、大概2つの種類の不満のどちらかな事が多いです。

1種類目→ゴリゴリコードを書いてほしかったけど、なぜか外注をゴリゴリ使っていて開発コストが爆上がりするパターン

2種類目→ビジネス的な相談をする役員目線での話がしたかったのに、「技術」担当なんでとビジネスモデル側の話に踏み込んでくれない。

どうでしょうか・・・？

CTOを高給で雇ったのに、期待値とズレる、という問題をお抱えの方はおそらく「入社前の期待値調整」がしっかりと成されていないままCTOとして迎えてしまうことが多い傾向にあります。

特に立ち上がりばかりのスタートアップがCTOを招く場合には、給料よりもビジョンに共感してくれる人を選びがち、責任範囲をきっかりわけるよりも二人三脚で一緒に頑張ろう、という感覚で、期待値を言語化しないまま迎え入れてしまうことが多いのではないでしょうか。

親しき中にも礼儀あり、ということで、どのようなコミュニケーションを求めているか、どのようなアウトプットを期待しているのか
迎え入れる前に、幾つかの案件を一緒にやるなどして、実務上のアウトプットや責任範囲について入念にすり合わせてから採用したほうが良いかと思います。

急いては事を仕損じる、といいますが、特に重要な役職でのミスマッチは非常にインパクトが大きいので慎重すぎるくらいがちょうどよいかと思います。

2つ目：CTOと一緒に仕事をして、暫く経つけど最近、動きが悪いように感じる。

これは、大概の場合、組織の成長に伴うCEOが求めるCTOの役割の変化にCTOが気づいていないパターンです。

ざっくりわけるとCTOの役割というのは、各フェーズによって以下のように変化していきます。

■超スタートアップ初期（社員10名以下）
寝食忘れてゴリゴリコードを書いてほしい、プロダクト開発命
=>いわゆるスーパープログラマーとしての働き

↓

■スタートアップ中期（社員50名前後）
採用や組織作りに注力しはじめて、組織としての開発チームの構成
＝＞いわゆる組織マネージャーとしての働き

↓

■スタートアップ後期（社員100名以上）
多数のチームを束ねて、開発工数の費用対効果を説明しつつ半年、1年先の開発ビジョンを示す
＝＞いわゆるアカウントタント&アーキテクターとしての働き

一人だった開発チームも、10人、30人と増えていく中でCTOに求められる役割も変わってきます。

しかし、初期から参画していればしているほど、自分に求められている役割が変わってきていることに気づきづらいのも確かです。
これをCEO側が認知し、きちんとすり合わせていかないと、「最近、違うこと求めれるなぁ」とか「CTOの動き最近悪いなぁ」というすれ違いが発生し、最終的には退任する、なんてことにもなりかねません。

3つ目：CTOから退職したいと言われた。

スタートアップで一番起きてはいけない問題がこちら。CTOからの退職打診。

自社で握っていたはずのシステム周りのノウハウや知見が全て消し飛ぶので、かなりのインパクトがあります。。

どんな理由を持って、退職するのは本人のみぞ知る、というところなので退職理由に関する分析は致しませんが

基本的に退職を翻意にすることは難しいので、なるべく傷跡が少なくなるように、在職期間中に他のエンジニアへと引き継ぎをするなどして

ノウハウが途絶えないようにしましょう。

特に、日頃触っているプロダクトなら現場で触っているエンジニアが把握していることが多いので大丈夫なことが多いのですが

毎月1回実施する処理や画面上からは現れてこない処理など目に見えない処理が時限爆弾のように隠れている可能性があるので

その点に関しては、念入りにCTOに確認しておくと良いでしょう。

CTOとはいえ、相手も人間であり、しかも、社内でも役職の高いレベルからシステムを握る人材です。

最初のエンジニアなので信頼が何よりも大事なのはわかります。

失敗したくないからこそ知り合いのエンジニアにしたいのもわかります。

でもだからこそ、自分が相手に何を期待しているのか、をしっかりとすり合わせる必要が

お互いのためになによりも大事なのではないかと思います。

では、ここから私が考える良いCTOとの付き合い方について述べていきます。

エンジニア社長が考える、CTOのうまい付き合い方

1つ目：いきなりCTOでオファーしない。

私も経験があるのですが、いきなりCTOのポジションでオファーしないほうが良いと思います。

というのも、社内に他のエンジニアが在籍していたりする中で、外部からCTOとして入っていくと

少なからず、、ハレーションが起きます。。もっというと、ギクシャク感が出ます・・苦笑

仮にエンジニアがおらず、初のエンジニアだっとしても、まずはマネージャー職などからキャリアをスタートしてもらうと良いのではないかと思います。

入社してCTOになるとキャリアとしては既に上限に達しているので、キャリアアップへのモチベーションが湧きようもなく

最初はビジョン共感で働いてたとしても、徐々に給与への関心が少なからず移ってきます。

また上述したとおり、組織のフェーズによって求められるCTOの役割というのは違ってきます。

そのエンジニアの素質と期待値がズレているままCTOに就任させてしまってはお互いに不幸になります。

まずはマネージャー職で色々と仕事をしてもらい、適性を見極めた上でCTOを打診するほうが良いのではないかと思います。

2つ目：ワークサンプルを実施して、仕事のミスマッチを減らそう。

Googleの入社試験でも実施している「ワークサンプル」

これは、

期待する職務に似た業務サンプルを渡し、実際にその出来栄えを評価する

というものです。

つまり、CTOとしてどのような仕事をしてほしいのか、どのような課題を問いてほしいのかを
幾つか伝えた上で、期待に沿うアウトプットなのかどうかを招聘前に確認するのです。

Googleの入社試験においても、このワークサンプル試験が占める割合は非常に高く、人材のマッチングの上では非常に有用なやり方なのだと思います。

ちなみに私の会社では入社後に試験があり、そこで現状のスキルや仕事の癖を把握してプロジェクトへとアサインしています。

入社後試験を導入してからは、明らかにプロジェクト進捗率の改善、バグの発生が目に見える形で現れていると感じます。

3つ目：他社のCTOと比べない。一度雇ったなら自社のCEOを全面的に信用する。

非IT系のスタートアップCEOがついついやってしまいがちなやつです。

ふとCEOのアタマによぎることがあります

「うちのCTOって他社と比べてどれくらい優秀なのだろうか」

しかし、これは悪魔の囁きです。

他社比較はCEOなら誰でも思うことじゃないか、と思うかもしれません。

でも、

結婚しているにも関わらず、お隣に住む夫婦の奥さんと比べている旦那がいたらどう思いますか？

おそらくヒトデナシと思うと思います。

たとえとしては大げさかもしれませんが、つまりそういうことなのです。

システム開発というのは、色々な制約条件の中で、最適解を求めていくお仕事です。

リスクの折り合いの付け方や考え方は人それぞれで正解なんて正直ありません。

なので、とあるCTOが100万で作れるといったものが、他のCTOでは300万は必要だ、ということも日常的にあるのです。

日数や金額だけで比較し、CTOの良し悪しを決めるのは正直いって、CTOが可哀そうです。

一度、CTOとして招聘したのなら、自社のCTOが自社にとってはNo1の理解者である、という気持ちを
持って言ってほしいなと思います。

疑われる中でエンジニアリングをすることほど辛いものはありません。

まとめ

とにかくCTOを入れとけば、社内開発も安泰安泰！と思っているようでしたら大間違い。

CEOとして、一人ひとりとしっかりと向き合い、組織作りをしていく必要がありますよ！

皆さんのプロダクト開発のお役に立てば幸いです。

それではまた次回の記事でお会いしましょう。