|
[2011 年 4 月号] |
［レポート］
先日開催されたETロボコン*1-1の説明会で、ETロボコン2011の開催がアナウンスされました。毎年ETロボコンに参加されている常連チームの方々は、すでにモデルの検討を始めていると思います。一方、初参加の方はモデルを検討するときに何に気を付ければ良いか分からない人もいるのではないでしょうか？
*1-1正式名称はETソフトウェアデザインロボットコンテスト。
先日、オブジェクトの広場では、2010年のチャンピオンシップ大会でゴールドモデル（モデル部門2位）を獲得した「田町レーシング」チームのメンバを中心に2010年のモデル審査を振り返る座談会を開催しました。本記事では、座談会で議論したETロボコンにおけるモデリングのポイントやノウハウを3回に分けてご紹介します。本記事がETロボコン2011参加者の一助になれば幸いです。
なお、本記事では、「田町レーシング」チームが作成したチャンピオンシップ大会のモデルを度々引用します。ぜひ、実際のモデルを手元に印刷して記事を読み進めてください。座談会中では東京地区大会のモデルについては言及していませんが、zipファイルには東京地区大会のモデルも入っています。ぜひ見比べてください。
ETロボコンは、組み込み分野におけるソフトウェアデザインの技術を競うロボットコンテストです。組み込み分野の学生および若手エンジニアへ分析・設計モデリングの教育機会を提供することを目的に2002 年から毎年開催されています*1-2。
*1-2https://www.etrobo.jp/2011/robolink/robolink.php
ETロボコンには、LEGO Mindstorms NXT*1-3で作成した倒立振子型のライントレースロボット*1-4で競技フィールドの走行タイムを競う競技部門と、ソフトウェア分析・設計の内容を競うモデル部門があり、両部門の総合的な成績で最終的なチャンピオンを決定します。競技内容は他のロボットコンテストと大きな違いはなく、モデルの審査があることに大きな特徴があります。
*1-3LEGO社が提供している教育用ロボット開発キット。https://www.legoeducation.jp/mindstorms/about/index.html
*1-4倒立制御は参加者共通のライブラリで容易に実現でき、複雑な制御理論よりもソフトウェアの分析・設計に集中できるようになっている。
モデル部門の審査では、ソフトウェア分析・設計の内容をまとめたモデルシート（A3紙 5枚）が「モデルの書き方」、「内容」、「追加課題」、「オリジナリティ」の4項目で評価されます。競技者はこのモデル審査基準に気を払いながら、ロボットの競技用プログラムについて検討した結果をモデルシートにまとめます。
本記事では競技規約やモデル審査基準については解説しませんので、詳しくは公式サイトを参照してください。
今回の座談会では以下の9名のメンバで議論しました。
三村 次朗
組み込みソリューション第一部所属。もうすぐ3年目の初級エンジニア。石油探査用システムの開発に携わる。ETロボコンは2009年度の新人チームで参加し、東京地区大会のモデル部門で3位という成績を残した。2010年度は参加経験者としての立場から、モデルのレビューなど各種支援活動を行った。変更に強いソフトウェア設計に興味があり、Test Drivenな開発プロセスを好む。いかに楽をして仕事をするか日々考えている。
平岡 尚
組み込みソリューション第二部所属。2年目。現在半導体製造装置の制御ソフトウェアの開発に携わっている。ETロボコン2009には新人チームとして参加し、東京地区大会のモデル部門で3位になったものの、競技部門ではリタイアして悔しい思いをした。今年のロボコンでその雪辱を晴らすべく参加した。ETロボコン2010では主に性能面（競技）を担当した。
大西 洋平
組み込みソリューション第一部所属。業務では車載オーディオ機器や車両制御など組み込みソフトウェアの開発に携わる。学生時代を含めてETロボコンに4回の参加経験があり、ETロボコン2010ではリーダー役として参加した。知識やノウハウを他の人と共有することに関心があり、得られたノウハウはこうして記事として積極的に公開している。
辻 博靖
組み込みソリューション第二部所属。数年前から大手メーカーでオブジェクト指向の分析・設計を中心とした人材育成の企画・実施の支援業務に従事している。ETロボコンへの参加は今回が初めて。スクラッチからの開発を経験したいという意気込みで参加を表明したが、結果的にモデリングのみの担当に。構造重視の現在のモデリング手法に振る舞いをパターン化することに重点を置く責務駆動設計の考え方を取り入れたいと日々模索中。
国正 聡
組み込みソリューション第二部所属。ここ最近は教育ビジネスに携わっており、新入社員の若いパワーを感じながら研修の企画、運営を行っている。今回初めてETロボコンに参加するにあたり、誰も考え付かないようなアイデアで完全走破を目論んでいたが、知識、経験、時間が足りずあえなく断念。ほとんど雰囲気を感じ取るぐらいしかできなかった今回の参加だが、未だに時々、シーソー上での3秒停止の実現方法を思い描いたりしている。
林田 幸司
組み込みソリューション第二部所属。オージス総研入社後、ビジネス系のオブジェクト指向システム開発に数年間携わる。その後、アクセス制御を目的としたミドルウェア製品やCORBA仕様に基づいた開発および技術コンサルティング業務に数年間携わる。現在はそれらの経験を生かしオブジェクト指向技術研修コースの講師や教材の開発に携わっている。また、モデリング技術普及活動の一環として、UMTP主催のUMLモデリング技能認定試験のセミナーの講演の実施や、大学においてオブジェクト指向やUMLに関する寄付講義を実施。ETロボコンは今回が初出場。プライベートではジャズメンに憧れ、趣味としてドラムスを練習中。
手嶋 高明
組み込みソリューション第二部所属。2006年、2009年は田町レーシングとしてETロボコンに参加。2010年は田町レーシングと芝浦雑伎団の支援を行うとともに、東京地区のコミュニティ活動（愛称：東京連合）を開催。2011年は東京地区からチャンピオンシップ大会優勝チームを出すことを目標に活動する予定。業務では、ここ数年、開発者を支援する立場として開発プロセス改善やドメイン知識共有、支援ツール開発などを行う。
山内 亨和
アドバンスドモデリングソリューション部所属。主にシステムの開発プロセスや調達プロセスを標準化、改善したり、実践の支援を行う。オブジェクトの広場等記事を書いているため、読み手に対し分かりやすく情報を見せることへ強い意識を持っている。特に日本語の使い方にはこだわる。
青木 淳
組み込みソリューション第一部所属。組み込みソフトウェア開発コンサルタントとして、数々の顧客現場にてソフトウェア開発改善活動を支援。常に現場目線の改善提案を心がけている。最近の顧客は開発上の課題がソフトウェアに留まらないことが多く、SysMLを活用したシステムモデリングの啓蒙普及を推進している。
今年の座談会も昨年同様、モデルシート全体に関する工夫を確認することから始めました。今年の田町レーシングのモデルは、昨年にも増して読みやすさを追求し、見出しの書き方、モデル要素の名前の付け方、分析の切り口などに注意を払っています。また、性能面を分析するときの視点を提示する価値について議論しました。
山内：一番上に見出しがあって、すごい分かりやすいですね（図2-1）。そういえば、昨年のモデル座談会でも、見出しの使い方が良いなって思いました*2-1。狙いをちゃんと考えた上で分析・設計をしていることが分かります。
*2-1ETロボコン2009 モデル座談会（前編）「2. 審査員に評価されるモデルシートの書き方 」を参照。
 |
 |
| (a) モデルシート（全体） | (b) 見出し部分（拡大） |
手嶋：スタンスや方針を示すことは本当に重要です。読み手は書き手のスタンスが分からないと、理解するまでに時間がかかったり、誤解する可能性があります。私が2009年に参加したときも注意を払って書きました。
国正：良いモデルを書くのも大事なんですが、見出しで書き手のスタンスを強く訴えることも大事ですね。最初に強く訴えられているかいないかで、読んでもらう人の見方も変わってきます。
国正：見出しは一番最初に読んでもらうところだから、どこまで細かく書くか非常に悩みましたね。特に構造モデルの見出しは提出直前まで何度も直しました。
三村：コンセプトシートの「ここに注目！」に「モデル間のトレーサビリティを意識しました」とありますが、そもそもなぜモデル間のトレーサビリティを取り上げようと考えたのですか？
林田：最初は、昨年のチームがトレーサビリティの面で評価されていたし*2-2、モデル審査基準にもあるので（図2-2）、そこは頑張ろうか程度のつもりやったね。
*2-2ETロボコン2009 モデル座談会（前編）「シート間のつながりが分かるような資料構成にする」を参照。
機能面、構造面、振る舞い面の各図に記載されている内容が一貫しており矛盾のないこと。例えば、以下のようなケースはNGと判断します。
|
林田：でも、実際にモデルを作って社内レビューをすると、トレーサビリティがあるモデル、つまり複数のモデルの内容が一貫している方が自分達が理解しやすいし、レビュアにも理解してもらいやすいですよね。やはり、ここはUMLを使うことの強みをより生かせるところやと思いますよ。
辻：個人的には、「トレーサビリティ」というキーワードのためにやったのではなくて、モデルの読みやすさを重視したら、結果的にトレーサビリティの向上につながったんじゃないかなと思っています。
三村：読みやすいモデルを突き詰めていった結果こうなった、ということですね。
山内：では、他のチームでトレーサビリティが取れているところは少ないんですか？
大西：地区大会だと、基本的な部分でトレーサビリティが取れていないケースはたまに見かけます。コミュニケーション図で登場する操作がクラス図に登場していなくて整合性が取れていなかったり、言葉が統一されていなかったりします。
手嶋：他のモデルは、例えば「シートの4枚目に詳細説明が書いてありますよ」といっぱい注釈を付けてあったり、確かにトレースはできるけど、込み入っていて煩雑と感じるモデルもありましたね。
手嶋：一方、田町レーシングのモデルは、徐々に理解を深めていくような展開になっていますよね。ドメイン分析でコア構造を出してから詳細な構造に入っています。単純に注釈を付けて 「トレースできる」だけでなく「トレースしやすい」ことも考えてますね。そのあたりも工夫しているのかなと思いました。
三村：資料全体として見やすくしているということですね。
三村：具体的に、トレーサビリティの面で工夫したところを教えてもらえますか？
辻：モデルシート全体で、分析の切り口や用語を合わせることでトレーサビリティを向上させています（表2-1)。詳しくは各シートを説明するときに紹介します。
| # | ダイアグラム | 工夫の内容 | 説明のある節番号 |
|---|---|---|---|
| 1 | ドメイン分析のクラス図（P.1左上）と要求図（P.1下） | 分析する単位を揃えた。 | 前編3.5 | 2 | ユースケース図（P.1右上）と要求図（P.1下） | 「コースを走破する」というユースケースについて要求図で分析していることを示していた。 | 前編3.5 |
| 3 | ドメイン分析のクラス図（P.1左上）と構造分析のパッケージ図（P.2左上） | ドメイン分析で出したクラスの名前をパッケージ図の名前にも対応させている。 | 中編2.1 |
| 4 | ドメイン分析のクラス図（P.1左上）と構造分析のクラス図（P.2左上） | ドメイン分析で出したクラスと同じ概念のクラスを構造分析にも出している。 | 中編2.1 |
| 5 | 要求図（P.1下）と構造分析のクラス図（P.2左上） | 要求図の分析の切り口に合わせてクラス図のクラス階層を整理した。 | 中編2.1 |
| 6 | 要求図（P.1下）とクラス図（P.2）と性能に関する記述（P.4〜5） | 要求図で掘り下げた要求をクラス図のどこで実現するか吹き出しを付けた。 | 中編2.1 |
| 7 | ユースケース記述（P.1右上）とコミュニケーション図（P.3上） | ユースケース記述の基本系列の実現可能性をコミュニケーション図の基本的な振る舞いで検証した。 | 後編の記事で紹介する予定。 |
辻：今回、2009年と2010年の差分に着目して分析した結果をアピールすることが大事だと考えました。モデル審査員の方々は毎年膨大な量のモデルシートを見ているので、年によって変わらないところは見飽きているはずです。ルールの変更をどうモデルに取りこんでいるか？を注目して見ているんじゃないかなと考えました。
辻：2009年と2010年の差は以下だと考えています。
辻：これら新しい難所の特徴にフォーカスして資料を作りました。これらのポイントはすべての資料に記載しています。
辻：構造に関しては、具体的な難所名を登場させずに動的な経路選択を実現できる、拡張性の高い構造を作り上げることに注力して描きました（図2-3）。振る舞いでも、動的な経路選択を取り上げ、基本構造を変えることなく新しい難所を走破できることを示しています。立体難所に関しては性能面で解説を付け加えています。
 |
 |
| (a)構造分析：基本構造 | (b)振る舞い分析：ミステリーエリアの振る舞い |
辻：性能面では、走破戦略（コースのどの部分を走るか）と技術要素（走るために必要な技術）という2つのことを考えなければいけないとアピールしています。動的な経路選択は走破戦略、立体難所は技術要素と関係があります。他チームのモデルで、性能面を走破戦略と技術要素の2つの視点に分けて分析したものはあまりありません。この点も田町レーシングの特長だと思います。
辻：まず、インコースは走行体が転倒しやすい立体難所がないので、走破戦略としてはリザルトタイム短縮が最重要です。速度を落とさずに、可能な限り短い距離を走行できるコース取りを考えることが重要だと考えました（図2-4）。
図2-4 立体難所のないインコースでは最速を目指す走行が重要
（クリックすると拡大した画像が見られます）
辻：そして、アウトコースは走行体が転倒しやすい立体難所があるので、信頼性の高い走りを実現する技術要素が重要です（図2-5）。要は、10回試行すると10回成功する技術要素を開発することが重要ということです。経路は決まっているので、その道を確実に通れるかというのが大事であることをアピールしています。
図2-5 立体難所のあるアウトコースでは確実さを追求する走りが大事
（クリックすると拡大した画像が見られます）
要求分析のシートでは、ドメイン分析、ユースケース分析、要求図を使った走破戦略の検討について議論をしました。田町レーシングのモデルシートでは、要求図で要求を整理し、後に続く構造・振る舞い・性能のモデルの根拠を示しています。また、議論では、ETロボコンに関する技術的な内容だけでなく、要求を仕様化するときの要求図の使いどころなど実践面にも話が及びました。
辻：要求分析のシートの内容は、ドメイン分析、ユースケース分析、要求図を使った走破戦略の検討の3つです（図3-1）。
図3-1 要求分析のシート
（クリックすると拡大した画像が見られます）
辻：まず、1つ目のドメイン分析で、田町レーシングがETロボコンの競技をどう捉えているかを示しています（図3-2）。大事なのはコースをエリアに分け、エリアごとの走破戦略を考えることだとしました。ドメイン分析のノートにも書いていますが、エリアごとに担当者を決めて、エリアごとに最適な走法を個別検討しやすくなります。
手嶋：2009年の田町レーシングモデルと視点が異なっている点が面白いですね*3-1。2009年モデルはコースを論理的に捉えて、区間の組み合わせ分、複数あると考えました。2010年モデルはコースを物理的に捉えて、イン/アウトコースの2つと考えてますね。視点によって捉え方が異なることが分かりますね。
*3-1昨年のモデル座談会記事の「3. ドメイン分析」を参照。
図3-2 ドメイン分析
（クリックすると拡大した画像が見られます）
辻：ユースケース分析は、アクターに提供する価値は何かを考えて、なるべくシンプルにまとめました（図3-3）。他のチームのモデルを見ると、ユースケースを機能分解のように用いているところが多く見られます。しかし、ユースケース図は機能分解のためのモデルではありません。我々は、ユースケースはアクターへの価値提供という観点を重視して分析しました。
図3-3 ユースケース分析
（クリックすると拡大した画像が見られます）
辻：「コースを走破する」というユースケースの要件は、要求図を使って分析しています（図3-4）。ユースケースから単純に構造分析にいくやり方だと、要求分析と構造分析の関係性が分からなくなるので、この構造を導出した理由が説明できるものが間に欲しいと考えて要求図を使いました。読み手の「なぜこの技術要素が出て来たの？」「なぜこの構造になったの？」という疑問に答えるためです。
図3-4 要求図を使った走破戦略の検討
（クリックすると拡大した画像が見られます）
辻：まずは、要求図の見方を簡単に説明します。5つの要素で描いています。
辻：丸の中に+がある記号は包含と言って、MECE*3-2感を意識して要求を分解するときに使う表記です（図3-5）。「コースを走破する」は「エリアを走破する」と「エリアの境界を認識する」に分けられると示しています。
*3-2「重複なく・漏れなく」を意味するMutually Exclusive and Collectively Exhaustiveの略。
手嶋：ANDの関係ですね。
図3-5 包含の利用例
（クリックすると拡大した画像が見られます）
辻：<<deriveReqt>>は根拠を示す関係にあたります。例えば、「正確な弧を描く」から「ミステリー・エニグマ共通」に矢印が向かっていますが、これは「『正確な弧を描く』ってなんで必要なの？」という問いかけに「『ミステリー・エニグマ共通』を走るから」という根拠だと読み取ります（図3-6）。
図3-6 <<deriveReqt>>の利用例
辻：「坂道」と「シーソーのみ」は多段回で<<deriveReqt>>を描いています（図3-7）。これは図の下から読んでいくと、「『傾斜を認識する』のはなぜ？」、「それは『下り坂を認識する』をやりたいから」と読めます。さらに、「『下り坂を認識する』のはなぜ？」、「『坂道』があるから」と読めます。そういう風に辿って読めるようにしています。
図3-7 <<deriveReqt>>を多段回で利用する例
（クリックすると拡大した画像が見られます）
辻：1番下にある技術要素の「時間計」と基本機能の「経過時間を認識する」の関係に<<satisfy>>というものがあります（図3-8）。これは要求を満たす関係で、「経過時間を認識する」という要求を「時間計」という技術要素が満たしているという関係を示しています。
図3-8 <<satisfy>>の利用例
辻：図の左側と右側に「方位を認識する」という同じ名前の要求があります。2つの要求間には、<<copy>>で線を引き、右側の要求をグレーにしています（図3-9）。<<copy>>の仕様上の意味は、矢印元の要求が矢印先の要求のリードオンリーコピーであることを表しますが、ここでは矢印が交錯するのを防ぐために使っています。
図3-9 <<copy>>の利用例
大西：用途としては合っていますか？
青木：仕様では、用途を特に限定してないですね。
辻：「System Engineering with SysML/UML」では、「要求図には1つの要求を複数の名前空間に含めることはできないという制約があり、その制約を回避するために<<copy>>を使う」と書いてありました。今回はそういうのがなかったので、レイアウトを良くする目的で使いました。
辻：最後に、「タイムロスの低減」という箱に<<designConstraints>>というステレオタイプがあります（図3-10）。これは、設計制約を表します。ある要求を実現するときの判断基準を理解できるようにするために書いています。
図3-10 <<designConstraints>>の利用例
辻：トレーサビリティに関して要求分析のシートで意識した点を紹介します。まず、ドメイン分析と要求図での分析の単位は意識して合わせています（表2-1の#1）（図3-11）。ドメイン分析では、コースをエリアというものに分けて、エリアごとに走破戦略を考える必要があるということを書いているので、要求図の中でもエリア単位での検討を意識しています。
 |
 |
| (a) ドメインモデルではエリアごとに適切な走破戦略を検討することを示した | (b) 要求図ではエリアごとに要求を分解して検討した （クリックすると拡大した画像が見られます） |
辻：次に、ユースケース図と要求図とのつながりを意識して描いています（表2-1の#2）（図3-12）。「コースを走破する」というユースケースに必要な機能を要求図で分析していることを示すために、ユースケース図から要求図に矢印を引っ張っています。
図3-12 ユースケース「コースを走破する」について要求図で分析していることを示した
青木：「マーカー色の判定の制約」は<<designConstraints>>に入れてもいいけど、「タイムロスの低減」は競技規約に関係するから<<designConstaints>>じゃなくて<<requirement>>かなと思います。
三村：それはなぜですか？
青木：アクターが直接関係していないので、競技規約は純粋なアクターからの要求ではないんだけど、主催者からの要求なのかなと思いました。
青木：ただの「制約」という言い方だったら、競技規約を制約にしても良いでしょう。でも、「設計制約」という言い方をした場合には、どちらかと言うとハードウェアとか物理特性など設計していく上で、本当は変えられるかもしれないけど、今回は変えちゃいけないものという意味合いがあります。
国正：競技規約を<<designConstraints>>として出した理由は何？
辻：もともとは、リザルトタイムが一番早いチームが優勝するっていう競技規約があるから、それを受けて「タイムロスの低減」を出したんですよね。でも、「コースを走破する」というユースケースからブレークダウンして出てこないから、浮いてしまって<<designConstraints>>にしました。
青木：この場合、競技規約を<<copy>>で持って来て、<<deriveReqt>>を出すのがスマートな考え方かなと思います（図3-13）。
図3-13 競技機規約からタイムロスの低減を派生させる場合の例
手嶋：田町レーシングのモデルは、ETロボコンでよく見かける要求図の使い方と少し違いますね。よく見るのは、要求図で機能要求と非機能要求を抽出して、機能要求はユースケースモデルで、非機能要求はまた別の方法で分析するというやり方です。一方、田町レーシングは、ユースケースの1つを要求図でブレークダウンして、それらを駆動系・認識系という基本機能で分けています。なぜこうしたんでしょうか？
辻：実は、最初はサヌック*3-3の2009年の要求図の使い方を参考にし、ゴール指向分析に要求図を使おうとしていました。トップに「優勝する」というゴールを置いて、その要求を分解したのですが、うまくまとまらず、スコープをユースケースの単に抑える今回のやり方に切り替えました。
*3-32009年にチャンピオンシップ大会で総合優勝した東海地区のチーム。
山内：うまくまとまらなかったのはなぜ？どこら辺で不整合が起きましたか？
林田：発散しすぎるからじゃないですか？「優勝する」とかからやっちゃうと、どこまで分解したら良いか？とか分解の粒度が難しくなります。
辻：論理的分解が難しかったです。トップレベルではMECEを意識して分解できるんですけど、それ以上分解しようとすると破綻して論理展開ができません。それで「優勝する」から分解するやり方はやめようという結論になりました。
辻：そして、トレーサビリティに価値を置いて、そのためにはどう表現したら一番良いかを考えた結果、今の表現に落ち着きました。
青木：ちなみに、私のSysMLの記事*3-4でも、先にユースケース図で機能要求をおさえてから要求図で分析するやり方を推奨しています。それを読んだ結果、このやり方にしたんですか？
*3-4システムエンジニアリングでSysML を使いこなす, https://www.ogis-ri.co.jp/otc/hiroba/technical/SysEngSysML/index.html
辻：そういうわけじゃないです。皆で悩んだ結果、ここに落ち着きました。
（一同笑）
大西：青木さんがこのやり方を推薦する理由はなぜですか？
青木：組み込みの人であったとしても、最初に非機能要求が出てくることはあり得ないからですね。私がコンサルをやるときは、先にユースケース図を描いて、システムと利害関係者の関係を示しています。
青木：まずは、ユースケースで全体像を押さえて、いきなり実装に入るんじゃなくて、要求図を使って機能要求も非機能要求も仕様化してからクラス図に入る流れが良いですよと推奨しています。
三村：青木さんの記事でも途中で非機能要求の発見っていうのがありましたよね。
青木：そう。機能をいろいろ詳細化していると、いろいろと非機能要求が出てきますね。そこで根拠を示すノートに<<rationale>>というステレオタイプを付けて、なんでこの非機能要求を出したのか数式などで示して詳細化していきます。私の経験の範囲では、その方がしっくりくるかなと感じでいます。
山内：面白いなと思ったのが、上の包含でエリアごとにブレークダウンしたところの要求と、下の基本機能にあたる要求が全然違う使い方をしているんですね。要は、エリアと基本機能の要求が違う概念のように見えるんですよ。同じ要求なのに、要求の描き方が違うのはなぜでしょう？
山内：私の解釈としては、上がユースケースで、下がユースケース中に登場するイベントフローの各イベントというように見えます。
辻：当たりです。例えば、4枚目に走破戦略のアクティビティ図が描いてありますが、このアクションは要求図の基本機能に対応しています（図3-14）。なので、このアクションの組み合わせでエリアは走破できるという感じで表現しています。
図3-14 シート4枚目 インコースのアクティビティ図（の一部）
要求図に出てきた基本機能とアクションが対応している
山内：はい、思った通りでした（笑）。上でMECEをとってブレークダウンし、下で個々の要求を挙げるという描き方は一般的ですか？
青木：一般的と言えるほどSysMLは普及していないので、やったもん勝ちですね。
（一同笑い）
青木：文法的に間違っていないので、後はどういう使い方が普及するかという問題だと思います。さっき、要求図の使い方が2通りありますよねという話もあったけど、仕様書にはどちらの書き方も書いてあるし、今後どっちが主流になるかは分かりません。
青木：仕様書には、要求図から出発する方の描き方が最初に書いてあります。でも、逆にユースケース図から要求図に持っていくこともできるよとも書いてあります。そういう書き方なので、仕様書では、どちらかと言うとユースケース図から持ってくる方が異端的な扱いにはなっています。
青木：ただ、使った感じでは、こっちの方がしっくり来るなという感じはしています。ユースケースは目的レベルや機能レベルという形でとどめてrefineを使って分け、上でMECEをとってブレークダウンし、下で個々の要求を挙げるというやり方もすると思います。
青木：UMLもSysMLも単なる表記方法でしかないから、いろんな使い方はできます。どれが正しいかじゃなくて何を表現したいかで描き方は変わってきます。どういう使い方が分かりやすいかっていう市民権をこれからどうやって得ていくのかなというとこでしょう。
大西：おー、いきなり冒頭で深い話が出てしまいました（笑）
（一同笑い）
山内：確かに、ここが一番深くなりましたね。
三村：他のチームは、あまりやっていないところですからね。
林田：今回、辻君が要求図の中身を考えて、僕がそれをVisioを使って可視化する担当をしました。この要素数を見てもらうと分かるんだけど、ものすごい描くのが大変。A2の紙にいっぱいいっぱいやったのを無理矢理ここに縮めて描きました。個人的にはこれはもう2度と描きたくない。
（一同笑い）
大西：今回、本当は経路の通り方を何通りか候補を用意して、設計制約があるから最終案を選んでいるというところまでを描こうとしたんですけど、それを描こうとすると収まらないということでやめたんですよ。
青木：要素ごとに分割してやっていくのが良いと思いますよ。
大西：そうですね。最初に描くときに全体を描こうとして破綻したので、一番最初に難所ごとに描いて、1回統合してから地区大会のモデルを作って提出しました。
青木：個人的な感想だけど、要求図の仕様って最終的にツールで操作することを前提にしているように見えるので、絵として見せることははっきり言って重要ではないという印象を受けるんですよ。
山内：要求管理ツールの方に落ちていくってことですか？
青木：そうそう。だから最終的に線を引っ張っているところを全部ツールでクエリを書いてて、表形式にして管理したりとかするんじゃないかなと。そのときにちゃんとつながっているよねと確認ができれば良くて、あんまり絵的に見せるのにかっこ良くなっていないよなと思います。
山内：これすごい構成管理するのが大変そうですよね。
国正：絶対に線が重なりますもんね。
林田：ほんま辛かったわー。すいません。ちょっと脱線してしまいまして。
三村：今回の要求図は、田町レーシングの尊い犠牲の上に成り立っているんですね。
（一同笑い）
手嶋：2010年は要求図がかなり流行ったから、2011年は皆が要求図を使い始めて、ものすごいやりすぎるチームが出てくるんじゃないかなと思います。それで、審査員から「ここまでするメリットが見えないけど、やりすぎなんじゃないの？」って言われそうな気がします。
国正：さすが、そこまで見えているとは。
（一同笑い）
辻：今回、描き方のオリジナリティ性は高いと思っているけど、そこは評価されていません。要求図にはコメントがありませんでした。
三村：田町レーシングとしてのメリットは何かありましたか？
辻：今回は構造の導出理由を明確にするために描きました。「なぜこの構造？」って聞かれたときに、「ここはこういう理由があって」、と答えられるというメリットはあると思います。
国正：今聞きたかったのは、実感したうれしさがあるかどうかですよね。
大西：今のところ作業上のメリットはあまり見えてないですね。もうちょっと長いスパンの開発で、要求が変わるタイミングがないと分からないんじゃないですかね。
手嶋：おそらく来年は要求図を使うだけじゃなくて、使ううれしさが求められます。
前編記事はいかがでしたか？今回はモデル座談会で議論したトピックのうち、モデルシート全体の工夫と要求分析について紹介しました。
2010年の田町レーシングは、モデルの読みやすさを徹底的に追求し、見出しの書き方、モデル要素の名前の付け方、分析の切り口などに注意を払ったことを紹介しました。モデルとはコミュニケーションの道具であるため、書き手が整理できているだけではなく、読み手にとっての読みやすさも気を払うと、実際の開発が効率的になります。
また、要求分析では構造分析や振る舞い分析のモデルの根拠を示すという目的のために要求図を使いました。今回は要求図を採用しましたが、要求図が唯一の手段ではありません。各チームが自分達のやりたいことに照らし合わせて、適切な方法を取るのが王道です。要求をいかにモデル化するか？は、ETロボコンでも大きく注目されている分野です。ぜひ各チームで創意工夫してください。
来月は、チャンピオンシップ大会でも評価の高かった構造分析と振る舞い分析について紹介します。お楽しみに。
| © 2011 OGIS-RI Co., Ltd. |
|
