ObjectSquare [2011 年 6 月号]

[レポート]


ET ロボコン 2010 モデル座談会(後編)
〜ゴールドモデラーが明かす、モデリングの秘訣〜

株式会社 オージス総研
組み込みソリューション第一部
大西洋平

目次

1. はじめに

本連載記事では、田町レーシングチームのメンバを中心に開催したETロボコンモデル座談会の中で挙がったETロボコンにおけるモデリングのポイントやノウハウを3回に分けて紹介しています。

後編にあたる本記事では、難所の攻略方法、2011年の参加者へのアドバイスを扱います。また、連載をする中で読者から質問・コメントを受ける機会がありましたので、この場を借りて回答させていただきます。

なお、本記事では、田町レーシングが作成したチャンピオンシップ大会のモデルを度々引用します。ぜひ、実際のモデルを手元に印刷して記事を読み進めてください。

目次に戻る

2. 難所の攻略方法と性能面の解説(インコース)

難所の走破戦略を検討する上での立脚点として、走行タイムの早さを競うインコースとボーナスタイムの確実な獲得を追求するアウトコースの2つに分けて考えました。4枚目にあたる「最速を目指す走破戦略・技術要素」のシートは、インコースを最速で走るための走破戦略と技術要素について解説しています。要求分析とのトレーサビリティを分かりやすく解説できていましたが、一方で、例外系が明示的に書かれていないことが指摘されました。

2.1 インコースは走行タイム最速を目指した

平岡:シート4枚目は、インコースを最速で走る走破戦略と技術要素を解説しています(図2-1)。走破戦略の要点はシートの左上の黒枠を見てください(図2-2)。私たちは、走行タイムを最短にするためには、速い速度を維持しながら最短の移動距離を走らなければいけないと考えました。


図2-1 最速を目指す走破戦略・技術要素(シート4枚目)
(クリックすると拡大します)


図2-2 走行タイム = 移動距離 / 走行速度

平岡:インコースはエニグマデコーディングやミステリーサークルといった曲線コースの難所が多いため、方向転換によるタイムロスをできるだけ減らすコース戦略を採ることが重要です。モデルシートでは、「タイムロスを減らす」ための走破戦略を検討し、必要な技術要素を書きました。「タイムロスの低減」を前提にして、走破戦略や技術要素を検討する必要があることをシート1枚目の要求図でも示しています(図2-3)。


図2-3 要求図でタイムロスの低減の制約を考慮していることを述べている
(クリックすると拡大します)

平岡:シート中央のアクティビティ図は走破戦略を説明しています(図2-4)。要求図でエリア単位に要求を分析していたのに合わせて、アクティビティ図でもエリア単位で走破戦略を図示しています。アクティビティ図のアクションの粒度は要求図の基本機能、構造分析の区間とそろえています。また、エリア中の各径路で採用している技術要素をトレースできるようにアクティビティ図のアクションにコメントをつけています。


図2-4 走破戦略のアクティビティ図
(クリックすると拡大します)

青木:タイムロスの低減に対して数学的な解決策を取っているところがオージスらしくて純粋に面白いなと思いました。メーカー系のチームだと、モータ特性など物理的な特性を考慮して速くする制御工学的なアプローチを取ると思いますね。実際にインコースは速かったです。

大西:制御工学的なアプローチでがんばってもメーカー系のチームにはおそらく勝てませんからね(笑)。

目次に戻る

2.2 例外系は重要なところにフォーカスして書くと良い

手嶋:このアクティビティ図は、きれいに流れていて見やすいけど、余りにも一本道すぎますよね。実際には考慮したんだと思いますが、例外系のフローが書かれていないので、大丈夫なのかな?と思いました。実際に去年は、スペースの都合で例外系の記述を省略したところ、実現性に疑問を持たれました*2-1

*2-1ETロボコン2009モデル座談会「例外系は重要な所にフォーカスして書く」を参照。

青木:一般的には、組み込み系は8割が例外系だと言われています。だから、正常系のフローが完成しても、まだ全体の2割しか完成していないと考えた方が良いです。

手嶋:例えば、エニグマデコーディングの衝立を誤検知したまま、ミステリーサークルに行くと経路を間違えて通ることが起こります。

青木:ちゃんとパリティ用の衝立*2-2を検知すれば、誤検知に気づくことはできますけど、やってないですよね。

*2-2エニグマデコーディングの衝立は3つあるが、スタート地点に近い方の2つだけでミステリーサークルの経路は判断可能になっている。最後の1つは誤検知を発見するパリティとして用意されている。詳細は2010年の競技規約を参照。

林田:しかし、この5枚の紙面の中で正常系以外に例外系を入れるのは紙面上の限界がありませんか?

辻:モデル審査委員の方は失敗が起きそうなところを考慮しているかどうかを見ていると思うので、例外系を網羅的に検討する必要はないと思っています。

平岡:今回は、パリティ用の衝立を使って誤検知を防ぐことはしていません。そのかわりに、そもそも誤検知が起きないように工夫しています。具体的には、1本目と2本目の衝立を確実に検知するために、2本のちょうど真中に入ってから判別しています(図2-5)。


図2-5 衝立を正確に検知するため正面から判別する
(クリックすると拡大します)

目次に戻る

2.3 例外系の分析手法としてはFMEAなどを使うと良い

林田:例外系の分析については、ユースケース記述や要求図で検討されていると、より説得力が出るのかなと思います。

青木:ユースケース記述に例外系を入れておくと良いでしょうね。

青木:私はメーカー出身なのでFMEA*2-3が一般的なやり方だと思っています。機能レベルのFMEAをやると、非機能要件やユースケースの例外系フローが洗い出されるので、お客様にも薦めています。

*2-3Failure Mode and Effect Analysisの略。

林田:FMEAとはどういうものですか?

青木:FMEAは、機能が故障することを「故障モード」として認識して、故障モードが発生する状況や、影響の度合い、回避方法などを分析する手法です。例えば、ハードウェアであれば、センサが切れたり、通信が途切れたりすることを故障モードとして認識します。ETロボコンであれば、エニグマデコーディングが解読できない状況を故障モードとして捉えて、ミステリーサークルの走破戦略への影響を分析できます。FMEAをやって機能が不足していることに気づいたら、ユースケースに入れていけばよいでしょう。

林田:なるほど、それはおもしろいですね。メーカーのチームはすでにモデルに書いているかもしれないですね。

青木:メーカー系の場合、業務の中でハードウェアに対するFMEAを取り入れている企業は多いですよ。部品レベルのFMEAではハードウェアしかできないけども、機能レベルのFMEA自身はソフトウェアに対しても適用できます。実践しているチームはいるでしょうね。

目次に戻る

3. 難所の攻略性能面の解説(アウトコース)

「確実さを追求する走破戦略・技術要素」シートは、アウトコースの難所やガレージ・インの走破戦略や技術要素を扱っています。アウトコースは転倒のリスクが高いため、本シートでリスク分析と転倒への対処について解説したことは評価されました。一方で、構造面との対応関係が分かりづらいとの指摘がありました。

3.1 アウトコースとガレージ・インは確実さを追求した

大西:5枚目は、アウトコースの難所やガレージインの走破戦略や技術要素について解説しています。ここでは、速さよりも確実さが重要だと強調しています(図3-1)。なぜかというと、提供されている倒立制御ライブラリでは、平面上の走りでは姿勢を維持できますが、段差を乗り越える場合に倒れてしまうリスクが高くなるためです。速さを競うより、倒れずに難所を走破してボーナスポイントを確実に獲得することが重要です。


図3-1 確実さを追求する走破戦略と技術要素(シート5枚目)
(クリックすると拡大します)

大西:シート構成を説明すると、上段に想定されるリスクとリスク対応後のアクティビティ図(図3-2(a))、中段によく起こる失敗の代表例と対策を挙げ(図3-2(b))、下段に対策に必要な技術要素を挙げています(図3-2(c))。


(a) 上段:想定するリスク(左)とリスク対応後のアクティビティ図(右)
(クリックすると拡大します)

(b) 中段:失敗例と対策 (c) 下段:要素技術
図3-2 シート構成(一部を抜粋)

大西:失敗例には、ロボットに働く力や倒立制御の動きなどを説明しています(図3-2(b))。例えば、リスク2「段差を乗り越える時に前のめりに倒れる」には、「段差に衝突した衝撃で前傾になると、倒立制御で重心を前に倒す力が働いて急加速する」としています。

大西:シート下段の技術要素の解説は文章だけだと分かりにくいので、センサ値をグラフで示して説得力を高めています(図3-2(c))。

辻:4枚目と5枚目は審査員から「走破戦略や技術要素をよく分析しているので、高い走行性能が期待できます」と評価されていましたね。

目次に戻る

3.2 性能面の記述と構造との対応関係が弱かった

手嶋:シート4枚目と5枚目のアクティビティ図は、どのアクションをどのクラスが担当するのかすぐには分からず、構造面との対応関係が把握しづらいですね。アクティビティ図は構造面との対応を気にせず自由に書けるので、流れを感覚的に把握するには良いですが、その分、構造面との対応を示すには工夫が必要です。例えば、デシジョンノードを使って定量的な情報を外に出して、アクションをクラス名やメソッド名に近づけるなど工夫すると構造面との対応が分かりやすくなると思います。

手嶋:具体的には、「80cm直進する」を表したい場合、「直進する」をアクションとし、デシジョンノードで80cmを超えているかどうかを判定すると、直進走法クラスが担当することが分かりやすくなると思います(図3-3)。


図3-3 デシジョンノードを使って「80cm直進する」を描いた場合のアクティビティ図

大西:確かに、クラスとの対応関係は書けていませんね。ただ、要求図との言葉の対応関係はかなり気を払いました。

目次に戻る

4. ETロボコン2011参加者へのアドバイス

モデルシートに対する議論を終え、座談会の締めくくりとしてETロボコン2011に参加する人へのアドバイスについて議論しました。2011年は競技規約の改定により、コースの分析に対する重要性が高まるとの予想のもとに、構造モデルを洗練する方法について解説がありました。また、多くのチームがモデルとソースコードが乖離してしまう問題についてはモデリングツールのコード生成の機能を活用するよう提案がありました。

4.1 ETロボコン2011ではコースの分析の重要性が高まる

三村:モデルシートは一通り見てきましたので、最後にETロボコン2011に出るチームにアドバイスをいただけますか?

大西:毎年、モデリングワークショップで、審査員の方が「構造が十分練られていない」とコメントするのを聞きます。ETロボコン2011の競技規約では、難所なしと難所ありの2ステージ制に分かれたことで、ステージごとに走行を大きく変える必要が出てきました。2011年は、新しく追加された「ステージ」を含むコースの分析が重要になるのではないでしょうか?

大西:今までは、難所ありのコースしかなかったので、コースに合わせてパラメータをチューニングして、練習通りの走り方をすれば勝てるという感じでした。2011年は2ステージ制になり、ベーシックステージは走行タイムを競う、ボーナスステージは難所を走破した時のボーナスステージを競うことになります。ステージごとの要求が異なります。この点は、構造モデルとして分析すべきだと思います。

大西:また、Bluetooth通信が利用できるようになったので、情報をもらって判断するなど動的に走行を変更することが増えるのではないでしょうか?*4-1

*4-1Bluetooth通信機器と走行体の間での双方向通信が解禁になった。これにより走行状況をBluetooth通信機器側で解析して、走行体の走行を変えることが可能。

林田:状況変化に柔軟な対応できるような構造にしていないといけないようですね。

目次に戻る

4.2 現時点での機能バリエーションと時間軸の変更を意識してモデルを洗練する

三村:田町レーシングはコースの特徴を分析してモデルを作成していたと思いますが、モデルを作成する上で気をつけたことなどありますか?

辻:モデルをいかに洗練させるか?という論点でコメントをすると、私はクラス図を作り上げるときに2つの点を意識します。

辻:1つは現時点のバリエーションです。自動販売機を例にあげると、缶ジュースを販売するものがあったり、 タバコを販売するものがあったりしますが、そのようなバリエーションの中で本質的に変化しないところはどこかに 目を向けることで安定した構造を目指します。

辻:2つ目は時間軸に対する揺さぶりです。過去や未来に対して視点を動かしたときに本質的に安定しているところはどこかを探します。自動販売機の例で説明すると、昔は硬貨で購入できたけれども、今はSuicaでも買えるようになっています。機能的な面で変化はありますが、商品とお金を交換するというビジネス構造自体は変わっていません。そのような変動に耐えられるモデルを目指します。

目次に戻る

4.3 モデルとコードの乖離を防ぐには、モデルとコードのラウンドトリップが有効

大西:今回、モデリングと競技用プログラムの作成をうまく回すのが難しいと感じました。整理する対象があやふやな状況ではモデルが作れないので理解するために実装主導で始めてしまいました。その結果、モデル提出締め切りが迫って来た段階では当初の分析モデルの構造とコードが乖離している状況でした。

大西:モデルシートを書く人と実装する人が分かれて作業していて意思疎通がうまく出来ていなかった面もあるのかなと思います。

手嶋:モデルシートを書く人と実装をする人で分かれてしまうと、モデルとコードが乖離するリスクが高まりそうですね。

青木:モデルからコードを自動生成していないの?

大西:していないです。

青木:モデルからC++ソースコードのひな形を作って、実装が変わればリバースしてモデルに反映すれば、そうそうずれていきません。そういうやり方をやらないと、整合性を取るために時間だけ取られてしまいます。

手嶋:モデルシートと競技という分け方ではなく、モデルチームと性能チームで分けたらどうでしょう?

青木:そうですね。性能面はトライアンドエラーが必要なところだから、別チームでやる必要があります。しかし、モデルの最終形が実装になると考えると、実装もモデルの一環として同じ人がやった方がいいです。

青木:田町レーシングのモデルは、基本構造の中に難所固有の情報が出ていません。なので、性能面のチューニングをやる場合は、全体構造は変えずに終了条件や走法の派生クラスを自由に修正できるようになっています。やろうと思えば、モデルとコードの整合性を取りやすい構造になっていたはずです。

林田:今回は、性能チームが先行開発として実装手動でやってしまった面が大きいでしょうね。

青木:お客様にオブジェクト指向開発を導入する時は、全部モデルから修正するようにしていました。実装で変えたとしてもリバースしてモデルに反映していないものは認めないルールにしました。そうやっているとモデルとソースコードが乖離しないし、変な変更が加えられたとしてもリバースした時点で発見できます。

三村:それはモデリングが熟達しているからできるのでしょうか?

青木:モデリングとC++の文法が熟達していない人にやらせました。C++の細かい文法は知らないので、むしろモデルからコードを生成して、関数の中だけ実装するようにした方がやりやすいという状況でしたね。

林田:モデルチームは、ソースコードの雛形を作るところまではしっかり担当して、あと性能担当が中身をしっかり実装するように分担すれば良かったかもしれないですね。あと一週間あればね。

手嶋:あと一週間あれば、一週間後にテンパってたんだと思いますよ。最初が肝心ですよ。

(一同笑い)

目次に戻る

4.4 技術要素は前年のモデルシートから情報収集し、試走で改善した

三村:走破戦略や技術要素はどうやって開発していきましたか?全て自分で考えたものでしょうか?

平岡:昨年のモデルシートから情報収集しました。毎年、技術要素の仕組みや効果について分かりやすく解説しているモデルシートがいくつかあります。それらを読んで、基礎的な技術要素をピックアップし、自分達の戦略に合うようにカスタマイズしました。

大西:会社で本番コースを購入していたので、十分試走ができ、技術要素の改善がしやすかったですね。東京連合で聞いた情報が参考になりましたね*4-2

*4-2東京地区からチャンピオンシップ大会総合優勝を出すことを目標に、東京地区の参加者で集まって試走会やモデルレビューなどを行った。通称、東京連合。「ET ロボコン 2010 チャンピオンシップ大会を目指して

林田:情報共有させてもらえたし、東京連合で交流できたのは良かったよね。この取り組みは続けていきたいですね。

手嶋:東京連合の取り組みは2011年も続けていきますよ。

目次に戻る

5. 読者の質問およびコメントに対する回答

ETロボコン2010モデル座談会の議論はこれで終わりとなります。4月から3カ月にわたって連載してきた本連載記事に対して、読者の方から質問・コメントが寄せられましたので、この場を借りて回答します。

5.1「UMLだからこそ取れるモデル間のトレーサビリティ」って何ですか?

これは前編記事の「2.2 モデルの読みやすさを意識してトレーサビリティを向上させた」にある以下の発言を指してのコメントです。

『林田:でも、実際にモデルを作って社内レビューをすると、トレーサビリティがあるモデル、つまり複数のモデルの内容が一貫している方が自分達が理解しやすいし、レビュアにも理解してもらいやすいですよね。やはり、ここはUMLを使うことの強みをより生かせるところやと思いますよ。』

筆者は「UMLだからこそ取れるトレーサビリティ」は2つあると考えます。

1つ目は、UMLの仕様で定義されているダイアグラム間のトレーサビリティです。例えば、クラス図の操作とシーケンス図のメッセージが対応しているなどが挙げられます。この点はモデル審査基準の「トレーサビリティ」という項目で言及されています。

2つ目は、UMLモデリングのプロセスによってもたらされるモデル間のトレーサビリティです。例えば、ドメインモデル・分析モデル・設計モデルという順にモデルを作成するプロセスであれば、これらのモデル間にトレーサビリティはあるはずです。これは仕様のように公式に定められたものではなく、開発者の間で共有されている共通認識のようなものだと思います。

この2つのポイントを押さえてモデルを作成すると、モデルの読み手は、モデル間のトレーサビリティを利用し、各モデルを対応付けながらモデル全体を短時間で理解できるようになります。モデル審査においても、一番大事なモデルの中身のレビューに集中することができます。

逆にモデル間でトレーサビリティが取れていないと、モデルを”解読する”負荷が上がってしまい、モデルの中身のレビューの比重が下がってしまいます。

付け加えると、これらの作業は「2.3 複数のダイアグラムを読みやすくする工夫を施した」に書いてあるように、モデラ自身が情報を整理したり、概念の粒度を揃えたり、同じ名前を使ったりするなどして、トレーサビリティを向上しなければいけません。かなり難しい作業ですが、良いモデルを作成する上で重要なことです。

5.2 読みやすい=ストーリー性があるってことでしょうか?

読みやすさは色々な要素が組み合さって決まり、また人の主観的によって変わるので、明快にこれだとも言えません。

田町レーシングのモデルでは、ストーリー展開(テーマの一貫性、概略から詳細や結論から理由という流れ)だけでなく、分析の粒度や切り口にもこだわっています。詳しくは前編記事の「2.3 複数のダイアグラムを読みやすくする工夫を施した」を参照してください。

5.3 対象ドメインが徹底的に分析されていて、読み手の立場に立った表現が戦略的に練られていますね?

読み手の立場にたった読みやすさは徹底的に戦略的に練っています。

ドメイン分析を示すことで、モデル審査員の方に田町レーシングの考え方を知ってもらうことができ、後に続くシートをスムーズに読んでもらえる効果があると考えています。

また、モデル審査委員の方に着目してもらえるようにオリジナルの切り口を盛り込んでいます。例えば、記事でも言及しているように、2010年から競技規約が変わった部分に着目してモデル化しています。

2011年も競技規約が大きく変わっているので、規約の変更に着目するやり方は有効だと考えます。ただし、競技内の本質的な部分は変わっていないはずので、変えるところ、変えないところは区別する必要があるかもしれません。

5.4 SysMLは日本語の資料が少ないですが、どのように要求図の使い方を学びましたか?

記事中にある「System Engineering with SysML/UML」、雑誌記事、ネットメディアの記事で勉強したり、社内の有識者に教えてもらったりしました。

なお、ネットで見られる記事としては以下があります。興味ありましたら、参照してください。

5.5 要求図は要求と機能と制約の関係が1つの図で示せる反面、ゴチャゴチャしがちな印象です。

要求図は全体像が把握しやすい反面、複雑になりやすいという指摘は全くその通りです。田町レーシングもモデルシートに載せる際にレイアウトに苦労しました。要求図を使う場合、ある程度、要求がまとまってきたら表形式のように管理しやすいフォーマットに移すなどした方が良いと思います。

5.6 要求図に対する審査員の評価はどうだったのでしょうか?

2010年のモデル審査では要求図に対してコメントがついていないので、どういう評価があったかは分かりません。2011年のモデル審査基準において要求に関する基準が詳しく設定されたので、2011年のワークショップでは何か言及されるかもしれません。

5.7 連載記事を読んで、2011年は要求図でモデルを書きたくなりました

ありがとうございます。そう言っていただけると、この連載記事を書いたかいがあります。田町レーシングが描いているやり方以上に、もっとうれしさや良さがはっきり分かるような手法を開発してくれるとうれしいなと思います。

5.8 どういう過程を経てモデルを完成させましたか?

UMLで描いているモデルの原形は6月くらいにおおよそでき上がっています。その後、2か月かけて難所の攻略方法を検討しながら、要求図に書いている非機能的要求を抽出しました。モデルシートそのものは提出日の2〜3週間前から一気に作成しました。また、その時に、モデルをより分かりやすく、納得性を高めるために、中身の詳細を修正しています。

(例)ユースケースの粒度、クラス図の属性の配置やクラス間の責務の再配置、etc.

5.9 プロジェクト管理の面で工夫した点はありますか?

週末しか作業時間がない、各メンバの勤務地が地理的に離れている、家族がいて毎回の作業日に参加できないメンバがいる、という状況であったため情報共有を念入りにやりました。

具体的には、作業日には必ず現状の成果と次のマイルストンまでにやることを確認していました。また、議事録をちゃんと書き、欠席したメンバにも状況が分かるようにしました。

5.10 ツールは何を使いましたか?

利用したツールとしては以下の通りです。

目次に戻る

6. おわりに

4月から続けてきた本連載もこれが最後です。読書の皆さんにとって役に立つ連載になったでしょうか?

本連載記事は、田町レーシングからETロボコン参加者へETロボコンにおけるモデリングのノウハウを提供することを目的に執筆を開始しました。しかし、筆者の当初の想定を超えて、Twitterやブログで反応してくれる読者が多数おり、お互いにノウハウをやり取りすることができました。これは当初の目的を超えた成果です。

ETロボコンはワークショップや各地区の勉強会など対面で学びあう機会は多くありますが、ブログなどを通じて情報をやり取りをしている人はまだまだ少数派だと思います。ブログなどを使って地理的に離れた人と意見交換できると、対面で学ぶ機会をうまく補うことができ、一人だけでは考えつかないアイディアを得ることが出来ます。今後、後に続く人が出てくることを期待しています。

ETロボコン2011参加者の皆さんはすでにモデリングの真最中だと思います。自分が満足を得られるよう、良い成績を得られるよう、頑張ってください。応援しています!

(ETロボコン モデル座談会 完)

目次に戻る





© 2011 OGIS-RI Co., Ltd.
INDEX PREV
INDEX PREV