EMを目指すことは“キャリアのベストプラクティスのひとつ”だと伝えたい　川崎雄太さんのキャリアの考え方

ITエンジニアと一口に言ってもフロントエンド、サーバーサイド、インフラ、QA、マネジメント……など、ポジションやキャリアにはさまざまなルートが。使う技術やツールはもちろんのこと、面白さや考え方も異なります。「なぜ、どういうきっかけでその道に進むことになったのか」「何がやり甲斐なのか」には、人それぞれの答えがあるものです。

いろいろな人から自分なりのキャリアの選び方を伺うことで、テックの世界の知見を共有する本企画。今回は川崎雄太さん（@yuta_k0911）にLT形式で発表していただきました。

speakerdeck.com

自己紹介

スキルマーケット「ココナラ」の運営・開発などを行う株式会社ココナラでHead of Informationを担当している川崎雄太（かわさきゆうた）です。2024年9月からココナラグループに加わった株式会社ココナラテックの執行役員も兼任しています。

また、SRE・社内情報システム・セキュリティという3つの分野のエンジニアマネージャー（以下、EM）を担当しています。
その他にもDevRelをやったり、あとはSREコミュニティに貢献したいという思いから、SRE NEXT 2024にコアメンバーとして参加しています。来年もコアメンバーをすることになりました。

今日は私がEMになった理由についてお話したいと思っています。

技術・言語の遍歴

初めてプログラミングに触れたきっかけは、大学1年生のときにC言語の授業を受けたことでした。また、ゼミ選びでは「オペレーションズ・リサーチ」という分野を専攻し、その手段としてプログラミングを使っていました。

「オペレーションズ・リサーチ」というのは、いろいろな確率を数理統計学的に分析する学問です。例えば、タイタニック号が沈む確率を導くのであれば、天候や乗組員の状況などいろいろな確率を掛け合わせ、プログラミングを使って割りだすといった感じです。

それから社会人になって、バックエンドエンジニアになった後、そこからインフラエンジニアやSREを経験して、さまざまな分野をかけ合わせた仕事をするようになりました。

これまでに経験してきた言語をざっとまとめると、バックエンドはJava、PHP、それから言語に入れていいかはさておき、Shell。インフラではShellを基本的に使っていて、時にAnsibleという感じです。SREになってからはTerraformやPythonを使ってインフラのコード化や自動化を推進していました。

EMになった理由

EMになったきっかけは、2社目のリクルート在籍時に30人規模の組織のチームリーダーを任されたこと。自分から取りに行ったわけではなく、ふとしたきっかけから何となく「できるよね？」とお願いされました。

受け身で始まったEMとしてのキャリアでしたが、もう10年を超えています。なぜ生業になったのか、改めて考えてみました。

ひとつには、私はもともと人をリードすることが好きだったのだと思います。学生時代、体育会系の部活に所属していて、それなりの人数をリードする立場を経験していました。このときに薄々ながら組織を動かすことの面白みや、やり甲斐を感じていました。

もうひとつは、社会人2年目くらいのときに、OJTのトレーナーや小規模なチームのリーダーを務めたことが大きかったと思います。そのときに至極当たり前なのですが「自分ひとりではできないことが複数人ならできる」という気付きがありました。

私はアルゴリズムを考えるのが好きで「バックエンドの処理を高速化するにはどうするか」「メモリの使い方をどうするか」といった処理ロジックを考えるのは得意だったのですが、それをコードに落とし込むのはあまり得意ではないと自己分析していました。

自分よりも効率良く開発できる仲間を見て「自分が同じ土俵に立とうとするよりも、その人が働きやすい環境を作るほうが組織としては最適解なのではないか」と感じました。私は“組織の成果の最大化”をキーワードに考えることが多いのですが、それを目指すためには一人ひとりが苦手なことではなく得意なことに注力して、互いの苦手を補い合うかたちのほうがいいのではないか、と。

また、ちょっと打算的な話になりますが（笑）、自分の得意・不得意を棚卸ししてキャリアパスを思い描いたとき「EM、いいんじゃないの？」と思ったこともきっかけのひとつです。ひとつのスキルを突き詰めて稀有な存在を目指すのもいいのですが、「100分の1を3乗すれば100万分の1になる」というような掛け算から生まれるキャリアの希少性も武器になるんじゃないか、という認識がありました。

EMの楽しさ / 頑張りどころ

EMという立場でも技術を理解し、メンバーに教えられる、経営層に伝えられるようにする必要があります。トレンドを追いかけつつ、「課題解決の手段として使えるものはないか？」というアンテナを張り続けることが重要です。また、自分の信条として、コードを書けないEMにならないように、今でも時にはAnsible、Terraform、Pythonを書くようにしています。

あとは適材適所な組織作りをして、“組織の成果の最大化を愚直に追い続ける”ということを考えています。

システム的な仕組みがいくら整っていても、例えば、Notion AIやGitHub Copilotなどの開発生産性が高いドキュメントツールを導入したとしても、組織がイケていなければDeveloper Experienceは下がってしまいます。ここに関与して、より良い方向に導くのが自分の役割だと思っています。

エンジニア組織という入れ替わりが激しい環境で、既存メンバーとこれからジョインする方を理解して、いかにインテグレートして組織を作るか。こういったことに取り組めるのがEMの醍醐味でもありますし、やり甲斐にもなっています。

やっていて思うのは、イケてる組織を作るためには福利厚生、人事などのエンジニアリング以外の領域にも踏み込むべきかもしれない、ということ。評価設計や制度設計などさまざまな領域に携わっていくなかで、非エンジニアリングの領域にも楽しさを感じるようになりました。やることがめちゃめちゃ多くて大変ではあるものの、おもしろい仕事だと思います。

後進を育てるためにも「EMを目指すことは、キャリアのベストプラクティスのひとつ」だと啓蒙していくことも大事かなと思っています。

マネージャーになることに対して苦手意識があるエンジニアの方も少なくないと思うのですが、広い視野を持って困る社会人はいないと思いますし、マネジメントスタイルは十人十色で、トップダウンでやる人もサーバント・リーダシップのように後ろから背中をしっかり支える人もいます。

EMはおそらく多くの会社で不足しているはずなので、機会があれば試しにチャレンジしてみるのもひとつの手なんじゃないかな、と。そのきっかけでキャリアの道が別の方向に拓けるかもしれません。

僕から伝えたいことは以上になります。ありがとうございました。