柳沼 秀龍／Hidetatsu Yaginuma
Turing株式会社 Autonomous Drivingチーム エンジニア。SIer、メルカリ、スタートアップを経験後Turingへ。メルカリではマイクロサービスアーキテクチャへの移行プロジェクト、メルペイの立ち上げを経験しテックリードに。その後スタートアップでテックリード、VP of Techocologyを経験する。完全自動運転EV実現という人類のグランドチャレンジへの挑戦に惹かれTuringにジョイン。自動運転AIと車を接続する自動運転システム全体の設計・開発を行っている。
これまでのキャリア課題解決は、開発だけでなく運用もセットである多くの人に愛されるシステムに携わる幸せ壊れないシステムを作り上げる難しさコードだけでなく組織で課題を解決する面白さ完全自動運転EV実現というグランドチャレンジ非合理的で壮大なチャレンジ抽象的な会話を抽象的なまま進められる強さソフトウェアエンジニアリングの力が求められる理由車と大規模ソフトウェア開発の共通点ミッションは自動運転を作り、それを顧客に届けることTuringは完全自動運転という抽象度の高い壁を解決する場所カジュアル面談はこちらから
これまでのキャリア
ーーまずは柳沼さんのこれまでを伺いたいです。SIer、メルカリ、スタートアップと多くの経験を積まれてきました。それぞれの環境で何を学び、どんなキャリアを歩まれてきたのでしょうか？
課題解決は、開発だけでなく運用もセットである
キャリアのスタートはSIerで、さまざまな業界におけるエンタープライズ企業の課題解決に従事していました。現実の問題をモデル化してシステムに落とし込むプロセスは面白かったですね。一方でSIerの構造上、システムを納品した後は仕事が自分の手から離れてしまいます。開発に携わったサービスのその後に関われない寂しさや、開発後に起きる運用課題に関与できないもどかしさを感じていたのです。
人々に安心・安全に使い続けてもらうプロダクト作りをするためには、システムを作ること以上に、運用やそれを見越した開発を行うことが大切だと気づき、事業会社でのキャリアを考え始めました。
多くの人に愛されるシステムに携わる幸せ
ーーそこからメルカリへと転職されていますが、転職のキッカケはなんだったのでしょうか？また、どんなミッションを担っていたのでしょうか？
キッカケ自体はスカウトでした。当時のメルカリは創業期から続いていたモノリシックアーキテクチャーから、スケーラビリティを求めてマイクロサービスアーキテクチャに移行するタイミングでした。移行に要する技術が私のスキルセットと親和性があったことで、声をかけていただいたのです。
アーキテクチャの移行にはさまざまな仕組みづくりが必要で、立ち上げ期からさまざまな経験をしました。その後メルペイの立ち上げに携わり、AML/CFTと呼ばれる不正取引やマネーロンダリングを検知・抑止するシステムの開発を経験しました。多くのユーザーに利用いただいていたメルカリ・メルペイですが、1分でもサービスが動かなくなると大問題です。ただ作るのではなく、運用するためのチームづくり、深い技術領域に触れること、チームのコンディション向上や組織運営の大切さを学びました。ソフトウェアを組織で開発する経験を積め、使っている人が多ければ多いほど開発は面白いのだと実感できたのは非常に有意義でしたね。
壊れないシステムを作り上げる難しさ
ーー大きな転換期でさまざまな経験を積んだのですね。メルカリで働く中で感じた1番大きな学びはなんでしたか？
メルカリで感じたのは、壊れないシステムを作り上げる難しさです。サーバー、ハードウェア含め壊れないものはこの世に存在しません。多くの人が触れるシステムを正しくつくり、維持することは技術難易度が高いです。
特にメルカリのユーザーはスマホやPCなどITリテラシーに濃淡があります。多くのユーザーが安心・安全に使えることが前提にあるからこそ、単に技術だけでなく、体験やデザイン、運用の全てを経験できたのは面白かったですね。
コードだけでなく組織で課題を解決する面白さ
ーーそういった貴重な経験を積まれたのですね。そこからスタートアップへ転職していますが、キッカケはなんでしたか？また、転職で得た経験について教えてください。
非常に充実したメルカリでの経験も、組織が2000名ほどになったタイミングで感覚が変わってきました。マイクロサービスアーキテクチャーを導入したことで、システムとしての堅牢性や安全性、保守性は高まりました。一方で開発に関わるビジネスパーソンとしては、システム全体に横串しで携わるのは難しくなったのです。その時に、上から下まで全体を見渡して仕事ができる環境の方が自分に合っているのではないかと考え、当時100名規模のスタートアップへ転職しました。
転職してからは、40~50人ほどいるエンジニアのためのデプロイを簡単に実行する基盤づくりやインフラを簡単にプロビジョニングする基盤、またシステムインフラのメンテナンスといった、特定の機能に関わらない組織全体が利用する仕組みづくりに責任を持っていました。そこからチームのテックリードとなったのですが、VPoEと会話する中で技術的負債や組織コンディションの工場、マネジメントの設計などに取り組み始め、VP of Techonologyというポジションに就きました。
ーー開発からマネジメントの比重が増えたことで、得られる経験や学びも変化したと思います。どういった変化がありましたか。
マネジメントをして学んだことは数多くありますが、扱う成果が大きく、責任も大きい点は非常にやりがいを感じました。現場でコードを書く、動かすことは自己完結的な側面もありますが、マネージャーとしていろんな人を巻き込んで大きな成果を出すのは面白かったです。会社の利益を出すことと、個人にとってもやりがいを感じる環境の設計・アラインメントを経験できたことは自身の目線を大きく上げてくれました。
完全自動運転EV実現というグランドチャレンジ
ーー大きなやりがいを感じていた中でのTuringへの転職。かなり悩んだのではないかと思いますが、なぜ転職を決意したのでしょうか？
非合理的で壮大なチャレンジ
正直前職を辞めるつもりは特になかったのですが、2022年の9月ごろにTuringを知り、「こんな会社があるのか、面白そうだ」と思い山本一成さんとカジュアル面談をしました。そこからオフィスへ遊びに行き、体験入社、入社へと進んだのですが、心を動かされたのは大きく2つの点です。
1つめは車を作るという発想です。自動運転ソフトウェアだけを提供するビジネスモデル・事業もある中で、あえて車を0から作る挑戦をしているのです。普通に考えると、効率性や事業の勝ち筋として合理的ではありません。ですが、テスラを超えたいという思いから、車を作るという意思決定をしています。
そもそも、テスラを超えるという考え自体も設定する目標としては一見本質的ではありません。一般的には、優れた完全自動運転を作ってそれが結果的にテスラを超えていた、という流れがオーソドックスでしょう。一方で、Turingでは、あえてテスラを超えたいという話をミッションに添えています。やるからには勝つという話は必ずしも合理性がないと当時は感じ、だからこそ面白いと思ったのです。これは私の考えですが、結果や勝利への執着という文脈は、ソフトウェアの世界ではあまり表立ってはいません。そんな環境で働くことに惹かれたのです。
抽象的な会話を抽象的なまま進められる強さ
もう一つの理由は、Turingで働く人です。オフィス見学や体験入社の時に感じたのは、抽象的なものを抽象的なものとして扱える賢さでした。通常の会話は抽象と具体を行き来して会話がなされます。ですが、Turingでは抽象的な状態でも相手と認識が揃っている安心感があるのです。
課題を抽象化して話せるので議論が本質的でスピーディーに進めます。その上でみんなが何かしらの技術に強いです。この2つを両立させているのがすごく居心地が良いですね。技術に閉じないスタンスを持ったシニアな人材が視座を高く持ち、Turingは何をしないといけないか、この開発をしてどんなインパクトがあるかという議論ができ、それをカタチにできる人が多いです。
ーー転職の決意が固まった感情的な理由を教えてください。
転職の意思決定は最後まですごく悩みました。ですが、完全自動運転EVの実現というテーマを、自分の人生の中で絶対に経験したいと素直に思ったんです。技術的に面白いことは間違いなく、優秀な人材と一緒に当事者としてチャレンジできる機会は人生でそうそうありません。この思いが日に日に膨らみ、Turingにジョインしていました。
ソフトウェアエンジニアリングの力が求められる理由
ーー柳沼さんは入社後に車両解体や試作車づくりのプロジェクトを経験されていました。ソフトウェアエンジニアリングと車の開発の共通点や、今のTuringにソフトウェアエンジニアが求められている理由を教えてください。
車と大規模ソフトウェア開発の共通点
入社したタイミングのミッションは、Turingが開発する車両のための試作車作りでした。組織全体の車の中身の解像度を高めると同時に、試作車のアーキテクチャーを作っていきました。
私はソフトウェア出身で、車の中の仕組みは非常にざっくりとしかわかっていませんでした。ですが分解してわかったのは、車は大量の部品からなる極めて複雑なシステムですが、ひとつひとつはシンプルだということです。あるひとつの部分が動き、それが連動して他の機械に影響を及ぼします。システムとして巨大で複雑だけど全部がつながっていることは、これまで経験してきた大規模システムと似ているなと感じたのです。プログラムは書いた通りにしか動かない。それと同じような感覚でした。
ミッションは自動運転を作り、それを顧客に届けること
ーーそこから自動運転システム開発チームの立ち上げを進めています。今のミッションについて教えてください。
Turingにとって自動運転はその核であり、命といってもいいと思っています。Turingの車両が顧客に選ばれるとき、優れた自動運転に大きな期待を寄せられているはずです。これまではAIを作るチームと自動運転システムを開発するチームは別れていたのですが、ベストな体験のためにこれらは本来不可分だと考えています。そこで、今回これらを両方やるチームを立ち上げることになりました。このチームのミッションはシンプルで、自動運転を作りそれを顧客に届けることです。
このチームは、ディープラーニングから車載ネットワークまで非常に広範な知識が求められることが特徴です。現実的にはここまで全部できる人はまれなので、それぞれの専門性を活かしながら協力して仕事しています。
自動運転はAIだけではできません。AIが出力する経路通りに車が本当に動いてくれるためには、適切なCANメッセージを送ったり、制御の知識が必要であったり、車の中のソフトウェアっぽい部分を深く理解する必要があります。私達は完全自動運転システムという、2023年現時点で誰もできていないことに挑戦します。各分野に専門性の高いメンバーと働くことができるのはエンジニアとして面白い環境ですね。
ーーそんな環境に身を置く柳沼さんが、ソフトウェアエンジニアとして力が活かせる・やりがいを感じる点はどんなところですか？
解き方のわからない課題をソフトウェアを使って解決していくのが面白いですし、腕の見せどころだと思っています。よく言われることですが、ソフトウェアエンジニアとはソフトウェアが書けるだけの人ではありません。優秀なエンジニアは課題解決自体が得意です。まだ誰も解くことができていな自動運転という課題を、解き方自体を発明していけるのが面白く、やりがいを感じます。
Turingは完全自動運転という抽象度の高い壁を解決する場所
ーー翻って、柳沼さんはTuringをどんな環境・場所だと捉えて仕事を楽しんでいますか？
Turingが向き合っている課題は極めて巨大です。そして、誰も解き方がわからない問題を解いています。目の前の仕事に対してどんな課題設定をすればいいのか、どんな課題の分割をして、どんな順番で解くのかを考えなければならない環境です。加えて、答えがないからこそ、Turingではめまぐるしいスピードで課題の優先順位や課題自体が変化します。課題自体の複雑さ、大きさ、そしてこのスピード感はTuringのポイントですね。
ーーその課題解決において、自動車業界での経験は必須なのでしょうか？
あるに越したことはないですが、基本的には必須ではないと考えています。私は、車を作ることは大規模なシステムを作ることと似ていると考えています。車を大きなロボットと捉えれば、まず電源が供給され、その後このコントローラーが起動し、こう指示をすれば動き始める、といったように全部つながりっています。これは、大きなソフトウェアとよく似ています。
このように構造が似ているからこそ、システムを抽象化してモデル化する能力や、重要なところを課題設定する能力、論理的思考力などを用いて解決に導くことができます。私自身が自動車業界での経験があるわけではないし、他にもそういうメンバーは多いです。
ーーそんな中で求められる技術スタックなどはあるのでしょうか？また、求められるスキルやスタンスについて教えてください。
私達はLinuxやC++、Pythonなどオープンな技術を用いています。機能安全や車載サイバーセキュリティなど車特有の要件はありますが、基本的には車は普通のハードウェアであり、車の中で動いているのも普通のソフトウェアです。エンジニアリングスキルは高いものを求められますが、自動車特有のスキルセットなどを求めているわけではありません。
求められるスタンスは、自身の携わったプロダクトが安全に使われ続けるところまで責任を持てる人です。車は一歩間違えると重大事故につながるので、安全やセキュリティ面でかなり高いものが求められます。技術に閉じるのではなく、安全かつ顧客に高い価値を届けているところまで見届ける姿勢が必要だと考えています。
最後になりますが、Turingでは完全自動運転EV実現や人類未到の課題の解決にみんなが燃えています。「自分たちがテスラを超える」そう思ってワクワクしていて、そういった雰囲気の中で一種の高揚感を持ちながら働ける環境です。人類のグランドチャレンジに向かって、一緒に最高の課題解決をしていきましょう。