CLOSE

「憧れるのをやめましょう」3度のCTO経験から勝てるエンジニアになる秘訣を伝授(全3記事)

何でもできるはNG? CTOが語るエンジニアの成長戦略とキャリア展望

パーソルキャリア株式会社CTO兼エンジニアリング統括部エグゼクティブマネジャーの岡本邦宏氏が、CTOの役割と求められるスキルについて語りました。経営戦略とテクノロジー組織の強化を担う立場から、6000人規模の組織におけるマネジメントの実際と、年間60億円規模のIT投資を活用したマルチクラウド環境の重要性を解説。インフラ・バックエンド出身者が多いCTOの特徴や、グローバルキャリアを含めた今後のエンジニアの成長機会について提言しました。

CTOに必要なスキルとイメージ

岡本邦宏氏:この中で1個1個説明するとちょっと時間がないので、僕がCTOなのでちょっとCTOに注目して話したいと思っています。ちょっとここでまた質問です。CTOって何ができる人のイメージですか? こういうスキルを持っているとか言語化するとなると、どんな人物像でもいいので、チャットで話してもらっていいですか。



何ができる人なのですかね。実はちょっと先ほど答えのヒントをもう言っちゃったんですけど。どんな感じだと思いますか? メチャクチャ開発できる人とか、たぶん思っていると思います。実際それでもいいです。なんか適当にCTOってどんなイメージでしょうか?



正しく理解して使用するか判断ができる。あー、すばらしい。経営管理できる人。すごいですね。よくみんなわかりますね。僕が学生の頃は、そんなことはわかってなかったけどね。工程を1人で回せる。あー、はいはい。なるほど。リーダーシップ。そうですね。リーダーとリーダーシップって、似ているようで違いますからね。本当にそのとおりだと思います。リーダーシップとか。

うんうん、あー、すごい。技術をわかりやすく伝えられる人のこと。すごく大事ですね、これ。会社ってエンジニアだけじゃないので。やはり営業さんがいて、総務がいて、人事がいて、企画がいて、とみんなそうなので。開発から逸脱しても、PMやチームマネージャーでもできるような、強強な人。

でも総じてみなさんすごいですね。当たっています。僕はたぶん学生の頃はこんなふうに答えられなかったです。ちょっと言語化すると難しいんですけど、なんとなくちょっとサマってみましょうと。

経営におけるテクノロジーの戦略、これは会社の大きさにかかわらず、たぶんテクノロジーの戦略を取り入れる人。先ほど経営の参画とか、たぶん上流から下流までわかっている人。まさにこれってわかってないといけないんで。

テクノロジーの組織の強化とか醸成ですよね。文化の醸成も含めて、わかってないとできないので。だから「こういったことをやる」ってことをわかりやすく説明もできなきゃいけないし、「こういったことを掲げる」ということもやらなきゃいけないし、それをWhatからHowに落とすみたいなこともやらなきゃいけないんですよね。

なので、だいたいCTOというのは、どこへ行ってもこういうことを求められます。ちょっと黄色で書いてないところもありますけど、黄色いところは絶対に求められます。なので、今日、今僕はメッセージ性の(強い)発信を話していますけど、こういったスライドを作って、どういうふうに話そうかな、どうやったらうちのこと伝わるかな、みたいなことも当然大事ですし必要です。

ただ書いているだけなら、みなさんもたぶん1、2年ですぐ同じぐらいになれると思うんですよ。開発って、すぐなれるんです。

やはりほんとフレームワークってメチャクチャ今秀逸なので、もうシニアエンジニアも1年目エンジニアもほぼ変わらないぐらいの品質のものが実はできちゃうんですよ。そんな時に、プラスアルファで何かをやるってなるのが、たぶんCTOだったりとか先ほどのテックリーダーだったりとか、ITエンジニアリングマネージャーだったりとか、そういう要素だと思うんです。


CTOに求められるエンパワーメントとマネジメントスキル

CTOはこういう要素です。だからスキルでいうと、テクノロジー関連の投資の妥当性や、あとは下でパフォーマンスを最大化引き出すマネジメントとか。先ほどマネジメントで出ていましたよね、組織を見るとか。まさにそれです。エンパワーメントするというところですね。

600人いると、やはり正直顔と名前がわからない時があります。ただ、それをやはり働き方とかパフォーマンスを理解した上で、全員でどう伝えていくかというのも(大事です)。僕1人が600人というよりも、例えば各リーダーがいたりとか、マネージャーがいたりとか、ゼネラルマネージャーみたいな人がいるんですよね。だからそれぞれが100人、100人、100みたいなのが6個あって、そこからさらに50人、30人みたいな、どんどんどんどん階層的にピラミッドに落ちていくんですよね。

それをどう伝えていくかとかをちゃんとわかった上で連れていかないと、もうわけがわからなくなる。やはり経営って抽象度が高いので。抽象度高い話を、例えば1年目のみなさんにしても、「ハァッ?」ってなっちゃうと思うので、それをマネージャーがちゃんとわかりやすく説明するのも必要だし、僕がマネージャーに説明する時もそう。抽象度が高いけども、ここの部分だけはちゃんとポイントとして伝えてね、みたいなことをやっていくのも大事。マネジメントですもん。

6000人規模の組織におけるCTOの発信力と役割

僕は実は社内ではこんなことをやっています。エンジニアだけではなくて、ビジネスサイドの人にもやはり僕の考えを知ってもらうために、「採用こんなことやっているよー」で今600人になりましたけど、結果的にはあと「フリーランスのエンジニア活用ってこうやったらどうですか?」「パートナーってこうやって使ってチーム作っていますよ」というのを、意図的に図を使ったりとか資料を作ったりして、6,000人向けに発信をしています。



冒頭でスケジュールを伝えると、なんとなく「ああ〜、だからか」って。だからエンジニアらしくしてないのかって思ったかもしれないですけど、実はこれ自体がエンジニアの役割なんですね。僕はCTOなのでそういうことをやらないと。僕はテックリードもやれるんですけど、今はCTOの役割をたまたまやっているので、それだけです。なので、技術責任者だったら、たぶん実際プロダクトのほうにちょっと軸足を多めにするかもしれないです。

CTOの豆知識

ちょっとここでCTOの豆知識。ちょっとですね、実はですね、こないだ僕、先ほど3人か4人ぐらいで対談したって言ったじゃないですか。某大手企業のCTOとも話したし、某ユニコーンで絶対みなさんが使っているようなアプリのCTOさんとかと対談したんですよ。

その時に、僕は気づかなかったんですけど、実はエンジニアとCTOに共通することがありました。インフラ・バックエンドからスタートした人が多いんだなって。僕はもう自分のことしか知らないのでわかんないんですけど、友人のCTOに聞いてみると、「あ、確かに俺もそうだ。インフラだ」とか「俺バックエンドだわ」って。



なんでかなってちょっと考えた時に、確かにフロントとか顧客側を理解したCTOになる人が僕のイメージは多いのかなって実は思っていたんですよ。実は。ただよくよく聞いてみると、インフラが多いという理由は、小さかろうが大きかろうが、例えばエンジニア、例えばクラウドを活用する。今でこそクラウドを活用するのは当たり前ですけど、例えばネットワークの知識を知っていたりとか、もしくはクラウド活用した上でこのプロダクトを上に乗っけるフレームワークを活用したりすることは、ベースはこいつがないと駄目ですよね。

だからフロントでお客さんのことを当然考えるのも大事なのですけども。でもエンジニアならそこを作ってくれる企画がいるんだとしたら、結局エンジニアはインフラとか、いわゆるSRE的な動き、もしくはバックエンド的な、ビジネスロジックのとこも含めてなのですけど、懐(の部分)からスタートする人とか開発をする人が多いんだなという結果が、ちょっと僕の中での今回の気づきだったなと思っています。



なので、じゃあ今すぐ別にインフラとかバックエンドの勉強に取り掛かったらいいかという話じゃなくて、今、世の中って結局クラウドとかある状態なので必要ないかもしれないんですけども、ただ僕は先ほど言ったように、そのネットワークのプロトコルとかわかった上で、クラウドの設定とかパラメータ設定したほうが、やはり今いるエンジニアにも説明がわかりやすいし、なぜこのパラメータ設定しているかというのもちゃんと腹落ちしてもらわなきゃいけないんですよ。

だからこそ、社会に出ていく上で、当然顧客設定の画面だけのところで捉えがちなんだけど、その裏にいるバックエンドだったりインフラだったりのことをしっかりと初めからやっとくと、それはそれでたぶん立ち上がりも早いんじゃないかなという、僕の中での持論です。

なので、あくまでこれは僕の豆知識なので、参考にする・しないは別に自由なのでいいんですけど、そういったことも実はありましたという僕の気づきを今日言ってみました。

30コンテンツのマネジメント経験から学んだ役割の重要性

じゃあなんでできるようになったのかと(いう話をします)。ちょっと元に戻るんですけど、僕がCTOでできること一覧を(先ほどのスライドで)書きましたけど、(僕がなにを)やったかって言うと、オーストラリアから帰ってきて、株式会社サイバードという、上場している今もある会社なんですけども。30コンテンツくらい見ていたんですね。



30コンテンツって一言で言ってもアレなんですけど、例えばEXILE mobileさんとか、矢沢永吉mobileさんとか、1個1個がなんかエンターテイメントのサイトとか会社みたいなものなんですよ。だからそれ自体が1個のPLで、いわゆる売上とか利益とか、もしくはそれに対しての開発工程とか、エンジニアの採用も全部やらなきゃいけないんですもん。それを30個やっていたんですよ。30社ぐらい見ていたんですよ。

だけどほんと死ぬかと思ったんですけども、ただそれぞれが、会社が別みたいなものなのでやらざるを得なかったんですけど。それをやることによって、自分がなんの役割かというのを、ちゃんと自分がここでやらないとこの会社、1個1個の会社が回らないんだなってのがわかったので、そこの気づきが、すごくやってよかったなと思っています。

何を言いたいかというと、結局一人ひとりが自分の役割を理解した上で、会社は会社でたぶんこれからみなさん勤められると思うんですけども、その環境に合った育ち方がたぶんあると思うので、僕の今回のものを参考にしてもらってもいいですし、たぶんその(会社の)中で、育成の仕方のオンボーディングがあると思うんですよ。

なので、環境で育つので、環境を育てやすいところとか、もしくは自分が合っているなというところを選ぶのがすごく大事ってことを言いたかったのです。


マルチクラウド環境とIT投資60億円が生む成長機会

じゃあどうやって環境を選ぶのがいいのって言うと、わからんよって話だと思うんですよね。そのとおり。



じゃあちょっとこれ一例です。左側は、うちの場合は人材サービスなので、応募者さんの管理データです。で、企業さんが「この人採りたいよ」と。その真ん中にいる株式会社パーソルキャリアは、新規サービスを作るチームがいて、あとは僕のようなエンジニアのチームがいてデザイナーさんがいて、UI/UXとかサービスデザイナーもいます。



その時に、しっかりとそのサービスをローンチするだけでは駄目で、それをちゃんとしてくれる運用のエンジニアや企画者もいます。メチャクチャいます。6,000人いる会社なので。それをベースとして、会社としてのミッションとしては、目指す方向性は何かというのを定めた上で、人を集めなきゃしなきゃいけないんで、人事の人が動いてくれるみたいな(感じです)。

こういったものがいわゆる会社の組織としての役割なので、色ごとに職能、職種みたいなものを分けています。たぶんしっかりと自分の役割というのを定義してくれている会社さんとかのほうが、たぶん初めから価値発揮がしやすいんじゃないかなと思っています。

先ほど「何でも屋だったら何でも屋にしかならない」って言ったじゃないですか。それはそれでいいんですけども、ぶっちゃけると、これをやりながら複業をやればいいし、僕も複業推進の会社の4社ぐらいで技術顧問とか外部CTOやっているので、そういった考え方でもいいのかなと思っています。

なので、うちの中では35サービスもやっていて、実はマルチクラウド・マルチサービスでやっているんですね。AzureもGCPもAWSも、それこそOracle Cloudも使っています。みなさんが使う中古アプリというんですかね。名前言ったら怒られるかもしれないですけど、まぁアプリですよね。データ検索すると思うんですよ。

じゃあ中古買うとしたらだいたいもうアレが出てくると思うんですけど、そこの会社さんで言うと、僕の友人がCTOなのです。GCP、ベンダーロックインのほうが近いですよね。99.9パーセントGCPです。それはそれでいいんですけど、僕はいろいろな、例えばじゃあ先ほどのマルチクラウドはと言っている時に、それぞれの特性がやはりあると思うんですよ。

先ほどのじゃあChatGPTでやるとすると、OpenAIって言ったらAzureじゃないですか。そんな時に、そういうのをちゃんと取り入れやすい柔軟性を持っている会社とか、それを全部バックグランドで動かしているプロダクトのほうが、やはりエンジニアとしてのスキルも伸びやすいし、可能性としては自分がもうここはGCPしか使えない、AWSしか使えないってなると、それしか覚えないんで。もう個人でやる場合もありますけど。

だとすると、もうそもそも会社のケイパビリティ的にそれだけの幅があって、お金が60億、例えば毎年IT投資をやっているんですが、それだけのシリーズDを毎年やっているみたいなものだとすると、たぶんメチャクチャおもしろい(って思ってくれる人がこの中にどれだけいるかわかんないですけど)。なので、僕はこういった選び方も1個の参考になるかなと思っています。

なので、1プロダクトでも、裏側でどういうふうなアーキテクチャになっているかって(を知ること)は、すごく今後の会社選びですごく大事です。あくまで本当にフレームワークの開発のサイクルとかはHowでしかないんで、ぶっちゃけるとそれって2、3年やれば飽きちゃうんですよ。だけど、これだけサービスがあってこれだけマルチクラウドがあってマルチフレームワークがある時に、それぞれのアーキテクチャ、それぞれの時流の中での自分のライブラリ選定みたいなほうが、たぶん飽きないし成長しやすいかなと僕は思っています。そういう意味で僕も設計しています。

なので、パーソルキャリアのところで、自分たちの手前味噌で申し訳ないんですけども、自分の意思で働くことを決めていける人を今後増やしていきたいので、こういったミッションを我々は掲げています。「人々に『はたらく』を自分のものにする力を」と掲げています。


グローバルキャリアとライフイベントをサポートする制度

制度的にもいろいろあります。キャリアチャレンジって言って、グループが大きく、6万人とか10万人いる会社なので、実は日本だけに限らず、アジアに行ったりとか海外に出たりもします。僕も2年前にパーソルキャリアで初めてベトナムの開発子会社を立ち上げたりもしたんですね。10年前にも立ち上げたことあるんですけども、もうあの時とぜんぜん違うので。ベトナムはみんなスーパー優秀なのです。もう1回立ち上げようと思って、パーソルキャリアでちょっとお金を使わせてもらって、子会社を作ったりしました。

そういったグローバルキャリアチャレンジもありますし、Dritって言って、自分たちがサービス作りたいよ(と思った時に)、社内ベンチャーみたいなのを作りたいと思ったら、そういったサービスにもお金を出してくれます。

エンジニアの交換留学も当然あります。基幹システムやってみたいとか、ヘビートラフィックのビジネスヘビーなところをやってみたいとかがあれば、複業制度で(行えます)。僕もやっていますけど。そういったところもあります。

ライフイベントサポート、これメチャクチャ大事で。うちってマジで、育休とかむちゃホワイトなのですよ。僕が若い時はブラックしかなかったんですけど、今って本当に残業ほぼないから、逆に複業をしっかりやってくださいとか、そこで得た知識をこちらにまた活かしてくださいみたいなことをしっかりサイクルとして回しているので、先ほどの評価制度と共に、こういったところをメチャクチャ大事にしています。みなさん今後会社を選ばれると思うんですけど、(こういったところも)参考にしてみてください。間違いなくうちはトップクラスだと思っています。自負しています。社外からも評価されています。


マルチクラウドとマルチベンダーで育つエンジニア像

ちょっとあと5分ぐらいなので、まとめに入ります。勝てる(価値貢献)のエンジニアは、エンジニアリングに加えて、やはりビジネス視点とか広い視点を持っている人が大事かなと思っています。

2番目。その需要と供給って、やはり激しい人材サービスに限らず、産業構造はもう本当に日進月歩なので。テクノロジーもそうですね。時に、小さかろうが大きかろうが、プロダクトに関われる環境において、先ほど言ったマルチクラウドとかマルチデバイス、マルチベンダーとか、それと含めて、幅広いケイパビリティを持っている会社が、エンジニアが育ちやすいなって思っています。

ちょっと下のところは働き方なのでアレですけど、自分たちが働き方を選択できれば、それぞれ働き方というか満足度も上がると思うので、そういった意味では、そういったものを参考にしたり、評価制度だったりとか、そもそも制度として持っている(かも見てみましょう)。みなさん常にスマホ見ていると思うんですけど、このプロダクトの裏側のアーキテクチャとか、採用しているクラウドってなんだろうって見たほうがいいと思うんですよ。

そうした時に、「あ、1個だけなんだ」とか「1サービスだけなんだ」ってなると、「んー、たぶん3年で飽きるかも」みたいなところも、実は持っていてもおもしろい観点じゃないかなって僕は思うんです。

なので、冒頭に戻るんですけども、なんか憧れるのをやめましょうというのは、自分たちで切り開くというのもすごく大事かなって思っているので、そういったところの観点で考えながら就活をぜひやってみて、エンジニアになってみてくださいという、今日のまとめです。


語学力と技術力で切り開くエンジニアの可能性

まだ4分ぐらい残っているので、質問タイム。なんかあればぜひここのチャットで、答えられる範囲で答えます。時間がないので、もしアレだったら後日うちの人事が受け取って、また別途答えられると思うので。なんか(あれば)ぜひぜひ。

お、SESとか。SESですねー。いろいろな会社さんに出られるというのもいいんですけれども、やはり自分が商材、商品みたいなものなので、それがいいって思う人はいいんじゃないですか。自分たちでプロダクトを作るとか、社内で開発をしたいとか、お客さんのことを(考えて)プロダクトを作ってみたいってなると、言ってもやはりその先にいるお客さんのプロダクトなので、自社のプロダクトじゃないんですよね。そこをどう捉えるかですね。別に悪いわけじゃないと思います。僕もSESの経験、というか会社自身もやっていましたし。

「起業した時に専門的な知識はありましたか」。うーん、僕はデータベースエンジニアだったので、そこらへんは詳しかったのかなと思っています。パソコンを使った、例えばあの時高かったので、もう本当40万円、50万円のタワー型のデスクトップパソコンを一日でぶっ壊しましたし。壊したからこそ直しました。直せましたし、みたいなことはあるかも。

「大学生のうちに(これだけは)やっとけ」。これはメチャクチャ聞かれるんですけど、これは毎年言っています。同じことを言いますね。エンジニアの開発とかはそれぞれの開発の環境があるので、別に焦らなくていいと思います。ただ学生さんのこの時間って、僕は歯学部なんですね。ちょっと医学部なので(文系か理系か)どっちになるかわかんないですけど。語学は第1が英語じゃないですか。第2はたぶんフランス語とかスペイン語、中国語を取っているじゃないですか。それはメチャクチャやったほうがいいと思います。

僕は途中にアジアの、ベトナムで子会社を作ったり、シンガポールにも2023年には2回とか打ち合わせしに行ったりもしているんですけども、一緒にサンフランシスコにも行きました。Google本社にも。やはり英語はしゃべれないと話にならないんですよね。僕は英語がしゃべれるので、25歳の時にオーストラリアに行きました。4年ぐらいいたので、おおよそしゃべれるんですけど、やはりそれがあってよかったなって思ったんです。

僕の部下にインド人がいるんですけど、もう日本人より日本語をしゃべれますし、彼は英語もヒンディー語も日本語もしゃべれるとなると、スーパーじゃないですか。だからエンジニアリングスキルは入ってからでも絶対に追いつくので、焦らなくていいです。先ほども言ったように、憧れなくていいです。絶対に追いつくので。環境で育ってくれるので。

ただ、学生にしかできないことというのは、マジでやったほうがいいです。なので、メチャクチャ英語とか、語学をやってください。絶対僕が言ったことが「あ、岡本さん言っていたな」と思い出してくれるので。

「大学院進を検討しているのですが、会社として院卒に求めることは?」院卒に求めることとしては、別に院卒だからというふうには求めないです。専門分野を突き詰めておけば、それを自己PRで言ってくれればいいです。データサイエンティストとかやっていました、マーケティング観点もやっていました、でもぜんぜんいいと思います。活躍は当然できるし、異分野でもメチャクチャ活躍している人はいます。

エンジニアだった人と、エンジニア志望だったデータサイエンティストが、いきなり企画(の話をするうえ)でも、持っているからこそ仕組みについても話ができるんですよ。あ、時間になっちゃいましたね。すみません(笑)。ちょっと熱くなっちゃいました。

僕はいろいろなところでも登壇しているので、ぜひぜひそういう機会があればこういった質問も受けるので、また何かあれば人事経由で僕に質問してください。今日はどうもありがとうございました。がんばってください。ぜひ、素敵なエンジニアになってください。以上です。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!