　私たちのチームは、入社3～8年目の社員5名で構成されていました（表1）。全員が複合機の開発に従事しておりますが、うち1名は普段はハードウェアを開発しており、ソフトウェア開発を本格的に行うのは今回が初めてでした。私自身は、2008年にもチームメンバーとしてETロボコンに参加した経験があり、今回リーダーを務めることになりました。他のメンバーはETロボコン初参加で、普段の業務でもモデルを使っておらず、

モデリングって何だろう？

何のためにモデリングをするのだろう？

といった状態からのスタートとなりました。


社歴	業務内容	今回の活動での主な役割
3年目	ソフトウェア開発	モデル作成
3年目	ハードウェア開発	足回り・戦略パラメータ調整
4年目	ソフトウェア開発	足回り・戦略パラメータ調整
6年目	ソフトウェア開発	チームリーダー
8年目	ソフトウェア開発	フレームワーク実装
表1　F＆Fチームのメンバー

チーム目標

　連載第2回の説明にもありましたが、今回のETロボコン活動ではチームごとに目標を設定しました。そこで、私たちF＆Fでは、以下の2つの目標を立てることにしました。

モデリングスキルを向上させる
モデル部門で入賞する

　後述する技術紹介のところでも説明しますが、私たちは今回「モデル駆動開発ツール（以下、MDDツール）」を“使わない”開発スタイルを取りました。当初は、他の2チームと同様、MDDツールを使ってみるということも検討しましたが、メンバーとの話し合いの中で、“ツール習得にかかる時間もモデリングスキル向上に使いたい”と考え、今回の取り組みではMDDツールを使用しないことにしました。

　私たちのチームは、業務で日ごろモデリングを使っていないメンバーで構成されていましたので、とにかく「モデリングスキルを向上させる」ということを第1の目標にしました。また、単にそれだけですと目標達成基準が曖昧になってしまうので、「モデル部門で入賞する」という目標も加えました。もちろん、チャンピオンシップに出場したいという気持ちもあったのですが、「走り」よりも「モデル」を優先する方針の下、こうした目標を設定しました。

チームの活動スケジュール

　F＆Fチームの活動スケジュールを図1に示します。

図1　F＆Fチームの活動スケジュール

　F＆Fのメンバーは、筆者以外、ETロボコンの参加が初めてだったので、活動は“取りあえずロボット（LEGO Mindstorms NXT：NXT）を動かしてみること”から始まりました。メンバーでロボットを家に持って帰り、大会事務局から提供されるサンプルコードを使って、環境のセットアップや簡単なライントレースを試すということを1カ月ほど行いました。

　それと並行して、モデリングの基礎教育も開始しました。これは、3チーム全体で行った勉強会とは別に、チーム独自で行いました。具体的には、書籍「思考系UMLモデリング即効エクササイズ―モデ力を鍛える13の自主トレメニュー（翔泳社）」を使用し、その中の課題を各自で解いてミーティング時にレビューし、ディスカッションするというものです。全体の勉強会でもモデルのディスカッションは行っていたのですが、人数が多く時間的に制限があったので、より各人が考える時間を持ちたいと思い、このような機会を設けました。

　私たちのチームでは、活動初期のミーティングをほとんど基礎教育の時間に当てました。この時期メンバーから「ETロボコンのモデリングをしなくてもよいのか？」とよく聞かれましたが、その度に私は「今は“ロボットの特性を把握すること”と、“モデリングの基本を理解すること”が大事だ」と説明しました。

　モデル提出には締め切りがあるので、どうしてもそちらの作業をしないと不安になってしまうのですが、こうした“基本的なことを活動初期に押さえておいた方が最終的には良いモデルが作れる”のではないかと思います。

分析クラス図の作成

　ロボットの特性が大体分かり、メンバー間のコミュニケーションにモデルが使えるようになったところで、ETロボコンのモデル作成に入りました。難所は全てクリアしたいと考え、それに合わせたモデルを作成することになりました。私たちが考えた走り方のコンセプトを図2に示します。

図2　F＆Fチームの走らせ方のコンセプト

　コース上で起きる事象の検知と、その検知によって切り替える走り方をあらかじめリストのような形で定義しておき、それに従って走行を切り替えます。例えば、図2では最初ライントレースで走行していて、マーカーの検出を待ちます。マーカーを検出すると今度は直線走行に切り替え、そのまま決められた距離（300mm）を走行します。その距離に到達したところで今度は回転走行に切り替え、方位が90度になったところで直線走行に切り替え、400mm進む、といった感じです。この構造をクラス図で表現したものが図3です（図の簡略化のため、要点のみピックアップしています）。

図3　走行切り替えの部分のクラス図
※クリックで画像拡大表示

　「走行方法クラス」は、走行に関するパラメータを持ったクラスです。それぞれの走行方法クラスは、実際の走り方のアルゴリズムと関連付いています。例えば、ライントレース走行は「PID制御クラス」と関連していて、ライントレース走行のパラメータに基づいて、PID走行が行われることを示します。「検知方法クラス」も同様に検知に関するパラメータを持ったクラスです。それぞれには、検知のためのアルゴリズムとの関連があります。

　「NXTクラス」はロボットを示しているのですが、「現在使用している」という関係によって走行している際に、“現在、どの検知クラスのインスタンスを使用して事象の発生待ちをしているのか”を示しています。そして、事象が検知された場合には検知クラスの「検知時に切り替える」という関係から切り替えるべき走行方法クラスのインスタンスを特定し、走行方法の切り替えを行います。クラス図を作った後、この構造に基づいて自分たちがクリアしたい難所なども全て表現できるかどうかを検討し、足りない走行方法や検知方法などを追加した上で、最終的な分析クラス図を作成しました。

　ここまでの作業は簡単にできたわけではなく、途中いろいろなコンセプト（例えば、どんなことがあっても必ずコースに復帰するなど）も検討したのですが、結局そのような構造を捉え切れなかったり、難所をクリアすることができないなどの問題が発生したため、コンセプトの見直しといった“手戻り作業”が何度もありました。そのため、最終的な分析クラス図ができたのはモデル提出の1週間前となってしまいました。

　ここまでの作業を通じて、“自分たちが考えたことを実際に形にする”、特に“図やモデルとして表現する”ことがいかに難しいかを実感しました。

提出用モデルの作成

　モデルの提出まで1週間しかない状態でしたので、他に必要なモデルの検討と提出用のモデル作成を並行して進めました。

　提出モデルでは、最低でも機能／要求・静的構造・動的構造に関して、A3用紙5枚にまとめる必要があります。機能／要求に関しては、それまでユースケースとしてきちんと表現していなかったところがあったので、分析モデルを作る上で明確になったことも含めてユースケースを作成・追加しました。

　構造に関しては、分析クラス図ができていたのでこれを基にコードとして実装するための設計クラス図を作成しました。分析クラス図には、走行に関連する概念しか入れないようにしていましたが、設計クラス図ではこの構造をソフトウェアで実現した際に、各クラス間の依存性を下げたり、変更の局所化ができるなどの保守性を良くするための仕組みを入れたりする必要があります。例えば、分析クラス図ではそれぞれ「～に従って走行する」という関係で走行クラスと走行アルゴリズムの対応関係を明確にしていたのですが、インタフェースを用いて、「Strategyパターン」を応用した形を取りました（図4）。このようにすることで、走行方法を後から追加することが容易になります。実際にこのような形で実現できるかどうかは、シーケンス図などを記述して確認しました。