エンジニアのキャリアのうち、王道とも言えるステップの1つにCTOがあります。昔と比べてエンジニアのキャリアパスは多様化していますが、今も「いつかはCTOに」と考えている方は多いのではないでしょうか。

一方で、若手エンジニアの方の中には、CTOへのあこがれはあっても、それまでにどんなキャリアや経験を積めばいいのか、明確に見えている人は少ないでしょう。そもそも、CTOになっている人のキャリアは千差万別で、「これをすればいい」というものがはっきりとあるわけではないからです。

当然ながら経営にも関与できるCTOになるには、エンジニアとしてのスキルはもちろん、組織づくりや技術的な知見なども求められます。CTOになる人材は、どのようにエンジニアのメンバー時代を過ごし、スキルを醸成してきたのでしょうか。

今回は、LINEを活用したCRM・ソーシャルログインサービスを開発する株式会社ソーシャルPLUSのCTOに就任された佐藤亮介さんに、paiza株式会社の代表取締役 片山良平が話を聞きました。かつてpaiza株式会社でいちエンジニアとして働いていた佐藤さん。彼のpaiza退職後のキャリア形成、転職先での組織づくりのエピソードなど、CTOに就任されるまでのご経験についてお話しいただきました。

株式会社ソーシャルPLUS 執行役員/CTO 佐藤亮介
福井高専、福井大学および同大学院にて情報工学を専攻。SIer、Web系スタートアップを経て2017年1月より株式会社フィードフォースに入社。開発リーダーとして「ソーシャルPLUS」のバックエンド開発に従事。分社化に伴い2021年9月より株式会社ソーシャルPLUSへ転籍。執行役員/CTOとして「ソーシャルPLUS」「CRM PLUS on LINE」の開発やチームビルディング、エンジニア採用に取り組む。

プログラミングスキルの価値を知った学生時代

片山：CTOご就任おめでとうございます！paizaも含めて、これまでに歩んできたエンジニアのキャリアについて聞いてもいいですか。

佐藤：子どもの頃からロボットやゲームが好きで、情報系の分野に興味があったので、高専から大学院まで情報工学の勉強をしていました。就活を始めたときもそのままエンジニアになるつもりでしたが、当時は今ほど自社でプロダクトやWebサービスを開発している企業は多くなかったんです。特に地方で就職するなら、SIerかその下請け企業に入るくらいしか選択肢がありませんでした。

また、就活を進める中で「どうやらSIerで上流工程に入るとプログラミングができなくなるらしい」という話を聞きまして。私はプログラミングが好きだったし、これからの世の中で価値が上がっていくスキルだと思っていたので、ひとまず受託開発企業に入社しました。ちょうどリーマンショックが起きた年で、正直言ってあまり待遇はよくなかったのですが、業界構造や開発業務の流れを学んで数年後には転職するつもりでいました。

片山：学生の頃から、プログラミングスキルに価値を感じていたんですね。

佐藤：（学生時に）動画や画像処理の研究をしていて、当時から研究室のみんなが使える動画や静止画の変換システムを開発していたんです。それで教授から「佐藤のプログラムがなかったらみんな研究できなかったよ」と言われた経験があって。みんなの役に立てた喜びと「そこまで作れる人って意外と少ないんだな」と実感したことで、学生ながら「価値が高いスキルなのかもしれない」と感じていました。

paizaを使って転職活動し、そのままpaizaのエンジニアに

片山：最初の就職先から、paizaに転職するまではどんな経緯だったんですか？

佐藤：就職後にWebプログラミングの技術に触れる機会があって、すぐに興味を感じました。そのころには自社サービスを手がける企業も増えてきていました。Webサービスはこれから伸びそうな分野だと思い、自主的にWeb開発の勉強を始めました。

それから3年くらいたって、高専時代の同級生に会ったときに、彼が東京のベンチャー企業に転職するという話になったんですよね。それで「自分もそろそろ転職しようかな」と思っていろいろ調べていた頃に、paizaと出会いました。

片山：運命の出会いですね（笑）。

佐藤：そうですよ（笑）。当時Web開発の勉強は個人でしていたのですが、業務経験はなかったから、転職活動を始めたとしても、スキルをうまく証明する術がありませんでした。でもpaizaのスキルチェックを受けたら、すぐにAランクを取得できたんです。「自分は他社でもエンジニアとして通用するレベルのプログラミングスキルがあるのかな」と思えたし、業務でプログラミングスキルを評価されることはなかったので、ちょっとうれしかったんですよね。

片山：理想的なユーザー体験をしていただいてありがとうございます！（笑）

佐藤：そのまま求人情報をながめていたときに、paizaを運営する会社の求人票があって。本当はSランクをとってから転職活動を始めようと思っていたんですけど、気軽な気持ちで応募してみたらすぐに面接日程調整の連絡が来ました。転職活動をしようとは思っていたので、Sランク取得を待たずに選考を受けてみたら、めでたく入社に至りました。

paizaで知った受託と自社開発の違い

片山：paizaに入社して、最初はどんな仕事をされていたんでしたっけ？

佐藤：主に求人を掲載している企業側が使う、バックエンド機能の開発ですね。スカウト機能とか、ユーザー属性の検索機能とか。今、ソーシャルPLUSの採用活動でもpaizaを使っているんですけど、自分が作った機能をユーザーとして使うのは感慨深いものがあります（笑）。

片山：ご利用ありがとうございます（笑）。初めてpaizaに転職して、前職と比べてギャップやカルチャーショックを受けたことはありましたか。

佐藤：前職は受託開発だったので、仕事は自動的に与えられるものだったんですけど、paizaでは、まず「何をすべきか」から自分で考えなければならない。それが最初にぶつかった壁ですね。前職ではあまり考える必要がなかったことでしたから。

片山：自分で考えてやった仕事で、何かうまくいった思い出ってありますか？

佐藤：プラチナスカウト機能の開発ですね。企業側に「どんな機能がほしいですか」とアンケートをとって、希望が多かった機能を作ったりして。採用担当者の方に使ってもらうと、明らかに使う前よりも求人応募率が上がっていました。採用活動に慣れていない人からすると、スカウトって利用するハードルが高いと思うので、スカウトメールのテンプレを公開したり、プロセスを簡単にしたりして、とにかくユーザーがもっと便利に使えるように改善していきました。

組織づくりができる企業を目指し二度目の転職

片山：そこから、どうしてpaizaを辞めて転職しようという気持ちになったんですか？（笑）

佐藤：それも聞かれるんですね（笑）。一番大きかったのは、当時の事業的な戦略と、自分のやりたいことにギャップを感じたからです。当時のpaizaはとにかく集客に力を入れていましたよね。集客コンテンツの企画や制作ができる人を採用して、組織を大きくしようとしていたじゃないですか。もちろんサービスにおいて集客は大事ですが、エンジニアの仕事とはマッチしにくいというか。開発業務って1年、2年と積み上げていくことで成果が出る側面もあって、集客重視の戦略上は、短いスパンでの評価につながりづらいんですよね。それで「自分はもっとエンジニアの組織づくりに注力している企業に転職したほうがいいのかも」と感じるようになりました。

片山：当時のpaizaのフェーズと、佐藤さんの考えがマッチしなくなっていったんですね。次の転職先は、どんな観点で探したんですか？

佐藤：まずCTOがいて、エンジニアの育成を重視しているところですね。ソーシャルPLUSには、今もしっかりコードレビューをしあう文化があって、それはすごくいいなと思っています。paizaに入った当時はエンジニア組織ができたてだったこともあって、自分のコードに対して「本当にこれで大丈夫なのだろうか」と感じる場面も多かったので。技術的な相談ができるポジションの人がいて、エンジニアの組織をしっかり作っているところに行きたいと思っていました。

事業内容は、paizaで企業向けのバックエンド機能が改善できた経験から、B2Bのサービスを中心に見ていました。

片山：paizaでは、開発チームのメンバーとしては一人目の社員でしたもんね。転職されたフィードフォース（※現在所属するソーシャルPLUSはフィードフォースから分社化したグループ会社）では、どんな仕事をしていたんですか？

佐藤：現職ではRuby on Rails をメインで使って開発していて、特に転職当時は社内にWebアプリの設計やDBチューニングが得意なエンジニアが少なかったため、そのあたりを主に担当していました。最初はDBのアラートが毎日飛んでいる状態でしたが、新機能を開発する傍らで少しずつ直していき、一年後にはアラートが飛ばない状態にまでもっていけました。paiza 時代に培った Rails のベストプラクティスも役に立ったと思います。

エンジニア側にもっとビジネス視点が必要だと感じた

片山：逆にpaizaとの違いを感じたり、最初のイメージとのギャップを感じたことってありましたか？

佐藤：エンジニア中心の組織だからこそ逆に難しいなと思ったのは、ビジネスサイドとエンジニアサイドとの関係ですね。エンジニアの意思が尊重されるのはいいことな反面、ビジネスサイドの人が言いたいことを言い切れなくなるとか、何か問題を感じてもそれをうまく伝えられなくなるリスクもはらんでいます。エンジニアがもっとビジネス視点を持てば、そういった懸念もなくなり、よりよい組織にできるのではないかと感じていました。当時はビジネスとエンジニアの間に立てる人があまりいない状態でしたから、私が意識的にバランスをとりながら間に立つようにしていました。

事業がうまく回らなければサービスは終わってしまうし、エンジニアの給与も出せなくなっちゃうわけですから、継続的な収益は意識する必要があります。paizaでそのあたりの感覚はかなりきたえられました。もちろん、私がそういったポジションに立ったことで摩擦も生じましたが……。

片山：そうなんだ、どんな摩擦ですか？

佐藤：例えば何かを決めるときに、エンジニアの人数が多いと、意見が分かれたときに全員から合意をとるのは難しいですよね。どうすれば合理的かという観点で決めていったのですが、そうすると、まだ実績の少ない新しい技術はどうしても採用されづらくなりがちです。そういうことが1回、2回じゃなくて継続的にあると、フラストレーションが溜まるメンバーも出てくるでしょう。特に転職してすぐの頃は、リーダーでもないのにいろいろ口を出してくるやつになってしまっていたので、急にそんなやつに「もっとビジネス的な視点を加味しようぜ」って今までと違うことを言われたら、もとからいたメンバーもうれしくはないですよね。

まずは、みんなから「こいつの言うことは間違ってないんだ」と思ってもらえる仕事をしていかないといけないし、エンジニア側にもビジネス側にも信頼してもらわないといけない。開発リーダーに就任するまではその状態が続いていたので、正直言って大変でしたね。自分より若手のエンジニアと衝突してしまうのもつらかったです。

片山：paizaでは若手なほうでしたもんね。

佐藤：今までは自分が若手側だったのが、転職してからは若手メンバーに説明する機会がかなり増えました。今ではだいぶ慣れましたけど、最初は自分の知識や経験から「これはこうしちゃいけないな」って感覚的にやっていたことも、急に全部言語化しないといけなくなってしまって。そこでうまく言語化できなければ、みんなにわかってもらえない、納得してもらえないという場面も多くて、苦労しましたね。

片山：そこまで苦労しながら、正式にリーダーになる前からある意味リーダー的な動きまで担っていたモチベーションってどこにあったんですか？

佐藤：転職して一年くらいは特にそういった動きはしていなかったんですが、振り返ったときに「プロダクトがこの一年であまり成長できていない」と思ったんです。paizaにいた頃は、分かりやすく事業が変わっていくフェーズだったので、特に意識しなくても「この一年で何をやったか」が明確でした。一方、当時のソーシャルPLUSは、エンジニア個人はがんばっていても、チームとしてベクトルをそろえるということをしていなかった。そのせいで、プロダクトとしてどう成長したのか、チームが目指している方向に正しく進めているのかの実感が得られていませんでした。これはどうしたらいいのだろうと改めて組織を見回してみて、さきほど話したようなエンジニアのビジネス視点の課題に行き着いたという流れです。2年目からは、そこをどう改善していけばいいかという観点で動くようにしました。

片山：具体的には、どんな取り組みをしたんですか？

佐藤：その頃、仕様の落とし所が決まらないまま半年くらい頓挫していた新機能がありまして。難しい機能の落とし所って、全員の合意をとるのはまず不可能ですよね。誰かが主導して方向性を決めないと進まないし、いったんリリースしてユーザーの反応を見てから改善すればいいんじゃないかと思って。私が先導して、最小限でリリースしないといけない部分を決めて、2、3ヶ月でリリースまで持っていきました。

片山：そういう動きをしていったことで、開発チームのリーダーになられたんですね。

佐藤：ビジネスサイドのプロダクトオーナーも、やっぱり半年間頓挫していた機能がリリースされたことを高く評価してくれたみたいです。それで、入社して3年目で正式に開発チームのリーダーに就任しました。それからしばらくしてフィードフォースが上場し、ソーシャルPLUSが分社化することになりました。

CTOへのキャリアを意識しはじめたきっかけ

片山：CTOを意識したきっかけやタイミングってあったんですか？

佐藤：フィードフォースはもともと会社の中で複数のプロダクトを抱えていたのですが、技術的な領域はプロダクトごとに異なっていたんですよね。それで、一貫して技術を見るようなCTOは置かずに、それぞれにリーダーやマネジャーを置いて、何かあれば彼らに相談するという組織構成に変更になったんです。もともとCTOだった人も退職されたんですが、組織構成が変わったことで、逆に「CTOがいないと意思決定ができない場面が結構あるぞ？」と気付かされたんですよね。例えば課題の解像度が低いときとか、売り上げにもとづいて予算を決めるときとかって、経営に近いポジションで判断できる人がいないと難しいじゃないですか。経営にかかわらないメンバーだけだと、判断に対する責任をとることもできないですし。だったら私がCTOとして、そういった判断をできたらいいなと思うようになりました。

片山：やっぱり上場や分社化のタイミングがターニングポイントなんですかね。

佐藤：あとは、一度いろいろな企業を見るために転職活動をしたり、他社の人の話を聞きに行ったりしていた時期があったんですよね。それでわかったのが、それなりに開発経験があれば、他社に転職したとしても、日々の業務に大きな違いはない。ただ組織設計やビジネス面は、企業によってかなり違いがある、ということなんです。それで、自分も今後は組織全体に影響を及ぼせるレベルのスキルを身につけないと、キャリアアップできないなと思いました。そうそう、その時期に升水さん（※paizaの取締役）とも会って話したんですよ。

片山：そうなんだ。どんな話をしたんですか？

佐藤：私が辞めたあとにシステムトラブルが起きたことがあったそうで、「昔はとにかく売り上げにコミットしがちだったけど、もっと技術面でもバランスをとっていかなければならないと気づいた」って話をされました。私は逆に、エンジニアも技術だけではなくビジネスを理解する必要があると感じるようになっていたんですが。

片山：すごい、時を経て歩み寄ってますね（笑）。

佐藤：そうなんですよね（笑）。「日本のスタートアップが増え始めた頃って、経営者も組織の作り方やエンジニアの関わり方をわかっていなかったから衝突も多かった。でも最近はみんなの知見が増えてきて、お互いがわかりあえるようになってきた」という話も聞きました。私みたいなエンジニアが経営に入ろうとすると、新しい考え、新しい価値が生まれるかもしれない。そういった世の中の潮流が動き始めたところでCTOになれたのは、いいタイミングだったと思います。

片山：CTOになると、実際にコードを書いて開発する場面がほとんどなくなるかと思いますが、それに対する恐怖心とかはないんでしょうか。現場で開発する業務がしたくなるときってないですか。

佐藤：もちろん今でもコードを書くのは好きで、今も平日の空いた時間や休日にはコードを書いています。

一方で、サービスの成長速度をあげるためには、開発組織を大きくしなければなりません。設計や開発にしても、いつまでも自分が担当するのではなく、チームへ移譲していったほうがいいと考えています。また、チームの育成も必要なので、他のエンジニアとペアで新機能を設計したりコードレビューしたりすることにも注力しています。もともと設計が好きなので、プログラムを作る仕事と同じように新しい組織の構造を作る仕事にもおもしろみを感じていますし、新たな挑戦だと思って取り組んでいます。

片山：実際にCTOになれたのは、どういう点が評価されたのだと思いますか？

佐藤：先にお話しした半年頓挫していた機能を担当したときから、抽象的な要件を具体化して、サービス全体への影響を考慮しながら要件定義に落とし込んで、基本設計レベルに分解するという働きをしていたことですかね。それまでは、広い範囲への影響を考慮しつつ、要件を分解して落とし込めるような人が社内にあまりいませんでしたから。他にもチームマネジメント、スクラム開発の進行、プロダクトへのコミットメントなどが評価につながったのではないかと思っています。

あとはソーシャルPLUSが分社化するにあたって、採用を強化できたこともあると思います。早くエンジニアを増やさないと、今後の開発が追いつかなくなってしまう状態だったのですが、無事に目標の人数を採用できました。

片山：それはすごいですね！エンジニア採用がうまくいった要因って、どこにあったんでしょうか？

佐藤：私自身が採用に対して関わる領域を増やしたのが大きいと思います。基本的に採用活動って、人事の人が中心になって求人票を作ったり、スカウトを送ったりしますよね。一方でエンジニアは急に面接に参加させられたりして、早い段階から主体的にかかわる場面があまり多くない。だから、まずは求人票作りから入っていったり、リファラルで知り合いに声をかけまくったりして、今までよりも採用活動への関わりを増やしていきました。また、今まであまり採用に関わっていなかったエンジニアたちに面接へ出てもらう場合は、採用プロセスやノウハウなどの情報を共有しました。あと、今までエンジニア採用は正社員だけだったのですが、正社員にこだわらず業務委託でも求人を募集したことで、アプローチできる求職者のプールが広がりましたね。

技術の土台を築いたあとでその先のキャリアを考えればいい

片山：最後に、いずれはリーダーやCTOになりたいと思っているエンジニアの方に対して、意識するとよいことや、仕事との向き合い方などのアドバイスをいただけますか。

佐藤：まず、エンジニアとして基礎の技術は大事にしたほうがいいと思います。普遍的な技術を身につけないままだと、ちょっと難しい課題にあたったときに、メンバーに展開できないですから。自分で手を動かす機会が減っても、基礎となる技術の知識がなければ、サービスの設計や要件の展開、そして技術的な正しい判断ができません。

また、人とつながるのが好きな人は、フロントエンドとバックエンド、ビジネスとエンジニアみたいな感じで、チーム同士の間に立って、人と人をつなげるハブみたいな動きを早くからしてみてください。

基本的にひとつの分野で100点をとりたい人は、無理にリーダーのポジションを目指さずに、スペシャリストに進んだほうがよいと考えてます。私自身は、ひとつで100点を目指すよりも、いくつかの分野で80点をとるスキルの伸ばし方のほうが得意なのですが、同じような人はリーダーやCTOに向いているかもしれません。若いエンジニアのみなさんは、まずは目の前の業務に一生懸命取り組んで、基礎的な知識を身につけながら、自分がどちらのタイプか考えてみるのがよいかと思います。