テクノロジーカンパニーにおいてCTOの果たす役割は重要で、企業の成長段階や規模、業態によってその任務は様々です。
前編に続き、今回はラクスルの取締役CTO泉雄介氏、Wantedly 取締役CTOの川崎禎紀氏、メドレー取締役CTOの平山宗介氏、空 取締役 CPOの田仲紘典氏に、「CTOとVPoEの役割の違い」「技術選定をどこまで現場に任せているか」などについて、語り合っていただきました。
今回の現役CTOメンバーは？
TECH PLAY プロデューサー 鳴釜優子
──今回、今後の成長のためにぜひCTOを採用したいというAzitさんから、CTOの業務内容や課題についてディスカッションしてみたいというご要望をいただき、皆さんにお集まりいただきました。まずは、皆さんの自己紹介をお願いします。
Azit・吉兼：Azitは2013年に創立した会社で、2015年からは「CREW」というモビリティプラットフォームを開発・運営しています。半年前くらいまでは、テックリードの十亀がAndroidからiOS、サーバーまで全部一人で開発していたのですが、エンジニアチームは5人に増え、今後もさらに強化していきたいと考えています。
今後はCTOを採用したいので、CTOやVPoEの肩書・ロール・ミッションをどうしていくべきか、皆さんのお話を聞いて考えていきたいと思っています。
▲株式会社Azit 代表取締役CEO 吉兼 周優氏
Azit・十亀：吉兼と会社を起ち上げ、現在はテックリードをやっています。サーバーサイドエンジニアです。創業後2年半くらい、エンジニアは自分一人だけでしたが、最近5人に増えました。迅速な意志決定をしながら、強力かつ柔軟に動けるエンジニアの組織作りや技術選定などについて、いろいろ皆さんのお話を聞かせてください。
▲株式会社Azit テックリード 十亀 眞怜氏
ラクスル・泉：ラクスルの取締役CTO、ハコベル事業本部長をしています。ラクスルの事業内容は印刷・広告のシェアリングプラットフォーム、ハコベルは荷主と運送会社をつなぐシェアリングプラットフォームです。2019年の1月末時点では組織全体で241名、エンジニアは総合職の約4割です。
ちょうど今、自分の時間の使い方を整理しようと、1時間単位のマトリックスで記録していたので、今日の座談会は良いタイミングでした。
▲ラクスル株式会社 取締役CTO ハコベル事業本部長 泉 雄介氏
Wantedly・川崎：肩書は取締役CTOです。基本的には技術側で、エンジニアリング組織のマネジメントをやっていますが、人事、デザインや編集チームも見ています。事業としては、ビジネスSNSプラットフォーム「Wantedly」にて、会社訪問サービス「Wantedly Visit」、つながり管理アプリ「Wantedly People」などのサービスを提供しています。
最近は「Wantedly Visit」の海外展開が進んでいるので、日本国内は従業員数100人ですが、グローバルだと120人くらい。エンジニア・デザイナーで約40人。4月に新卒が入ってきたら50人くらいの体制になります。
▲ウォンテッドリー株式会社 取締役CTO 川崎 禎紀氏
メドレー・平山：メドレーは創業10年目の医療系IT企業です。医療介護系の人材採用システム「ジョブメドレー」が事業の柱です。この事業を基盤に、3年ほど前からスマホで医師の診察が受けられるオンライン診療システム「CLINICS」や、直近ではクラウド型の電子カルテ「CLINICSカルテ」などの新規事業も立ち上げ、それぞれ展開しています。
私は取締役CTO、開発本部長という肩書きで、プロダクト開発全般の部署を見ています。会社は従業員約300名で、うちエンジニア・デザイナーは30名くらい。特徴的なのは、20代より30代後半から40代が多いことです。
▲株式会社メドレー 取締役CTO 平山 宗介氏
空・田仲：空は現在メンバー25名ほどのスタートアップです。エンジニア・データサイエンティスト・企画・デザイナーの組織体で11人。「MagicPrice」という価格最適化のプラットフォームを提供し、現在はホテルの客室料金設定が可能になるレベニューマネジメントサービスを行っています。
私の肩書きは取締役「CPO」。つまりプロダクト責任者で、実質的にCTOとVPoEの両方を担っています。
▲株式会社空 CPO 取締役兼エンジニア 田仲 紘典氏
CTOとしてのミッションや役割は？
──次は、皆さんのミッションについて教えてください。
川崎：4年前から「Wantedly Visit」にはエンジニアリングリードがいて、「Wantedly People」を立ち上げるときにも別のエンジニアリングリードが入り、プロダクトは自分の手から、直接は離れています。それぞれのリードがレポートしてくれるので、細かいプロダクトの戦略にCTOが口をはさまさない体制になっています。
自分が今プライマリーに責任を持っているのは、組織そのものや技術戦略、デザイン、会社のブランド向上など。会社の力を底上げしていくことがミッションです。
泉：その時のフェーズによって、CTOとしてやることは変わってきています。エンジニアの人数がまだ8～9名くらいだった入社当時は、インフラ・セキュリティなどのディフェンス周りを担当。それが引き渡せるようなチームを作ってからは、プロダクト側を見ていくようになりました。今は技術的な課題や技術負債の解消に取り組み、それを会社の強みにしていこうと考えています。
1年前にヤマト運輸と資本提携するタイミングで、ハコベルの事業も見るようになりました。ゼロイチからプロダクトを見て、課題整理やチーム作りなどに関わり、サービスリリースしてからは事業全体を見ています。リリースまでは私もコーディングやデプロイもしていました。今は業務の中心はエンジニア採用になっています。
十亀：皆さんの会社に、VPoE的な役割を担う人はいるんでしょうか？
泉：エンジニア組織が現在50人、マネージャーが5名います。そこに評価やレポートラインもつけています。エンジニアリングマネージャーとテックリードが各スクラムチームに1人いて、VPoEの役割を分担して担っています。こうした体制を今年2月に作りました。
平山：CTO室やVPoEはいないですね。社内には自走できるエンジニアが多いので、あまりがちがちに組織マネジメントはしていないんです。当社の場合、他社のプロダクト開発と概念が少し違うかもしれません。
まず会社の哲学ありきで、それを実現するプロダクトがある。それを拡大するための営業戦略があって、コンプライアンスがある。事業の性格上、官公庁や医師会とのやりとりなどもあります。
医療者と私たち開発者の関係が良くないといいプロダクトができないので、カスタマーサクセス面も重要です。プロダクト改善は企業の哲学を実現するために行うものですから、メンバーのメンタルマネジメントもきちんとしないとスケールできないと考えています。
田仲：肩書きはCPOですが、CTOとVPoEの両方を私が担当しています。CPOという役職名がついているのは私だけで、エンジニアメンバーはインフラやフロントエンドなど、それぞれの強みを活かした開発をしています。
私は大学時代からセキュリティやネットワークが専門分野なので、先導して作っています。ただ、デザイナーやエンジニア、データサイエンティストに対しては、フォロワーで「何かあったら責任とるから」と言って、各自進めてもらっています。
技術選定は現場任せがいいのか、CTOがジャッジすべきなのか
──では、皆さんに描いてもらったCTOとしての業務内容と時間的な割合の円グラフについて、それぞれご説明いただきたいと思います。
田仲：昔はプロダクト開発が100％占めていたんですが、今はその比率がかなり減りました。現状はプロダクト開発10％、組織開発40％、採用40％、外部露出2％、その他8％ですね。組織開発は最初からずっとやっていること。レベルの高いメンバーたちとコミュニケーションを取るために、1on1に力を入れています。
エンジニア、デザイナー、企画、データサイエンティスト11人全員に対して、2週間に一回ずつ。私自身がデザイン畑でなくても、デザイナーとの1on1はできます。悩みの相談に乗ったり、将来何を目指したいのかという話をよくしますね。直近多くなっているのは採用業務です。
技術選択は、最終ジャッジには関わります。基本的な考え方としては、社内一人しかできないような技術は選定しない。社内で最低限3～4人くらい使えないと導入していません。さらにその技術を選択することで、それが顧客に対する業務の生産性向上につながるかという視点も大事です。
だから、Go言語は採用していませんが、Reactは導入しています。Reactはエンジニアとデザイナーで勉強会をしたりして、使えるようになってからプロダクトインしました。
川崎：言語もそうですが、どういうアーキテクチャを選ぶのかということも、CTOの重要な判断になりますね。どうアーキテクトしていくか、その中の要素技術として例えばデータストレージはどうするか、メッセージキューはどうするんだっけとか、考えなくちゃいけないことがたくさんある。
常にサービスやプロダクトを伸ばしていくためにどうするかという視点から考えます。最近だと、MLOps（機械学習基盤）にもっと投資するべきだよね、というような話が社内では出て、昨年から取り組んでいます。
泉：未来の事業価値をどういう技術で作るのか、その技術を選定することで、製品やサービスにはどういう効果があり、どういう将来像が描けるのか。それを一つのストーリーとして語ることが技術選定の意味だと思いますね。
平山：私の業務割合をいうと、プロダクト、事業（プロダクト以外）、組織（ブランディング、広報、採用）がそれぞれ3分の1といったところでしょうか。自分としては、あくまでもプロダクトが根幹にあって、それを成功させるためには事業や組織に関しても自分がやらなければならないと考えています。最終的なカスタマーサクセスのために会社全体はもちろん、個々の組織に対してまでテクノロジーを浸透させることが、自分が考えるCTOの役割だと思います。
医療分野のテクノロジーって、レガシーな部分が結構あるんですよ。その中でアップデートが必要な部分を現在のITレベルにまで引き上げるためには、やはりテクノロジーの力が必須。それがメドレーのプロダクトを成長させるためにも絶対必要だと思って取り組んでいます。
だから、自分はCTOだけど、プロダクト開発業務がメインになるんですね。本当はクライアントの前できっちりスーツを着ながらも、コードが書けるギークでもあるという人材が欲しいんですが、なかなかいない。そういう人を採るためにも、組織のブランティングを変えていかなくてはいけないと思います。
吉兼：でも、実際そういうことできるエンジニアは少ないですよね。若いエンジニアはGoogleナイズされているというか、アンチスーツみたいな文化がありますよね。
平山：業界全体のエンジニアに対するコンセンサスを変えていかないといけないと思います。スーツを着ながらもギークであるのがかっこいいというエンジニア像を業界として打ち出していかなければ。
メドレーの場合、ITコンサルファームから一度Webベンチャーに行って、それから当社にジョインしてくる人が多いですね。今後はSIer出身の人を半分採って、Web系の人を半分採って、育成をしながら組織をうまく作っていこうと考えています。バランスをとるのは難しいけれど、今こういう論調がないこと自体が問題だと思っています。
自ら技術開発を担う割合と、経営やマネジメントに徹する割合
川崎：私の業務を細分化すると、採用活動20％、デザイン・編集10％、技術戦略・インフラ基盤10％、経営会議・取締役会10％、海外事業10％、組織開発20％、情報発信20％と、なります。これは、直近1週間の実績です。
採用活動は最初の面談から出ることもあれば、クロージングで会食することもある。採用チームが強くなってきたのと各チームのリーダーたちの協力があるので、以前に比べれば採用活動の割合は減りました。
Wantedlyには「1on1を大切にしながら、組織開発を進める」というカルチャーが、創業当初からありました。トライブとスクワッドという社内用語があって、スクワッドというのは最小の組織ユニットのこと。3～8人くらいで一つのミッションを持っています。スクワッドの集合体がトライブ。トライブは固定的ですが、スクワッドは流動的で四半期で組織が入れ替わったりします。
自分が直接見ているスクワッドはデザイナー・編集と、インフラ開発基盤。新しく入ってきた人については、1on1を3カ月間毎週やります。トライブのリーダーとも毎週1on1で話すし、スクワッドのリーダーとも月に1回は話すようにしています。週に15人くらい1on1している計算になりますね。時間は一人につき30分程度。1回の時間より頻度の方が重要だと思っています。
他にも、海外メンバー全員と話す月一回のカンファレンスコールがあったり、日本にいながら海外向けの開発をやっている外国人エンジニアと話す機会も多いです。
泉：私の場合は、ハコベル事業開発10％、ハコベル開発25％、その他（定例・開発ミーティング、会食など）、採用（登壇・スカウト・面接・ブランディング）19％、組織マネジメント20％、2月の実績はこんなかんじでした。
組織マネジメントではやはりメンバーと話すことが重要。その対象や機会をもっと増やして、メンバーの考え方がプロダクト全体に染み渡るような、そんな組織を作りたいですね。
ハコベル事業開発ではお客さんのところに行って、物流の課題を聞いたりする時間も含まれます。他に、経営会議、承認など企業ガバナンス系のミーティングもありますが、それはその他のところに入れました。
十亀：Azitのテックリードとしての私の業務割合は、組織開発40％、プロダクト20％、技術キャッチアップ10％、採用20％、技術広報10％。チームが1人から5人に増えたので、組織開発のために割く時間が増えました。プロダクトチームがどう動いていくのかが固まったら、この時間は減らしていけると思います。
私自身はプログラミングが好きなので、その時間をもっと増やしたいですね。ただ、あまりにも大きいタスクに携わると、バグが出たけど修正は誰かに任せるといった不誠実なことになってしまうので、現在は単発で処理できる範囲でやっています。現状では、技術キャッチアップに10％しかとれていない。技術選定の判断はどうすれば良いのか悩んでいるところです。
泉：組織開発には、どういう行動が入っていますか。
十亀：メンバーの技術・スキルの強み、最適なチーム構成などを考慮しながら、組織全体の長期的な展望や設計を考える仕事ですね。現在は私がマネジメントしているメンバーが3名いて、彼らとの1on1を週次で1時間くらいやっています。
プロダクトチームは20代が多く、会社全体でも平均年齢30歳前後。だからこそ、1on1は時間をちゃんととった方がいいと思っています。今後は生産性を上げるためのスクラムを回していきたい。CS部門から上がってくる不具合や要望への対応、事業のマイルストーンとのバランスをとる戦略とか、考えなくてはいけないことが山積みです。
泉：組織全体の設計、メンタリング、育成…。チームが主体的に動くための組織開発ですかね。結構なウエイトを占めていたので、ちょっと気になって(笑)。
十亀：そうですね。もう少し減らして現場に近いところを増やしたいです。
川崎：とはいえ、会社の成長フェーズごとに、あるいはプロジェクト単位でも、プロダクト開発のやり方や、組織の作り方は変わり続けるので、まったくなくなることはないですよね。小さいプロダクトをたくさん作って、できることを何でもやるフェーズと、6カ月かけてアプリをリニューアルするから、そこはスクラムで回していこうというフェーズとか。
「プロジェクトのスコープ・サイズ・人数・メンバーの好みに応じて、やり方は変えていいんだよ」というメッセージを出したいですね。その代わり、絶えず方法を見直しながら自分たちで良くしていってほしいと。5人のチームが3つあったとしたら、それぞれ違ってもいいんだよというメッセージの方が僕は好きです。
起きていない技術課題に対する心配は必要ない
──Azitさんの技術調査は、どんなスタンス・手法でやっていますか。
十亀：うちはAWSにRailsを載せています。事業の戦略や見通しから、GKEの上にGoで認証基盤を切り出そうとプロジェクトを進めています。RubyからGoに変える言語選定や、Web技術が発展してきている中で、ネイティブアプリで進めていいのだろうかとか、一時盛り上がったにもかかわらず、1年後にはほぼ誰にも使われていない技術も多い中、どう考えるか。そもそも技術調査は現場に任せた方がいいのか、自分で考えた方がいいのか、そのバランスに悩んでいるところです。
川崎：どの時間軸で考えるかが影響すると思いますよ。会社自体、サービス自体がなくなる可能性もある。売上ゼロの時期に5年後のことを考えてもしょうがない。1年ぐらいのスパンで、プロダクトや事業が当たるためにはどうするか、それに必要な最短・最適な技術を選定するしかないですよね。
ちなみに、Azitさんは社会インフラ的な事業だから、長期的なスパンでの技術選定が必要になったりするのでしょうか。
十亀：的外れなフォーカスをしているかもしれないのですが、基盤つくらなきゃとなったときに、残り1カ月で作り上げなくてはとなるとキツイ。どのくらいのスパンまで見据えておくべきなのか、まだわかっていないんですね。
平山：事業戦略やプロダクト開発において、意思決定の根幹に関わるような技術選定ならともかく、そういった影響を受けないのに技術をどうしようと考え続けるのは、時間がもったいないと思っています。
メドレーでは、どういった言語やライブラリを使うか？といった細かい判断は、基本的には現場任せにしています。CTOとしては、事業の成長を止めかねないような技術負債が積まれていないかを見ていく必要があると考えています。この技術を採用したら、この事業がすごく伸びるということであればCTOが考えていいけど、そうでないのならあまり考えすぎなくてもいいと思います。
川崎：あとは攻めたいのかどうかですね。その技術を選んだことで事業やプロダクトで優位性が出るなら賭けてみるとか、その技術を自分たちが日本に広める、海外に広げるという覚悟があるならやればいい。
うまくいけば採用も強くなるし、他と差別化もできる。「RubyとGoで開発してます」はいろんな会社がやっているので、それだけでは技術的な差別化は難しい。採用ブランドのために、「この技術に投資している」というメッセージを出してみるという選択もありだと思います。
泉：自分も川崎さんがさっき言っていた、最新技術がどうこうよりも「現時点の戦力で最速でできるものを選ぶ」というのが正解かなと思います。
技術選定は、テックアプライの会社なのか、テックイノベーティングの会社なのかでも変わってくるようにも思います。Googleのようなテックイノベーティングで、技術のための技術（Tech for Tech）開発そのものが事業戦略のような会社だったら、技術を攻めていかないといけないですが。
吉兼：将来を考えたときに、「テクノロジーに投資する会社です」と言うだけではパラダイムシフトは起きない。それまでに、技術に対するスタンスやカルチャーをどう作っていくのかが悩みどころです。それがどういうメンバーを集めていくのかにも関係してくる気もしています。
泉：いま僕らは、配送ドライバー向けのアプリを作っているんですが、常時1万人のドライバーが繋がったら落ちるけど、それはパンクしそうになってから考えればいいというスタンスですね。
Jeff DeanというGoogleのアーキテクトが言っている「1000のオーダーで何か変わる時はアーキテクチャを一回見直せばいい」という言葉があります。そこまで到達するまで、何か不都合が生じるまで別に今のままでいいじゃないでしょうか。まだ問題も起きていないのに、技術投資とか技術開発するって、起きていない課題に対しての心配しすぎかも。
技術はレイヤーによって変化するスパンが違いますよね。インフラ部分だったら30年くらい、カーネルレベルだと10年単位でほとんど変わりません。ミドルとかも10年スパン。MySQLを学んでおけば10年、20年は使える。サーバーサイドも割とゆっくり。でも、フロントエンドはネイティブアプリも含めて早い。だから技術選定は、どこのレイヤーの話をしているのかにもよると思います。
川崎：プロダクトが価値を出し続けていったら、大きくリニューアルするタイミングが絶対来ます。うちも3年経ったのでリニューアルしましょうと、6カ月かけてアプリをアーキテクチャやライブラリも含めて、全部リニューアルしました。プロダクトに価値が生まれてくれば、投資できる余力が何年かしたら出てくるはず。だから今は価値を出すほうに振っておけば安心です。
最新の技術を使うことだけがクールではない
吉兼：ところで、創業期から僕はプロダクトマネージャーやUIデザインを担当してきました。もちろん、技術的な基盤を強固にしていくことはスケールしていくための大前提として必要な上で、ユーザー体験をよくすることと最新の技術を使うことに一定の乖離が生じているとも思います。このあたりのバランスの取り方はみなさんどのように進めていますか？
川崎：最新の技術を使うことだけがクールではない、とわかってもらうことが大事ですね。
平山：最新技術がクールだという風潮になりがちな、業界自体の文化も変えてくべきなんですよね。
川崎：必ずしも、みんなが最新技術だけをクールだと思っているわけではないんですよね。最新技術自体が価値でなく、プロダクトで価値を出すことが大切だと思っている人は少なくない。Azitさんもそういう発信をして、そういう人を採ればいい。
平山：最新技術ばかりに目が行く人を採用していると、開発組織が弱くなってしまうような気がします。その人がその最新技術自体を作っているなら別ですが、どこかで作られたものを知っていることが、最新技術を知っている事とイコールになってしまうのは、違うように思います。
川崎：最新だから良いわけでもないし、最新だからダメということでもないんです。例えば、さっきDockerの話が出てましたけど、うちはKubernetesもかなり早い段階から本番に入れている。それこそGCP東京リージョンが来る前から使っていたので、自分たちでAWS上にクラスタを作って運用していました。まさに“いばらの道”でしたけれど。
でも、それをやった理由はちゃんとあって、これから先、新しい事業やプロダクトを増やしていくときにいろんなものをのせていくため、リリースまでの時間を短縮し、リーンに高速な仮説検証を繰り返すための環境が必要だと判断したんです。
それまでは新しいAPIサービスを作るのにインフラチームの作業が必要で、それに1日くらいかかっていたのを、Kubernetesクラスタを作ったことで、1時間以内に新しいサービスが出せるようになった。問題があったから、方針があったから、そこに投資すると決めた。新しいから、好きだからというだけで使ったというのではないですね。
十亀：このインフラをこの技術に変えたらもっと早く出せるんじゃないかなど、変えるほどの強い確信があるかどうか、自分の中で判断がつかないことがあるんです。でも1日くらいしか変わらないなら、このままでもいいかもしれないとも思ったりします。そうした葛藤を続けている間に、気がついたら取り残されていたら怖いなと。
平山：そのあたりはもう芸風の問題じゃないですか(笑)。ここにいるみんなも最新の技術トレンドを押さえていないわけじゃないし、むしろ詳しい。でも、いい意味でその技術を信じ切ってないというか、プロダクトに必要かどうかをドライに判断しているんじゃないでしょうか。
本当はのめり込みたいことはある？
泉：僕、皆さんに聞きたいことがあります。川崎さんの業務割合で出た「好き・嫌い・得意・不得意」という話。「好き」ってことは、誰よりも早く深くできるという意味だから、それ自体、強い競争力を持つわけですよね。川崎さんが好きなら、そこを川崎さんに任せたほうが、企業としても一番バリュー出るんじゃないのかと思ったのですが、どうですか？
吉兼：CEOの立場としては、僕もそれがいいと思いますね。皆さんは役員としてのミッションも持っているようなので、そのミッションを他の役員の人が分担すれば、CTOはもっと好きなことができるようになるような気がします。
川崎：何か一つ突き抜けたところに時間を使うのは、たしかに必要かもしれないですね。
泉：「この時間こそが、本当は一番事業価値や企業価値につながるんだ」といった確信があるのか、ないのかでしょうか。
田仲：フェーズによって違うかもしれないですね。僕は今年の1月まで、開発が100％だったけど、テックリードが入ってきたので、開発現場を任せられるようになった。今は、組織を拡大したいという思いが強いので、採用や組織開発の割合を大きくしています。
泉：質問の言い方を変えると、「今これをやっているけど本当はこっちをやりたい」「こんなのムダな作業じゃないか」っていうことはありますか。
田仲：本音でいうと、1年前はプロダクト開発をずっとやっていたかったですね。でも、自分が近未来やりたいこととは、イノベーションをいかに早く起こすかということ。そのためには優秀なエンジニアの母数を増やすことが必要だった。うちに入ったら優秀なエンジニアが育っていくという環境を作りたい。だから、組織開発・採用のところを注力しています。
吉兼：自分よりそれが得意な人に「優秀なエンジニアの母数を増やす」というミッションを渡して、得意なことにフォーカスするのでよいのではないでしょうか。
田仲：10年後を見越して、プロフェッショナル領域なのかマネジメント領域なのか、どっちにいきたいのかは、自分の中で決めればいい。プロフェッショナルを突き詰めたいならその割合を大きくしていけばいい。組織開発やマネジメントは、VPoEとかに任せていけばいいと思います。
CTOが取締役になることのメリットは？
吉兼：僕から最後の質問です。CTOが取締役でもある場合、意思決定においてのメリットはどんなことがあると思いますか。また、自分の役員としての価値はどこにあるとお考えですか。
川崎：Wantedlyは取締役が3人いて、CEOもプロダクト開発に理解がある人だから、役員会も半分くらいプロダクト・テクノロジーの人で占められています。プロダクトで世の中を良くしていく会社にはテクノロジーが必要なので、プロダクトやテクノロジーがわかる人が経営を担うのは当然だと思っています。メリットというより、いない方がおかしいみたいな。
平山：取締役会は会社全体の空気を作るもの。その意味で哲学が必要ですね。例えばエンジニアが少ないから増やしたいという議論もよく出ますが、そういう時は「人月の神話」の話をしたり、「開発とは」「エンジニアとは」という概念レベルの話を僕がして、ちゃんと哲学を持ってエンジニアを採用するという空気感を他の取締役に浸透・醸成させるようにしています。なので、単純に「このテクノロジーの承認ください」っていう話はしていません。
田仲：僕も「役員にエンジニアがいるのは普通」という感覚ですね。役員にエンジニアがいることで、テックに注力していることが伝わるし、社内の人にちゃんと話ができる。CTOって、職人気質なクリエイティブの人たちに対してのハブでもあるので。
ビジネスサイドの人だけだと、プロダクトもビジネスサイド寄りの組織になってしまう。プロダクトが成長するためだけに投資をすることになる。かゆいところ、エンジニアリングでアプリケーションをこう変えたいというような声が届きにくくなってしまう。「それやる意味ある？」という話になってつぶされることになる。
Reactを導入した時は、「Reactでこういう生産性が生まれる」と説明をして通しました。役員にCTOが入っていれば、そうした声は通りやすくなります。
泉：技術の話をビジネスサイドに翻訳する、そういう役割もありますよね。エンジニアリングに出てくる原理原則は、経営に適用できる場面が結構あると思っています。人事制度や組織のデザインと、テクノロジーのアーキテクチャ作りも似てるところがあります。
──ということで、CTOのミッションや具体的な仕事内容について各社それぞれの話が展開されたと思います。吉兼さん、AzitのCTOを採用するイメージはつきましたか？
吉兼：本当に勉強になりました。これからの当社の方向性を考える上でも貴重なサジェッションをいただきました。内部昇格、外部からの採用を含めて、CTOが率いる強くかつ柔軟な組織作りを目指して頑張っていこうと思います。ありがとうございました。
