　連載「3つの設計アプローチで見るETロボコン参戦記録」の第1回では、私たち富士ゼロックスが企業として「ETソフトウェアデザインロボットコンテスト（以下、ETロボコン）」活動に参加した理由を、第2回では、全チームを通じた取り組みについて紹介しました。そして、連載第3～5回にかけては、異なる設計手法を取り入れた各チームの具体的な取り組み・活動を紹介してきました。

　連載の最終回となる今回は、3チームがそれぞれ行った設計手法の特徴とその差異、使いどころといった技術的側面と、終了後に行ったアンケートから見えてきたETロボコン活動による若手エンジニアの育成効果について、全体リーダーを務めた土樋祐希が考察したいと思います。

チーム1：「Fusion＆Futures」の取り組み（連載第3回）／手書き
チーム2：「みんなとみらい1」の取り組み（連載第4回）／DSL
チーム3：「みんなとみらい2」の取り組み（連載第5回）／BridgePoint

各設計手法の特徴について

　表1は、各チームが行った3つの設計手法について幾つかの観点からまとめたものです。


	手書き（Fusion＆Futures）	DSL （みんなとみらい1）	BridgePoint （みんなとみらい2）
開発に必要な教育コスト（低い程よい）	○	◎（*1）	△（*1）
モデルとコードの一致度（一致している程よい）	△	○（*2）	◎
環境構築に必要な学習コスト（低い程よい）	◎	×	△
フレームワーク部分の品質確認方法	コードを記述して、ロボットで確認	コードを記述して、ロボットで確認	モデルをVerifierで確認
作成したコード量（*3）	1800行程度	1900行程度	5000行程度
表1　各設計手法の比較

表1の注釈：

（*1）：モデルを記述するのに必要な教育コスト。DSL作成そのものやBridgePointのアーキテクチャ構築の部分は除いている
（*2）：一致するのは、DSLで記述された部分のみなので“○”にした
（*3）：大会で使用したコース戦略（イン・アウト両方）を含んだライン数（自動生成の場合は生成後のコード量）

　“開発に必要な教育コスト”という観点では、直感的にコースを作成できるという点で「DSL（Domain Specific Language：ドメイン特化言語）」に優位性があります。「BridgePoint」（注1）の場合、Executable UMLのモデルの作り方に慣れる必要があるため、その分教育コストが掛かります。また、モデルでの動作確認にもノウハウが必要であり、初期の立ち上げはその分のコストを考慮した方がよいでしょう。

　“モデルとコードの一致度”は、その手法によってモデルとコードの乖離（かいり）が起きやすいかどうかということです。乖離が起きやすい場合は一致度が低く、起きにくい場合は一致度が高いとしています。この項目に関しては、BridgePointやDSLによるモデルからのコード生成に軍配が上がります。ただし、DSLによる開発の場合はフレームワークや組み合わせる要素（今回でいう“足周り”の各要素）を作る部分に従来手法による開発が必要となりますので、その部分に関しては手書きと同じ課題が残ります。

　“環境構築に必要な学習コスト”は、各設計手法で必要となる環境を作り上げるのに必要なコストです。DSLによる開発の場合はDSLを作り上げるために必要な学習コストが、BridgePointの場合はツールから自動生成されたソースコードを環境に適合させるためのアーキテクチャ構築に掛かるコストが必要になります。この項目に対しては、“ツールが不要”という点で手書きによる開発が有利です。DSLとBridgePointを比較した場合は、初期に必要となるスキルはDSLの方が広範囲になると思います。どちらも手書きよりもコストが高く、今回の活動でもメンバーに環境構築まで学んでもらうことができませんでした。この件については、本稿の後半でもう一度触れたいと思います。

　“作成したコード量”に関しては手書き、DSLで2000行弱だったのに対し、BridgePointでは5000行程度と倍以上の差がありました。自動生成であるため、手書きよりも冗長なコードができているという面は否めません。ただし、BridgePointのモデルコンパイラは、使わない属性や関係に対するコードは生成しないなど、コードサイズを抑える工夫がなされています。そのため、他のツールに比べて生成されたコードは小さく抑えられていると思います。また、自動生成されるコードにはモデルを駆動させるためのライブラリのコードも含まれています。ETロボコンは全体のコードサイズが小さいため、この部分の占める割合が大きくなっていますが、規模が大きくなればその割合は小さくなるでしょう。DSLでは自分たちにとって最低限必要なコードのみを作ることができるため、自動生成でもそれほどサイズが大きくなりません。

　こうしてみると、どの設計手法も一長一短な部分があることが分かります。では、実際のところ、どのやり方（設計手法）を採用しても大差ないということでしょうか。いえ、そのなことはありません。作ろうとするソフトウェアの規模や複雑さによって、向き不向きといった差異が出てきます。

※注1：「BridgePoint」とは、メンター・グラフィックス社のMDDツール。詳しくは、連載第5回を参照のこと。

ソフトウェアの規模や複雑さによって適材適所に

　今回の活動では、3つのどの設計手法を採用しても、その開発規模は1万行を超えることはありませんでした。ETロボコンの場合は規模・複雑さ、どちらもそれほど大きなものではありません。コードを手書きして、直接ロボットで動作確認したとしても、数カ月もあればこなせる範囲だと思います。この程度の開発規模の場合、MDDなどの手法を使うと、教育コストや環境構築に掛かるコストが相対的に大きいものとなり、負荷となってしまいます。それでは、規模・複雑さが増えた場合は、どうなるでしょうか。2つの側面から検討してみたいと思います。

作るバリエーションの量が増えてしまった場合

　まず、“作るバリエーションの量が増えてしまった場合”に何がおこるでしょうか。ETロボコンで例えると（実際にはあり得ないのですが）、大会のコースが100種類あり、その分ソフトウェアを作らなくてはならないというケースです。

　100個のソフトウェアを限られた時間で作らなくてはならないとしたら、どのように走らせるかという“コース戦略”を考えるだけでも大変です。さらに、それらを手書きでプログラミングするのも大変な作業です。また、「手書きで入力したパラメータにミスがないか」、コース戦略をテーブルとして実装した場合には「次の走行方法へのリンクを表すインデックスに間違いはないか」など、人為的なミスをレビューで発見することは困難ですし、実際に走らせてみないと分からないとなれば、品質の確保に膨大な労力と時間が必要になるでしょう。

　こうしたケースでは、DSLを使ってコース戦略を作成し、そこから戦略のコードを自動生成するというアプローチの強みが生かせます。コース戦略をDSLで作れば、コードへの変換自体に不具合は入り込みません。DSLを使いこなすために必要な教育コストは非常に低く、レビューもしやすいので、人員を追加して対応することも容易に行えるでしょう。

作ろうとするアプリケーション自体が複雑な場合

　次に、“作ろうとするアプリケーション自体が複雑な場合”について考えてみましょう。特に組み込み機器では、機器の外側から入ってくるさまざまな事象（イベント）に対応しなければなりません。いつ入ってくるか分からないイベントが多い場合、それに対応するソフトウェアは複雑になります。

　ETロボコンではそれほど多くありませんが、例えば、筆者がかかわっている複合機の場合は、印刷指示によってイメージを作成し、用紙トレイから給紙し、印字を行って出力するという一連の処理を行います。通常の印刷処理自体を作ることはそれほど難しいことではありません。しかし、実際に印刷を行っていると、用紙切れが発生したり、トナー（複合機で使用するインクのこと）がなくなったり、カバーが開けられたりと、さまざまな事象が起こり得ます（実際に起こります）。複合機のソフトウェアではこうした事象を適切に扱う必要があります。

　これらのイベントとソフトウェアが持つ状態の組み合わせは、タイミングを含めるとほぼ無限にあります。そのため、全てのテストを行うのは非常に難しく、不具合が起こりやすくなります。テストが難しいソフトウェアでは品質をできるだけ上流で作り込む必要があります。

　こうしたケースではBridgePointが適しているでしょう。BridgePointは、外部からのイベントの扱いをステートマシン図で表現できるので、イベント処理に対する曖昧さや不確定さを防ぐことができます。さらに「BridgePoint Model Verifier（モデルシミュレータ）」を使えば、実際の機器上では起こしづらいタイミングでもイベントを発生させて動作の確認ができるため、開発の早い段階で品質確保ができるようになります。初期導入コストが掛かっても、開発規模が大きくなると相対的にメリットの割合の方が高くなるでしょう。

　以上のように、どの設計手法が適切であるかは、対象となるソフトウェアの規模や複雑さ、性質によって変わります。例えば、3000行のアプリケーション開発を手書きで行い、非常に効率が良かったとしても、数万行のアプリケーションでそのやり方が適切であるとは限りません。これと同様に、数万行のアプリケーションで使えた手法が100万行のアプリケーションに適切とも限りません。設計手法を選択する場合には、“どのようなソフトウェアを作ろうとしているのか”ということを考慮する必要があると思います。

ETロボコンで適切な設計手法とは？

　それでは、技術的な考察のまとめとして、ETロボコンではどのような設計手法が適しているのかについて、筆者の考えを紹介したいと思います。

　ETロボコンは開発規模があまり大きくないため、“ETロボコンだけ”を目的に考えれば手書きによるアプローチで十分ではないかと思います。モデルのメンテナンスや情報共有のプロセスに気を付ければ、Fusion＆Futuresチームのやり方が向いているといえるでしょう。

　ただし、コースを速く走ろうとすると、どうしてもチューニングや試行錯誤の部分が出てきます。そのため、“繰り返し”がしやすい手法を取り込んだ方がよいと思います。特に、私たちは今回、制御部分に関してはあまり作り込むことができなかったため、その分コース戦略の組み替えで対応しました。こうした点では、みんなとみらい1チームが行ったDSLによるアプローチが最も効率的なのではないかと思います（ただし、DSLを作れるエンジニアがいる前提ですが）。

　では、みんなとみらい2チームのBridgePointを使ったアプローチはどうでしょうか。ETロボコンのことだけを考えるのであれば、少し負荷が高かったと筆者は考えます。では、負荷ばかり掛かって、無駄だったのかというと、そうではありません。連載第1回で紹介した通り、私たちの目的は“自分たちの業務で使える手法を学ぶ”というものでした。われわれが普段行っている開発規模や複雑度の高い複合機の開発では、BridgePointを使う開発は有効な部分も多いといえます（実際、筆者はBridgePointで開発を行っていました）。また、「モデルを書けば動く」ことをメンバーが実感できたことは、モデリングの観点を大きく変え、今後の分析・設計に役立つものが得られたと考えています。

　参考までに、図1にETロボコンで使えると思われる設計手法の組み合わせを示します。この図に示す通り、ETロボコンではMDD（モデル駆動開発）／MBD（モデルベース開発）（注2）／DSLを組み合わせることができると思いますので、参加される方はこうした手法を試されてみてはいかがでしょうか。

図1　ETロボコンで使える各種手法と適用ドメイン

※注2：「MDD」と「MBD」は、どちらも同じ意味で使われることもありますが、ここではMATLAB/Simulinkなどを用いた連続・制御系のモデル開発をMBDと呼び、離散系を取り扱うモデル開発（UMLなどを使う）をMDDとしています。

　本連載では、MDDツールを使った手法としてDSLを使った開発と、BridgePointを使った開発を紹介してきました。実際に、こうしたMDDツールを業務に取り入れていくというのはハードルが高いように思われるかもしれませんが、どちらの手法も既存のコードや手書きのコードと組み合わせることができます。適する領域を探しながら、最初は小さい範囲に組み込んでみて、徐々に適用範囲を広げていくというやり方をされると、実際の現場でも受け入れられるのではないかと思います。

　また、ツールを使うとコードを自動生成できるということに注目されがちですが、大切なことはコードを自動生成することではなく、モデルという抽象度の高い状態で品質を保てる状態に持っていくことだと思います。今回、3チームともにモデル（特にクラス図）を厳密に書くことを意識してもらい、実際にそのモデルでやりたいことができるかどうかを確認してもらっていました。そのため、モデル提出後に実際のコードを作り始めても大きな構造の変更は必要ありませんでした。特に、BridgePointを使用したみんなとみらい2チームに関しては、審査員から「モデルの完成度が高く矛盾がまったくありませんでした」というコメントをいただくことができ、大きな励みとなりました。このように、MDDツールを使う、使わないにかかわらずツールが解釈できるような厳密なモデルを作ることで、モデルの質を向上させることができると思います。