パーソルキャリア株式会社CTO兼エンジニアリング統括部エグゼクティブマネジャーの岡本邦宏氏が、エンジニアとしてのキャリア構築について語りました。「憧れるのをやめましょう」という大谷翔平選手の言葉を引用しながら、透明性のある評価制度や6段階の報酬体系、エキスパートとマネジメントの複線的なキャリアパスなど、同社における「勝てるエンジニア」育成の仕組みと、フルスタックエンジニアを超えた専門性の価値について解説しました。
エンジニアの憧れを超えてチームで作り上げる価値
岡本邦宏氏:ではみなさんここで質問です。みなさんの憧れのエンジニアって、もしなんか具体的に人物名でもいいですし、ただどういうふうに、こういうエンジニアになりたいとか、関わるというのもあると思うんですけども、なんか書いてもらえますか。
ああ、t_wadaさんね。はいはい、そうですね。僕もよく飲みにいったりします。ああ、ひろゆきさんね。今日もね、うん、今回のサポーターズに(もいます)。うんうん。ひろゆきさんはエンジニアという感じよりも、もはやもうコメンテーターに近いですけど、今ね。うん。うん、そう。
(自分の名前を見て)あ、うれしい。これはでも、書いたのはうちの社員ですね。はは(笑)。なんか、まぁまぁまぁ、でもぜんぜんいいです。はい。でもそうですよね、ちょっとまぁいろいろ。やはりひろゆきさん、まつもとゆきひろさんとか、あとひろゆきさんとかもやはり(多いですね)。
あと落合(陽一)さんもそうですけど、やはり表のメディアに出ている人が多いのかなと思っていますし、たぶん、パッと出てこない人も多いと思うんですよ。
ということは、結局憧れる人もいるでしょうけども、結局はでもそういうものかなって僕も思っています。僕自身もたぶん、僕自身と働きたいみたいな人が入ってくれるとすごくうれしいんですけども、別に僕に憧れたとしても、なんかそれもちょっとどうかと思うので。
そういう意味では、なんか今回でも書いているように、正直大谷(翔平)さんが言ったように「憧れるのをやめましょう」と。すごく良い呼びかけだなと、僕は思っています。
「エンジニアになってすばらしいプロダクトを作るんだ」「優秀になるんだ」とかの夢を掲げるのもすごく大事です。ただ、それだけじゃ駄目です。こうしてエンジニアを目指す学生さんが一堂に集まっている横を見れば、やはりこれって仲間なのですね。チームなのですよ。
だから日本だけじゃなくて世界を見ても、ぶっちゃけものすごく有名な人がいるんですよ。今日僕がこうやってしゃべっている間にも、たぶんプロダクト開発とかもそうだし、孫(正義)さんはミーティングでいろいろな発案とかアイデアとかを出しているんですよ。
ただ焦る必要はなくて、憧れてしまってはやはりそういう人たちを越えられないので、自分のペースで僕は(やって)いけばいいと思うんですよ。僕自身もそうだったので。
(僕だって)普通にオーストラリアへ飛び出して行って、日本でみんな真面目にやっているけど、僕だけ斜め横に外れちゃったんで。だけど今、複数社でCTOをやらせてもらっていて、そういったところもあるので、僕は自分自身のペースと自分自身のやり方でぜんぜん良いと思うんです。これも後でちょっと説明しますね。
なので、憧れるのをやめましょう。もうすごい方がいっぱいいるので。僕なんか足元にも及ばない人もいっぱいいるんですけれども、ただ本当に僕もそう思っています。
透明性のある評価制度が生む価値貢献とエンジニアの成長
じゃあ勝てるエンジニアってどうすればなれるの?……ちょっとこの「勝てる」という言い方には語弊があるので、僕は価値貢献というふうにカッコでつけさせてもらっています。
大事なのは、これはちょっとパーソルキャリアの中にヒントがあるかなと思っているので、(スライドに)書かせてもらいました。「透明性の評価制度」って、なんか当たり前のように聞こえると思うんですけど、メチャクチャ難しくて。
一般的な成果報酬型ではなくて、エンジニアはやはりチームでやらなきゃいけないんですよね。大谷(翔平)さんだけがすごいわけじゃないわけで、あれもチームで勝ったなと思うんですよ。吉田さんがメチャクチャ打つとか。
同じです。エンジニア、データサイエンティスト、デザイナーとか、専門分野に携わる人がやはりこういったところをしっかりと評価してもらえる制度を導入しておかないと、やはり自分のやりがい搾取になってしまいます。自分自身がやったとして会社に評価されないとしたら、たぶんいる意味がないというか、価値を発揮しにくい状態になると思うんですよ。
なので、会社というのはしっかりとしていて。たぶん今日もいろいろな人がサポーターズで登壇してくれていると思うんですよ。ただ、こういった観点で言っているかどうかはわかんないと思うんです。
ただいろいろなフレームワークの使い方とか、例えばフルスタックエンジニアでああだこうだとか、エンジニアの開発サイクルとかっていろいろ言っていると思うんですけど、あくまでそれはHowであって、結局働くということは、裏側でこういった仕組みがちゃんと整っているかとか、今後みなさんも会社を選ぶと思うんですけども、こういったものを基準としてちゃんと持っているかはすごく大事で。
営業さんのように、なんか1年間で何万何千稼ぎましたってわかりやすいんですけど、エンジニアじゃ何万行コードを書いたって言っても「ハァ」って感じじゃないですか。だけど、それも含めて、ちゃんと開発パフォーマンスを評価制度として取り入れるのが、メチャクチャ大事なのですよね。なので、我々はそういったスキル評価をやっています。
多様なエンジニアスキルを評価する6段階の報酬制度
市場価値に合ったスキル評価ですね。実はこれ、まだ一部なのです。PE1からPE6の6段階あって、各データアナリストのデータだけでもこれだけまだあるし、データサイエンティストはこの中にいます。エンジニアでも、これ(エンジニアと)一言で書いてありますけど、メチャクチャいます。フロントエンジニア、バックエンドエンジニア、インフラエンジニアとかクラウドエンジニアとか、いろいろなエンジニアがいます。
表に書ききれないんで書いてないだけですけど、これぐらい事細かに、全部管理職とか非管理職とかでぜんぶやり方を書いた上で、報酬設定もして、幅広い報酬レンジを設けているので、年齢がどうこうとかスキルがどうかとかよりも、上司とも含めて、自分がやっている方向性が合っていて、ちゃんとそれが会社の人事と目標設定が合っているのか。そういったもので設計されているので、すごく働きやすい。もしくは、自分がどっちの方向に向かったらいいんだろう、みたいなとこが迷いにくい仕組みになっています。
キャリアパスの複線化 エキスパートとマネジメントの両立
もう少し突っ込みますね。これはちょっと気づいた人もいるかもしれないですけど、上のほうにいくと、マネジメントコースとエキスパートに分かれています。これは専門性を突き詰めるエキスパートコースもすごく大事ですし、当然それを束ねるマネジメントもいないと、やはり会社って回らないですよね。
なので、キャリアパスを複線化することによって、それに対して会社のやる気、ケイパビリティを、この6,000人とかいる会社に対してのまとまりとして作っています。
企業によっては、上位グレードへ行くと、「なんかマネジメントしかしないんじゃないの?」みたいなイメージがあるかもしれないんですけども、当然我々の場合はそれも大事ですし、そうじゃないところもしっかりと評価してあげる仕組みを作っています。
エンジニアから技術戦略を描くCTOまでのキャリアステップ
次に行きましょうか。これは僕が勝てるエンジニアの一例として書いています。実は左から右への流れる図なのですけど、実際これがすべてだとは思っていないです。だいたいがあるフロントエンジニアと、アプリケーションエンジニアから始まったり、インフラエンジニアから始まったりして、データエンジニアは若干別のところにしていますけど。
右のほうにいくとすると、エキスパートとマネジメントが置かれています。これが別に偉いとかそういう話ではなくて、そういう職能なのですよね。その人の能力とかスキルなので、これはたぶんいろいろな会社にも当てはまるかなと思っています。
この前もCTO会談をYouTubeでもやりました。有名な某CTO何人かでやったんですけど。やはりこの図は、なんか「ふんふんふん」って納得度が高かったです。
例えばITコンサルタントにいく人もいるでしょうし、設計にいきたいから、アーキテクト。プロジェクトを回す、プロダクトを回すのが好きな人は、プロジェクトリーダーとかマネージャーをやればいいと思っていますし。
エキスパートでテックリードをやりたいみたいな人もいますし。マネジメントだと、わかりやすく言うと僕がCTOなのですけども、横にCIOも当然うちの会社にはいますし、CPOもいます。なので、誰が偉いとかそういう話ではなくて、役割の話なのです。実はCTOも役割なのです。役割の1個です、ぶっちゃけると。
なので、そこを目指すというのもアリなのかなと思っています。ぶっちゃけると、左側でフロントエンジニア目指して、右側に行かずにそのままシニアエンジニアというかたちでも僕はいいのかなというふうに思っています。
専門性をもう少し具体的に話すと、この専門性でエキスパートというのは、専門性を発揮して市場にインパクトをもたらすレベルの改革を主導することができるというのでも、ある種(そういう)言い方もできるかなと思っています。
さらに特定の領域、僕だったらいわゆる技術の領域だったりとか、技術の領域における経営の参画だったりとか、あと僕は技術の戦略を描くのがけっこう得意だったりします。
なので、この会社は3年ごとにこういう技術戦略をやるから、バックキャストで、1年間で3ヶ年計画を立てるんですけども、1年間こういうふうにIT投資をして、人材活用をして、その上でインフラやフロントのバックのエンジニア、もしくはプロダクト作りをこうしましょうみたいなところを、戦略を描かないといけないです。パワポでも数百枚とか平気でいつも書くんですけども、そういったところをやったりしています。
なので、当然それにはお金が必要なので、経営にかけあって「これだけ必要ですよ」みたいなところを(やります)。ちょっと先ほどのシリーズAとかBとかの話に近いですよね。なので、CTOはそういう役目だったりもするので、意思決定とか協力を引き出すとか、そういった役割も僕がやったりとかしています。
セキュリティの観点は、例えばCIOに任せたりとか、プロダクトのほうはCPOに任せたりとか。その代わり全体の技術戦略を満遍なくこなして、そこらへんの情報をちょっとずつ取り入れながら、僕がやったりしています。
フルスタックエンジニアを超えた専門性の価値
最近だと聞かなくなったかもしれないんですけど、この中にもいるかな? フルスタックエンジニアを目指したいという人もいると思うんですけども、フルスタックのことはこの中に書いてなくないですか? 先ほどの表もそうですけど。
(フルスタックエンジニアは)確かに聞こえは良いんですけども、例えば、大谷さんは特別ですよ。世界でも1人ぐらいしかいないんで。投げて打って走れて、キャッチャーもできて監督もできて、みたいになると、いやいや確かにフルスタック野球プレイヤーだけど、何屋さんなの? みたいな。結局君は何屋さんなの? みたいになっちゃうんですよね。
だから、結局なのでもできる=なんにもできないみたいになっちゃうので、だったら先ほどのように、例えばじゃあアーキテクトで突き詰めるとか、テストエンジニアでもいいですよ。エンジニアリングマネージャーでもいいし、フロントエンジニアの中では突き詰めるでもいいと思うんですけども、なんかそういったところが要素としてあっても僕はいいのかなと。むしろそっちのほうが今は重宝されるというか、結局はそういったものが役割なので、会社の中でも価値を発揮しやすいかなって思っています。
実際1人とか2人で自分たちの会社を立ち上げる時はフルスタック的に動くのですが、結果5人とかでは会社はそこから大きくならないじゃないですか。(大きくしようとすると)14人とか20人、30人、すぐなっちゃうんで。
そういった時に、フルスタックだけだと当然回らなくなっちゃうので、「自分はじゃあこの領域やります」「インフラだけSRE的にやります」みたいな、(あるいは)品質だけ担保するエンジニアになります、とやはりなっちゃうんです。
そうした時に、そこをわかっていて自分の中でキャリアパスを描けるかどうかというのはすごく大事で。フルスタック自体は悪いことじゃないんですけども、何でも屋になっちゃ駄目ですよという話ですね。そうしちゃうと、便利屋になっちゃうんです。
(次回へつづく)