こんにちは！CTOのsuzukenです。
先週今週とお休みを頂いておりました。何を書くかなあと考えていたら当日に・・。せっかく休みなので、少しテンションを落として休みモードで書いてみます。まとまりのないゆるい文書ですが、よかったらお付き合いください。
この記事はCARTA TECH BLOGアドベントカレンダー、12/2の記事になります。
CARTA CTOの仕事、わかっているようでわかっていなかった
昨年1月からCARTA HOLDINGS（以下、CARTA）のCTOを務めています。2012年に新卒でVOYAGE GROUP（現CARTA）に入社し、ソフトウェアエンジニアとしてfluctの開発をしてきました。その後エンジニアリングマネージャーをやったり、チームを立ち上げたり、はたまたコードをコミットし続けたりと、プロダクトを作ることを通じて事業に携わってきました。
やってみると、CARTA CTOの仕事というのを知っていたようで、わかっていなかったということがこの2年弱でわかりました。
CARTAは事業が多くあり、独立して意思決定している
CTOとしての私のミッションはCARTAのエンジニア組織をより強くすること、そして経営におけるテクノロジー活用を推進することです。CARTAは連結子会社だけでも約20社あります。子会社の数だけ状態があります。例えば次のような状態があります。（ほんの一部です）
- 売上総利益と販管費のバランス
- 組織のコンディション
- 競合状況
- 採用の進捗、メンバーの育成度合い
- マネジメントの習熟度
- テクノロジーの活用度合い
- ....
「単にテクノロジー活用度合いをあげればOK」というわけでもなく、もっと緊急の課題がある事業も多いです。事業によって期待されるアウトカムの大きさも異なります。なので、優先度をつけて順に局地戦に持ち込んで改善していく・・というのが王道です。たとえば「この事業は将来も大きく利益を残すだろうけれど、機能追加のしづらい状態になっているから今のうちに改善しておこう」などです。実際のところ、こうした意思決定はすでに各事業の技術トップ（CTO、テックリード等）が判断して進めており、僕のところには「こういうのいま改善してるんすよね〜」（あるいは「もう倒したわ！」「倒し方わかったんで、あとはYARUDAKE」）という事後連絡が来ることが多いです。頼もしい・・。となると余計CARTA CTOの仕事とはなんぞや・・となりました。
そんなこともあり、僕個人やCTO室としてはいまはなるべく長期的なこと（イメージとしては2,3年先）を想像しながら「今のうちにこの技術に投資しておいたほうがいい」「この制度・仕組みをつくったほうがいい」等、将来に向けて探索する時間を長めに取っています。
キャリア初期の学びを振り返る
新卒でソフトウェアエンジニアとして入社したときは「よい機能をよりリリースし、顧客に届け、単位時間あたりに生み出す価値を最大化する」ことで事業が伸びていく場所に身を置いていました。これはキャリアを歩み始めるなかで、とてもよい環境でした。
PMF後のプロダクトが複数あり、リリースしたものがどのように使われていくのかを肌感として知ることができました。これは僕の「事業をエンジニアリングする」働き方の原点です。エンジニアとしてリリースしたものがどのような影響を及ぼしたのかを知り続けることは、事業を開発する感覚を鋭くさせてくれます。この環境のなかで、デリバリーや自動テストの重要性、MTTRの短縮がアジリティに与える影響の大きさ、複数人でスピーディーにコトを進めるためのチームのありようなど、多くのことを学びました。事業を開発するチームのなかで、多くの意思決定をし、失敗し、繰り返したことは、実装それ自体よりも多くの学びを与えてくれました。
では複数の事業・組織があるなかで、一体こうした経験をどう活かせばよいか。また、事業の成功確度を上げるため、経験の浅いメンバーにも事業開発の経験を加速して積んでもらうにはどうすればよいか・・というのがCARTA CTOをはじめた当時の問題意識でした。
複数の事業・マルチプロダクトにおいて、CTOがやっていること
「ハイアウトプットマネジメント」にある通り、マネージャーのアウトプットは以下により定義されます。*1
マネージャーのアウトプット＝自分の組織のアウトプット＋自分の影響力が及ぶ隣接諸組織のアウトプット
自身でfluctのCTOとして担当している事業に100%の時間を使っている場合には、「自分の組織のアウトプット」の比重が高い状態でした。CARTA CTOをはじめた当初は自分の直轄組織はほぼなく、間接的な影響を与える比率が非常に高い状態でした。
CARTAでは組織全体のアウトプットを高めるために、育成の仕組みとして以下の仕掛けがあります。以下に一部を抜粋しています。
- 全社としての育成・ミッショングレード制度
- 技術力評価会
- 読書会及び費用支援
- 社内勉強会
- 社外勉強会費用負担
- （新卒向け）エンジニア研修
去年の1月、「ではここから何を変える必要があるだろうか？」と考えていました。制度としては成熟していますし、課題は個別にはあるものの、改善しても大きなインパクトを与えるものではないように思えます。
ただぽっかりと抜けていたように感じていたのは「私達はどこに向かうのか」です。CARTAでは多くのエンジニアがそれぞれの事業にコミットしています。その分、共通したCARTAのエンジニア組織としてどうありたいのかが、言語化されていないように感じていました。暗黙的に私達が大事にしているものを、もっと言語化しよう。その結果作ったのがTech Visionでした。
Tech Visionを作ってから、採用・育成すべてにおいて価値観のすり合わせが進みました。CARTAのエンジニアが大事にしているクラフトマンシップはこれだよね、と同じ言葉で話せるようになりました。また僕自身も「共に信頼し、共に創る組織にもっとしていきたいんです」等、社内外にブレなく同じ言葉で伝えられるようになりました。
マネージャーの仕事は、現状を深く理解し、ありたい姿を言葉にし、そのための障壁をなくし、メンバーが思い切りアウトプットできるようにすることです。失敗してもいいから、どんどんリリースしよう。失敗にすぐ気付けるようにしよう。やってみないと成長しない。だからみんなでどんどん挑戦できるようにしよう。そういうチームを僕は増やしたい。こういう話をエンジニアだけじゃなくて、事業開発メンバーにも、経営陣にも、セールスメンバーにもオペレーションメンバーにも、同じことを話しています。失敗できるようにするのはモニタリングだけじゃない。実は真の制約ではないことを、組織内ルールで制約にしてしまったりする。そうじゃなくて、チームで真の制約に向き合えるのがまずはベースラインだよね、というような話を延々としています。
自分でも「同じことをいつも言ってるなー」と思いますし、おそらく聴いているメンバーもそう思ってるんじゃないかなあと思いますが、そうなってやっとちゃんと伝わったものだとも思います。
やったことがないなら、学べば良い
採用面接をしていると、たまに「CARTAでは特定のプログラミング言語に習熟していることを採用の要件にいれないのですか」と聞かれるのですが、敢えて入れていない場合が多いです。重視しているのは「新たな技術を学べるか」ということです。ソフトウェアエンジニアとして学ぶ力があるのなら、新しい言語、仕組みを理解し、使いこなすことができると考えています。例えばある言語に深く精通しているのであれば、他の言語も深く掘り下げやすくなります。
プログラミングだけではなく、マネジメントも同じです。CARTAにおいてマネジメントは1つの役割です。偉くもなんともありません。ピープルマネジメントを知らないなら、学ぶ。メカニズムデザインを知らないなら、学ぶ。それでよいと思っています。謙虚に、相手を信頼し、相手を尊敬できるなら、だれでもマネジメントの入り口に立てます。僕もマネジメントをやったことはありませんでした。けれど、あとからいくらでも学べます。何ならプログラミングよりもはるか前からマネジメントは存在していて、歴史があり、多くを学ぶ環境があります。
キャリアにおいて、今までと違うことをすると、知らないことばかりです。僕もそうでした。そのとき「前にうまくいったこと」をそのままやるのではなくて、ちゃんと学んでみる。自分の考えが「実は思い込みなんじゃないか」と疑ってみる。すると少しずつ「こうあるべき」だと思っていたものがほどけて、また新しい価値観を自分にインストールできる。そういうものなんじゃないかなあ、と思っています。
最大の敵は、自分自身の認知バイアス
組織マネジメントをしているときに僕が一番怖いのは、認知バイアスです。なぜなら新卒から同じ会社で働いていて、他の会社の当たり前を知らないからです。経営統合、オフィスを移転、M&A、上場、などなど多くの出来事がありましたが、あくまで同じ会社の歴史のなかで自分は働いています。だから話をきいて、想像して、考えて、読んで、書いて、聞いて・・・それでもやはり体験しないことはわからない。そうした人がマネジメントしているのは、怖いことだと思っています。だからずっとバイアスと戦っています。「このままでいいや」「これまでうまくいってるんだから大丈夫でしょう」「自分たちはうまくやってる」「コミットしてるからなんとかなるでしょう」ではなく、「なぜこの制度は必要なのか」「なぜこれが当たり前になっているのか」そういうことをずっと考えています。マネジメントの仕事は、そうした暗黙のルールやありようを疑い、取り払い、真の制約に向かえるようにすること。スピードも意思決定も筋力もまだまだ足りていないなあと反省ばかりしていますが、去年1月と比べれば学び、知り、変えていけているように思います。
ここまでやってきて、自分の認知バイアスを防いでくれたのは、事実を把握することと、それに気づかせてくれる同僚です。「それやばいんじゃないの」「こういうことが（事実として）起きているけど、大丈夫？」など、そういう気遣いで気づくことがたくさんあります。情報の透明性が高く、考えを発信していれば、そうやって教えてくれる仲間が増えていきます。もちろんその指摘が間違っていることもあります。でもお互いにそういうものです。人間だし、間違えます。だからお互いに気軽に教えられる。全部うまくいくことはない。そういうものじゃないかなと思っています。
来週月曜日から虎ノ門ヒルズへ移転し心機一転、渋谷から離れることでまた取り払えるバイアスもあるように思います。もっと事業を伸ばすのは、やはり学んで、やってみるしかありません。そもそもなぜこの事業をやるのか、将来わたしたちは何を変えていくべきなのか。徹底的に話して、決めて、すぐやる。組織としてもやりきった数が成長につながると信じています。やってみて、また皆で学んでいきましょう。価値を届け続けよう。
まとめ
振り返って書いていたら長くなってしまいました。キャリアとか書きながら全然まとまってないですね・・。僕も考えながらやってます。CTOだって悩みます。ぜひ一緒に考えて、楽しんで、事業をつくっていきましょう。まだまだ未来像に到達するためにやれることは多くあります。来年以降も創造的な仕事ができる環境をもっともっとつくっていきます。
*1:アウトカムの話は今日は置いておいて、一旦アウトプットの話をします。
