System Software Team x CTO 座談会 【前編】
フルスタック組織における低レイヤ開発への期待
Computing Workshop を主催した高野率いる System SoftwareチームとCTOが、自社オペレーティングシステム (OS) 開発、形式検証といった「低レイヤ」の面白さについて語り合いました。
カーネル開発や形式検証など、様々なコンピュータサイエンスのバックグラウンドを持つメンバーたちが、フルスタック組織における低レイヤ開発への想いと、一緒に働きたい人物像について話します。
「前編」では、OS開発に向ける期待や、それぞれの「やりたいこと」について語りました。
「アプリケーションをわかっている人」がOSを作る - 通常のOS開発と逆のアプローチ。
2022年4月 入社。『ゼロから学ぶRust』講談社 (2022)、『並行プログラミング入門』（オライリー・ジャパン、 (2021) 、の著者。大阪大学 招聘准教授。TIER IVではSystem Software Teamチームのチームリーダーを務める。Computing Workshop では 『seL4チュートリアル』を発表。
2022年 4月 新卒入社。専門分野はオペレーティングシステム、リアルタイムシステム。東京大学情報理工学系研究科コンピュータ科学専攻の社会人博士課程にも在籍。TIER IVではAutowareのリアルタイム性能に関する低レイヤソフトウェアなどを担当。Computing Workshop では 『Autowareにおけるリソース競合の定量化』を発表。
東京大学 大学院情報理工学系研究科 コンピュータ科学専攻 特任准教授。世界初の自動運転技術のためのオープンソースソフトウェア「Autoware」を開発した。ー集まっていただきありがとうございます。「それぞれの面白いと思っていることや、やりたいこと」をテーマに皆さんの考えを聞かせてください。
石川 今、社内でOSを作ろうとしていますよね。自分達の強みはアプリケーションが社内にあって、そのアプリケーションに最も近い人たちがOSを作る点です。とても尖ったものができるんじゃないかと、期待しています。
加藤 つまり、アプリケーションに近いところをやってる組織でOSを作るべきだと。
石川 「OSを作ってる人たちがアプリケーション開発もするべき」ですね。僕も相当Autoware.Universeにコミットしてます。なので「こういうOSの機能があった方がいい」とか、「OSとアプリを一体化させる」とか、過激な思想ができてしまいます。低レイヤ開発の世界には、アプリケーションに興味がないタイプの人もたくさんいるのですが、方向性を変えるのも良いかなと。「ハッカー気質のある人が、アプリケーションにも真面目に取り組みつつ、OSを開発すると次のパラダイムシフトが作れるのではないか」そう思いながら働いています。
加藤 一言で言うとフルスタックだよね。私がTIER IVで作りたい組織は超絶フルスタックみたいなもの。組織自体に「アプリケーションを知っている事」が内包されているので、結果いいOSが作れると。
石川 難しいのが、組織がフルスタックなだけだとダメな点。組織の中に本物のフルスタックエンジニアが必要なんです。
高野 僕もその意見わかります。まず「キラーアプリがある」というのが大きいですね。普通、OSを作ってもアプリがないんですよ。だからOSに最適なアプリを探さないといけなくなりがちです。TIER IVではそこが普通のOS開発と逆になってます。要求があって、「これはOSが必要だよな」と。シーズじゃなくてリクワイヤメントから出てきてる。すごい面白いなと思っています。
形式検証 - 低レイヤのやりたいことをやる
2023年 新卒入社。専門は形式検証。Computing Workshop では 『UPPAALによるAutowareの形式検証』 を発表。TIER IVでは形式検証・OS開発・パフォーマンス改善を担当。加藤 神戸くんはどうですか。低レイヤの仕事って社内でもそこまで多くないので、やることを見つけるのも簡単じゃないですよね。「何でもやっていいよ」って言われてる状態ですし。
神戸 専門が形式検証なので、僕の立場としては自動運転に形式検証を入れたいですね。形式検証をアプリケーションレイヤにも入れるし、OSレイヤにも入れる。これは面白いですよ。
加藤 形式検証とか形式手法って、まずどこから入っていこうと思ってる？フルスタックの中で。
神戸 同時に進めていますね。Autoware、つまりアプリケーションの方にも入れるし、OSにも開発途中から入れていこうとしています。
加藤 進める方は方法論から考えたい感じ？それともツールから考えたい？
神戸 どちらかというと、「使えそうなツールを一通り試してから、ベストなものを後で決めよう」ってフェーズですね。
Computing Workshop の 『UPPAALによるAutowareの形式検証』 より。
石川 かなりボトムアップにやってますね。方法論よりも作業から始めてます。
高野 今はツール選定と、「何ができるか」について、ちゃんと技術的な確立をするフェーズです。上手くいけば、将来的にコンサルタントとかもやりたいと思っています。
加藤 System Software Team では既に具体的なチケットとか切ってるんですか？ 形式手法を使うものに。
神戸 MRM*と、OSの一部への適用を検討しているところです。
アプリケーション全体を見るとMRMは独立していて適用しやすいし、状況に応じた分岐が多いので人の目で安全か判断するのは難しい部分だからです。
*MRM: Minimal Risk Maneuverの略。緊急時に縮退運転や停止する機能。CTOのやりたいこと - 大事な部分を超真面目にやる
加藤 最近チップの性能が良くなってきて、ゾーンアーキテクチャって言葉が出てきました。 大きいセントラルコンピューティングユニットと、ゾーンっていう考え方で構成されています。このゾーンっていうのは1個のECUの中に閉じててもいいし、複数のECUから1個のゾーンが構成されててもよくって。
加藤 で、ゾーンコントローラーってやつがいわゆるOSで、ネットワークプラスそのコンピューティングリソースを管理してくれている。アプリケーションを書く人は、ゾーンを気にすれば良くて、どのECUで動かさなきゃいけないとかは理想論で言うと気にしなくていい。このゾーンコントローラーってやつは安全じゃなきゃいけないけど、ECU単体になってて、そんなハイスペックじゃなく、機能もすごい限定的。これを超真面目にやりたい。例えばISO 26262*に則ってて、Formally Verifiedされていて、全部Rustで書かれてて、それで自社チップ。
*ISO 26262: 車載向け電気・電子システムの機能安全についての国際規格神戸 それはやりましょう (笑)。
高野 それはやりたい (笑)。
「やりたくないこと」と自分たちの理想 - AutowareをRustで書き換える?
加藤 そういえば、高野先生チームは「バグを出したらいかんぞ」と常日頃言っているらしいですね。
高野 バグで自動運転車が事故るのは本当にやめたいんです。プランニングとかはまだ発展途上なので、バグをゼロにするのは難しい部分もあると思います。ですが、「バッファーオーバーランで人ひきました」は絶対やりたくないんです。
加藤 「ソフトウェア」のバグですね。
高野 潰し方が方法論として確立しているものもあります。それをあとは適用するだけなので、避けられるものは避けたいです。
石川 僕らとしてはそういう理想があるけど、社内では思想が強すぎると言われます (笑)。やりたいことは、要するに全部Rustで書き換える、Autoware カーネル*上では全部カーネル空間でアプリケーションが動く。
*Autoware カーネル: Autoware向けにTIER IVが開発しているRust製のOS。神戸 外部ライブラリを使わない。
高野 あとリアルタイムガチガチ (笑)。
石川 でもそういうことを言うと、「C++でこんなに開発頑張ってるのに、Rustに移植するんですか」となるんですよね。OSSコミュニティのみんなで作っているものなので、当然なのですが。
加藤 いろんなことを試していけばいいと思うんですよね。せっかくトランスフォーマーとか出てきてるんで、「ちょっとトランスフォームの意味を間違えちゃった」 、「これ楽にRustに書き換えられちゃいます!」みたいな (笑)。
石川 テクノロジーで解決しましょうっていう立場をとることは必要ですよね。
System Software Team x CTO 座談会 -フルスタック組織における低レイヤ開発への期待 後半へ続く。
TIER IVではOSを作成、Linux Kernelを改造したいソフトウェアエンジニアを募集してます。
お問い合わせ先
メディア取材やイベント登壇のご依頼：pr@tier4.jp
ビジネスや協業のご相談：sales@tier4.jp.
ソーシャルメディア
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
関連リンク
