【前編】CTOの役割は経営？それとも技術戦略？―Azit CEOが現役CTOに聞いてみた！【PR】
テクノロジーカンパニーにおいてCTOの果たす役割は重要だ。企業の成長段階や規模、業態によって、CTOとしてのミッションや業務内容・役割など、その任務は異なります。
そこで今回、リブ（LiB） CTO 水上学氏、STORES.jp Inc. CTO 矢部剛嗣氏、コネヒト CTO 島田達朗氏、BASE 取締役CTO 藤川真一（えふしん）氏の4人に、「CTOって、経営者？技術者？」「技術戦略・技術選定はどうしてる？」などなど、現役CTOの本音を生々しく語っていただきました。
＜現役CTOメンバー＞
株式会社リブ（LiB） CTO 水上 学氏
STORES.jp Inc. CTO 矢部 剛嗣氏
コネヒト 取締役CTO 島田達朗氏
BASE株式会社 取締役CTO 藤川 真一（えふしん）氏
＜司会進行＞
TECH PLAY プロデューサー 鳴釜優子
モビリティプラットフォーム「CREW」で急成長のAzitがCTOを急募
──今回、今後の成長のためにぜひCTOを採用したいというAzitさんから、CTOの業務内容や課題についてディスカッションしてみたいというご要望をいただき、皆さんにお集まりいただきました。
CTOの仕事は実は企業によってさまざまで、いざCTOに就任したとしても、その人は何から始めればよいのかよくわからないということがあると思います。ぜひ、積極的に情報・意見交換をお願いします。
Azit・吉兼：Azitは2013年に創立した会社で、2015年からは「CREW」というモビリティプラットフォームを開発・運営しています。現在は正社員が約30人、アルバイト合わせて100人規模。そのうちプロダクト開発のチームが7人、うち専任のエンジニアは5人ほどいます。その他はデザイナー、PMなどですね。
昨年の秋に約10億円の資金調達を実施しました。今後、組織がどんどん大きくなるタイミングで、あらためてCTOやVPoEの役割が重要だと考え、採用活動を強化しているところです。僕自身はデザイナー出身の創業者なのですが、今日はCTOの果たすべき役割などについて、現役の皆さんに教えていただきたいと思っています。
▲株式会社Azit 代表取締役CEO 吉兼 周優氏
Azit・十亀：吉兼と一緒に会社を起ち上げ、現在はテックリードをやっています。サーバーサイドエンジニアです。創業後2年半くらい、エンジニアは自分しかいませんでした。ようやく5人に増えて、今後はしっかりとしたエンジニア集団を作っていきたいと考えています。迅速な意志決定をしながら、強力かつ柔軟に動ける組織体としてのエンジニアチームをどうやって作っていけばいいのか、ご意見を聞かせてください。
▲株式会社Azit リードエンジニア 十亀 眞怜氏
コネヒト・島田：2014年から満5年目を迎えたママ向けサービス「ママリ」を開発・運営しています。「ママの一歩を支える」というブランドミッションのもと、妊活・妊娠・出産・子育ての疑問や悩みを解消するメディア・コミュニティアプリで、2018年に出産をしたママの3人に1人が使っているサービスです。僕の場合は、エンジニアとして共同創業し、CTOになりました。CTO歴は会社と同じ歴になりますので、8年目になります。
LiB・水上：女性向けのライフキャリア支援サービスを展開するLiBでCTOをやっている水上です。エンジニアですが、プロダクトの企画面にもメインの仕事として関わっています。実際の仕事の割合でいうと、プロダクト（開発・企画）・インフラの順ですね。
LiBにエンジニアとして入り、半年後にCTOになりました。最初はCTOが何をするかわからないところからスタートし、現時点でCTO歴2年です。
STORES.jp・矢部：オンラインストア開設を支援する「STORES.jp」にはエンジニアとして入社しました。2016年にMBOをしたタイミングで組織が大きく変わりました。それまでは代表の直下にフラットにメンバーがいる体制だったんですが、技術部門を設置してCTO職を設け、私がCTOになりました。とはいえ、私もまだCTO経験2年です。
BASE・えふしん：BASEの取締役CTO藤川です。BASEは2012年12月に創業し、その時は技術顧問として関わりました。会社が成長し、採用を強化して組織固めに入ったタイミングでCTOに就任しました。CTOという役職は、CEOに頼まれないとなかなかやれる機会がないので、オファーを受けました。CTO歴は5年になります。
CTOはどんな仕事にどれだけ時間を使っているのか？
──最初のお題は、ご自身のCTOとしての業務内容とその比率を円グラフで描いてくださいというもの。どんな仕事にどれだけ時間を使っているのかお聞かせください。
えふしん：私の場合は事業20％、エンジニアリングマネジメント30％、採用30％、チームプロジェクト10％、経営10％。CTOとしての対外的な活動や、プロダクト部署のマネジメント、さらに経営者という役割を同時に果たさなくてはなりません。
割合として一番多いのはエンジニアリングマネジメント。エンジニアを束ねるマネージャーたちに関する業務ですね。マネージャーたちとは1on1のミーティングに結構時間をかけています。あとは採用ですね。CTOとして表に出ることも多いので、面接のクロージングや、採用予定者との会食にも顔を出したりします。
私自身が個別に関わるプロダクト開発のチームもあるので、開発メンバーと直接話す時間もとっています。まだまだ現場の仕事が多くて経営に関わる仕事が10％しかできてない。今後は現場の仕事をメンバーに移譲していくことが課題だと思っています。
吉兼：それはここ数年の状況ですか？それとも以前から？
えふしん：去年は200名くらいの人と面接していたので、採用業務が全体の40～50％くらいありました。今は分担して少し減っています。
吉兼：意外だったのは、技術開発をする時間がほとんどないんですね。
えふしん：ですよね(笑)。Webサービス企業のCTOの仕事はやはり事業寄り、プロダクト寄りになりがちだと思います。エンジニアリングはスケーラビリティやユーザービリティ、スピード向上など基盤開発に関する業務も含まれますが、基本的には開発業務は開発メンバーに移譲していきたいし、それが当社ではできつつあります。
ブロックチェーンとかのテクノロジーベンチャーなどは、CTO自身がもっと先端技術を追う必要があると思いますが、Webサービスの会社はエンジニアリングマネジメント、つまり人の管理が重要だと思っています。
矢部：僕は開発組織40％、マネジメント30％、開発支援15％、その他10％、技術検証5％。STORES.jpは、去年経営統合による持ち株会社が親会社としてできてから、採用にも力を入れるようになってきました。この1年は、今後どういう組織体制で開発していくか、プロダクト開発のロードマップと合わせて、採用計画を立てるようになりました。
多くはメンバーに任せてはいるものの、採用したエンジニアのマネジメントにも時間をとっています。新しく入社した人から、「どうしてこの技術なのか」とか質問が出てくることがあるので、今までの経緯を伝えるあたりは僕がやっています。技術検証については、希望も含めて5％。実際はそんなに時間は全然取れていないかもしれません。
えふしん：開発組織ごとのマネジメントと全体のマネジメントを合わせると、7割がマネジメントってことですよね。
吉兼：人が増えることによって、マネジメントにかける時間はどう変わりましたか？
矢部：今はマネージャーという肩書きは組織に置いていなくて、開発自体は小さいチームに分け、それぞれにリーダーポジションがいます。評価はリーダーにお願いしています。規模感としては、開発チーム16名。それを5チームに分けているので、リーダーが5人ですね。
吉兼：BASEはどのぐらいの規模感ですか。
えふしん：エンジニア組織は全体で60名くらい。マネージャーが7～8名。マネージャーたちとは、常に1on1ができるように組織を作っています。マネージャーを置けないところはまずは自分が見て、構造化できるようになったら権限を渡しています。
Webサービス企業のCTO、コアコンピタンスは何なのか
水上：私の業務割合はプロダクト開発30％、インフラセキュリティ30％、採用30％、その他10％。マネジメントが入っていませんが、それはLiBならではの組織の特徴があるからです。
まずLiBは5つの事業部制になっていて、エンジニアはそれぞれに紐づいています。エンジニア評価もそのチームの事業責任者がします。そのためCTOとしてのマネジメント業務があまり発生していないんですね。
ただエンジニアや事業がまだ育っていないチームについては、自分が企画や業務改善などビジネス面でのアドバイスはするようにしています。5事業部中3事業部は社内エンジニアがまだいないため、開発は業務委託。ですから外注のコードレビューは私の仕事になります。
インフラやセキュリティは、面白いなと思いながらやっています。採用は新卒・中途の面接ですね。技術検証については、個人で毎日1時間だけとってやっています。あくまでもプライベートの枠でやってる感じです。
えふしん：インターネットサービス企業のCTOが持つコアコンピタンスって何でしょうか。技術的なバックグラウンドとして何が求められるかという話。もちろんフロントエンドでもいいと思うんですが、インフラ、セキュリティ、スケーラビリティあたりをコアにする人もいる。最近だと機械学習とかも入ってきていますね。
水上：自分でそれをコアにするかどうかはともかく、事業で一番コアなところをCTOが知っている必要性はありますね。LiBではお客さまの個人情報を扱うので、セキュリティについては深い知識が必要です。ゲーム系の会社だと企画業務についての知識があるエンジニアがCTOになるケースが多いのでは。
えふしん：そういう意味では、CTOって一人である必然性ってないですよね。3人くらいいてもいいんじゃないかなと。CTOって技術のトップなのか、経営陣の一員なのか、会社ごとにミッションが違いますね。技術のトップだとすると、オフィサーってなんだというのもあるけど、独立してやれるだけの組織で誰かがまとめる必要があるなら、それはCTOなのかとという議論もある。
島田：僕は「チーフ（C）」と名がつくのであれば、CTOは一人でいいと思うのですが、その他にVPoEやVPoP、プロダクトやエンジニアのマネジメントの責任者に肩書きをつける会社もありますね。これらは会社のフェーズによって違っていいと思います。
もちろんゼロイチでスタートする会社ならCTOが全部やる必要があるでしょうが、それがタイミング、フェーズによって、徐々に細分化し、権限委譲されて役割分担されていくのかなと。
吉兼：フロントエンド、バックエンドなどの技術分野でCTOの役割を分担するより、一人が意思決定した方がいいのでしょうか。
島田：先程申し上げた通り、タイミング、フェーズによりますね。名前（役職名）が人のロール、役割を作ると思っているので、技術ごとに責任者を置いてそれを明示化するというのは選択肢の1つだと思います。役職名をどうつけるかはまた別問題ですが。
世の中にはGoogleのようにCTOを置いてない会社もあります。CTOの役割を別の方法で担保しているので、必要ないという判断なのだと思います。すごく極論ですが、CTOを置かないという手段もあって良いと思っています。
吉兼：では、なぜCTOをやり続けているのでしょうか？
島田：CTOという役職が、少なくとも一定の規模のベンチャーにおいては経営観点で必要だからです。インターネットベンチャーにおいて、テクノロジーを使わないということはありえない。だからテクノロジーの責任者がいることで心理的に安心だし、その人が意思決定することで前に進むことが多い。フェーズによっては必要。でも、適切に役割分担された企業（Google）には必要ないのかもしれない。きっとそういう企業はCTOという肩書きの人はいなくとも、技術的な観点で経営にコミットしてるメンバーがいるのだと思います。
えふしん：重要なことは、CTOという役職名や一人なのか複数なのかということよりも、テクノロジー的な意思決定において、誰が責任を持てるかということですよね。
会社のフェーズによってCTOの仕事は変わっていい
吉兼：その場合の「テクノロジー」の言葉の意味は、統一がとれているんですか？
えふしん：それはバラバラじゃないですか。WebでずっとやってきたCTOは、必ずしも機械学習に詳しいわけじゃない。最近ではフロントエンドとサーバーサイドもどんどん技術が分かれてきているので、それぞれ頑張らないといけない。
前にグリーの藤本さんがブログで書かれてましたけど、CTOが全部の技術を理解する必要はないと。でも、意思決定はできますよね。ただ、AIとWebサービスは補完関係にあって両方それぞれ成長していかなくてはいけない。今後AIのビジネスが広がっていくと、今みたいなCTO構造だと辛いんじゃないかな。組織が作りにくくなるんじゃないかは思います。
吉兼：会社のフェーズによって、コアコンピタンスな技術はどんどん変わっていきますね。CTOにはその変化に絶えず追随することが求められているのか、それともフェーズやタイミングによって人を変えていくべきなのか、このあたりはどうでしょう。
島田：ケースバイケースだと思います。経営陣の合意があるなら代わってもいいし、CTOとしてフェーズに合わせて自分が変わっていくと決断するならそれでもいいと思います。重要なのは、そのとき最適な人を経営として据えられていると思えるかということではないでしょうか。
水上：LiBは創業期と今ではCTOが代わっています。会社のフェーズによって、よりいいCTOがいるのだったらその人に代わればいい。自分が変化できると思うんだったら、続ければいい。例えば、会社が成長していくと、CTOは単に技術だけでなく経営の数字なども理解しなくてはいけなくなりますよね。それを新しいコアコンピタンスに加えることができるかどうか。
矢部：プロダクトや事業をCTOとして推進できなくなったのであれば、CTOを誰かに代わってもらう選択肢は全然ありだと思います。会社の規模やフェーズ、組織、経営陣にもよりますが、結局、自分が変わるか、別の人を選んでいくしかない。
えふしん：会社の成長を考えたとき、自分がボトルネックになってしまったら、それ以上成長しなくなってしまうので、CTO交替を怖がるべきではないですよね。それを踏まえてどういう組織を作っていくか、誰が何を担うのか考えなくてはいけない。
CTOにどうしたらなれるかというキャリアパスで考えると、CTOがリードエンジニアの先のキャリアパスなのか、エンジニアマネジメントの先なのか、これは何がその会社のコアコンピテンシーなのかで変わってきますよね。CTOという肩書きは、とても曖昧で難しいものだと思います。
島田：私の業務内容は、広報10％、採用20％、マネジメント20％、開発15％、経営・取締役アレコレ35％です。
えふしん：バランスいいですね。開発もしているし、経営もしている。
島田：本当はもっとコード書きたいです(笑)。うちのエンジニアは20名弱、機械学習のエンジニアが少ないので、僕も手を動かしています。
えふしん：「経営」の中身はどんな業務があるのですか？
島田：ここに書いた経営・取締役アレコレというのは、創業CTOとしての役割という意味合いが多いですね。
創業者というのは社内ではワイルドカードで、良くも悪くもバシッと言ったら意見が通ってしまいます。そういう意味で、例えば「セキュリティ的にはこれを絶対やらなくちゃいけない」ということを進めたりするには有効です。また、会社の組織の間の溝にボールが落ちるときがありますが、そういう場合は僕が動いてそれを拾うようにしています。
CTOは経営者なのか、技術者なのか
吉兼：社内にCTO室的なものがあるんですか？
島田：CTO室は作りました。プロダクトのオーナーは当面の課題を達成するのに必死になりがちですが、それに対して長期的にリスクを防ぐためのセキュリティ強化は、ときにプロダクト開発のインセンティブとは相反することがあります。
だから、その長期的な課題はCTO室として推進する戦略です。M＆Aで上場企業の傘下に入ったので、CTO室の設立は会社としてセキュリティをちゃんとやるという意思表明でもあります。
現在、CTO室はエンジニアとデザイナーに加えて、カスタマーサクセスグループ（CS）が所属しています。「ママリ」はメディアとコミュニティをやっているんですが、コミュニティ活動はその価値を経営的な数字として定量化するのが難しい。どんな質問にもみんなが優しく回答してくれるコミュニティの質や雰囲気を維持するために、CTO室が積極的に関わる必要があるんです。
えふしん：Webサービスがメインの企業は、いわゆるUI・UXをよくすることでユーザーにより楽しく、有益に使ってもらい、結果として数字が上がっていくというところがあると思います。
一方で旧来的なビジネス、営業が顧客に直接売ってくるチームとは、それぞれ持ってる数字が違うと思いますが、そのバランスをCTOとしてどう考えていますか。
島田：バランス感がとても大事だと考えています。当社には営業部隊もありますし、toB向けサービス、サイト自体のマネタイズ、有料プレミアムプランの増加なども大事な指標です。PV単価を上げるとユーザー体験を棄損しがちになるので、そこに介入してバランスをとっていくことも僕の経営に関する35％に入ってます。
えふしん：PVを増やそうと思ったら、プロダクトチームが頑張っていいサービスを作らないと増えない。そうすると、数字は営業が持っているけど、実はその数字はプロダクト側に依存しているってことになりますよね。
サービスの根幹のビジネスはプロダクト側が持っていて、そこにCTOが関与している。CTOという言葉自体もテックという響きよりもビジネスの趣きが強い。これもCTOという役職の特徴だと思っているんです。
島田：結局、CTOは経営者であって、技術はあくまでも経営の手段だと僕は思っています。技術という手段を使ってプロダクトを前進し、そのための意思決定のプロセスを合理的にしていくという役割ですね。
CTOだから技術的負債を解決することを目標におき、責任を持つべきと言われることもありますが、僕はちょっと違って、技術的負債を解決すべきという意思決定を経営目線ですることが大事だと考えています。つまり、CTOの仕事はテクノロジードリブンというよりは、経営ドリブンなんだと。
水上：LiBは営業サイドの方がメインですね。プロダクトの目標数字はエンジニアが持っていますが、事業としての売上とかは営業が持っているというスタイルです。プロダクトのロードマップは事業責任者とコンセンサスを取りながら作っている。事業責任者は元エンジニアや、エンジニアじゃない人もいます。
技術投資の判断に悩むときはどうしてる？
十亀：Azitのテックリードとしての業務割合は、組織開発40％、プロダクト20％、技術キャッチアップ10％、採用20％、採用広報10％というところです。
最近は面接する機会が増えてきて、Tech Blogも始めました。プロダクトについて書いたりしています。技術調査はどう進めていけばいいのか迷うことが多く、皆さんがどうされてるのか聞きたいと思っています。
組織開発については、今まで僕一人で他のメンバーとコミュニケーションとっていたところを、今後はプロダクトチームとして会社内でどういう存在になっていくのか、会社のプロダクト作りの文化はどう作っていくのか、しっかり考えていきたい。今はそのための時間をとっているところです。
えふしん：十亀さん、テックリードっぽくないですね。テックリードだったらもっと半分くらい技術に集中してもいいのかなと思いました。今は会社として拡大期にあるタイミングだし、今後組織がもっと大きくなったらテックリードでいられなくなる。どうやって自分の技術を維持していくのか、他人に渡すのか、今がその端境期なんだろうなと思いつつ、技術の時間に寄り切れてないという感じでしょうか。
十亀：組織開発に関しては、今後然るべき方を採用して、移行していけたらと考えています。また、テックリードとして、社内の技術をそろそろリファクタリングするべきという意思決定には関わっていますが、リファクタリングの実際の作業には関わっていないですね。
えふしん：そこまでやっていたら、1日20時間くらい働くことになっちゃう(笑)。
十亀：具体的にどういう技術に投資するとかは、手探り状態ですね。例えばこの言語に移行しないと、エンジニアが採用できないかもと思っても、それを自分で考えていくべきなのか、現場の人たちがこの言語がいいと提案してもらって承認する方がいいのか。
島田：言語選択は人材採用にも繋がることだから、結構重要ですよね。例えば、今のタイミングでPHP5系とかを使い続けるのは厳しい。そこはGoとかにしようという話が出る。ただ、そういう使用言語レベルの話は現場から言いづらいので、経営が採用戦略の一貫として意思決定する必要があるでしょうね。
一方で、ライブラリをまとめた方がいいという話は粒感が小さいので、現場の意思を尊重したほうがいい。経営レベルのイシューなのか、現場の課題なのか、そういう切り分けをしたほうがいいと思います。
えふしん：言語選択は一つの例ですが、開発言語を変えると辞めちゃう人も出てきますよね。その人たちが辞めていいのかみたいなことは経営判断がいる。一番いいのは、みんなの意見を聞きながら、最も優れたアイデアを出した人に従って決めること。誰が実作業するかという話も最終的な判断はCTOの仕事だけど、誰ができるか、誰もいなければ自分でするしかない。
島田：新しい言語は楽しいので、最初はいいけど、実際に進められる人がいないと、リファクタリングできなくてスタートアップは死にます。で、新しい技術に触ることを目的に転職してきた人は、開発できなくなるとその間に別の新しい技術に惹かれて、競合に抜かれてしまう。その現実性も見極めることが大事なので、そこはフラットに社内で議論したほうがいいと思います。
技術負債の解消のためにCTOができること
十亀：技術負債を解消しましょうというのは経営の判断ですか？
えふしん：内容にもよりますけど、コードのリファクタリングだったら現場でやっていいと思います。それができる人たちをテックリードにしていくとか。抜本的なアーキテクチャの変更とか、開発パートナー企業の選択とかは、CTOがテックリードと相談しながら決めますね。いずれにしても、CTOは課題解決の優先順位を設定してあげることが重要です。
エンジニアが重要だと思っていることを、CTOがビジネスだけ見ていてキャッチアップできていないと、いつか問題が顕在化し、それ見たことかということになる。ここはCTOやCTO室などで、リスク検討していつやるべきか判断すべきですね。
水上：そのあたりは、CTO室でできるだけやるようにしています。情報が入るようにしていて、怪しいものとかはちょっと待ってもらう。一日で終わるようなもので戻しがきくものは、そのまま現場に任せてしまう。例えば認証周りを変えるとか、セキュリティ系みたいなものは確認したり、コードレビューしたりします。
僕としては、できるだけ現場依存というか、現場が主導権や判断を握っていた方がいいなという考えがあります。「そういう思考だから技術負債が解消しないのね」ということも現場が認識していないといけないですし。現場で思考してもらって、それが上がってきたときに、危なかったらこういう理由で危ないよということを、サジェッションする。そういうスタイルでやってますね。
島田：賛成ですね。結局、技術的負債の意思決定は現場の賛同が得られないと不満がたまるので、現場が意思決定していることがすごく大事。
えふしん：まずは現場からいかに声を上げてもらうかが大事。新規開発に伴ってフレームワーク変えようよという話が仮にあったとしたら、CTO側から、「こういうことを考えているんだけどどう？」と意見を聞くようにしています。そうしていかないと、頑張って現状を維持しようとすることを考えてしまうので、変化を促し、意見を引き出すようにしています。
CTOにも壁打ちが必要だ。CTO室は何をするところ
——皆さんが持っているミッションを共有する人、CEOやCTO室のメンバー、あるいはVPoEとの役割分担はどうしていますか？
えふしん：経営的な問題とか、リスク、組織がどうあるべきかとか、社長との1on1を毎週やっています。それと日々相談できる場所として、CTO室を作っています。CTO室はエンジニア採用がわかり、技術のプラットフォームを相談できるような人に入ってもらっている。今は僕を含めて3人。そこで相談して、自分の考えを整理します。やっぱり自分一人で考えていると、頭がごっちゃになるので、壁打ちする相手がいるといい。このあたりの課題についてVPoEに責任を持ってもらうというのは次のステップですね。
矢部：CTO室は今ないんですが、そこはCEOと毎週1on1しながらやっています。まだ人数も少ないので、経営も組織も技術もその1on1を元に決めている感じですね。
吉兼：社員が何人くらいになったら、CTO機能を分担したほうがいいものなんでしょうか。
島田：目的ありきでしょうね。セキュリティをちゃんとしたいというような目的があれば、対策チームを作ったほうがいいだろうし。
えふしん：組織をスケールさせるにあたって、自分がボトルネックになると思える瞬間というのがあると思うんです。CTOの仕事が24時間では足りないと明らかになるようなら、移譲していかなくてはいけないんだけど、CTOのお悩みは必ずしも全員に共通するものじゃないですからね。
それを共有できるようなポジションを作らないと、情報開示もできない。だから、そういうのを組織として作り、責任をもってもらわなくてはいけない。まずは、組織の運営にあたって自分がボトルネックにならないようにするというのが大切ですね。
水上：CTO室を作ったのは、それまでインフラや基盤をエンジニアチーム全体で見てたのが、事業部制になったために見られなくなる部分が増えたから。そのため共通の基盤を見るところとして、CTO室を作り、そこがセキュリティを守る責務を持つようにしました。
矢部：当社にも、プロダクトを作るチームと基盤を整えるチーム、さらに技術的負債をどのタイミングで解消していくかというチームはあります。CTO室という名前はつけていないですが。
水上：VPoEは置かず、CTOとCTO室でカバーしています。CTO室の中に業務委託で入ってもらっている元CTOの人がいます。似たような経験をしているので、壁打ちの相手になってもらっています。
役割が人を育てる。CTOは交換可能であるべき
──最後の質問はAzitさんから。
吉兼：一通りお話を聞いて、Webサービス企業だからといって特別なことは何もないなと思いました。CTO室は普通の会社でいう経営企画室の役割ですよね。一般論ではなく、ケースバイケースで意思決定するしかない。
当社の場合は創業してから、CTOやVPoEに限らず、まだCXOの肩書を渡したことがない。世の中にはすごい人がたくさんいるし、会社が成長しているので、優秀な人が採れてしまう。もっと優秀な人材がこれから採用できるかもと悩んでいると、CTOに限らず誰にも渡せていない。リーダーシップを発揮してくれる人を採り続けようというアクションもしながら、どのタイミングで肩書を渡していくべきか。そこが悩みなんです。
えふしん：CTOに限らず、エンジニアのキャリアパスというのがありますね。例えばエンジニアからエンジニアリングマネージャーになった人がいるとして、そのマネージャーは上司なのか部下なのか。組織図上には上司と部下にしなくてはいけないかもしれないけれど、うちではマネージャーは役割として考えているので、戻れることも大事にしている。
とりあえずマネージャーやってみたあとに、現場に戻ることができる。どちらも経験しているという意味でその人の役割が広がるわけだから、評価を下げたり、減給したりしないで、現場に戻るというパスがあってもいいと思うんです。それと同じで、CTOも交換可能であるべきかなと。だからさっきのCTOの定義はすごく大事で、何を期待しているか、状況によって変わっていくべきではないかなと思っています。
創業者の役割という話でいうと、創業者には創業の理念、フィロソフィー、パッションなどがありますよね。創業後に入って来る人は優秀かもしれないけど、そういう部分を持っていない可能性がある。
そういうときにCTOという肩書きがずっと誰かにロックインしている状態は健全ではないと思うので、そのときに周りからどうCTOという肩書きが見られているか、社会的にどういう役割を背負っているのかを柔軟に考えていく必要があります。その意味では、早めにCTO職をつくっても問題ないんじゃないでしょうか。CTOを外したら会社を辞めるような人材なら、それはそれまでかなと思う。
CTOになってよかったこと、そのメリットとは
吉兼：本質的に役割は会社の成長フェーズによって変わっていくべきですし、1on1でそのグリップもできる気がしますが、社外からの見られ方を意識するとストレスを感じる人もいるんじゃないかとも思います。もう一つ聞きたいのは、CTOになってよかったこと、その便利さやメリットは何でしょうか。
えふしん：この座談会に呼んでいただいてるのもCTOだからだと思うんですけど、そういう部分の責任を負っているということだと思う。それに尽きると思う。
島田：CTOを置くのは、会社として技術を大事にしているという意思表明だと思います。CTOがいるメリットは確実にあるし、面談をしていると、CTOがいない会社に入りたくないという人もいる。
なぜかというと、ビジネスの人の権限が強い会社だと、エンジニアが欲しい機材などが買えない状況などがあるから。そういう議論をする時点で、エンジニアにとってはストレスなわけで、技術投資はちゃんとやるという意思表明としても、CTOがいるメリットなのかなと思いますね。
CTOに限らず、肩書きが人を育てるのはいいことだと思います。僕自身、創業者兼CTOという肩書がついたのはよかった。テクノロジーのことは自分の範疇として責任をもって意思決定しようと思うし、研磨しようと思う。自分より優秀な人に負けないように頑張ろうと努力していますから。
水上：うちはCTOが変わったり、時にはCOOも変わるんですけど、マイナスというよりは、役職者が交替するのは会社が変わる為には必要なことだという文化がありますね。そういう文化を作ったらいかがでしょう。
吉兼：そういう文化にした方がいいのはわかるんですが、特に中途入社で入ってくる人たちの意識を変えていくのはハードルが高いような気がします。
水上：CTOの交替を含めて、全社に公開して各人に思いを伝えていれば、ある一定の納得感は得られると思うんです。そこは丁寧にやるしかない。私もCTOですが、良さそうなCTO候補がいれば紹介するし、自分も変わるかもしれないし、別の肩書きになるかもしれないけど、あまり気にしないでねって。採用面でも不安はないですね。
吉兼：やはり文化形成がトータル的に大事なんですね。
えふしん：あとは責任の所在ですよね。結局、最終的にCEOに責任が全部あるわけじゃないですか。そこに対して免責リスクが考えられるならば、ちゃんと巻き取ってくれる人を置かないと、CEOが全部対応することになる。
例えば、セキュリティリスクで、個人情報が流出したということがあったら、それをいち早くチェックしたり、改善していくことを考えてもらう人材を充てていく。責任の移譲をしたい人がいるかいないかという話かなと。結果、その人のスキルや意識が足りなくて降格したりするときに、納得感を持って降りれるか、交代できるかというのは一番重要です。
矢部：CTOを受けた立場からすると、CEOから信頼されてその役割を与えてもらったと思っているので、期待には応えたいし、技術的な経営判断や事業がうまく進むために必要なことは考え続けていきたい。それがうまくできるうちはやり続けたい。でも、それができなくなったら、交代するのもやむを得ないですね。
島田：やはり肩書というよりは、責任者を明確にしたほうがいいですね。結局、人が増えると組織図が不明確になりがちで、責任者の所在がわかりにくくなる。そのためのCTOの肩書きは、責任者を明確にするという観点で意味があると思います。
吉兼：今日のお話を聞いて認識が変わりました。皆さん、本当にありがとうございました。
