7年間のCTO人生を振り返ってみる

13 min readJan 7, 2016

2015年8月、株式会社ビズリーチにおいてCTOから事業責任者へと職務が変わり、もうすぐ半年が経過しようとしているところですが、一度、7年弱に渡るCTO人生を振り返ってみようかと思います。

CTOとは何をする人ぞ

CTOとはChief Technology Officerの略。最高技術責任者とも言われます。AWSさんや、TechCrunchさんなどが主催する、CTOを集めるイベントに参加させて貰うと、たくさんのCTOの方とお話する機会もあり、時々、CTOの役割って何なんでしょうね？なんていう話になることがあります。お話を聞くと千差万別、まだ役割が完全に決まっていないくらい、歴史の浅い役割であるということと、結局はトップの一人なので、最終的にはその人ができる限界値が役割になっているのだと思うのですが、ひとつのケーススタディということで、僕がやってきたことを綴ってみようと思います。

サービスの立ち上げ時期（2008年〜2009年）

最初はとにかく「作る」。作るために必要なことは全部やる。もちろん、助けてくれる人がいれば、そこは任せてあと全部。そうやって残った仕事はなんだったかな？というのをつらつら書いてみると

ビジネスモデルの理解と、最低限の画面、機能の絞り込み
スタイルガイドの作成、HTMLパーツの作成
メール送信、暗号化モジュールなど共通ライブラリの作成
Jenkins、Subversion、Tracの構築
インフラ、アーキテクチャの設計、構築（園田さんが手伝ってくれた）
データベース、ER設計
各画面のコーディング、量産。
各画面のアクション実装
テスト（仲間からのDoS攻撃かと思うほどのバグ報告を受ける）
高速でバグ修正
現時点では不要だと思われるリッチな要求を撃退（課題を閉じる）
リリース作業

今だとGithubやCIサービス、TwitterのBootstrapなどもあって、色々はしょれると思いますが、この当時はOSSも含めて選べるほどは無かったので、そこのお手製が何より大変だった印象が残ってます。今は本当に便利で素晴らしい世の中だと思います。

何せ2ヶ月で総画面数150（求職者側、企業側、管理側と3アプリケーション必要だったため）にも上る開発作業で、かつOSSもIaaSもまだリッチじゃない状況だったので、基盤を作るのに1ヶ月、アプリケーションを作るのに1ヶ月、という時間配分でやっていました。この頃、僕自身はJavaとPHPが比較的得意な言語だったので、将来このサービスがエンタープライズ的な発展を見せる可能性があることと、日本における採用容易性（この時すでにPHPやRubyのエンジニアの平均給与額が高騰していた、Javaエンジニアの数は日本においてかなり多かった）を考えて、Javaを選びました。もう少し時間があれば、この時AWSや、Ruby on Railsを採用してみたかったな、というエンジニア的な「やってみたい欲」はありましたが、現実を見て判断し、結局、言語はJava、インフラはさくらインターネットさんの専用サーバを借りてスタートを切りました。

僕のようなスタートを切ったCTOにおいて、今振り返って大切だったなと思うスキルはこんな感じでしょうか

手足のように使える言語があり、インフラ含め、スマートじゃなくてもなんとか短期間で作り上げ、動かすことが出来る技術力
とりあえずスタートさせるために横道に逸れず、やりたいことの気持ちを抑えて我慢しながら突っ走る精神力
冬場でも気合いで風邪とかひかずにギリギリの睡眠時間で2ヶ月間作り続けられる体力
最低限、ビジネスを理解して、短期間で実装できる方法を何かしら考えられる頭脳と、技術を知らない人に伝えられるコミュニケーション力

心技体、そして経営者と対等のスピードで会話が成り立てばバッチリな気がします。他にもユーザー視点とか、センスとか、あれば良いものは色々ありそうですが、場合によっては他の人で代替が出来る可能性もあるので、最初のエンジニアとして必要なのは、このあたりの力だったのかな？と思います。

会社が100人くらいまで成長する過程（2010年〜2013年）

人が増えて行く時に絶対的に必要になるのがマネジメント力。人間というのは感情で動いてしまう生き物なので、人が増えると、とにかくヒューマンマネージが必要になってきます。開発チームが大きくなるとプロジェクトマネジメントも求められます。CTOが積極的に事業やP/Lに関与する場合はプロダクトマネジメントも要求されます。このタイミングは、最初に要求されたCTO像と全く異なるのがなんとも言えないところで、様々なベンチャー企業のお話を伺っていると、ここで大きな壁にぶつかっている方も多くいらっしゃるようです。実際、そりゃそうだと思うくらい求められるものが違うので、しょうがないですよね。

どんな天才エンジニアでも、一人でPDCAを回しながら開発出来る量には限界があります。結構腕のあるエンジニア10人を束ねて開発していったほうが、やはりサービスの改善スピードは上がります。

では、そうやって成長するまでの過程にどんな壁があったか、昔を思い出しながらつらつら書いてみたいと思います。

2人目のエンジニア、3人目のエンジニアを採用すると、場合によっては1人の方が早いので、めっちゃ忙しい立ち上げの時期に将来のために一度しゃがんで強いチームを作る方に考え方がシフトできるか。
そもそも採用しないといけない、しかも僕の場合は当時お金が無かったので外部の採用サービスを使えない。人脈を使い、良いエンジニアとめぐり合うための時間を投資できるかどうか。（ビズリーチの初期は、代表の南の人脈で3人目のエンジニアまでは出会うことが出来ました）
ソースコードレベルの美学を含めて開発をしていた人間にとって、どうしても美的に美しくないコードを書く仲間を受け入れるのがとても難しい心理があります（後で書き直しちゃったり。。。）。それも大きくなるためには仕方が無いんだ、と割り切り、サービスにとって致命傷になりそうなもの以外はそっとアドバイスする程度にするなど、今まで美学を持って作ってきた執着心を切り離すことができるか。
得体の知れないベンチャーに来てもらうため、対外的な発信力や、自社の魅力を語る力、最後の面接で口説き落とす力など、対外的に自分の存在や考え方を発信し、自分自身がコンテンツとなる覚悟。外に出ると色々言われるので、批判に耐えられる心構えも必要。
エンジニアが増えると、日々誰かがモチベーションが落ちているかもしれません。良いサービスをスピーディに改善するためには、やっている仕事の意義や、わくわく感を共有したり、プライベートで悩んでいても時間をとって話をして、モチベーションを高く保ってもらうことを、自分自身が開発することよりもプライオリティを上げられるか。

こんなところでしょうか。一番辛いところは、どうしてもコードを書き続けることが難しくなってきます。これはサービスの成長というよりも、組織が大きくなればなるほど難しくなるのだと思っていて、少人数でそれなりに大きなサービスをやっている場合、同じ問題にはぶつからないかもしれません。しかし、組織の成長を考えると、自分がやっていた楽しい仕事を誰かに受け渡し、あんまりやりたく無かったけど、やることで会社が成長できることを手にとっていかなければならないというのは、てっぺんにいる人間の使命でもあるので、自分自身がCTOではありましたが、気持ちは常に代表取締役社長のつもりで何をすべきか、は考えていたように思います。

もう一つの難しさは、今まで基本ロジックに従順なプログラミングという世界で生きていたので、ロジックよりも感情が先に立つ人間を扱うという仕事は思考回路的にも真反対を向きます。不慣れでもあります。僕は、マネジメントに関する勉強もしましたが、何より、哲学、宗教学、脳神経科学を勉強することで、人というものを知る努力をしました。対人が苦手なエンジニアは多いと思いますが、人間というものを一度勉強してみると面白いと思います。自己評価で恐縮ですが、僕はこの期間を通して、僕自身、より人間らしくなれたのではないかと思っています。

会社が300人くらいまで成長する過程（2013年〜2014年）

組織が200–300人くらいのフェーズを迎えると、取締役、部長、マネージャー、スタッフくらいの4階層以上に分かれて来ます。そうならなければ一人一人をケアすることはもう不可能なレベルに達します。こうなると、取締役CTOというポジションの人間は、スタッフからはかなり遠い存在になります。スタッフから見た時、マネージャーはよく接するでしょうし、ちょっと大きな問題があったら部長に話す機会はあるでしょう。しかし、その上ともなるとよっぽどのことが無い限り、仕事で業務を共にする機会が無いスタッフの方が圧倒的多数になります。

こうなると、何気なく言った一言、ちょっとした振る舞い、色々なもので人間性の全てを判断されていくことになります。そして、ひとつひとつの言動に対しての重みが増してしまうが故に、下手に現場を混乱させてしまう事件も発生します。

このフェーズで特に意識したことはこんなことでした。

できるだけ間違ったニュアンスで取られ無いように、わかりやすく、単純に、一言一言に気をつけて話すこと。相手の人数と、メッセージングにかけられる時間を考慮して、伝える情報の解像度を変える力。
組織が壊れないように、スタッフから聞いたことですぐに判断せず、その上司に確認の上、何かを実施するならばトップダウンでやるのではなく、マネージャー、部長に決断、実施して貰うように促す。（自分自身で勝手にやらない）
職位と給与構造などのルールの明文化。インターネット企業としては、人件費が大きなコストのひとつになりやすいため、高い給与を払うためにはそれ以上の利益を上げられる、もしくはそれ以上のコストを圧縮できる人でなくてはならない。エンジニアやデザイナー、ライターという職種で、全員の仕事が数値化しづらい業務における職位、給与構造を構築するのは本当に大変でした。外部コンサルに発注して出来るかどうか分かりませんが、エンジニア魂としては、総合職と同じような構造にすることで、優秀なエンジニアのモチベーションは地に堕ちるという感覚を持っていたので、ものすごく考え抜いて作りました。
エンジニア採用のため、自分自身がスポークスパーソン、採用のためのエバンジェリスト的なポジションを取る。
営業組織と開発組織がお互いをリスペクト出来るよう、力のバランスを取ることと、何をやっているのかをお互いが知れるようにすること、風通しの良いコミュニケーションが出来るような組織構造を作ること。何より、営業組織のトップと良く話し合い、強い信頼関係を作ること。
チームのメンバーを信頼し、任せる。そして失敗しても、チャンスを与え続けること。どうしようも無くなった時は、その頑張りを評価し、すべての責任を取り、助けること。
すべての社員において、自分が彼/彼女を救えるかもしれない唯一の存在であるならば、プライベートも含め、何よりも優先的に時間を取ること。
すべての社員において、自分が嫌われようとも伝えなければならない現実や、大きな過ちを納得して貰えるまで伝えること。
自分自身の見た目、振る舞い、言動がそれぞれの社員からどう解釈されるかを常に考え、100%の指示が集められなくとも、その時の最適解を見つけ、判断し、行動すること。（永遠の課題だと思います）

特に、組織の断絶が起こらないように気をつけたのは、今でも良かったなと思います。大きな組織になっていく中で、営業組織と開発組織は断絶しやすいというのは、色々な会社を見てきて思うところにあります。お互いが理解し辛いということだったり、大切にしているものが違ったり、そういうもので表面的に離れやすく、対立しやすい組織でもあると思いますが、深くお互いを知ることで、防げる部分も多くあると思います。ここは、今でも組織を任せた仲間に、大切にして欲しい部分でもあります。

会社がさらに大きくなる時期（2015年以降）

300人以上は心持ち的に大きく変わる部分はありませんが、僕自身の経験上今気をつけていることも含めて、異なる部分を少し書いてみたいと思います。

今まで作り上げた開発組織ごと任せるという決断。大切に作り上げてきた組織、仲間を誰かに全権限をもって任せるというのは大変でした。モノやサービスへの執着から離れるのはさほど時間がかかりませんでしたが、人への執着を切り離すのは壮絶な心の葛藤がありました。絶対に自分の方が彼ら、彼女たちを幸せに導ける。なんというか、そんな感情です。何度も京都のお寺に行って、自分の心と向き合って、沢山の時間をかけて執着を振り切りました。まさか、自分がこんなにも執着を持つなんて夢にも思ってなかったのですが、これを乗り越えられたのは、今、すごく大きな経験ができたと思っています。
自分自身の欲求、狂気との戦い。執着と戦えば戦うほど、自身の欲求もコントロール出来るようになります。どんどんLess is Moreな思考回路になってもきます。自分は今、どうしてこんなに頑張っているのだろう？ここに単純なお金のため、とか、何かが欲しいから、とかそういう欲求では頑張っている自分の背中を押すことができなくなってきます。10億円欲しいか？と聞かれて、欲しいと答えるのは簡単ですが、では、1,000億円欲しいか？その代わり1,000倍面倒な人生を送ることになるぞ。と言われると、10億でいいや、って思うと思います。大きな会社が何段階にも渡って事業を作っていく以上、より大きな事業、それこそ100億円、1,000億円、1兆円になるようなビジネスを考え、やって行かねばならなくなるのですが、個人としては、ふと、なんでここまでやってるんだっけ？と思う瞬間があります。そこでもう一段頑張るのって大変なんだな、というのは2015年の初めくらいに良く思いました。今では人生を楽しむための仕事。ここで大失敗したとしたら、人生に悔いがないくらいの大勝負をしたバカ野郎だったな、と一生言えるからいいか。と思っているくらい開き直れたのですが、それでも楽にやるのと、狂気を持ってやるのとでは大きな差があります。常に狂気を持ち、破壊と創造を繰り返し続ける覚悟を持ち続けることを、今は強く意識しています。

最後はもはやCTOとか関係無くなってますが、事業を任せる立場になっていくと、数字と状況を見て大きな判断をする方が役割としては大切になってきます。

今までも、ここから先も、自分の器以上には大きなコトは成し得ないし、大きな組織も率いることは出来ないと思っています。今の自分の限界が今の組織と事業であり、この限界を超えた時に、少し大きな組織と事業になっていると信じて、これからも自己研鑽をし続けて参ります。

CTOでは無くなりましたが、CTOの魂を持って、さらに前へ進んで参りたいと思いますので、今後ともよろしくお願い致します。