[2013 年 3 月号]

[ レポート ]


ET ロボコン 2012 チャンピオンシップ大会
ワークショップレポート

- 本当の 「 モデル駆動開発 」 への途 -

株式会社 オージス総研
組み込みソリューション第二部
手嶋高明

2012 年 11 月 14 日 ( 水 ) 、15 日 ( 木 ) の 2 日間、パシフィコ横浜で ET ロボコン 2012 チャンピオンシップ大会が開かれました。本記事では、大会 2 日目に行われたワークショップについて筆者が気になったトピックを所感を交えて紹介します。2013 年の ET ロボコンがすでに始まっていますが、2012 年を振り返るきっかけになれば幸いです。

大会 1 日目に行われた競技については下記サイトで紹介されています。ぜひご覧ください。

また、弊社新人が執筆した参戦レポートも公開中です。参加者視点で書かれた内容ですので、こちらもぜひご覧ください。

目次

1. 2012 年の振り返り

1.1. 有効活用され始めた要求モデルと、価値の薄れるユースケース

1.2. アーキテクチャは集約傾向

1.3. 本当の 「 モデル駆動開発 」 には道半ば

1.4. 競技波乱を招いたロバスト性の欠如

2. 2013 年へ向けて

2.1. キレイなモデルを評価するのはおしまい、手垢にまみれたモデルを期待

3. 筆者感想

3.1. レース戦略 ( 作戦 ) も重要に

3.2. 千差万別のアーキテクチャに期待

3.3. 「 モデル駆動開発 」 は意識や習慣づけから

4. 最後に

1. 2012 年の振り返り

渡辺氏 ( 審査委員長 ) と河野氏 ( 性能審査団 ) より、2012 年のモデルと競技の傾向について発表がありました。その中で、筆者が気になったトピックをいくつか紹介します。

*1左 : 渡辺博之氏 ( 審査委員長 )
右 : 河野文昭氏 ( 性能審査団 )

1.1. 有効活用され始めた要求モデルと、価値の薄れるユースケース

要求モデルは、「 完全に定着し、有効活用されている。( 渡辺氏*1 ) 」 と振り返りました。2011 年のワークショップでは、審査員から 「 要求モデルの分析が足りていない。」 と指摘がありましたが、2012 年は改善し、「 何をやりたいのか、そのためにどんな課題があるのか、課題をどうやって克服するのか、といった流れが非常に明確で、審査員が腑に落ちる形で理解できた。( 渡辺氏*1 ) 」 と評価しました。

しかし、要求モデルがその価値を高めたことに反比例して、ユースケースの価値は低下したようです。ユースケースは、システムが提供する機能を表すモデルで、ET ロボコンでは、要求モデルから洗い出した機能要求や非機能要求のうち、機能要求をユースケースで表すといった使い方がよく見られます。

ですが、要求モデルの内容が充実したことで、システムが提供する機能や機能間の繋がりを要求モデルでも把握できるようになりました。審査員は 「 要求モデルで全て ( 機能要求や非機能要求 ) が書かれているのに、あえて一部 ( 機能要求 ) だけユースケースで提示する使い方が散見された。改めて、ET ロボコンにユースケースは必要か、必要なら何のために書くのか議論が必要。( 渡辺氏*1 ) 」 と語りました。

要求モデルにユースケースを取り込んでしまうのか、それとも、ユースケースに独自の価値を見出すのか、今後は機能の表し方にも各チームの特徴が大きく表れるかもしれません。

1.2. アーキテクチャ*2は集約傾向

ルールに大きな変化がなかったこともあり、2012 年のアーキテクチャ*2は 2011 年の延長で集約傾向にあったようです。「 ライントレースのアーキテクチャ*2は大体固まった。( 渡辺氏*1 ) 」 と述べていました。具体的には、「 コース 」 を 「 区間 」 に分け、区間を 「 走行 」 と 「 条件 」 の組み合わせでクリアする形が多く見られ、また、「 走行 」 と 「 条件 」 の部品化も進みました。

ライントレースのアーキテクチャ例
※発表内容をもとに筆者作成

Bluetooth 通信を活かし、分散アーキテクチャにチャレンジしたチームも見られたようです。例えば、走行体から送ったデータをもとに PC で復帰ルートを検索するチームがありました。ただこれについては、「まだ ( 走行データなど ) 単純なデータやり取りに留まっている。( 河野氏*1 ) 」 と述べるなど、審査員は物足りなさを感じており、「 通信のメリットを生かせるようなルール変更が必要。( 河野氏*1 ) 」 という認識を示しました。

*2基本設計や設計思想、およびそれに基づき構築された構造。

1.3. 本当の 「 モデル駆動開発 」 には道半ば

ライントレースのアーキテクチャは固まったものの、まだ本当の 「 モデル駆動開発 」 には至っていないと指摘がありました。特に、「 開発初期に動作を検証できたり、開発後にエビデンスとなり得る ( 動作を保証できる ) モデルには至っていない。( 渡辺氏*1 ) 」 と語りました。

その中で、エクセレントモデル ( モデル部門 1 位 ) を獲得した 「 みらいまーず 」 は、本当の 「 モデル駆動開発 」 に近づいている例として挙がりました。特に、振る舞いモデルの評価が高く、他のチームが曖昧な振る舞い記述に留まる中、「 みらいまーず 」 はオブジェクト間の振る舞い ( シーケンス図 or コミュニケーション図 ) に加え、コアとなるクラスについてはオブジェクト内の詳細な振る舞い ( ステートマシン図 ) まで示しており、その点を、動作の検証や保証が可能なモデルとして評価していました。

余談になりますが、過去 2010 年のワークショップでは、審査員から 「 構造が貧弱なために、振る舞いが複雑になっている。」 と指摘がありました。当時は、構造面での責務分担を十分に行わず、すべて振る舞い面で解決しようとするモデルが多く見られました。つまり筆者が思うに、2012 年に 「 詳細 」 な振る舞いモデルが評価されたのは、アーキテクチャ*2が十分に成熟し、構造モデルが一定レベルに達した証拠だと考えています。まだ本当の 「 モデル駆動開発 」 に至っていないと指摘はありつつも、ET ロボコンのモデルは年々着実にレベルアップしていると感じました。

1.4. 競技波乱を招いたロバスト性の欠如

2012 年の競技は、ベーシックステージの完走率が 50% 未満という波乱の結果となり、90% を超えていた 2011 年と比べて大きく低下しました。競技会場は同じでしたが、2012 年は天井のダウンライト*3を点けたことが影響したようです。ちなみに、2011 年は節電のため消していたそうです ( 噂 ) 。

ここからは筆者の予想となりますが、複数の参加者が、「 コースの場所によって、同じ色でも光センサの値が大きく異なっていた。」 と話しており、想像するに、指向性の高いダウンライト*3によって、コース上の照度が斑 ( まだら ) になっていた可能性があります。ラインを光センサで認識する走行体にとっては大きな試練です。

コース上の照度が斑 ( まだら ) に
※イメージ

効果のあった対策は、「 2 輪倒立走行 」 と 「 まいまい式 」 だったそうです。「 2 輪倒立走行 」 は、ここ数年流行っている尻尾走行に比べ、光センサが地面に対してほぼ垂直に向くため、ハードウェア的に真上からの外乱光の影響を受けにくい特徴を持っています。「 まいまい式 」 は、ソフトウェア的に外乱光の影響を軽減します。これらの対策を行わなかったチームの多くはリタイアしてしまったようです。実行委員も 「 意図しない結果 」 と述べていましたが、ダウンライト*3点灯によって、ロバスト性 ( 外乱に対する耐久性 ) の欠如を浮き彫りにする結果となりました。

*3天井に埋め込まれ、真下の比較的狭い範囲を照らす照明。

2. 2013 年へ向けて

2.1. キレイなモデルを評価するのはおしまい、手垢にまみれたモデルを期待

審査委員長の渡辺氏*1は、これまでの 11 年間を振り返り、まだ出来ていないこととして次の 3 つを挙げました。

これを踏まえ、「 設計としてキレイなモデルを評価するのはおしまい。2013 年以降は、本当の意味での『 モデル駆動開発 』やロバスト性を持った『 組み込みアーキテクチャ 』をテーマに、実際の開発で使ってきた有効性のあるモデル ( 手垢にまみれたモデル ) を目指してほしい。( 渡辺氏*1 ) 」 と述べるとともに、「 そういったモデルを目指せるようなルールを考えていきたい。( 河野氏*1 ) 」 と語りました。

3. 筆者感想

2012 年の ET ロボコンを通して、筆者が感じたことをいくつか取り上げます。何かのきっかけや参考になれば幸いです。

3.1. レース戦略 ( 作戦 ) も重要に

2012 年の競技はダウンライト*3に悩まされたことから、システムのロバスト性 ( 外乱に対する耐久性 ) に注目が集まりました。2013 年は多くのチームがロバスト性の向上に力を入れると思われます。ただそれに加えて、「 システムをどう使いこなすか。 」 といったレース戦略 ( 作戦 ) も重要になるのではないかと考えています。と言うのも、筆者が聞いたところでは、ダウンライト*3対策に効果のある 「 2 輪倒立走行 」 や 「 まいまい式 」 を準備していたにも関わらず、走行スピードを優先して使わない選択をした結果、リタイアしてしまったチームがありました。

システムは道具ですので、システム自体は万全でも、使い方を誤ってしまっては良い結果は得られません。特に、ロバスト性を高める対策は走行スピードとトレードオフになる場合が多く、難しい選択を迫られます。他チームの状況 ( 試走結果や競技タイム ) なども考慮するなら尚更です。大会当日の追い込まれた心理状態の中で最良の選択を行うことは望むべくもなく、事前にしっかりと検討しておく必要があります。

今後は、システムの良し悪しだけでなく、それを使いこなすレース戦略 ( 作戦 ) の良し悪しも、競技結果に大きく影響してくるのではないでしょうか。

3.2. 千差万別のアーキテクチャ*2に期待

上で紹介したように、ライントレースのアーキテクチャ*2はほぼ固まったという声が聞かれました。ルールが大きく変わらない中で、時間の経過とともに一つの形に収束するのは自然な流れかもしれません。しかし裏を返せば、どのチームのアーキテクチャ*2も似通ってきたと言え、少し残念に思います。

アーキテクチャ*2は、システムの品質などに大きな影響を与える根幹であるとともに、モデルに込めた思いや考えが表れやすい部分です。それ故に、チームの特色を生かしたアーキテクチャ*2が数多く出てくれば、モデルを見る楽しさや面白さも一層増すはずです。収束を経た後に、次の成長に繋がるような革新を起こす、2013 年はそんな千差万別のアーキテクチャ*2を楽しみにしています。

3.3. 「 モデル駆動開発 」 は意識や習慣づけから

筆者は、「 東京連合 」 という ET ロボコンのコミュニティ活動を行っています。その活動を通して各チームの開発する様子を眺めていると、分析や設計の段階において、実はまだ多くのチームがコードを書いた後にモデルを作っていると感じます。具体的には、「 頭の中で考え → コードを書いて動かし → 動いたコードをモデルに反映する。」 というように、コード先行で開発を行っている場面をよく見ます。

このやり方でも、コードをモデルへ反映する作業を怠らなければ、最終的にモデルとコードは一致します。しかしこの場合、モデルは開発の出力でしかないため、「 動作検証のためにモデルをどこまで具体化すればよいか。」 や「 動作保証のためにモデルで何を示せばよいか。」 といった感覚は身に付かないように思います。恐らくはモデル自体も、取って付けたものになるのではないでしょうか。

「 モデル駆動開発 」 はテクニック的な話もさる事ながら、「 まずモデルで考える 」 という意識や習慣づけが大切だと感じます。そうすることで、モデルが開発の入力になり、フィードバックが繰り返され、動作の検証や保証が可能なモデルにも近づくのではないでしょうか。

組み込み開発の場合、ハードウェア特性や要素技術の調査、パラメータのチューニングなど、モデルで考えづらい作業があります。ただそれに引きずられて開発全体がコード先行にならないよう、意識や習慣に気を付けてみてはいかがでしょうか。

4. 最後に

ET ロボコン 2013 に関する情報が少しずつ公開され始めました。2013 年は 「 デベロッパ部門 」 と 「 アーキテクト部門 」 の 2 部門に分かれるようです。
「 デベロッパ部門 」 は、これまでのルールを踏襲しつつ、難易度を下げた部門で、「 モデル駆動開発 」 の習得に適した印象です。
「 アーキテクト部門 」 は、レッドカーペットと呼ばれるエリアで自由にパフォーマンスを行い、クリエイティブさを競う部門とのことです。サプライズや感動も評価対象になるそうです。これまで、残念ながら 「 競技が地味 」 と言われることも多かった ET ロボコンですが、「 アーキテクト部門 」 の登場で、見る側にとっての魅力が一段と増すのではないでしょうか。

また、Ruby による動作環境も整いつつあるようです。これからの ET ロボコンは、門戸がさらに広がり、組み込み系エンジニアだけでなく、業務系、Web 系エンジニアの参加も増えてくるかもしれません。

興味を持たれた方は、ぜひ一度参加してみてはいかがでしょうか。




©2013 OGIS-RI Co., Ltd.
Prev Index
Prev Index