「要求仕様が与えられない。そこに自動運転開発の面白さがある」組み込みエンジニアが大企業からチューリングに転じた理由

組み込みエンジニアとして、2024年11月にチューリングに加わった鈴木さん。Driving Softwareチームでは自動運転モデルの組み込み、車両制御、運転データ収集機能を1つに統合するプロジェクトを進めています。大手企業からチューリングに転身した動機、ミドルウェア開発・組み込み開発の醍醐味、自動運転開発の難しさとやりがいなどを聞きました。

AIと実世界の「つなぎ」の開発に興味があった

――鈴木さんが携わっている開発の内容について、教えてください。

所属するDriving Softwareチームでは、開発している自動運転システムに、自動運転モデルの組み込み、自動車の制御、運転データ収集機能を1つに統合するプロジェクトを進めています。

「Tokyo30」も実現間近で、もうすぐ自動運転が稼働し始めるフェーズを迎えています。でも、現状のシステムは運転データの収集と自動運転のプロセスが分かれていて、自動運転中に何が起きているのかデータを収集できない状態です。

自動運転中の運転データ、とくにユーザーの介入操作が発生した箇所は自動運転に失敗した箇所を意味する重要なデータです。今後の開発において必要となる自動運転中のデータも取得できるようにするのが、統合の狙いです。

自動運転ソフトウェアのカバー範囲は、ハンドルをどう切るかという制御のところからUIまで非常に幅広い。チーム全員の総力戦で取り組んでいます。

――パナソニック、デンソーと大企業でエンジニアとしてのキャリアを歩んできました。そこからなぜチューリングに？

前職のデンソーで、とくに不満はありませんでした。係長格から課長格への昇格試験も受けていたし、ずっと居続けるつもりでした。

ただ、しいて挙げるなら、技術エキスパートのキャリアパスが少なかったですね。自身の年齢的には「管理職になって大きな仕事の指揮に挑む」or「現場に居続ける」の分岐点にいたと思います。前職に限らず大企業は現場に居続ける道はあまりなく、そのような人材は少ないです。

――では、チューリングへの転職を決めたのは、技術エキスパートとして開発に携わりたいという動機が強かった？

そうですね。でもどちらかというと、完全自動運転にまつわるシステム実装がシンプルに面白そうだったからです。

もう少しかみ砕いて言うと、自動運転開発は推論AIが中心ではありますが、AIだけで運転はできません。AIと実世界をつなぐ部分が必ずあるわけで、その「つなぎ」のミドルウェア開発に興味があったんです。しかもチューリングは創業4年目で、時期的にもほぼゼロに近いところから関われるのも魅力でした。

それに、世界でただ一つの「前人未踏」の技術って、エンジニアとしてはやっぱり惹かれるものがあるんです。完全自動運転に挑んでいるプレーヤーは、少なくとも日本ではチューリングだけ。世界にインパクトを与えるような「前人未踏」の開発に携われるチャンスは一生に一度あるかないか。自分の人生を振り返ったときに「こんな開発をやったんだよな」と思い出に浸れるようなことをやってみたいと。人生一度きりだし、長いようで短いですからね。

――すごくわかります！　でも、当時は大手企業にいたわけですし、ご家族はチューリングという名前を聞いて「えっ？」となりませんでしたか。

なりました（笑）。でも、妻とコミュニケーションをした結果、最終的には「あなたがやりたいことを応援するよ」と言ってもらえました。

入社してすぐ気づいた、データ送受信の「異変」

――鈴木さんのこれまで培ってきた技術や強みは、どんなところで発揮されていますか。

※チューリングでは実機に触れる機会も多いです

私の得意分野は、動画を扱うシステム（テレビ、レコーダー）、OSカーネルのような比較的ハードウェア寄りのソフトウェア開発です。なので、チームではカメラ周りや現在位置などの入力を自動運転の推論へ渡す部分を、自動運転システムのデータ送受信で採用しているPublish/Subscribe（Pub/Sub）モデルの観点から見ています。

具体例を挙げると、Pub/Subモデルでは送信者と受信者が明確に分かれていて、1つのPublisherが複数のSubscriberにデータを送信します。データはPublisherからSubscriberへの一方通行で、SubscriberからPublisherにメッセージを送ったり、書き換えたりすることはできません。

とはいえ、PublisherがSubscriber全員にメッセージのコピーを作って配る実装だと性能が良くありません。そのため、自動運転システムではPublisherがメッセージを1つだけ特定の場所に置き、Subscriberはそのメッセージを見に行く実装にしていて、コピーを減らし性能向上を狙っています。

ところが入社したばかりの頃の自動運転システムでは、Subscriber側もメッセージを書き換えられるようになっていたんです。Subscriberの誰かが間違ってメッセージの中を書き換えると、ほかのSubscriberに届くメッセージもぜんぶ書き換わってしまう。実際それでバグが出ていて「あれ、おかしいな」と思ったんです。よく見てみると、カメラの画像データをSubscriber側が勝手に書き換えてしまって、書き換わったデータによってほかのSubscriberが誤動作していました。

Slack上で「赤い彗星」スタンプが頻発？

――鈴木さんが来てくれたおかげで、そのバグを解消できたということですね。そういえば鈴木さんは入社して2週間くらいで、Slack内で「赤い彗星」というスタンプをチームから頻繁に押されていた印象があります。

それは「リモート推論」という取り組みをしていたときの話ですね。将来的にJetson Orinでは性能が足りないようなモデルで推論したくなったときに「もっと強いGPUを積んだPCに推論だけ委ねる仕組みが必要だろう」と仮説を立てました。それを踏まえて、イーサネットでOrinからPCへ画像を送信してPCからOrinへ推論結果を返す仕組みを作りました。

そうしたら狙いどおり、推論の性能がOrinより3倍速くなったので、Slackに「3倍速いです」とメッセージを送ったら、同僚の渡邉さんが「赤い彗星」のスタンプを押してくれて（笑）。

※「赤い彗星」……アニメ「機動戦士ガンダム」に登場するジオン軍エースパイロット、シャア・アズナブルのこと。彼が駆る「シャア専用ザク」は通常の3倍の性能を有することから、転じて高速の性能を有する機体などを指すこともある。

――すごいですね！　鈴木さんはチーム内でも転がっているボールを拾うのを意識しているのですか。

そうですね。基本的には自分より明らかに得意そうな人、例えば自分の倍くらいのスピードで終わらせられるような人がいない場合、必要なボールは極力拾うようにしています。お見合いして誰もボールを取りに行かないのはもったいないし、私自身がなんでも面白がれる性分でもあるので。

――どんなボールも拾ってくれる人は、スタートアップだとめちゃくちゃ重宝される気がします。

確かに「鈴木さんっていろんなことができますよね」と言われることはあります（笑）。でも「いろんなことができるようになろう！」って頑張ったんじゃなくて。「やりたい」が先にあって、「いろんなことをやりたがってたら、できるようになってた」が近いです。

なんでも関心を持って、まずやってみるという姿勢は大切にしていますね。

「要求仕様がまだ決まっていない」自動運転開発の面白さ

――ほかのドメインの開発を数多く経験してきた鈴木さんから見て、チューリングの自動運転における組み込み開発の難しさは、どこにありますか。

いちばんは「要求仕様がわからない」ことですね。通常の組み込み開発だと要求仕様をだいたい決めてから開発を進めます。その要求仕様がない中で、探索的に開発をしなければならないのが自動運転開発の特徴であり、難しさだと思います。

――要求仕様がない中での開発は、具体的にどう難しいのですか。

例えば「ハードウェアの性能ってどれくらい必要ですか？」といった単純な問いにも、答えるのは難しいんです。今はNVIDIAのJetson Orinを使っているけど、これが最適解なのかはわからない。既に性能が足りなくなる傾向も見えています。

これから新たなハードウェアを自社で製造するのか。それともパートナーと提携するのか。それも含めてまだまだ手探りの要素が大きいと思います。

「前人未踏」の完全自動運転開発にはまだ「正解」がないし、他社の開発のアプローチもバラバラです。でも「前人未踏」だからこそ普通は取らないアプローチが取れます。例えば一見するとムダなものすごい性能のハードウェアを積んで実現してしまう方法が、後から見たら実は正解になることもあるんです。未知の領域の戦いができるのは、自動運転開発の面白いところでもあると感じています。

――要件仕様を決めるところからの開発は、これまではあまり経験したことがなかった？

そうですね。少なくとも量産プロダクトの開発では、プロダクトオーナーやプロダクトマネジャーでない限りは、あまり経験することがないのではないでしょうか。カローラの要求仕様を決めるトヨタのエンジニアは少ないはずです。

一方、チューリングだと「要求仕様がわからない」ので「そもそもこれで正しいだろうか」と問いを立てるところから始め、要求仕様を探索し、言語化する。その能力がチューリングではものすごく求められます。そのぶん大変だけど、何が起きるかわからないからワクワクしますね。

ミドルウェア開発に求められるのは「尖った技術」より「滅びない技術」

――鈴木さんにとって、組み込みエンジニアの面白さや醍醐味は何ですか。

組み込みエンジニアの役割は、限られたリソースと開発時間の中でうまく動作するシステムに仕上げること。単純に積んでいったら絶対に動かないものを「こことここを削ってみよう」と最適化を突き詰め、最終的にキュッと収まったときの「やった！」という感覚は、パズルが解けたときの達成感に似ていますね。

例えばパナソニックでテレビのファームウェアを開発していたとき、メモリの使用量がものすごく増えてしまって「ヤバいぞ」と焦ったことがありました。

テレビはUI、動画音声の再生、録画、番組表、最近だとネット動画アプリなどなど、多くのソフトウェアが同時に動作するため「たくさんのメモリ領域」を要求します。OSが必要に応じてソフトウェアにメモリの割当と解放を繰り返しますが、時間が経つとソフトウェアが使用しているメモリ領域は虫食い状（外部フラグメンテーション）になってしまいます。

一方で、いくつかのハードウェアは「大きな連続したメモリ領域」を必要とする制約があります。しかし、虫食い上になってしまったメモリ領域から大きな連続したメモリ領域は確保できないため動けなくなります。単純な解決策は、ハードウェア用に大きな連続した領域を予約してソフトウェアに使わせないことです。しかし、その分だけソフトウェアが使える領域が減ってしまい、動作可能なアプリが減って不便になりユーザに不都合が生じます。

単純な方法では、ハードの「連続で大きく確保したい」とソフトの「たくさん使わせてほしい」が相反してしまうんです。このジレンマを「ソフトウェアが使ってよいけど、ハードが固定で確保したくなったらソフトウェアは追い出す」仕組みを使って収めたことがありました。そのときはまさに「パズルがはまった」感覚がありましたね。

――同じチームの徳弘さんへのインタビューでも「トラブルなく安定的に使えるようにすることで、インフラに近づけていく過程が楽しいし誇りを持っているんです」というお話がありました。鈴木さんも同じような感覚ですか？

はい。トラブルもトラブルでけっこう面白いのですが……こういうと怒られるかな（笑）。でも、困りごとを解決するのが好きなのかもしれませんね。

あと、個人的にはインフラが安定稼働している状態で新しい機能を何の障害もなくスッスッと入れていくのは、エンジニアとして「腕の見せどころだな」って感じがします。

――自動運転開発と聞くとAIのどでかいモデルを開発するイメージが先行する一方で、デバイスに押し込んでいく量子化・最適化の世界もある。鈴木さんは後者に価値や面白さを見出してるのですね。

そうですね。チームに関して言うと、世界唯一の技術みたいなものを扱っているわけではないし、目的にもしていません。組み込み開発はすべてを結びつける「ノリ」みたいな役目を果たすものなので、どちらかというと「これは長く使えそう」という技術の選定眼を持っている人が求められると思います。

せっかく膨大な労力をかけて自動運転システムを作ったのに、1年後に「この部品がなくなっちゃいました」というのでは困りますよね。その意味で、組み込み開発では新規性よりは安定性が重視されます。新しい技術に関心を持ちつつ、安定性を維持できる開発を好む人のほうがいいかもしれませんね。

華のあるAI開発に比べると、組み込み開発は地味な存在です。でも、苦労して作ったものが実世界で問題なく動いて、社内・社外問わず使っている人たちに「ありがとう」「便利になったよ」と言ってもらえる。それが何より嬉しいですし、“組み込み屋”冥利に尽きますね。