藤門氏：
はい（笑）。小さな問題だったものがどんどん大きくなって届いたりもします。

でも「なんとかするよ！」と対応していました。マネジメントとエンジニアリングを両立したければ、やはり人数は絞るべきです。

伊藤氏：
ヤフー規模だとなかなかそうもいかないんでしょうね。僕はヒューマンマネジメントは自分の仕事の2割程度です。VPoEがいないので、リーダー4、5人が分散してメンバー5、6人を見ている感じですね。

採用はまた完全に別の人が担当しています。とにかくマネジメントの時間は節約して開発を進めている感じですよ。というのも、例えば技術的負債の解消などの大きなテーマがあったときに、50人規模の会社ならCTOがしっかりコミットした方がスケールするんです。

これが100人規模になるとまた変わってくるとは思うのですが、50名でサービスが2つ、それぞれ20人程度のエンジニアがいるような状態なら、どんどん自分が意思決定をした方がいいんですよね。

自分自身のスケジュールもマネジメントが必要

伊藤氏：
時間をどう作るかのスケジュールについても質問が来ていますがどうですかね？

僕は放っておくとどんどんミーティングで予定が埋まってしまうので、意識的に時間を空けています。これは当社の代表の影響です。

彼はボストン・コンサルティング・グループ出身のスーパービジネスマンなのですが、過密スケジュールかと思いきやカレンダーはいつも空いていてデータサイエンスや機械学習なんかをやっているんですよ。

僕より明らかに業務量が多いのに。こんなにすごい人でも時間は作れるんだという衝撃を受けてしまって。

藤本氏：
僕もスケジュールは半分埋まっているかどうかという感じです。

伊藤氏：
自分の時間をコントロールするのもマネジメントスキルの一つだと思いますよ。以前は大事な話だけにフォーカスする取捨選択ができていなかったので、会議をどんどん入れてしまっていました。

藤本氏：
ミーティングが入っていたら仕事をしているように見えてしまうのもあまり良くないですしね。

右側から：
ヤフー株式会社 取締役 常務執行役員 CTO　藤門 千明さん
株式会社一休　執行役員CTO 伊藤 直也さん
グリー株式会社　取締役 上級執行役員　最高技術責任者　藤本 真樹さん
株式会社メルカリ　執行役員CTO　名村 卓さん

最高技術責任者、CTOとしての経営への関わり方

言葉を尽くして技術に関して説明するか、信頼感を高めて任せてもらうか

伊藤氏：
次は経営の関わり方についても質問が来ているので聞きたいのですが、みなさんは経営にどう関わってますか？

藤本氏：
経営会議に出ていますよ。基本的におまかせすることが多いですが、技術や組織の方向性について自分の観点でまずいと思うときは、率直に「それはやめてほしい」とも発言します。とくに、なにかを逆にやらない選択をするのも大事なんで、そういう時とか。

伊藤氏：
具体的には、どういうことですか？

藤本氏：
グリーはいろいろな事業を手掛けてきた結果、おかげさまで運良く伸びてきた会社ですが、今個人的に意識しているのは勝つべくして勝つことかなと思ってます。

次は何を目指すのか、明確なビジョンを持ってフォーカスするなら不要なことはやらないと決めなければならないんです。

できるだけ自由な雰囲気は損なわないようにしつつも、やるべきことに集中していこうと意識しています。

藤門氏：
経営との関わり方で一番重要視しているのが、事業戦略を一緒に決めることですね。事業サイドが決めたことをエンジニアが請け負って進めるというのは一番嫌な構図ですから。

役員と週に1回は一緒にランチを食べに行って戦略を語り合いますし、経営会議でも積極的に意見をぶつけます。

また、役員に技術者ではない人が多いので、業界の状況や今後組織に求められる技術についてわかりやすく伝えるという部分には一番時間をかけています。例えばマイクロサービスなんかもすごく簡単な言葉で説明するんです。「小さく早く作った方が手戻りは少ないですよね」と。大体納得してもらえます。

名村氏：
メルカリは経営陣が企画をすぐに理解してくれるので、マイクロサービスの採用を提案したときも二つ返事でOKだったんですよ。

でも、逆にそれを現場に落とすのが大変で。エンジニアから「何でマイクロサービスなんですか！？」と言われました。エンジニアを説得する方が難しいです。

伊藤氏：
うちはあまり説明していません。以前は結構やっていましたけど。最近はどちらかというと「直也さんがやらないといけないと言うならそうなんだろう」と言ってもらえるように日々活動している感じですね。信用してもらうことを重視しています。

CTOとしてのあり方を経験から語る

エンジニア組織立ち上げではなく、後からCTOとして就任した場合は？

伊藤氏：
後半は僕が個人的に話したかったテーマから進めたいと思います。

特に僕と名村さんなのですが、後から雇われてCTOに就任した際、みなさんはどんなことに気をつけているでしょうか。

僕の経験上、後から雇われCTOの最大の課題は「自社のシステムが全くわからない」というところからスタートすることだと思います。にも関わらず、マネジメントだなんだと色々な仕事が初日から振ってくるし、全然わからない中、大事な技術的意志決定もしなきゃいけない。

時間に追われて、なかなかシステムの根幹をキャッチアップするためのきっかけを掴むことができないという。ただ、これを長いこと放置するとCTOとして十分な仕事ができない。技術的な問題が起きても対応できません。

当たり前のようですが、意外とこういうCTOは多いんですよ。最初は「入ったばかりだから」と周囲も見逃してくれるんです。本人もその状態が続くと妥協が生まれてしまう。

とはいえ、既存のシステムに身一つで切り込むのはなかなか難しい。

この大きな壁をどう乗り越えるかが後から入ったCTOの課題の一つだと思います。結構、ここは歯を食いしばってやらないといけないんじゃないかと思ってます。

伊藤氏：
僕はレガシー改善のための作り直しを入り口に突破したのですが、メルカリCTOの名村さんはいかがでしたか？

名村氏：
大変でしたよ。「新参者が変なコードを書いてるんじゃないか」と思われるのはどこの組織でもありえることですよね。

そこもマイクロサービスが必要だと思った点なんです。システムをもっと切り崩して小さくすれば、新しいエンジニアも切り込みやすくなるはずですから。

藤門氏：
事業には失敗がありますが、技術のせいにされることがないですか？

例えば開発スピードが遅いのは仕組みがモダンじゃないからとか、いろいろ言われますよね。そこが切り込むポイントだと思っているので、僕は率先して言われにいきます。

このトラブルは自分が責任を持つし面倒な部分は全部こなすから、現場は全力で対応して報告してくれとお願いするわけです。すると現場から情報が集めやすく、仕組みや問題点が浮き彫りになってきます。スピーディに状況を把握でき、部下からの信頼も得られるのでオススメですよ。

伊藤氏：
でも藤門さんを怒る相手は孫さんとかなんですよね？（笑）

藤門氏：
心が折れてしまう人もいますので、自分が入って「すみません！自分が今すぐなんとかします！」と言うんです（笑）。

ベテランCTOが経験してきた苦い失敗とそこで得た学び

伊藤氏：
これまで経験した失敗に関する質問も来ています。

僕はグリーに入社したとき、先に述べたように、上手く既存システムの全容をキャッチアップできなかったのが失敗ですね。わかっていないから技術的な意志決定をするのに、間違うことも多くて。辛かったです。

藤本氏：
僕の場合は、組織の人数が増えてきたので、社長からそろそろチームを分けるべきではないかと言われたんですよ。

それを受けて特にポリシーや考えもないまま雑にチーム分けをしたら、エンジニア全員が憤慨してしまって。組織発表のミーティングの場で、自分だけを残して全員「やってられるか」と席を立ってしまいました。

伊藤氏：
その状態からよく復活できましたね。

藤本氏：
結局そこからチームのメンバーが一番パフォーマンスを発揮するためには何を頑張ればいいのか、ということをちゃんと考えるようになったんですよね。

失敗談ですが、パラダイムシフトが起きたような感じでした。とはいえ詳細を話すともっと苦しい話になります（笑）。

名村氏：
別のMeetupでも言ったのですが、自社を「グローバルテックカンパニー」と言ってしまったのが失敗だったかもしれません。期待値が上がりすぎてしまって、社内から「Googleと違うじゃないか」という指摘も入るようになったり。

あまり背伸びしすぎたブランディングは良くないなと思いました。新たに入社する人にとっては「思っていた内容と違う」ということになりかねませんしね。

藤門氏：
とあるプロジェクトで開発全体の進捗が良くなかったので、自分の部門の中にそのチームのメンバーを30名ほど預かったことがあるんですよ。開発環境をいろいろと変えてはいったのですが、目の前に問題があるとつい解決したくなって、自分で改善を進めてしまいました。

結果としてプロダクトは出来上がったのですが、実は本当の問題はプロダクトではなく、エンジニアとビジネスサイドが対立していた点にあったんです。そこにもっと早く気付いていればそもそも組織を変える必要はありませんでしたし、早期解決も図れていたはずでした。

CTOだからと言って何でも自分が手を動かして取り組めば上手くいくというものではないんです。特に自分の管掌に人を配置するときは、冷静になって慎重に考えたほうがいいですね。

なまじ自分が優秀だと思っているばかりに、何かのプロジェクトをサポートしようとするとあれこれダメ出ししてしまって上手くいかないんです。あえて技術に関わらない選択もすべきだということは、自分の失敗から反省として学んでいます。

ビジネスサイドに寄り添うことで信用を高めていく

伊藤氏：
次は「経営陣からの信用を得るためにどんなことを意識していますか」という質問についていかがでしょう。

僕は、敢えてあまりエンジニアの立場に立たないということですね。ビジネス対エンジニアみたいな対立構造に持ち込まないように気をつけたいと思っています。

余計なところでエンジニアに対する信用を毀損していては、いざというときの説得コストが上がってしまう。

藤門氏：
技術的な問題や課題があったときに経営陣のフラストレーションを受け止めることが大事だと思っています。一旦話を聞くということですね。するといろいろと話してくれるようになるので、サービスに関する懸念点や要望なんかが全部自分のもとに集まってきます。

名村氏：
ビジネスサイドときちんと向き合うということは僕もやっていますね。エンジニアの正論をぶつけても会社は成り立ちませんから。一定の距離は保ちつつも、課題解決のために寄り添うようにしています。

時には辛い選択も迫られるCTOが持つべきマインド

伊藤氏：
「メンバーの解雇や面接不合格ほか、絶望感のある辛い意思決定をしたときのメンタルの持ち直しはどうされていますか」という質問が来ています。

藤本氏：
誤解を恐れずに言えば、リーダーにしろマネージャーにしろ、人の上に立つ人が辛い意思決定をしたとしても、相手に同調する、というのは必ずしも良いことはないと思っています。

2人で同じ状態になってしまったら前に進めないので、相手にとっても自分にとってもプラスになりません。

伊藤氏：
でも、昨今のマネジメント論で言えばその逆を良しとする風潮がありますよね。チームで仲良く頑張ろうという感じ。

藤本氏：
立場の上下関係なく、相手の目線でものを考えないと話が始まらないのは当然だと思います。

でも、本当に心の底まで相手と自分を同一視する必要はないのかな、ってことです。前に進めなくなっちゃうので。

伊藤氏：
それは僕も同意見です。僕たちは根本的にチームを強くするためにマネジメントしているので、そのために必要なことであれば多少辛くてもドライな意思決定をすることは必要です。

プロのサッカーチームで、「あいつは頑張ってるからとりあえず試合に出そう」なんてありえないじゃないですか。実力が足りなければ選手を変えていくのが強いチームです。

ただ、僕たちの世界はそう割り切れない部分があるということなんですよね。仲良くやっていきたい気持ちもよく分かります。

藤本氏：
今は辛くても3年後まで見据えたら必要な決断だとお互いに思わないと駄目ですよね。

名村氏：
仮に誰かが退職したにしたとしても、その人にはもっと別の良い場所があると思うようにしています。

伊藤氏：
ではメンタルはどう持ち直していますか？

藤門氏：
僕は寝れば大丈夫です（笑）。例えば1年かけて進めてきたプロジェクトが突然中止になるとか、自分にとっても誰かにとっても辛い意思決定はありますよね。

でも、自分も相手もお金をもらって仕事をしているプロだということを意識して、あまり気にしないようにしています。そもそも自分がCTOになれたのはそういう性格的な部分もあるのかもしれません。

伊藤氏：
僕は辛いときは釣りに行ってます。その時間は仕事のことは考えないようにしています。

10年前とはガラリと変わった情報収集の方法

伊藤氏：
次は、「CTOとして普段の情報収集で気をつけていることはありますか？」という質問です。

そもそも現代においても技術情報を10年前と同じように一生懸命収集しなければいけないのかどうかというところなんですよね。

名村氏：
GitHubのTrendingなんかは見てますね。中国のリポジトリ多いなとか。

あとは今何が話題でどんなツールが流行っているのかといったことはキャッチしています。昔はそれこそRSSリーダーを駆使して情報を得ていましたが、今は会社のslackに勝手に流れてきますから必死に収集している感じではないですね。

伊藤氏：
当時より業界全体のエンジニアの数も増えてますし、整理された情報が発信されるようになった感じですよね。

藤本氏：
でもslackにしてもそもそも全部見きれないんですよね。情報を取捨選択する必要があります。

藤門氏：
僕は一次情報を入手することを一番大事にしています。

名村氏：
Tech Journalのツール動向を見ていても方向性がわかりますよね。

藤本氏：
各分野詳しい人と友達になる手もありますよ。

藤門氏：
昔は結構本を買っていた気がしますけど、最近は買わなくてもなんとかなります。

伊藤氏：
総括すると、そんなに必死に追っているわけではないということですね。

組織が前に進んでいくための採用基準

伊藤氏：
採用・不採用を判断するポイントについての質問も来ています。みなさんはどういうところを大事にしていますか？

藤本氏：
いろいろありますが、自分と他人の意見を同じ地平で考えられるかどうかが大事だと思っています。

同じゴールに対して、自分の意見を第三者的に見た上で相手と比較できる人です。
というのも、エンジニア同士の議論ってしばしば「自分の意見はダメというわけではない」というのは難しくないんですよね。

ただ、そうやって自分の意見に固執し続けると、議論が進まなかったり、より良い意見がうまれなかったりしますからね。

名村氏：
ベクトルが自分に向いている人は採用しないですね。自分がやりたい技術が決まっていて、しかも自分の評価を気にしているような人です。

あとはその会社に所属していることで自分の価値が高まる、チームは自分のためにあるという価値観の人は避けたいなと思いますね。

伊藤氏：
どう見極めるんですか？

名村氏：
先程ブランディングの話が出ましたが、実際のところはこういう企業ですよと期待値を下げると勝手にリジェクトされていきますね（笑）。

あとは前職の給与に応じた評価もしません。そういうオファーをしても来たいと言ってくれる人は、大体良いエンジニアです。

藤門氏：
うちはまずはカルチャーフィットするかどうかですね。ヤフーは最初からWebの企業なので合う人が多いは多いのですが、今はPayPayの事業などで多国籍なチームが増えています。そういうグローバルな組織文化に合う人という視点は大事にしています。

あとは名村さんの言ったように、期待値を下げることも大事です。たとえば「データサイエンティスト」はキラキラしたワードに聞こえると思うんですよ。何でもできる人がスマートに仕事をしていて、しかも給与も高そうですよね。

でも実際はぐちゃぐちゃのデータを自分でクレンジングしてデプロイしないといけません。非常に泥臭くてきつい世界なんです。そういう仕事も全てできますか、と毎回聞いていますし、それで去っていく人も多いです。実際にサーバーまで自分で手を入れてものづくりをするような人が入社後に活躍していることが多いです。

伊藤氏：
僕は最終面接を担当しているのですが、現場に人が足りないという理由で採用しそうになっていないかを見極めていますね。本当にこの人がいいと判断した上で採用すべきだと思いますから。

CTO・テックリードの先にあるキャリアの選択肢とは？

伊藤氏：
今日のテーマはCTO・テックリードのその先はということだったんですが、時間がなくなってきてしまいました。

みなさん考えていますか？

名村氏：
あんまり考えていないですね。

伊藤氏：
会社を伸ばすという役割はあるんですけどね。今日の登壇者は同年代くらいなのですが、ここより上の先輩はあまり多くないんです。

だからこの先のキャリアを誰も知りません。僕自身、今日までCTOをやっているとは思っていなかったですからね。とっくに引退しているつもりでした。

技術顧問を一時的にやったこともあるのですが、自分は長く続けるのが難しいと感じました。。自分の経験を貯金として切り崩す仕事なので、3年もしたら人に教えられることがなくなってしまうので。

名村氏：
次世代のエンジニアを育てるために教育方面に進む人はいそうですけどね。

藤本氏：
CTOを辞めた人はもう一度別の会社でCTOをやるか、少数派ですがCEOやVPになっている、あるいは投資家になっているという感じですかね。

名村氏：
大企業のマネージャーをやっている人もいます。

藤本氏：
みんなやりたいことをやっているんだと思いますよ。

イベント終了後、今回のCTO meetupのPM担当のFLEXY土田と寺島と撮影していただきました。この度は、貴重なお話、有難うございました！

企画/編集：FLEXY編集部