　ETロボコンでは「試走会1」「モデル提出」「試走会2」「大会当日」といったマイルストーンを中心にスケジュールを考えることになると思います。試走会は、大会主催者側が用意する本番環境と同じような環境でロボットを走らせることができる重要な機会です。“試走会でどれだけコースの特性をつかむことができるか”が大会でうまく走行するための大きなポイントになります。

　私たちは、全チーム共通で以下のような大まかな予定を立てました。

試走会1までは主催者から提供されたサンプルコードを修正して走らせるようにして、ロボットの特性をつかむこと
モデル提出締め切りの3週間前（7月23日）に「内部モデル審査会」を設け、そこである程度指摘を受けたうえで、締め切りである8月18日に余裕をもってモデルを作成すること
試走会2までにモデルに沿ったコードを作って走らせること

　本来であれば試走会1までにモデルに沿ったコードを作るのが理想的なのですが、今回は“モデルとは何か”から学ぶメンバーも多く、また今回の活動の趣旨上、“モデル作成にじっくり時間を取りたかった”のでこのような進め方にしました。

　過去に参加してロボットに対する知見やノウハウがある場合には、試走会1までにモデルとコードを作り上げ、モデル提出までに提出する資料をしっかり仕上げる、ということができるかと思います。

　今回の活動実績を表1に示します。

表1　活動実績（全体）

　結果的には、7月23日の内部モデル審査会までにどのチームもモデル作成が間に合わず、大会提出用のモデルができたのも締め切りぎりぎりになってしまいました。それ以外については、大体予定どおりに進められたのですが、モデル作成が遅れたことでその後の試走会2や大会までの作り込みはかなりきつい状況となってしまいました。

活動の形態

　私たちのETロボコン活動は、ミーティングや勉強会など一部の活動に関しては業務改善活動として業務扱いになりましたが、基本的には自己啓発活動として業務外扱いとなりました。ただし、会社の各種施設・設備（会議室、機材、PC）などは利用してよいことになりました。これは作業するうえで非常に助かった点です。

　2008年に出場したときは、人数が少なかったこともあり、主に参加メンバーの家で作業をしていたのですが、やはり個人宅では広げられるコースの大きさに制約ができたり、負担が大きかったりして作業上問題がありました。今回は会社の施設や設備が使えるということで、コースも居室内の一部に設置することができました（図1）。

図1　設置したコース（紙製）

　業務扱いではないという点も、「業務として成果を出さなくてはならない」という心理的負担が軽減され、かえって作業しやすかったと思います。ただし、業務外の作業で行うということは、無理してやらなくてもいい、ということにもつながります。忙しい業務を抱えた状態でETロボコンの作業を行うのは個人のモチベーションに大きく依存します。大会が近くなると自然とモチベーションは上がるので問題ないのですが、序盤から中盤では目標などをきちんと定めていかないと、モチベーションが下がり、関与が少なくなるメンバーも出てくるので、この時期をどのように乗り越えて作業を前倒しできるかがとても重要になります。

過去モデル調査

　チームができてから最初の時期に、過去の優秀モデルを各チームに分析してもらいました。やり方としては、3チームそれぞれに昨年の上位3チームのモデルを配布して、チームごとにそのモデルの概要、良い点などを話し合い、その結果をチームごとに発表する形式を取りました。発表の際にはほかのチームからの質疑応答に対応できるように、モデルを読み込んでもらいました。この作業を通じて、ETロボコンで作成するモデルがどんなものであるかというイメージを持つことができたと思います。

　また、今回の参加メンバーは所属するグループや部門がばらばらで、チーム内でも顔は知っていても話したことがなかったり、お互い初めて知り合ったりというメンバーが少なくありませんでしたので、初期の作業としては作業目的が明確でよかったのではないかと思います。

　この発表を通じて、まだモデルを読み解く力も十分ではないメンバーが多いことも分かりました。そのため、モデル勉強会を手厚くやることにしました。

モデル勉強会

　今回の活動の大きな目的の1つが“モデリングをきちんとすること”でした。大会終了後に取ったアンケートでも、参加の動機として「モデリングスキルを高めたかった」という回答が1番でした（図2）。

図2　参加動機のアンケート結果

　しかし、モデルといっても種類はさまざまです。例えば、ロボットをうまく制御したい、ということを優先すればPIDなどの制御モデルを作り、最適なパラメータを求めていくというのがよいかもしれません。「MATLAB/Simulink（注1）」を使えば、ブロック線図モデルを作成して動作をシミュレーションし、コードを生成するといった開発もできます。実際、ETロボコンでも走行部門で強いチームはこうしたツールを使っているところもあるようです。早く走ることを主たる目標とするのであれば、制御モデルのスキルを上げるということもよいかもしれません。

※注1：MathWorks社の数値解析/モデリングツール。

　今回の活動では、企業として参加するということもあり、私たちが業務で持っている課題の解決に必要なモデリングスキルを伸ばすことにしました。

図3　複合機のコード量の変化

　私たちは、業務として主にオフィス複合機の組み込みソフトウェアを作っています。複合機のソフトウェアも過去に比べて複雑化、巨大化しています（図3）。そうした状況でも世の中の技術動向や、お客さまに合わせた新たな機能追加などの要求に短い納期で対応していく必要があります。複雑で巨大なものをそのまま取り扱っていたのでは修正に人手も掛かりますし、品質を確保するためにも大きなコストが掛かります。これが私たちの現状の課題です。

　このような課題に対しては、制御モデルのスキルを向上させても効果は期待できません。それよりも対象となる問題領域を抽象化し、その構造を静的にとらえる分析モデルのモデリングスキルが必要になります。

　一見複雑に見える事柄も、静的な構造として分析し、その本質を見いだすことで単純化できる場合があります。単純化できれば理解も容易になりますし、修正や品質確保に必要となるコストを下げることができます（図4）。そこで私たちは制御系ではなく、“構造的な分析モデリング”を中心に取り組むことにしました。

図4　分析によって単純化する例　
左の図は一見ごちゃごちゃで複雑に見えるが、右のクラス図で定義されるルールに従っている。ソフトウェアも複雑なものをそのままコード化するのではなく、このようなルールを見いだすことでシンプルにすることができる場合がある。このようなルールを見いだし、厳密な表記で表すのが分析モデリングといえる

　こうした分析モデリングのために筆者がよく使用しているモデルが「Executable UML（以下、xtUML）」のクラス図です。xtUMLはUMLのサブセットで、「BridgePoint（注2）」ではxtUMLを方法論として採用しています。

　xtUMLはその名のとおり、モデル自体が実行可能なセマンティクスを持っており、作成したモデルを実行して検証することができます。実行可能なモデルですので、通常のUMLよりも厳密な定義を行う必要があります（注3）。クラスの作り方も特徴的で、どのように作るか（How）よりも、そのシステムはどのようなものか（What）ということに主眼が置かれ、対象となるシステムの概念的な構造を表現することがよいとされています。そのため、xtUMLのクラス図は通常のUMLのクラス図よりも関係や属性を厳密に定義します。メソッドはあまり重要視しません。データベースで使用するER図のようなイメージです。関係や属性を厳密に定義するのは難しいことなのですが、対象となるシステムの特性をきちんと分析し、厳密に表現することで、対象となるシステムの理解が進みます。理解不十分な部分やあいまいな点など、後工程で発生すると大きな問題になるような事柄を、開発の上流工程でとらえることができ、早期の品質獲得にもつながります。

　こうしたことから、xtUMLのクラス図を中心に勉強会を行うことにしました。

※注2：Mentor Graphics（メンターグラフィックス）社のMDDツール。

※注3：動作させるにはクラス図のほかにステートチャート図、アクション言語によるロジック記述が必要になります。また、動作確認したモデルをコードに変換することもできます。xtUMLについては、以降の連載で取り上げるBridgePointチームの活動の回で詳しく紹介する予定です。

次ページでは、勉強会の進め方やチーム作業の進め方などについて紹介する！

　　　　　　 1|2 次のページへ