ティアフォーのコアともいえるオープンソース自動運転ソフトウェア「Autoware (オートウェア）」をテーマに、エンジニアたちが座談会を開催。語られた内容を3回にわたってお届けします。
Autowareエンジニア座談会【前編】では、黎明期から携わるメンバーがAutowareの成長プロセスを振り返りつつ、最近入社したメンバーが入社前後の印象や思いを語りました。
中編となる今回は、OSS（Open Source Software）を手がける面白さや、今後の課題などを語ります。
Ise Gakuki｜ CTO Office
伊勢：Autowareは、ティアフォーのものではなく「The Autoware Foundation（AWF）」で開発・拡大を進めています。
OSS （Open Source Software）に携わることの面白さ・喜びなどを聞かせてください。
Ota Satoshi｜ Planning/Control Team
太田：この1年で、ティアフォー社外からAutowareの開発に加わる方が大きく増え、よりOSSらしくなったと思います。自動運転の開発をしていると「あれをやらなきゃいけない」って思うものの、なかなか手が回らないこともあります。そのような時に「これ、やりたいけどできてないんだよね」ってみんなが見える形で課題を示しておくと、「それやるよ！」って言ってくれる人が現れるようになりました。そういう機会があるたびにOSSの強みや影響力、面白さを感じますね。
伊勢：外部コントリビューターについては、「知らない間にドキュメント書いたりバグを直してくれたりする人がいてうれしい」と、三宅さんも話していましたね。
三宅：そうなんです。何もお願いしてないのに、親切に直してくれる人が思ったよりもいて、うれしいですね。
伊勢：Autowareを使う側のSystem Integration Teamの三浦さんは、そのあたりはいかがですか？
三浦：私達は2週間に1回、お台場でロボットタクシーの走行実験をしています。そこで出た問題は基本的に自分たちで解析して、解決してます。解析が難しいものや仕様変更、機能開発が必要なものに関しては、各コンポーネントのチームに修正依頼をしていますが、Autowareの レポジトリを見に行くと「これで直るんじゃないか」というプルリクエスト（PR）を見つけたりします。実際、その方法で問題が解決することも多い。それもここ1年ほどでAutoware.Universeが拡大して、ユーザーやコントリビューターが増えてきたおかげだと思います。
伊勢：知らないところで誰かが作ってくれている。まだまだ規模が小さく、人数が限られているティアフォーとしては有難いですよね。
Miura Takeshi｜ System Integration Team
三浦：自分たちでできるテストの回数などは限られているので有難いです。より多くの人が使ってくれるようになり、改善スピードが上がっていくとうれしいです。
伊勢：今はAWF以外の人から、修正や提案が次々と入ってきている状態なのでしょうか？
満留：PRまで出してくれるのはAWFに関わっている人が多いですね。
ただ最近では、「CARLA（カルラ）」という自動運転シミュレーターとAutowareをつなげてくれる人もいるんです。「CARLA経由でAutowareを知った」という人がワーキンググループに参加してくれたりして、外部からの参入者は増えていると思います。それ以外にも「とりあえず使いたいんだけど」と質問をしてくる人も増えています。これにしっかり応えることで、ティアフォーやAWF以外のメンバーを増やしていきたいです。
伊勢：会社だけでなく、個人も増えると良いですね。
満留：はい。研究室にいる方や学生さんなどには、使いやすいのではないかと思います。
伊勢：「質問にしっかり応える」という点では、AutowareのGitHub Discussionsに来た問い合わせについて、みなさんよく話しているように思います。実装した人が答えてたりして、ユーザーと開発者の距離が近いんだなと、傍から見ていて感じます。
李：ユーザーに近いのがとても良いと思います。僕は大学や企業で研究開発をやってきましたが、ユーザーから生のフィードバックをもらえる機会が少なくて「これは果たして、どれくらい意味があるのか」と悩むことがありました。
そういう意味では、ティアフォーのOSSでは、多くの人に使われるAutowareにコミットしていると手応えが感じられます。自分が作って把握している機能にフィードバックが来て、問題を解決できれば感謝される。そうしたユーザーとの距離の近さが良いし、楽しいです。
Yabuuchi Kento｜ Localization Team
籔内：僕は最近は自分でコミットすることはあまりなくて、PRレビュー、つまりフィードバックを送ることが多いです。「ここのコードはこうした方が早いよ」とか「これは不要だから消した方がいいよ」とか。
バグを見過ごすわけにはいかないという責任感と、我が身のこととしてコードをチェックする役割を担い、それによりソフトウェアを育てられるところが、OSSの面白みの一つかなと思います。
伊勢：逆にOSSという形で、関係者が増えて大変なところはありますか？
Mitsudome Ryohsuke｜ Architect
満留：自分たちのソフトウェアではないので、変更や機能追加をする時にコミュニティ内で合意をとる必要があります。GitHubにディスカッションを立てるのが全ての始まりで、そこで「いいね、やろう」となったら大枠を決めていきます。ある程度固まったらコミッティーからの意見を仰いで、アプローチに対する合意がとれたら、イシューを作り担当（個人や団体）をアサインします。レビューワーはその分野に詳しい人や、元となるコードのオーナーにお願いしています。以前からなんとなくの流れはあったのですが、みんながコントリビューションしやすいように、最近プロセスが固まってきました。
ただプロセスが固まったといっても合意に時間はかかるので、その点は内部だけで開発するより大変です。それでも多様な開発者、団体と議論しながら開発しやすくなってきたのは確かですし、トータルで見ればティアフォーだけで開発するよりも効率が良く、正しい方向に進んでいると思ってます。
伊勢：OSSの難しい部分や取り組むべき課題などについては、どう捉えていますか？
満留：OSSだからといって、誰でも使ってくれるわけじゃないんですよね。本当に良いものじゃなければコミュニティは育っていかない。ティアフォーが独りよがりなことをしていたら「付き合ってられない」と、離れていくかもしれない。
だから、「みんなで作っているもの」と理解した上で、みんなの興味が離れないようにどんどん新しい機能を付けて、「ちゃんと良いものができている」とアピールしていく必要があると思っています。そこはプレッシャーを感じる部分ですね。
そして、機能を充実させつつ「安全だ」と言えるようにしなければなりません。みんなが好きなように使えるものなので、100％安全と言い切るのは難しいですが、「最低限こういう条件であれば、こういう性能を発揮できる」と、仕様を出すぐらいまでは必要で、そこは課題かなと思います。
レビュアーに全責任を押し付けられない。CI/CDを改善し、フレームワークとして様々なユーザーのユースケースをサポートできるようにしていく事が、チャレンジングな部分だと思います。
伊勢：OSSの枠組みの中で、そのチャレンジングな、多様なユースケースに、どのように対応を進めていますか？
Maxime Clement ｜ Planning/Control Teamt
Maxime：対象のODD (Operational Design Domain) を決めながら、AWFメンバーと協力しつつ行っています。どのODDでもアプローチは同じで、誰かが持ってきた問題を、内外のメンバーで議論して解決策を見つける。これの繰り返しです。多様なバックグラウンドの人がいるので、提起される問題や課題も様々ですね。
例えば、車体の大きさ由来の問題です。以前はCargo Transport（小型牽引車）に取り組んでいたのですが、最近Shuttle BusのODDの開発が始まりました。バスサイズの車両を扱おうとすると、Control/Planningの部分で車両サイズに起因する問題が出てきました。
今はAWFでこれに関するディスカッションをしています。他の誰かが持ってきた問題に対して、ティアフォーの考えるソリューションを提案することもありますし、ティアフォーが解決に困っている問題を提起することもあります。各々が問題を持ち寄り、持ち帰って検討して、また話し合う、この繰り返しで開発を進めてます。
伊勢：多様なメンバーとのコラボレーションやディスカッションと聞くと、いろいろな視点を持てる一方で苦労もありそうですね。
満留：アーキテクチャのレベルでは意見が割れたこともありました。みんなそれぞれバックグラウンドが異なるので、話し合いを重ねて折り合いをつけたり、いずれかが折れる形で解決したりもしました。
そのような経験を経て、「Autoware Core/Universeで最低限のインターフェースを集めて、アーキテクチャはそれぞれが好きなように作れるようにしよう」とか「ティアフォーの実装はこういうアーキテクチャだけど、別のアーキテクチャプランを作りたい人がいれば、それを認めて入れ換えられるようにしよう」という形ができました。
「切り替えられるようにすれば何でもいいよ」ということにしたので、その点はかなりやりやすくなりました。
Miyake Kenji｜ CTO Office
三宅：自動運転のユースケースはたくさんありますし、やってみないと分からないことも多いので、アーキテクチャ設計はとても難しいですよね。 だからこそ、やりがいがあって楽しい部分でもあります。
Maxime：難しさや苦労で言うと、異なるコンポーネント間のコラボレーションが未だ十分ではない時がありますね。開発において、私はPlanning/Control担当なので、PerceptionやLocalizationを担当するメンバーとの協働をもっと増やしたいと思ってます。これがないと、機能デザインの議論をする時に他の立場からの視点が欠けてしまいがちなので。例えば、Planningの設計者は「障害物の検出タイミング（タイムスタンプ）が正確である」という視点で考えてしまいがちですが、Perception側の人は実際の認識性能を考慮して設計するという視点を持ってます。多かれ少なかれ、これは内外での開発活動に共通の課題ですね。他のコンポーネントを担当している人の考え方をどんどん取り入れるために、オープンなディスカッションをもっと増やしたいと思います。
伊勢：利用する上でのチャレンジについても聞いていきます。OSSだとリリースの時、「いつの間にかここが変わってる」ということもあると思います。製品を作り評価する上で負担にはならないでしょうか。
太田さん、Planning/Control Teamの立場としていかがですか。
太田：Autowareはガンガン開発が進んでいるため、リアルタイムにすべての差分を把握するのは困難で、「いつの間にか変わっている」部分が多くあります。そのような中でのリリースは、バグが大量に見つかることも多くなかなか大変です。
だからこそ、日頃からバグをなるべく少なくすることが求められると思うのですが、ここは満留さんが言うCI/CDの改善でカバーしていきたいですね。
最近は誰でも開発に参加できるようになったからこそ、よりいっそう機能の保守にも力を入れて、リリース時の評価を少しでも楽にしたいと思っています。
満留：CI/CDで言うと、Localization機能はテストをするためのシナリオを作るにも、センサーデータが必要なのでまだ間に合っていないんですが、方針はできてきています。
李：現状Sensing/Perceptionでは、過去の実車走行で不具合があったシーンのデータ群を使って定性的に評価をしていますが、もう少し定量的にしたいです。あとは認識の部分だけで評価するのではなく、後段のPlanning/Controlとの統合評価もできるようになるともっと良いですね。
次回の「後編」では、ティアフォーの「組織」に対して感じていること、求める人材像についてお届けします。
オープンソースのソフトウェアを一緒に開発していきませんか？
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
Media Contact
pr@tier4.jp
Share the post
LinkedIn | X | Facebook | Instagram