CTOに求められる能力と限界 ～定義や役割、事業フェーズに合わせてコミットする秘訣とは～
※本記事は、2019年1月に公開された内容です。
2018年12月14日に開催されたCTO meetupのテーマは、「CTOに求められる能力と限界」。
第一線で活躍する敏腕CTOが集い、そもそもCTOとはどういった役職なのか？という根本的な定義から徹底議論を行いました。
企業規模やフェーズによって変化していくCTOの役割、求められる能力、立ち回り方など、現在CTOとして問題解決に取り組んでいる方、CTOの導入を検討している経営層、将来CTOとして活躍したいエンジニアを対象に大変興味深いディスカッションの様子をレポートします。
（掲載されている所属・役職は開催当時のものです）
【ご登壇者】
- 岸田 崇志 氏
株式会社LITALICO /執行役員CTO - 袖山 剛 氏
BizteX株式会社 /取締役CTO - 中筋 丈人 氏
株式会社FABRIC TOKYO /執行役員CTO
【モデレーター】
- 藤倉 成太 氏
Sansan株式会社 /執行役員CTO
登壇者のご紹介
分野、フェーズ、規模、経歴の異なるCTOが集結
【写真：左】Sansan株式会社 /執行役員CTO 藤倉 成太 氏
【写真：左】BizteX株式会社 /取締役CTO 袖山 剛 氏
藤倉：
Sansan株式会社でCTOを務めております、藤倉と申します。大学卒業後に新卒でSIerであるオージス総研に入社し、4年目にアメリカの子会社へ出向。20代後半はアメリカで働いていました。帰国後は自分のサービスと呼べるものを作りたいと思い、Sansanに転職。エンジニアとしてインフラからアプリケーション開発までさまざま手がけ、そこから開発組織のマネジメントにも幅を広げ、現在CTOとなった形です。
本日は「CTOに求められる能力と限界」というテーマですが、果たして能力と限界が本当にあるのか、CTOの実態を詳らかにしていく場にしていければと思います。みなさん、本日はどうぞよろしくお願いいたします。
岸田：
株式会社LITALICOでCTOを務めております、岸田と申します。LITALICOは福祉事業を手がける企業で、あまりテクノロジーの活用が進んでいない領域で、インターネット事業を立ち上げるという部分に面白さを感じて参入し、ゼロベースから組織づくりに携わって現在3年目です。転職する以前はグリー株式会社でエンジニア30名の時点で入社し、最終的には会社規模2000名ほどの組織で内製エンジニア部門を統括する立場も経験しています。社外CTOとして技術アドバイザーも務めておりますので、その観点からお話ができればと思います。どうぞよろしくお願いします。
袖山：
僕はBizteX株式会社を現在のCEOと一緒に立ち上げ、現在で2年弱になります。それまではSlerとしてグループウェアパッケージの開発をするアリエル・ネットワークで10年ほど働き、最終的にはゼネラルマネージャーとしてマネジメントを中心とした業務を行っていました。退職後は起業を考えていたところ、現在のCEOと出会い「CTOをやらないか」と誘われ、会社を創業しました。当社ではエンジニアでなくとも簡単にパソコン業務を自動化する仕組みを作れる、というコンセプトでクラウドRPAを開発しています。創業したばかりのCTOならではの課題などをお話しできるかと思いますので、どうぞよろしくお願いいたします。
中筋：
株式会社FABRIC TOKYOの中筋と申します。いわゆるファッションテック系のサービスを展開しており、CTOを務めて現在3年弱です。経歴としては高校卒業後に陸上自衛隊に入隊し、その後Slerとしてアマゾンで働いた経験もあります。どうぞよろしくお願いします。
藤倉：
CTOの役割はフェーズや事業規模に左右される、という前提があるので、今回は会社の設立時期や組織体系、フェーズが異なる方にお越しいただいています。
袖山さんの組織はエンジニアが10名未満、中筋さんは十数名程度。岸田さんは会社としての歴史は十数年ほどありますが、エンジニア組織自体は立ち上げから3～4年で、50名規模。僕の場合は会社としては12年目で、ものづくりのメンバーは180名ほどです。今回は、そんなみなさんのフェーズや立ち位置の違いを理解しながら聞いていただくのが良いかと思います。
フェーズごとに求められるCTOの能力と限界
CTOとは、変化していく役割を柔軟にこなしながら成果を出す存在
藤倉：
ではまず、各パネラーのみなさんがCTOという役割をどう定義づけているのか、という質問からスタートしたいと思います。袖山さん、いかがでしょうか。
袖山：
特に創業CTOは、「事業に対して成果を出すことができる、テクノロジースタイルの経営者」と定義づけています。開発やマネジメントスキルは必要ですが、そもそも事業が成立して、成長する可能性を提示できるということが大前提です。
中筋：
フェーズや状況に応じて自分の役割をスイッチさせながら、事業にバリューを出せるかどうかという観点で定義しています。例えば私がFABRIC TOKYOにジョインした最初期、メンバーはフロントエンドエンジニア1名、デザイナー1名、業務委託のエンジニアが2名でした。最初の業務内容は、サービスの利用規約の改訂です。読んだときにめちゃくちゃな内容だったので、私が直したんです。「これはCTOの仕事なのか？」と思いつつもこなしました。ほかには一時期マーケティング部門にも携わってKPIの作成なども行いました。本当にいろいろなことを求められます。ですから、いかに自分の能力や役割を組織にアジャストさせて貢献できるのか、という部分が大事ですね。
岸田：
やはり「役割を果たせるかどうか」が第一になると思っています。CTOはコーディングスキルの高い人という一般的なイメージがあるかもしれませんが、実際的にコーディングはCTOの役割の一つでしかありません。特に急成長している会社であれば役割もどんどん変化していくので、コーディングやシステムのアーキテクト以外にも組織や事業全体を見たときのバランスやメンバーの育成、開発のプロセスなど、さまざまな要素を組み合わせながら”組織全体のアーキテクト”として臨機応変に変化を出せるというのが、CTOとして望むべき姿ではないでしょうか。
技術に対する責任を持つための技術選択における意思決定の範囲
藤倉：
「テクノロジーを使って事業の成果を出す」という部分についてはみなさん同意見ですね。では話を変えて、例えば僕は日々コードを書いていませんし、書くべきではないと思っていますが、みなさんはいかがでしょうか？
袖山：
僕は現在1割書くかどうかというくらいです。だいぶ減りました。
中筋：
私も割合で言えば減りました。どちらかというと、新しい技術を取り入れるときに一ヶ月ほど無理やり時間を作って参考実装を書き、「こうしたらいいぞ」と共有したりします。
岸田：
組織がまだ小さいときは事業の深度が高い部分もカバーする必要があるためコードを書いていました。現在は周辺技術をきちんと把握しておかないと、意思決定でミスが発生する可能性もあるためコードに触れて、情報をキャッチアップするための時間を意図的に作っています。些細な意思決定のミスは数ヶ月、数年単位の事業の遅れにもつながりますので。
藤倉：
技術に対する責任を自分が持つ場合に自らコードを書くということですね。では、技術に対する意思決定はどのくらいされていますか？
岸田：
新たな技術にチャレンジするときは、守るべき部分と攻めるべき部分を分けて、組織のプロダクトマネージャーに選択してもらいます。熟考して選択するということはオーナーシップを持ってもらう上でとても重要だと考えています。仮に失敗したとしても、そこはCTOとして自分が尻拭いする。そういう役割だと思っています。その積み上げが、今後大きなサービスを作る際、プロダクトマネージャーが重要な意思決定するための良い経験になると思っています。
袖山：
当社は創業時に優秀なエンジニアを招いたので、基本的には僕が全部決めるというよりは、エンジニアも含めて協議するようにしています。
中筋：
私は2018年の10月からチームを4つに分けたのですが、そこからはエンジニアに任せるようにしました。ただ、自分の経験則として絶対失敗することが目に見えているときは口を出すことがあります。とはいえ、一度失敗させるのも重要ですから、「自分が尻拭いできる範囲内で意思決定してもらう」というのは、非常に同意できますね。
【写真：左】株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏
【写真：右】株式会社LITALICO /執行役員CTO 岸田 崇志 氏
技術的負債の返済タイミングをどうすべきか？初期段階から求められる計画性
藤倉：
最初にあった「技術で事業に成果を出す」という話に関連して、経営目線の技術選択とは一体何だ、という疑問が出てくるかと思いますが、みなさんのポリシーがあればお伺いしたいと思います。
袖山：
経営視点で言うと、プロダクトの最初期に起こる技術的負債の視点が一つあります。技術的負債は、プロダクトの成功がある程度見えてきた段階で初めて「返済をする」というフェーズに差し掛かります。プロダクトが失敗すればただのゴミになるだけですからね。これを踏まえて初期段階においては、後々返済せずに済む、あるいはある程度開発速度が維持できる範囲の負債でおさめる、ということを主眼に開発者と協議すべきです。プロダクトは世に出てお客さんに使われないと全く意味がありませんから、プロダクトが失敗しないという前提で後々の技術的負債の問題をかなり意識します。
岸田：
僕が経営視点で心がけているのは、3ヶ月後、6ヶ月後、1年後のサービスのあるべき姿を道筋立てて考えておくことです。どんな方向に進んだらいいのかをあらかじめイメージしておきます。特にスタートアップは流動的ですので、変化があるときにどう対応するかをイメージしておくことが大事だと思っています。成功確度を上げるために、組織内で「問い」が発生したときに、それに答えられることを常に意識しています。
中筋：
私の場合は「いかにお金をかけずに開発するか」という視点を大事にしています。ベンチャーキャピタルから出資を受けている場合、シリーズBになると数字に対するコミットメントが強く求められますから、事業計画に対してどうやってKPIを達成するのかが重要になります。限られたリソースと資金でいかに数字を達成するかが大事なんです。不要なものは開発しない、作る場合もなるべくMVP（実用最小限の製品）的につくることを重視しています。
岸田：
時間とお金に制約がある中で開発するのは良いサービスを生み出すポイントの１つだと思いますね。制約があるからこそ工夫しますし、自分自身も限られた期間で開発するためのスキルアップをしたいというモチベーションにつながります。スタートアップ時は特に、UI一つにしても無駄な遷移を減らすといった工夫が面白いですし、それが醍醐味だと思っています。
藤倉：
袖山さんがおっしゃったように初期段階のステージであるほど技術的負債も返せる範囲を考えなければいけませんし、どんなふうに返済計画を立てるのかが求められますね。技術的負債というとネガティブなので、「技術的借り入れ」と言うくらいがいいかもしれません。
中筋：
それでいくと、うちのプロダクトはECがCakePHPだったのですが、一昨年前、別のフレームワークに変更するという判断を意図的にしなかったんです。それよりも事業進捗を出すことを優先しました。その後、2018年の10月になってLaravelにリプレイスするプロジェクトが始まったのですが、これもある意味返済計画だと思っています。適切な時期に返済するのが非常に大事ですね。
リファクタに関しても、エンジニアは「リファクタしたい」と言うんですが、私は「お金で解決できるから後にしよう」と言います。お金をかけて人を集めればリファクタはできますから。肝心なのはそれをいつやるのか、という部分です。
岸田：
技術的負債を返済する中でインフラやデータベースの知識が身につきますし、学べる部分もありますよね。成功するサービスを見ていると、コードの綺麗さだけでなく、プロダクトとしてもアウトプットできているかが重要で、全体のバランスが整っていないと事業として成功しないんだなということもわかります。走りながら組織で柔軟に対応していくというか。
袖山：
リファクタしやすいコードかどうかもあります。例えばデータベースのテーブルの設定なんかは渋いので、そのあたりのハンドリングが必要だと思うのですが…。
中筋：
その点に関しては「リファクタリング自体を目的にするな」と言われることがありますね。リファクタリングによって生産性が上がる、バグが少なくなる、という話があったとしてもそれ自体を目的にしないのは大事だと思います。
藤倉：
ここまで、みなさんは経営に携わる立場のCTOとしてお話をされていますが、会場に来ている方たちに認識いただきたいのは、技術力をないがしろにしてはいけないということです。むしろ技術力を持つことは大前提です。正しい返済計画も技術力があればこそ立てられます。逆に技術力がないと返済期間が延びたり、不要な借り入れをしなければならないことになります。
ただ、人によって得意不得意がありますし、超人的なエンジニアばかりを集めるわけにもいかない。そこをどうバランスを取りながらやっていくべきか、という話ですね。
岸田：
もう一つ経営視点に関して言えば、CTOが目的思考がないと、手段が目的と化して途中で「今なにをしているんだっけ」ということになることが多いです。何に向かって走っているのか、視座を考えて振り返ることができる人は強い気がします。
袖山：
そういう意味ではビジネスサイドへの橋渡しが非常に重要だと思っています。今開発しているものがビジネスとしてどういう成果を上げるのか、具体的にどれくらいの売上があるといいのか、現場の肌感をどう伝えるのか。
僕が今の会社に入社した頃の問題は、社内の受発注関係でした。エンジニアが依頼してくる相手に対して「あいつらが…」と言い出す。そこで、いわゆるプロダクトに関わる部分はすべてエンジニアがやる、という形に働き方を変えました。スケッチを含めたプロトタイピングはもちろん、フロントエンドからKPI設計に至るまでエンジニアが行います。そうでないと、自分たちが事業にコミットしていると感じられない。自分たちが会社の中のどういう数字にコミットできているのかを橋渡ししてあげるのが大切だと思います。
【ご登壇者】BizteX株式会社 /取締役CTO 袖山 剛 氏
事業規模に適したエンジニア組織を作り出すため、CTOが考え出すべき戦略とは
藤倉：
ではここから事業規模とエンジニア規模をどう理解してマネジメントしているか、という話に移りたいと思います。利益から予算を決めて採用するという方法はありますが、ベンチャーは将来の収入がわかりませんから、エンジニアを採用できないという話になってしまう。そういった部分で、みなさんの採用戦略やポリシーがあればお聞きしたいと思います。
岸田：
大量採用した際の失敗事例があります。1つのラインに対して急激に5人だったのが10人、20人になったとき、いわゆる団子サッカーのような状態になってしまって、役割が不明瞭になり誰がボールを蹴って得点を決めたらいいのかわからない状況に陥ってしまった。そこで、まずは１つのプロダクトの中でも３人チームをいくつも作り、短期、中期、長期と分類しました。短期の人は直近の一週間や一ヶ月単位の開発。中期の人は数ヶ月かけて、ユーザーがサービスに飽きたときの施策を入れる。長期は半年から1年にかけて新しいアーキテクチャや新プロジェクトをつくるという形にしました。現在はそのあたりのバランスを含めて採用をしています。スケールする段階において、チームメンバーが速度を維持したまま走れるような体制をつくることはとても重要だと痛感しました。
袖山：
当社はシリーズAに到達した後くらいのフェーズで、プロダクトマーケットフィットを追っている段階です。ですから、まず全社的なOKR、いわゆる目標設計を行い、その中でエンジニア組織のキーになる数字は何か？ということを定め、実際にエンジニアにその数字を追ってもらう、という仕組みで動かしています。
よくエンジニア側から「このKPIにはどういう事業的意味があるんですか」と聞かれますが、きちんと「プロダクトマーケットフィットを達成するためのオブジェクティブがあり、それを分解していくとこういう数字になり…」と説明できるように設計しています。
中筋：
まさしく今日、CFOと予算を含めた3～4年後の話を詰めていました。当社はベンチャーではありますが、商品の企画、生産、店舗の運営、EC、チャネル開発など規模が壮大です。工場を買収してスマートファクトリー化しよう、という話も出ました。
そんな中で大事にしているのは、あるべき姿からの逆算です。そこに対して私がロードマップを引き、予算を組み、開発チームを作る。現在の課題は、それらをすべて私がこなしているため、私自身がボトルネックになっているということですね。
藤倉：
開発はいわば果実を収穫する前の栽培のフェーズなので、そこにどのくらいの予算やリソースをかけていいのか、方程式はありません。ただ、ここまでは数字や予算に重きをおいた話になっていますが、エンジニアはお金ではない、という点は重要です。お金とは違い、「色」を持つ人間ですから、採用したエンジニアには成果を出してもらえるように向き合い続けなければなりませんし、そういった視点で開発組織を見ていかなければいけませんね。
【モデレーター】Sansan株式会社 /執行役員CTO 藤倉 成太 氏
「本人のキャリアと会社としての成果の両面をすり合わせる」評価制度の意義と課題
藤倉：
さて、エンジニアを採用したら当然評価しなければなりませんが、その部分で気にされていることはありますか？
中筋：
当社の場合はOKR制度と、会社として3つのバリューがあり、その行動指針に即した行動ができているかどうか、をベースにしています。OKRが6割、行動指針が4割ですね。
気をつけなければいけないのは、数値的な結果は出ていなくても、他者から見てがんばっていると思える人をどう評価するか。結果ベースなら本来評価されない部分をどうケアしていくのか、現在模索中です。
袖山：
評価制度を入れたのはいつ頃ですか？
中筋：
2年くらい前ですね。OKRを入れたのは去年です。OKRは最初の2、3回はうまくいかないという話がありますが、OKRがMBOになってしまうといった事態もあり、まさしくそのとおりでした。
袖山：
うちはまさにこれから導入しようとしているところです。行動指針のようなビジョン評価は非常にあいまいで難しいと思うのですが、どういう基準で評価されているのでしょうか？
中筋：
例えば行動指針の一つに“Always Why, Always Run”というものがあります。「常に考え行動せよ」という指針ですが、おっしゃる通り評価はかなり定性的になります。クォーターの頭にエンジニア本人に行動指針に対して具体的にどんな行動を取っていくのかを定義してもらい、クォーターの終わりにマネージャーとパフォーマンスレビューするのが現在のやり方ですが、正直まだ穴は多いです。Amazonでも採り入れていた360度評価を加えられるといいと思うのですが、現状はそこまでできていないですね。
岸田：
事業や組織の成長に伴い1年ごとに評価制度のやり方は変えてきていますが、やはり組織がある程度大きくなっていくほど必要度は増しますね。うちがやっているのは、本人が半年後にどのようにになっていたいか、という部分のヒアリングです。個人の方向と会社のビジョンが一致すればするほど大きなパワーがでますから。極力自己実現したい内容に即したタスクを割り振り、本人にも「これを達成する」と宣言してもらう。会社としてもその人のキャリアを評価したいし、個人として成功してほしいという気持ちが大きいんです。
その上で、半年後に会社に対してコミットしてもらえたら非常に良いですよね。そのすり合わせに時間を使っています。本人の成長軸による自己実現と、会社としての方向が極力一致するようにする。評価される側が、この会社に1年いてこれだけスキルがついた、と感じられるととても素敵ですよね。同じ仲間と働く中で成長できることがスタートアップの醍醐味だと自分は思っているのでそのような環境を目指しています。プロダクト開発は人が資本なので、それが会社にとって翌年、翌々年のバリューへとつながっていくためです。
袖山：
1on1は定期的にやっていると思いますが、その中で評価のフィードバックもするのでしょうか？
岸田：
どちらかというとキャリア相談に近い形で1on1をしています。本人がゴールまでの階段を緻密に作れない、段数がわからないとすれば、そのステップを細分化するためのプロセスとして1on1を設けています。
藤倉：
エンジニアの評価は成長促進と結果評価、2つの視点があると思いますが、1on1は成長促進の意味合いが強いのかもしれないですね。ただ、成長したからといって必ず結果が出るわけではないですし、成長しなくても成果が出る場合もあります。成果の評価に関しては本人の納得感も重要です。本人の評価と他者の評価がずれてしまったときは、方向性を調整する必要がありますね。
質疑応答①
スクラム原理主義はプロダクトの開発を阻害する危険性を孕んでいる
質問者：開発プロセスとして、スクラムやアジャイルなどのフレームワークは活用していますか？
袖山：
最初はスクラムをやろうとしましたが、メンバーが会社に来ないことが多いのでスクラムもどきですね。
中筋：
システムがいくつかあり、ECはスクラムで、生産管理を行うシステムはウォーターフォール的です。適材適所ですね。
岸田：
うちは過去にもいろいろやりましたが、スクラムでやると原理主義的になってしまうケースが多かったように思います。先程の目的と手段の話かと思いますが、チームのレベル感、事業のステージに合わせて導入の深度はコントロールしています。
藤倉：
スクラムはもともとプロダクトをいかにクイックに小さい段階の繰り返しで開発を進めるかという話だったはずが、原理原則に縛られて「ウィークリーの振り返りには丸１日使うべきだ」となると、手段と目的がめちゃくちゃになってしまう。そこは気をつけるべきですね。
中筋：
スクラムはプロダクトマネージャー、エンジニア、デザイナーという構成で綺麗にチームを作れないとワークしなくなってしまいます。そのあたりのハイアリングもうまくいっていないといびつな形のチームになり、スクラムそのものがフィットしない。現実を踏まえてアジャストする必要がありますね。
藤倉：
スクラム的な役割分担でいうところのPO（プロダクトオーナー）をプロダクトマネージャーが担うケースがあると思いますが、我々の世界は小規模のプロダクトを並べていって何か当たればいいというものではなく、「このプロダクト１本で世界を取る」という、勝つか負けるかの勝負をしています。その中でプロダクトの意思決定をスクラムチームの中でしろ、というのはナンセンスです。そういう意味でもスクラム原理主義は難しいですね。
中筋：
改善をぐるぐるまわすフェーズで導入する分にはいいと思います。別のフェーズで大きな開発をする段階になったら別の手法にすればいいんじゃないでしょうか。
【写真：左】株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏
【写真：右】株式会社LITALICO /執行役員CTO 岸田 崇志 氏
ビジネスサイドと密接に絡んだCTOという立場の動き
質問者：CEOやCOOは技術サイドにどの程度関与していますか？また、CTOはビジネスサイドの施策にどの程度関与していますか？
袖山：
CEOは技術サイドにほとんど関与していません。何をしているのかは常にCEOに共有しています。逆にCTOとしてはビジネスサイドの企画に対してそれなりに口を出していて、CEOに対して「それが本当にビジネスとしてうまくいくのかどうか」という観点で言いたいことは言っていますね。言い合える仲であることが大切なのではと思います。
岸田：
プロダクトはチーム全体として成功するかという部分が大きいので、その中で自分たちが貢献できる部分を明確に定義した上でグロースを目指しますし、月次レポートや、技術的負債、もとい借り入れの返済に関する展望も含めてロードマップとして共有しています。事実を伝えるというだけではなく、それが実現したらどのような素晴らしいことが待っているかなど、ビジョンも含めて伝えるようワーディングを気をつけています。ですからビジネスサイド的な動きは普通にやっているのではと思いますね。
中筋：
先程説明したように、数年単位での理想像があった上で私がロードマップを引いているという意味では、関与というよりは協働しているという感じですね。ビジネスサイドにもかなり関与していて、よくない施策やよくわからない設定のKPIは積極的に潰します。
企業の成長フェーズにおいては、緩やかに役割をシフトしていきたい
質問者：企業が大きく成長するフェーズにおいて、自分でコードを書く段階からきっぱりと役割をモードチェンジしたのか、緩やかにシフトしていったのか、過渡期の話をお聞かせください。
袖山：
エンジニアが2名しかいなかった最初の１年はとにかくコードを書いていましたが、徐々に変化していきました。最初のきっかけは採用です。技術ブランディングをしようか、エージェントを使って採用をしようかとトライしても、中途半端では全く採用できないんです。本気で売り込みをしないと無理だと判断して徐々にコーディングの割合を減らし、最終的にリソースの７割を採用に使いました。
岸田：
僕は両方経験があります。一気に切り替えると文書化できないものを引き継げず失うものが多かったので、今は業務のメインとサブ担当をつけることで、計画的に切り替えるようにしています。コードを書いていても自分がボトルネックになってしまい事業リスクが大きくなったり、コーディングにかけられる時間が1日2時間という中で実装するとコードの全体像が徐々に把握できなくなるため、スピード感を出す上でデメリットの方が大きいと判断し、任せたケースもありました。
中筋：
スタートアップにおいてはいろいろな事件が起きるので、緩やかにシフトできないこともあります。私の例で言うと、ある日突然マーケティング部の部長も兼任してくれと言われました。もちろん経験はありません。さらに会社の資金が危うくなり、業務委託の方を減らしたら正社員のエンジニアが体調を崩してしまい、自分がマーケティング部の部長をやりながらコードも書く、という事態になってしまいました。自分ではこうしたいという思いがあっても、外部要因によってできないことはあるので、なかなか難しいですね。
岸田：
そのときに必要なことをやるという覚悟が重要だなと思いますね。
袖山：
正直CEOよりやることが変わっていく気がします。
藤倉：
ありがとうございます。第一部は以上とさせていただきたいと思います。
状況ごとに求められるCTOの能力と限界
採用、ミーティング、営業、登壇…CTOの日常業務は千差万別
藤倉：
第2部は、「実際CTOは日々どんな業務をしているのか？」という切り口からスタートしたいと思います。岸田さんから、今週の業務を共有していただけますか？
岸田：
エンジニアはコードを書くだけではなく、ディレクタースキルやデザイナースキルを学んでほしいというニーズも高まっているので、今週はデザイナー育成カリキュラムを作成していました。試験的に第二新卒の方を採用して、デザイナー育成にも取り組んでいる最中です。
中筋：
今週はミーティングと採用面接しかしていないですね。細かいところでは海外のツールを導入するための不明点をサポートに問い合わせたりと、こまごましたこともしていましたね。
袖山：
リファラルで一人採用したい方がいて、その人と水曜日に朝の4時まで飲んでいました。あとは名古屋に営業に行くなど、あまりCTO的ではないかもしれませんね。
岸田：
僕も昨日は名古屋に出張でした。スタートアップの学生向けに、それこそCTOが普段何をしているのかといったことを登壇して話したり、別のスタートアップ企業を訪問して、ベトナムのオフショア開発の進捗についてヒアリングもしましたね。
CTOはそれぞれに得意分野があり、全領域に万能ではない。不得意な領域を人に任せる技術
藤倉：
では、日々の仕事の中で、自分の苦手領域をどう解決しているのか、自分のCTOとしての強みや弱みを含め、何かあれば教えてください。
岸田：
コミュニケーションの取り方は気をつけています。特に職種が違うメンバーに対してどんなふうにメッセージを伝えたらいいのかという部分は、自分で文章や資料にまとめ、自分の考え方のバイアスが強く出ていないかという形でエンジニアのメンバーに一度レビューをお願いしています。また、事業上重要なポジションを任せてもらっているので、わからない部分はわかるメンバーに相談をしたり、弱みをさらけ出した上で、周りの人にフォローしてもらっています。自分のプライドを守るためみたいな些細な理由で事業によくないことが起きるわけには行かないので、わからないことをわからないということの重要性は重要なポジションを任せてもらう中で感じました。
袖山：
僕も似ていますね。前職で開発部隊だった時は、いわゆる「キレキャラ」でしたが、今は意図的に変えています。マネジメントするときは優しいマネジメントができる人と一緒に動いています。
中筋：
少し方向性が違う話をすると。私自身は比較的ビジネスサイドを得意としているので、その点での限界はあまり感じていないのですが、どうにもCSSが苦手で。ReactやVue.jsは使えるのですが、CSSはだめ。そこだけは一番優秀なデザイナーさんに任せたりしていますね。
岸田：
逆にそれ以外はすべて自分でされているんですか？
中筋：
サーバーサイド、フロント、インフラなど基本的に全部やります。インフラはオンプレまでできます。
岸田：
CTOの中でもインフラもフロントもできるのはレアだと思います。経営も含めたオールマイティ型は少ないんじゃないでしょうか。
袖山：
その一方でCTOに求められる能力の幅が広すぎる風潮がありますね。開発のスペシャリストとVPoE、CPOでは全く役割が違うにも関わらず、「CTOならなんでもできるんじゃないか」と思われている節がある。
中筋：
それもあって、うちはVPoEの採用を検討しています。私自身あまりピープルマネジメントが得意ではないので、そこはマネジメントが得意な人にやってもらおうと思っています。
岸田：
うちはVPoEに立ってもらっていて、すごく楽ですね。
藤倉：
では今の話の延長として、CTOとして悩んでることはありますか？
岸田：
いつまでCTOをやるのか、という問題はありますね。絶対に一定のタイミングで引いた方がいい。
袖山：
正直僕はあと数年したら、もっと優秀な人にやってもらおうと思っています。
岸田：
目的思考であればあるほど、自分じゃなくてもっといい人がいればその人の方がいいだろう、という葛藤はありますね。
袖山：
それこそVPoEもそうですし、もっとCTOも周りも役割を分割して、それぞれがすごく得意な人に割り振った方がいいのかなとも思います。ある程度SO（ストックオプション）ももらっていますし、CTOという肩書が便利なときはもちろんあります。でも、それらに固執せずに辞めるときはすぱっと辞めると決めています。
【写真：左】Sansan株式会社 /執行役員CTO 藤倉 成太 氏
【写真：右】BizteX株式会社 /取締役CTO 袖山 剛 氏
売り手市場のエンジニア業界をどう生き抜くか。クロージングの重要性
藤倉：
では採用に関する話に移ります。現在は売り手市場になっていて、エンジニアにはいい環境ですが、企業サイドには厳しい状況です。予算も限られている中で、どんな対策を採っていますか？
袖山：
採用時のクロージングを重視しています。特に会社の利と個人の利をマッチさせる部分ですね。例えば個人が将来的にどうなりたいのか、それこそCTOやVPoEになりたいという野望があるのなら、それに対して会社が何を提供できるのか、経営陣やエンジニア全体を巻き込んできちんと説明する。うちの会社がどんな文化でどういうふうに成長できる場なのかを何回でも訪問してもらい、知ってもらうようにしています。
岸田：
年収の高いエンジニアに入社してもらってもミスマッチだったというケースは結構あるので、面接というよりもマッチングという側面を重視しています。本人の弊社に対する認識とやりたいことが一致しているかなど、ギャップを埋めていく作業を重視しています。給与ベースだけでは相手の期待に添えないこともありますし、認識に齟齬がありミスマッチがあるとお互い不幸ですので。
中筋：
採用面はマーケティングのアイドマでいうとAやDの部分が弱いと思っているので、今はそこをテコ入れしています。簡単に言えば技術ブランディングや企業の露出を増やすといったことですね。今は社名がどこかに出たらみんなネットで調べてブログなんかを見てどんな会社か判断する。そこで良い印象が残るように情報発信していきたいです。
藤倉：
技術力が極めて高くても、事業ミッションとの相性を重ねにくい方もいます。喉から手が出るほどほしいと思う人材でも、一旦ぐっと我慢して、事業ミッションとその方の人生観が重なるように、うまく寄り添っていくのが正攻法ですね。
局所的なフェーズや領域において力を発揮する外部CTOの頼もしさ
藤倉：
ではここからは少しテーマを変えてディスカッションしていきます。現在CTOはポピュラーな役割になりつつありますが、経営者に限りなく近い形でジョインしてもらうとなると、容易に採用できるポジションではありませんし、社内に担える人材も少ないかもしれません。
そんな状況の中で、一部では技術顧問のような形で外部CTOを招くケースもあると考えられます。現役のCTOとして、外部CTOの使い方についてアドバイスをいただければと思いますが、いかがでしょうか。
袖山：
オールマイティな人材はほぼいませんから、自社の弱い部分を補完するという意味で外部CTOの起用はありだと思います。うちで言えば使用言語はReactとRailsですが、React系が弱いので、技術顧問としてReactに強い人を招くという感じですね。採用が弱いなら採用に強い人といった形で、局所的に利用するのがいいでしょう。
中筋：
私は技術顧問として3社と関わっていますが、特定の技術領域に対するコンサルティングや、社内CTOの壁打ち相手をするケースがあります。やはり事業を進める上でCTOは不安を持つことがあるので、そのときに同じ視座で壁打ちできる相手がいるのは心強いと思います。例えば月に1回会って壁打ちとしていろいろ発散してもらい、こうした方がいいのではと話し合うといった入り方も多いですね。
岸田：
現在、実際に外部CTO的なことをしています。アーリーステージの企業はCTOを雇うには予算がないし、事業自体もどうなるかわからないので、成功の確度を上げるという意味ではちょうどいい存在なのではないでしょうか。
そもそもエンジニアと接点が少ない事業の場合、いきなりCTOを採用するのは難しいものです。事業が軌道に乗るまでは外部CTOがお手伝いするというやり方がやりやすいと思いますし、コスパもいいと思います。
袖山：
CEOの壁打ちとしてはVCがいますが、CTOは壁打ちできる相手が少ない。壁にぶつかったときに自分で調べて解決するしかないのですが、正解があるわけではありません。そんなときに頼る相手がいるというエコシステムはCTOに必要なのではと思いますね。
【ご登壇者】株式会社LITALICO /執行役員CTO 岸田 崇志 氏
岸田：
実際、CTOの横のつながりはどれくらいあるんでしょうか？
藤倉：
東京近辺のCTOがFacebook上で作ったCTO会というグループがありますね。先日忘年会も行って、130人くらい集まりましたよ。
圧倒的な覚悟が必要なCTO。その到達地点には何があるのか
藤倉：
では最後に、みなさんのCTOとしての野望をお話しいただければと思います。自分がどういう役割やミッションを果たして、最終的に会社をどこまで連れて行きたいと思っているのか。CTOがどんな目線とパッションで生きているのか、という部分が来場者の方に伝わればと思います。
岸田：
基本的には第1部での話と同じです。事業の成功やプロダクトのヒットが一番のミッションで、それを支えるための組織やチーム、技術全体を総合的に作っていきたいと思っています。その上で、社会問題を解決できる、世の中に貢献できる、なおかつみなさんに使ってもらいやすい、そんなサービスを作り出せたら、初めて成功したと思える気がします。
中筋：
事業の成功はもちろんですが、ある意味私が追い出されるような状況を作りたいと思っています。採用した人たちが成長し、技術的にもビジネス的にも私はもういらないから他のことをやってくれと言われるのが、悲しくもうれしいことですね。現在LITALICOは組織として強くなった状態なので、そこが一つの目標地点です。
袖山：
当社ではRPAという自動化ツールを製作していますが、最終的にはそのツールによって、人が働かなくていいようにしたい。今はエンジニアたちが一生懸命コードを書いてプロダクトを作っていますが、それを誰でも簡単にできる世界です。この目標を達成するまではCTOという立場にこだわるつもりは全くなく、僕より優秀な人がいればどんどん立場を奪ってほしいと思っています。
藤倉：
ありがとうございます。みなさんのお話を伺っていて感じたのは、CTOは「圧倒的な覚悟を持った人」であるということです。例えばキレキャラでやっていた、ということ一つ取っても、それは覚悟があるからできることです。答えのない世界で「これが正解だ」と言い切るには、どうしても人に対して強くメッセージをぶつけなければいけませんから。
自分と同じ覚悟を持って進んでくれる人にジョインしてもらうのは難しい話だとは思いますが、今回このイベントに参加している方は、きっとそういう方なのではと思います。
【モデレーター】Sansan株式会社 /執行役員CTO 藤倉 成太 氏
質疑応答②
新エコシステムの創出、起業、スタートアップ支援…各々が描くCTOの次のキャリア
質問者：CTOの次のキャリアとして考えていることはありますか？
袖山：
CTOエコシステムを作りたいと思っています。それこそCTOの初期、さきほど話に出たCTO会に入る前の段階のような人たちが壁打ち相手にできるようなシステムがいいですね。
中筋：
正直もう働きたくないので、鎌倉に引っ越したい…という現実逃避はありますが、CTOを辞めた後もなんらかの形で技術的な方向でビジネスには関わっていると思います。
岸田：
LITALICO自体は大きな会社なので、CTOを経た後はスタートアップの支援をしたいと思っていました。その一方で、まだ自分が40才くらいなので、プロダクトが成功したら企業の立ち上げもしてみたいです。アドバイス的なことは50才くらいからできたらいいかな。プロダクトの作り手はアスリートに近いと思っているので、そのためにもきちんとプロダクトを成功させて、実績は出し続けたいですね。
【ご登壇者】株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏
会社と自分のミッションを重ね、人生を賭ける――成果を出すCTOのあるべき姿
質問者：CTOになろうとしたきっかけを教えてください。
中筋：
ファッションテック企業においては、テクノロジー面だけでなく商品の企画部分も伸ばす必要がありましたが、私がCTOとして立たないと商品企画に偏重して、普通のアパレル会社になってしまうという懸念があったのがきっかけですね。
岸田：
前職に理想とするCTOのロールモデルとなるような方が身近にいたので、CTOという役職自体を一度やってみたいという気持ちがまずありました。LITALICOは福祉や教育というテクノロジーとの融合が難しい領域ですが、そこでインターネット事業を開始するという点がチャレンジングで面白いなと感じ、CTOとして参入しています。
袖山：
現在のCEOの「エンジニアがやっていることを誰でもできるようにする」という理念や熱量に惹かれたことがCTOになったきっかけになりますね。CEOの方でCTOを探したいという場合は、ひたすら口説くのがいいと思います。
藤倉：
質疑応答は以上です。みなさんありがとうございました。
僕自身が思うのは、CTOという厳しい職種をこなす人は、会社のミッションと自分自身の人生のミッションをすみやかに重ねる能力を持っている人なのではと思います。だからこそ全人格、全人生を賭けられる。
技術的な知識だけでは絶対にできない仕事なので、自分自身がCTOになるのであればそうなったほうがいいですし、CTOを探している方がそういう人を見つけられれば、一緒に事業を成長させて成果を出せるCTOになってくれるのではと思います。
以上でパネルディスカッションを終了したいと思います。本日はありがとうございました。
写真：左から
【モデレーター】Sansan株式会社 /執行役員CTO 藤倉 成太 氏
【ご登壇者】BizteX株式会社 /取締役CTO 袖山 剛 氏、株式会社LITALICO /執行役員CTO 岸田 崇志 氏、株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏
企画/編集：FLEXY編集部
