ETロボコンに向けた具体的な全体活動：3つの設計アプローチで見るETロボコン参戦記録（2）（2/2 ページ）

[土樋 祐希 富士ゼロックス，＠IT MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

勉強会の進め方

　xtUMLのクラス図を理解するため、レオン・スター著の「Executable UML実践入門―クラス・モデルをいかに作成するか（CQ出版）」を題材に勉強会を行いました。

　この本の各章を各チームリーダーが順番に参加メンバーに対して説明し、筆者が必要に応じてフォローする、という形を取りました。開催は毎週1回です。モデルになじみのないメンバーもいるということで、単なる講義形式だけでは理解が進まないと考え、演習問題を用意して事前に参加者に解いてもらうという進め方をしました。演習問題については講師役の各チームリーダーに説明する章の演習問題を考えてもらいました。勉強会ではメンバーの回答を持ち寄り、みんなでディスカッションするという時間を設けました。

　演習問題を作るというのがなかなか難しく、チームリーダーは苦労していました。各演習問題には、本当は参加者に「こういうモデルを作ってほしい」という意図があったのですが、その課題を受け取った側はその真意を読み取れず、全然違う回答を出したり、モデルを作ってきたりすることがしばしばありました。そのようなモデルを見て出題者は課題の出し方があいまいであったということに気付いたりしたのですが、実はこれこそがモデルの効用だと思っています。

　ほかの人に何かをお願いする際に、頼む側と頼まれる側で異なったことをイメージしていて、出来上がったものが全然違うものだったというのはよくあることです。もし、モデルでお互いの認識が違っていることが早いうちに分かれば、その被害は小さくて済みます。図5は、勉強会で出した課題の例です。

図5　勉強会で出した課題の例　
課題1は所有という概念の抽出と、それ以外の要素（人、本、店）の関係を適切に表せるかの課題。本には概念的な本（「本を取り寄せた」という文脈で使われる）と、物理的な本（「その本を貸して」という文脈で使われる）があり、どちらを表現しているかということも重要。　
課題2は関係線を引っ張っただけでは正しいかどうか分からないという例。この線が「家系図における親」という意味であれば多重度は0..2ではなく2がふさわしく、「現在扶養している親」を示すのであれば0..2でもよい。ただし、多重度に2といった具体的な数値が入る場合、もう少し分析を進める必要があるかもしれない（この例では母親、父親というように親を区別することで多重度を1または0..1にすることができる）。また、世代間を考慮すると親と子というのは「人」の持つロールであるという分析の方がふさわしい。こうした思考を通じて表現しようとしている対象の理解を進めることができる

　特にチームリーダーには苦労のあった勉強会でしたが、大会終了後に取ったアンケートでは「こうしたやりとりがよかった！」というコメントが多くありました（表2）。

	同じ課題に対して、人がなぜそう描いたか、自分はどう考えたか、というのをディスカッションするのがモデリング思考を身に付けるのに役に立ったと感じている
	講師として参加したため、担当個所の理解が深まった
	理解不足であっても自分の力で取りあえずモデルを作ってみるというのがよかった
	自分がどの部分を理解できているか、できていないかがはっきりできてよかった
表2　勉強会に対するコメント（抜粋）

　今回のモデリング勉強会は、クラス図しか対象としませんでした。そのため、「開発プロセス全体とクラス図を作ることのつながりが見えなかった」「ロボコンとモデルの結び付きが最初分からなかった」といった意見もありました。

　勉強会の準備などで手間取って開催が遅れたのも原因ですが、7月に入ると提出用のモデル作成が佳境になったため、勉強会する時間が取れなくなったのも事実です。もう少し事前に準備しておくべきだったと思いますが、クラス図による分析をきちんと行うという意識を植え付けられた点ではよかったと考えています。

チーム作業の進め方

　これまで説明した大まかなマイルストーンの設定と、モデル勉強会以外の活動はチームに分かれて行いました。

　各チームで目標を決めて、それに対して活動するということは共通の進め方でしたが、それ以外は各チームリーダーとそのメンバーにお任せという形を取りました。ただし、何もないと状況がつかめませんので、作業内容と納期、担当者などの計画と進捗管理に「WBS（Work Breakdown Structure）」を書くようにしてもらいました（図6）。WBSも慣れないとうまく作業を分割できません。各チームリーダーはWBS作成とその進捗確認などを通じてプロジェクトマネジメントの練習もしたことになります。

図6　チーム（みんなとみらい2）が作成したWBS（ツールとしてExcelと開発マイルストーンを利用）

　実際には計画は立てたもののそのとおりに進まなくて大変だったようです。そのような生々しい話は次回以降、各チームリーダーに紹介してもらう予定です。

各チームの開発手法

　前回説明したとおり、今回参加した3つのチームでは異なる開発手法を取り入れて開発しました（表3）。手法の詳細も次回からの各チーム活動報告の中で説明しますが、ここでは各チームの開発手法を比較するうえでのポイントを紹介したいと思います。

チーム名	使用する手法
みんなとみらい1	DSLによるMDD
みんなとみらい2	BridgePointによるMDD
Fusion＆Futures	モデルを手書きで実装
表3　3チームの開発手法

　異なる手法によってソフトウェアを構築したといっても、作ろうとする対象は同じものです。そのため、大きな構造という観点では3チームに共通の構造が存在しました。図7と表4にその構造を示します。

図7　3チームに共通するドメイン構造

ドメイン名	ドメインの説明
足回りドメイン	ライントレースやマーカー検知といった主に制御やアルゴリズムに関する仕組みを提供する　 関心事の例：「どうしたらスムーズなライントレースができるか」
戦略ドメイン	足回りドメインの要素を使用してインコースやアウトコースといったコースの違いや、目的の違いによって変わる走行戦略を定義する　 関心事の例：「どうやって難所をクリアするか」
フレームワークドメイン	戦略ドメインで定義された内容と足回りドメインの要素をつなげ、ロボットが走行する仕組みを提供する　 関心事の例：「システムとしてどのように振る舞うか、戦略ドメインと足回りドメインをどのようにつなげるか」
表4　3チームに共通する各ドメインの説明

　この構造は、2008年に筆者らが参加したときに使用した構造です。戦略、足回り、フレームワークという大きな枠組みで構成することで、各ドメインの関心事を分離して、それぞれを独立した形で作り上げることができます。大規模なソフトウェアを作る場合には、こうした分割を行うことが重要です。ETロボコンはそれほど大きなソフトウェアではありませんが、分割することによる作りやすさを理解してもらうため、各チームこの構成を取ってもらうようにしました。

　この共通した構造を異なる開発手法で作ることで、どのような違いを生み出していくのかを次回以降で感じとっていただけたらと思います。

---

　今回は私たちの活動スケジュールと、全体としての取り組みについて紹介しました。この記事が掲載されているころには2011年度のETロボコンの詳細も出てきているのではないかと思います（関連記事）。ETロボコンはソフトウェア開発のいろいろな要素を試すことができる場ですが、企業の中の課題を解決する手掛かりをつかむ場としても使用できると思います。大変なことも多いですが、失敗を恐れずチャレンジすることで得るものは大きいと思います。

　さて、次回から3回にわたって各チームの活動・使用した手法の技術紹介を行います。次回は「モデルを手書きで実装」でチャレンジしたFusion＆Futuresチームの細田が記事を書く予定です。お楽しみに！ （次回に続く）

	関連リンク：
⇒	10周年記念大会となるETロボコン2011の概要が明らかに!!