2015年以降は毎年走行体が変更される可能性も

さらにこのアドバンストクラスの2015年以降の話もすると、プライマリークラスが参加年数の長いチームは代々先輩から引き継がれたノウハウがあるため、もちろん引き継ぎを行うこともまたいい経験となるだろうが、引き継ぎさえできてしまえば、少しパラメータを変えるだけでいいタイムが出てしまうという大きなメリットもあった。つまり、1からやらなくても済んでしまう、という点である。

そこでアドバンストクラスでは、毎年走行体のデザインを変えるなどして、「ノウハウが貯まらない」ようにするという。もちろん長く参加していれば絶対に何らかの経験は蓄積されてくるわけだが、それでも毎年毎年、参加チームが1から挑戦できる形にするという。

このように2部門3クラスが用意されて幅が広がってきたことで、実行委員会としては制限そのものは行わないが、プライマリークラスは入社2～3年目までの「初級」エンジニアや学生(高校生以上が参加可能)チームに参加してもらうことを基本とし、中堅以上のエンジニアは、アドバンストクラスか、アーキテクト部門に参加してもらいたい、という意向である。

完全な規制をかけないのは、中堅・ベテランエンジニアがコーチや監督として加わることもあるためだ。コーチや監督なら問題ないが、主力となってしまうのはできれば遠慮してもらいたいというのが実行委員会の考えである。もちろん、優勝するまでがんばるというのももちろん立派な姿勢ではあるのだが、中堅以上のエンジニアが主力として参加し、それでなおかつ3年、4年…とプライマリーに参加し続けるのは、あまり望ましいものではないとしている。

なお、順序としては逆だが、アドバンストクラスが設立されるに至った理由としては、デベロッパー部門の課題がいくつか挙がっていたからだ。まず優れた点を挙げると、「走行制御のしやすさ(ライントレース、並行2輪による方向転換の自由度)」、「ほどよい不安定さ(性能と安全のトレードオフ)」、「教育ツールとして定着(企業・大学などの教育で活用)」、「モデル・走行結果の相関が定着(良いモデルの走行体が良い走行結果を出す)」というところ。

それに対して課題は、「NXTによる走行体は2009年から使用されており、基本技術が攻略されてしまっており新鮮みが少ない」、「アーキテクチャがワンメイクのためモデルがどれも似たようなものになってしまう」、「5年間のノウハウが蓄積され、モデルやソースコードなど、過去資産の再利用によるチャレンジ度の低下」、「同じようにノウハウの蓄積量の差から、初参加と経験者とのレベル差が拡大してしまっている」、「競技内容と開発現場とのズレ」が挙げられた。これらの課題に対する解決への方向性として、継続性を確保しながら新しい課題に挑戦できるようにということで、アドバンストクラスが考え出されたというわけだ。

コースに関しては、プライマリーがベーシック+少ない難所ということで、難易度は2013年同様で、アドバンストはベーシック+多い難所、それとショートカット、そして前述したが当日になってみないとわからないという「理不尽な仕様変更」がキーワードとなるというわけだ。どんな形で行われるのかは、また東京地区大会やCS大会を今年もお届けする予定なので、楽しみにお待ちいただきたい。

さらにモデルに関しては、今年は2部門3クラスで、それぞれの特性に合わせた3つの異なる審査規約で評価するとしている。アドバンストの場合の審査項目は「ソフトウェアアーキテクチャ」と「制御戦略」で、審査内容としては審査項目の前者が「仕様変更への迅速な対応」、後者が「NXTrike走行体の特性を活かした制御戦略」とした。また、アドバンストクラスのモデルに対する実行委員会側からの期待としては、「「理不尽」に対応できる(柔軟な)ソフトウェア設計」、「新しい走行体を駆使するための制御戦略」としている。

またプライマリークラスとアーキテクト部門に関しては、大きな変更はないが、前述したようにモデルに関してはそれぞれポイントが異なるので補足しておく。まずプライマリーの審査項目は「モデリング能力」と「要素技術」の2点。それに対する審査内容は、前者が「ソフトウェアの内容をモデルで正しく表現」というものと、後者が「要素技術の習熟」としている。

アーキテクトの審査項目は「システムアーキテクチャ」と「技術要素」で、審査内容は「システムの構成・動作原理」と「パフォーマンスを支える各種技術」だ。アーキテクトはモデルだけでなく「企画書」が必要なのだが、その点についても触れておくと、これは昨年と変わらずに「製品企画の良さを優先して審査する」としている。そして、「Howよりは、Why/Whatを重点的に評価する」とした(WhyとWhatの明確な記述が求められる)。

アーキテクトのモデルは企画書の一部に含まれるのだが、ポイントとして「ソフトウェア詳細ではない、システムレベルでの構成や動作原理の記載」と「パフォーマンスを裏付けるさまざまな技術要素」とした。審査項目・内容としては、「わかりやすく書かれているか」、「モデルの良さ(How)」、「パフォーマンスプランの良さ(Why・What)」となっている。

なお、アーキテクトはエンジニアのプレゼン能力を高めるということが狙いなのだが、マイクパフォーマンスが得意な営業畑の社員にチームに加わってもらうのは、今後もありなのかどうかという点に関しては、まだアーキテクト自体が始まったばかりなので、今のところはありで、エンジニアはそうした人たちのいいところを学んで、数年後にはマイクパフォーマンスもエンジニアだけで行ってほしい、とした。