　システムの初期化時に、図10のような定義を記述したアクションを関数（BridgePointでは「Function」と呼ばれる）として呼び出すことで、走行戦略を構成するインスタンスとリンクが生成されます。ロボットクラスのインスタンスは、これらのインスタンスとリンクをたどって、走行を順に切り替えるという振る舞いをするようになっています。

　ここで、私たちが取り組んだBridgePointによる手法によって、連載第2回で紹介した各ドメインがどのように作られているかを説明します。

　前述した通り、私たちのドメイン分けでは「戦略」「足回り」「検知」という分け方でした。マッピングを行うとすると、私たちの足回り・検知を合わせたものが、ここでいう「足回りドメイン」に当たります。しかし、他の2チームとは異なり、私たちのチームでは明確に「フレームワークドメイン」というものを意識していませんでした。走行方法を順次切り替える仕組みを担っていたロボットクラスの振る舞いと、アーキテクチャ構築で作成したライブラリなどがこれに当たるといえます。また、戦略ドメインとしては、戦略をインスタンスとリンクで定義したアクション言語がこれに相当するといえます。今回の活動では、戦略・足回りは全てBridgePoint上で定義し、フレームワークについてもnxtOSEK依存以外の多くの部分をBridgePointで作成し、自動生成を行いました。

図11　みんなとみらい2チームによる各ドメインの実現手段

BridgePointによる開発のメリットとデメリット

　それでは、今回私たちのチームが使用したBridgePointによる開発のメリットとデメリットについて考察したいと思います。

　まず、メリットとして“設計（モデル検討）に専念できる”という点が挙げられます。ソースコードが自動生成されるため、配列のインデックス間違いなどのケアレスミスがなく、生成されたソースコードのレビューの必要がないため、その時間を設計に充てることができます（参考までにソースコード自動生成率は90.72％、記述したアクション言語の6.6倍のコードが生成されました）。また、モデルと実装が完全に一致するため、モデルのみをメンテナンスすればよく、モデルのみでコミュニケーションを取ることができます。私たちのチームでも、モデル検討に専念して十分にモデリングをした結果、南関東大会に提出したモデルと提出後に作成したBridgePointのモデルがほぼ同じものになりました（図8、図9を参照）。私たちのチームでは、あらかじめExecutable UMLのセマンティックを使用して机上で検討していたので、そのままスムーズに移行することができました。

　デメリットとしては“初期導入におけるツール負荷がやや高い”という点が挙げられます。その理由を説明するに当たり、私たちが考えるETロボコンにBridgePointを導入するために必要なことをドメインモデルの構築とアーキテクチャの構築に分けて挙げたいと思います。

　まず、ドメインモデルの構築では、Executable UMLの知識とサンプルモデルが必要になります。BridgePointのモデルでは、プログラムレベルではなく、分析レベルでのモデリングスキルが必要です。私たちは、3チーム合同のモデリング勉強会において、Executable UMLに触れる機会や、実際にBridgePointを使用した研修に参加できたので多少はハードルが低くなりましたが、まったくの新規でBridgePointを採用する場合には、私たちの活動と同等以上の教育が必要だと思います。

　一方、アーキテクチャの構築では、BridgePointに加えて対象となるプラットフォーム（今回は、nxtOSEK）に関する知識、そして、それらを結合することのできる設計・実装スキルが必要です。今回、私たちの場合はBridgePointのアーキテクチャ構築経験者が事務局にいたため、その者にアーキテクチャを構築してもらい、チームメンバーはドメインモデルの構築に専念しました。アーキテクチャの構築まで、チーム内でできればよかったのですが、時間の関係で取り組むことができませんでした（この点は今回の反省点といえます）。また、本格的にBridgePointを使用し始めたのがモデル提出後ということもあって、全てのドメインを結合して、何とか1周走れるようになったのが大会2日前とギリギリでした。そのため、走行戦略のチューニング期間は、実質1日しかありませんでした。

大会の結果

　出場した南関東大会の結果ですが、モデル部門では目標としていたエクセレントモデルの受賞はなりませんでしたが、上位6チームに与えられる“A評価”をもらうことができました。競技部門では、インコースは完走できたのですが、アウトコースはコースアウトによりリタイアとなり、43チーム中21位という結果に終わりました。これはやはり走行できるようになったタイミングが遅く、十分なチューニングができていなかったためだと思います。

　残念ながら目標としていたチャンピオンシップ大会には出場できませんでしたが、BridgePointを使用することで、MDDに対する理解が深まったことはプロセス上の非常に大きな成果であったと思います。BridgePointの開発を開始してからは、クラスとその属性や、他のクラスとの関連についてなど、メンバー間で抽象度の高い次元でコミュニケーションができ、通常のプログラムベースのオブジェクト指向開発との違いを実感することができました。

その他の取り組み

　今回活動するに当たって、プロジェクトマネジメントも取り入れることにしました。そこで、「WBS（Work Breakdown Structure）」を6月初旬のチーム目標作成後に私が作成しました。前日に次週までの計画を立案し、当日にメンバーで共有して進ちょく確認と次週までの実施内容を確定しました。継続するのが大変であったため、南関東大会が開催される1週間前からは更新できませんでしたが、それまでは毎週続けていました。

　実施しているときは、あまり効果を感じていなかったのですが、後でチームメンバーに聞いてみると、「自分の仕事の進ちょくが分かりやすくてよかった」という感想をもらいました。今回作成したWBSは、PMレポート共有プロジェクト（ETロボコン本部事務局主催のETロボコンのプロジェクトマネジメントのレポートを共有しようという企画）や活動の振り返りなど、プロジェクト進行時以外にも役に立ちました。

図12　作成したWBS

　私自身、普段の開発業務ではあまりチームのリーディングに携わるような機会がなかったのですが、今回、ETロボコンでリーダーを経験したことで、効率的なチーム運営の在り方を考えるきっかけになりました。この経験を今後の開発業務に生かしていきたいと思います。

　また、南関東大会終了後、チャンピオンシップ大会前に行われたETロボコンツールセミナーにおいて、BridgePointで出場したチームリーダーとして講演する機会がありました。外部で大勢の人の前で講演するのは初めてであったため非常に貴重な経験を得ることができました。大会では目標を達成できず残念な結果でしたが今回の活動を通じて、得るものが非常に大きかったと実感しています。

　さて、連載最終回となる次回は、3チーム出場した今回の活動についての技術的なまとめと、ETロボコン参加によって得た効果について、全体リーダーを務めた土樋が紹介します。ご期待ください！（次回に続く）