Findy Engineer Lab

エンジニアの"ちょい先"を考えるメディア

キャリアに正解や間違いはない。真摯に仕事と向き合えば、いつの間にか自分の後ろに道ができる

2024年5月に株式会社カケハシは、湯前慶大さんが執行役員CTOに就任したことを発表しました。

執行役員制度刷新および新執行役員就任に関するお知らせ
https://www.kakehashi.life/news-post/20240501

湯前さんはこれまで、株式会社日立製作所でLinuxカーネルの研究に携わった後、2014年に株式会社アカツキに参画。同社でエンジニアとしてのキャリアを開始し、エンジニアリングマネージャーやVPoE、執行役員 職能本部長など開発組織のマネジメントに従事してきた人物です。

エンジニアコミュニティでも、「マネジメントスキルが高い人物」として知られる湯前さん。ですが、「決して最初からマネージャーとしてなんでもできたわけではありません」と、彼は自身の歩みを振り返ります。今回は湯前さんのキャリアについてインタビュー。そのエピソードには、「エンジニアがマネージャーとして成長するためのエッセンス」が詰まっていました。

新卒入社当初から「会社を離れても通用するスキルを身に付けたい」と思っていた

──湯前さんは、日立製作所でLinuxカーネルの研究に携わられていたと伺いました。まずはその時代のことからお話しいただけますか?

もともと私は大学・大学院で物理を学んでいましたが、その延長線上で仕事をするのは難しいだろうと思っていました。「これからの時代は情報化社会になるから、ITに関する仕事をするのが良い道筋になるのではないか」と考えてエンジニアの道へ。学生時代に研究をしていたこともあり、何か特定の領域を突き詰める仕事をしたくて研究所に入りました。

余談ですが、リーマンショックが起きたのが2008年で、私が新卒入社したのは2010年です。当時は多くの企業が軒並み採用を絞ったり、人を解雇したりしていました。「これまで当たり前だった社会が、何かのきっかけで激変してしまうこともある」とみんなが痛感していた時期でした。

だからこそ、特定の企業だけではなくどこに行っても通用する人材になることを目指していました。なんなら、入社初日の時点で「いつでも転職できるようにスキルを習得するぞ」と考えていたくらいです。そんなモチベーションもあり、OSSを扱っている部署に入ってLinuxカーネルの研究に携わりました。

──Linuxカーネルは、各種OSSのなかでもかなり専門性の高い領域です。新卒からこの領域を研究するのは大変だったのでは?

その通りで、最初は何もかもわからないところからのスタートでした。OSという領域は歴史が長くシステムも複雑ですし、開発者に求められる知識も膨大な量になります。毎日必死に食らいついて、数年がかりで知識を身に付けたという感じでしたね。ただ、このときに地道に学んだ経験は、その後のキャリアにもプラスになりました。

──日立での経験で、印象深いものはあるでしょうか?

シリアルデバイスドライバーを改善するためのパッチを、Linuxカーネルのメーリングリストに送ったことがありました。すると、ドイツの開発者から「君のこのパッチがウチのコンピューターで動かないんだけれど、直す作業を手伝ってくれないか?」という内容のメールが届き、メールでやりとりをしながら1カ月くらいかけて修正しました。その方から「やっとできた、ありがとう」と感謝されて、それがすごくうれしくて。

日立の研究所では、自分たちが独自で改修していたOSの修正内容を、Linuxカーネルのメインラインに入れてもらうことを目的としていました。そのため、自分たちの作ったものが世の中で実際に使われるようになるのは、5年後とか10年後になってしまうんですね。

でも、ドイツの開発者の方とのやりとりを通じて「自分の作ったものがすぐに世の中の役に立つのは、こんなにもうれしいのか」と実感しました。研究所ではこの“すぐに”という経験はなかなかできないと気づき、転職を決意しました。

自分のマネジメントがメンバーの成長機会を奪っていた

──そうして、アカツキに転職されます。どのような流れで、マネジメントも担うようになったのですか?

アカツキでは主にゲーム開発に携わり、最初に参画したチームではスクラムマスター兼テックリードを務めました。コードを書きつつある程度のマネジメントもしていたんですが、当時はすごくジレンマを抱えていました。

チームを改善するために、やったほうが良いタスクはいくらでもあります。ですが、チームのための仕事に時間をかけると、自分がコードを書く時間がどんどんなくなっていきます。マネジメントを大切にするほど、自分が手を動かす割合がどんどん減ってしまう。逆に、自分が手を動かせばチームがおざなりになる。両方をやるための時間が十分に取れなくて。この状況は良くないので、何かしら折り合いをつけなければならないと思いました。

──その悩みを、どのように解決したのですか?

「コードを書きたい」という気持ちと、「チームの成果を最大化したい」という目標を逆の概念として捉えるのではなく、統合できないかと考えたんです。そもそも自分は何をしたいのかに立ち返ると、とにかくプロダクトを良くして成果を出したいのだと気づきました。

設計をするとかコードを書くといった業務は、それを実現するための手段でしかありません。エンジニアリングもマネジメントも達成したい目的は同じであり、それらを実現するための道筋が異なるだけだとわかったんです。

ならば、自分は成果を最大化することだけにフォーカスすべき。今のチームではチームの成果を最大化するためにマネジメントに徹する方がより自分の達成したいことに近づくと思い至った結果、マネジメントに集中しようと決断しました。

──マネジメントの面白さに気づいたエピソードはあるでしょうか?

その次に、あるチームのプロジェクトマネージャーになってから経験したエピソードをお話しします。もともとチームの運営がうまくいっていなかったところから私が立て直しをして、まずは安定してシステムを開発できる状態にしました。当時の私はチームの開発が円滑に進むように、事前に各種の根回しをしたり、開発のチケットを用意したりと、入念に準備していたんですよね。

こうした活動をすればするほど、チームもプロダクトも良くなり、売り上げも伸びたので、自分のしていることに何の疑問も持っていませんでした。取り組んでいる仕事が楽しくて、平日の深夜や休日にも仕事をしていました。いま振り返ればだいぶワーカホリックですよね(笑)。でも、こうした仕事をマネージャーがすべて引き受けることで、「自分が準備をしないとうまく回らないチーム」を、自分の手で作ってしまっていたのだと思います。

そんなあるとき、私がインフルエンザにかかり、1週間ほど何の仕事もできない状態になりました。おそらく、気づかないうちに疲れがたまって体が悲鳴を上げていたのだと思います。職場復帰した日には「1週間も現場を離れたらきっと問題が発生しているだろうな……」と、暗い気持ちになっていました。

でも、実際はその逆でした。職場に戻ったら、チームは何も混乱していませんし、スプリントプランニングでも他のメンバーたちがファシリテーションをして、自発的にタスクのチケット作成や見積もりも行っていました。「これはすごい!」と感動しましたね。

自分の手で「自分に依存するチーム」を作っていたことに、そのときようやく気づきました。みんなを信頼して仕事を任せることが大事だと知ってはいたけれど、本当の意味でそれを実践できていなかったんです。自分が努力するだけがすべてではないと気づき、マネジメントの面白さを実感しました。

「それは本当に自分がすべき仕事か」を自らに問う

──そうした出来事があってから、湯前さんのマネジメントスタイルは変わりましたか?

大きく変わりました。具体的には、可能な限り目の前の小さな課題解決に取り組まないようになりましたね。他のメンバーに任せていいことは積極的に任せ、自分はより事業や組織の根本的な課題と向き合おうと思うようになりました。

──「マネージャーが仕事を巻き取り過ぎてしまう」という事象はよく発生するものですが、どうすれば回避できるでしょうか?

「いま自分がしている仕事は、本当に自分でなければできないのか?」を常に問うように私はしています。以前の私は「エンジニアやデザイナーの方々が効率的に働けるように、自分が雑務を引き受けるべきだし、それがチームにとってベストな行動だ」と考えていました。

でも、ミーティングをファシリテーションするとか、タスクを考えてチケットを作るといったことは一見すると雑務のようだけれども、こうした活動がチームやプロダクトに目を向けるきっかけになりますし、むしろ積極的にメンバーへと任せていくべきでした。

ある意味で、その頃の私はコンフォートゾーンに入っていました。そうした雑務を引き受けている間は、チームを改善できている実感があって楽しいですからね。でも、真の意味でマネージャーがやるべきことは「いまの自分が持つ能力の限界を超えたところ」にあって、それこそ企業や組織にとっての真の課題なんです。その大変さから逃げてはいけませんでした。

──アカツキではVPoEや執行役員なども担当されましたが、そうした経験で印象に残ることはあるでしょうか?

執行役員に就任して経営会議に参加するようになりましたが、最初の頃はまったく発言できませんでした。経営に関する知識がなかったからですね。システムや開発組織についての知見はあるので、エンジニアリングマネージャーやVPoEの時代はその延長線で業務を遂行できました。ですが、経営会議に出てくる議題は技術の話なんてほとんどなくて、財務会計やM&A、投資、IRなど専門外のことばかり。何も知識がないので、何から勉強すればよいのかすらわからず、非常につらかったです。

これは何が起こっているのかと思っていろいろ調べたところ、いわゆる「ピーターの法則」という「人は無能になるまで出世する(自分自身のスキルが通用しない段階に来ると、それ以上は出世できなくなる)」という状態に陥っていたんですよね。このままではマネジメントの道を歩めなくなると感じたので、経営を体系的に勉強しようとビジネススクールに通い始めました。

──人によっては「自分には知識がないから、経営には参画せずあくまで開発組織のマネジメントに徹しよう」という方もいるはずです。なぜ湯前さんは、経営を学ぼうと考えたのですか?

これも先ほど述べた「コーディングもマネジメントも目的を達成するための手段」という話に戻るんですが、事業やプロダクトを良くすることが大切であって、そのためなら何でもやるべきだという気持ちが常にあるんですよね。目的を達成するためには自分が使える武器を増やしていくべきで、ならば経営を学ぶしかないと決心がつきました。

自分の力で、自分のキャリアを良いものに変えていく

──そうして、現在はカケハシでCTOを担われています。今後、事業や開発組織をどのように成長させたいですか?

カケハシは医療ドメインを扱っていることもあり、短期間で世の中を変えるのは難しい側面があります。医療のさまざまな施策は、数年とか数十年のスパンで進められていきますからね。ですが、大きく変えるのは難しいかもしれないけれど、小さな変化をたくさん起こすことは可能だと思っています。要するに1日単位で見れば誰も気づかないようなほんの少しの変化でも、それが1年、3年、5年と積み重なれば大きなことを成し遂げられるはずなんです。

そのために開発組織としては、継続的にプロダクトをブラッシュアップして、効果を素早く確かめることのできる土台を構築していきたいと考えています。究極的には、プロダクトのリリースから効果検証を毎日行えるようにして、医療体験を日々進化させたいです。目の前の小さな改善の連続が未来を作るという考え方を、カケハシの開発組織全体に浸透させていきたいですね。

それを実現するためにも、システムのアーキテクチャや組織構造をより「信頼性や生産性が高まる状態」へと変えていきたいです。カケハシは数年前からプロダクト開発を続けており、その過程で技術的負債が蓄積しています。また、組織構造の部分でもより良くできる余地があります。CTOとして、良いプロダクトをよりスピーディーに生み出すためのアーキテクチャや組織を再設計していきたいです。

──最後に今回のインタビューを踏まえて「エンジニアがより良いキャリアを送るために大切なこと」というテーマで結びのコメントをいただけますか?

正直なところ、私は「どんなキャリアを送るか」を考えずにこれまで働いてきました。日立でもアカツキでも、自分が「これをやりたいな」とか「こうすべきだな」と思うことをただひたすらやってきただけ。もちろんカケハシでもそうです。その環境で自分なりにできることやすべきことと一生懸命向き合ってきた結果、振り返ってみればその後ろに道ができていたという感じだと思います。

キャリアはこうすれば正解とか、こうしたら間違いというものはありません。むしろ「自分が選んだ道を正解にするんだ」くらいの気持ちで、目の前の仕事に責任を持って取り組むと良いです。それが本当の意味で、良いキャリアを歩むために重要なのかなと思いますね。

取材・執筆:中薗昴
撮影:山辺恵美子