　キャッツ株式会社の新卒社員4人組が“ハッスルCATS”というチームを結成し、2005年のETロボコン（注1）に参戦しました。これは新人研修の一環として実施されたもので、UMLを学び、組み込みソフトウェア開発の知識を吸収するだけではなく、仕事のやり方、チームによるプロジェクトの進め方といった、さまざまな能力を身に付けることを期待されていました。今回は前編として、参戦が決定した時点から初期モデルの作成、そして最終的なモデル完成までを紹介し、2005年7月に行われた競技会・審査ワークショップ当日のドキュメントを紹介します。ET2005でのチャンピオンシップ大会については、後編で紹介します。

※注1：ETロボコン

自律型ライントレース・ロボット「LEGO Mindstorm」を使って、組み込みソフトウェア開発の「分析、ソフトウェア設計モデリング」と「走行性能（タイムトライアル）」を競うコンテスト。

新人4人組がETロボコンに参戦

　キャッツに入社した私たち4名の新人は、ほんの少し前までは学生であり、しかもプログラミングの知識はほとんどなく、学校の授業でC言語を学んだことがあるという程度でした。当然「組み込み」「UML」という言葉は初めて聞く単語。こんなメンバーでETロボコンに挑戦したのです。

　ETロボコンとは、2004年まではUMLロボコンとして開催されていましたが、2005年の「Embedded Technology展」の特別イベントとして開催されることになり、「ETロボコン」と名称が変わりました。そもそもETロボコンとはUMLで設計されたモデリングを競い、その後、LEGO Mindstorm（PathFinder）を使用してコースを走行し、タイムを競うといった競技です。

　プロジェクトメンバーは、通常のソフトウェア開発に関する新人研修を受け、その後通常業務を行うといった日常の中、ETロボコン参戦のために、通常業務（定時）後に会社に残って、UMLモデリングを行い、自分たちでコースを作成し、何度も走行体を走らせては設計を繰り返しました。参戦中は毎日深夜に及ぶ作業になり、つらい日々でした。

　また、参戦前は「LEGOのおもちゃを走らせて競争するだけなので楽勝！」と思っていて、やる気満々でしたが、いざモデリングを始めると、メンバーそれぞれが違った考えを持ち、なかなか全員の意見はまとまりません。最初に突き当たったのはチーム開発の難しさでした。そんなときは、上司や先輩に報告・連絡・相談をすることが大切だと分かりました。ここでせっかくUMLを勉強したので、「新人、先輩、上司」の関係をシーケンス図でモデリングしてみましょう（笑）。

図1　ソフトウェア開発における「新人、先輩、上司」の関係を分析したシーケンス図

初めて作ったUMLモデル

　モデリングに取り組んだ当初は、分からないことばかりでした。整理してみると、

モデル図を何のために描くのか分からなかった
開発におけるフェイズ（要求分析や分析など）の意味が分からなかった
どんなモデル図があるのか分からなかった
モデル図の見方が分からなかった

などです。そこでまず、UMLの調査から始めることにしました。参考書籍として「組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発」（以下、eUML本）を読むことで、モデル図の種類や見方などを把握していきました。

　それでは、ハッスルCATSが初めて作ったUMLモデルを紹介しましょう。今回のモデリングは、「ユースケース分析」→「ドメイン図」→「状態図」→「クラス図」の順番で作成していきました。初期バージョンから完成バージョンへ至る過程で、どのように進化していったかを確認していただけます。

ユースケース分析

　UMLモデリングの第一歩として、まず要求分析を行うために、ユースケース図を描きました。eUML本を参考にしながら、ユースケース図には何を描けばいいのかを模索したのですが、ここで苦労したのは「ユースケースとは何か？」でした。資料などによれば「システムにさせたいサービス・機能を記述する」とあるものの、走行体を走らすという具体的な開発に即した形で、納得のできるユースケースを見つけ出すのは容易ではありません。

　ユースケースの意味もしっかり理解しないままに描いていたため、当初出来上がったユースケースでは、システムに何を要求しているのかが不明確でした。ユースケース図を描くに当たって、視点や粒度をどこに定めたらいいか、チーム内で議論をしても個々に意見が違い、なかなか決めることができません。走行体となるPathFinderをシステムとして見る考えもあれば、走行体の制御を行うRCXという機器をシステムとしてとらえる考え方もありました。

　そこで、先輩に相談したところ、次のような指摘を受けました。

ユースケースは、サービスや機能である
2つのユースケース（サービス・機能）を持つものを、1つのユースケースとして表現してはいけない

　また、ユースケース記述の項目のフォーマットなどを教えてもらい、ユースケースごとの役割や前提条件などが明確になっていきました。そこで、

アクターが何であるか
そのアクターが何に対して要求をしているか

を決めました。今回、アクターとなるのは開発を行う自分たちであるため、アクターを自分たち（ハッスルCATS）としました。また今回のETロボコンに参加するに当たり、タイムトライアル部門優勝という目標を掲げていたので、「優勝してほしい」「優勝したい」という気持ちを込めて、システムに相当する走行体のPathFinderは「優勝システム」としました。こうして出来上がった初期のユースケースを図2に示します。

図2　初期のユースケース分析

　ユースケースが明確にならず悩んでいたところ、先輩から「ドメイン図や状態図を描いてみれば」とアドバイスを受けました。試しにドメイン図や状態図を描いたところ、初期のユースケースで不明確であった詳細部分を明確にできました。最終的にモデル審査部門に提出したユースケース分析を図3に示します。

図3　完成したユースケース分析

　最終モデルでは「コース選択」が追加され、初期モデルでは2つだったシナリオが3つに増えています。これはユースケース以外のモデルを描いていくうちに、初期の要求分析に漏れがあったことに気付いたからです。ちなみに、コース選択とは「INコース」「OUTコース」を走行前に選択する機能です。タイムトライアルでは異なる2つのコースを1回ずつ走行して、合計タイムで順位が決まります。

　　　　　　 1|2|3 次のページへ