3つの設計手法を比較して見えてくるもの――そして、ETロボコン活動だからこそ得られる効果とは？：3つの設計アプローチで見るETロボコン参戦記録（6）（2/2 ページ）
最終回となる今回は、3チームがそれぞれ行った設計手法の技術的側面と、企業としてETロボコンに参加するメリットや実際に得られたものについて、全体チームリーダーが考察する。
企業としてETロボコン活動によって得られた効果
さて、ここからは今回のETロボコン活動によって得られた効果について紹介していきたいと思います。
今回の活動の大きな目標として、“一からソフトウェアを作り上げる経験をしてもらうこと”と、“モデルを使った開発をしてもらうこと”がありました。そこで大会終了後、メンバーに「今回の活動で生じたスキルの変化」についてアンケートを取りました。図2にその結果の一部を示します。
まず、「モデリング」に関しては90％以上のメンバーが向上したと答えてくれました。これはモデリング勉強会を開催したことと、モデル提出に向けて“他人に見せるモデルを作る”ということを意識した結果ではないかと思います。
次に、向上したと答えてくれたのが「要求分析」でした。これは自分たちでどのような走りをさせるかということを考え、それをモデリングするという過程を体験したからではないかと思います。今回参加してくれたメンバーには、現在中堅として活躍しているメンバーも少なくありません。そうした中でも要求分析の項目が向上したということは、注目すべき点です。これは連載第1回でも書いた通り、現在の組み込み開発は派生開発が多くなっており、要求から作り上げる機会が少ないためではないかと思います。今回の“一から作る”という経験によって、要求分析という上流工程を行う機会が得られたことが、こうした結果をもたらしたと考えられます。
また、「リーダーシップ」や「プロジェクトマネジメント」に関しては、半数程度が向上したと感じており、特に中堅手前のメンバーに効果があったようです。その半面、「リアルタイムOS関連」や「プログラム」に関しては変化がなかったというメンバーが多かったようです。リアルタイムOSに関しては、今回の活動でも一部のメンバーしかかかわらなかったためではないかと思います。プログラムに関しては普段の業務で十分やっており、今回の活動で新たに得たことはないと感じたのだと思います。
こうしたスキル向上の他に、アンケートで出た参加メンバーの感想の一部を以下に紹介します。
- 他グループ（部門）のメンバーとの新たなつながりができた
- ETロボコンに向けたチーム活動には満足しているが、結果が残せず悔しかった！
- もっとうまくやれたことがあったのではと思っている
- チームリーディングの大失敗をETロボコン活動で経験できたことは、自分自身の“大収穫”だと感じている
- 反省点が大量に見つかり、参加してよかったと感じている
- 全国大会へ出場できなかったことが悔やまれる
- 当初の目的だった、MDDに関する知識を習得できた
このように、他の部門やグループのメンバーとチームを組んで交流ができた点や、チームリーダーは普段機会の少ないチームリーディングを経験できた点などがよかったと感じているようです。現在の業務では、チームリーディングをする機会に恵まれている若手が少ないため、ETロボコン活動がよい練習の機会になったのではないかと思います。また、うまくいかなかった点を“次に生かしたい”という前向きな回答も多かったように思います。このように、“成功体験だけではなく、時には、質のよい失敗の機会を与えること”も教育の上では重要だと思います。
ETロボコンだからこそ得られる効果
このように、今回の活動はエンジニア教育として大きな成果を上げたといえるでしょう。では、こうした効果は社内研修では得られないのでしょうか。筆者は幾つかの点に関しては、“社内研修では難しい部分がある”と思います。以下にその理由を紹介します。
1つは、「参加者のモチベーションの維持」です。半年にも渡る活動を、業務を行いながら継続するには参加者のモチベーションが重要です。ETロボコンは対外的に競争するということで“負けたくない”という意欲がわきます。また、試走会やモデル審査といったチェックポイントもあり、それに向けて取り組みを行えます。さらに、会社名を出す（会社の名前を背負う）ということもある意味プレッシャーとなりますので、“やらなくてはならない”という気持ちになるようです。
次に「課題の質」です。大会運営側も毎年知恵を絞って新しい課題を出してくれますし、300を超えるチームが参加し、常に新しいアイデアやモデルが毎回生まれています。そのため、参加者は常によりよいものを目指して取り組みます。まさに“進化するソフトウェア課題”といえるでしょう。社内でこのような生きた研修課題を作るのは難しいのではないでしょうか。
そして、ETロボコンでは、各種セミナーや講演会なども用意され、一線で活躍されているエンジニアの方々の生の講義や話を聞くことができます。社内に閉じこもりがちなエンジニアにとってよい刺激になると思います。
このように、社内研修だけでは得られないメリットがETロボコンにはあると筆者は思います。
MDDツールの適用について
では、もう1つアンケートで見えてきた姿を紹介したいと思います。図3は「MDDツールを業務で使えると思うか？」という質問に対する回答を、MDDツールを使用したグループ（みんなとみらい1、みんなとみらい2）と、使用していないグループ（Fusion＆Features）に層別したものです。
こうしてみると、MDDツールを使っていないグループでは前向きな意見が20％程度にとどまっているのに対し、MDDツールを使用したグループでは約80％がMDDツールを使うことに前向きです。これは当たり前といえば当たり前なのですが、今回の活動で「MDDは使える!!」と感じてくれたメンバーが増えたことは大きな前進です。筆者はMDDツールを実際に適用するには「使える!!」という確信を持つエンジニアがどれだけいるかが大きなポイントだと考えています。そのため、ETロボコンのような小さな規模の開発でMDDを使用し、「使える!!」と思うエンジニアを増やしていくことは、MDDツールを展開していく上で有効だと思います。
今回の活動でできなかったこと
このように、今回の活動で得られたことはたくさんありましたが、一方で不十分だった点もありました。一番大きかったのは（前述しましたが）、MDDツールを使いこなすために必要となるアーキテクチャに関するスキルの展開ができなかったことです。
今回、メンバーの多くがETロボコン初参加でしたので、ETロボコンの課題を分析するのが精いっぱいだった上、MDDツールを使ったチームではその“使いこなし”に時間を取られ、ベースとなる環境整備まで踏み込んでもらうことができませんでした。
実際、BridgePointを使うには、BridgePointのコード生成の仕組みと、ロボットのセンサーやモータなどの各種ライブラリ、そして、タスクやメッセージなどのOSの仕組みを結び付ける必要があります。また、DSLを作るにはVisual Studioの「DSL Tools」の仕組み、DSLの元となるメタモデルの作成、Visual Studioの仕組み、C#でのコード作成、そしてテンプレートの作成といったことを学ぶ必要があります。
筆者が過去に社内で行ったDSL勉強会では、15人に8時間程度の講義・演習を行いましたが、最終的にDSLを作れるようになったのは2人程度でした。広範囲の知識やスキルが必要になるため、そのベースとなる部分をどのように教えていくかも含め、今後の課題であると考えています。
連載のまとめ
さて、全6回にわたって私たち富士ゼロックスのETロボコン活動を紹介してきましたが、いかがだったでしょうか。ETロボコン活動だけでなく、現在抱えている問題の解決のヒント・参考になれば幸いです。
今年（2011年）も私たち富士ゼロックスのETロボコン活動は始まっています。今回も技術的なチャレンジを取り入れた活動になっています。メンバーの多くが入れ替わっていますが、うれしいことに、昨年（今回の連載で紹介したチーム）のメンバーが今年のメンバーに勉強会を開いてくれたり、事務局側として働いてくれたりと、活動が受け継がれています。筆者としては、ETロボコン活動に参加したメンバーが将来会社の技術の一線を担い、後輩を育て、社外にも情報を発信できる人材に育ってくれたらと期待しています。
最後になりますが、こうした機会を与えてくださったETロボコン実行委員会の皆さま、協業してくださった日本マイクロソフトの皆さま、BridgePointの提供・サポートをしてくださったメンター・グラフィックス・ジャパンの皆さま、そして今回の活動を支えてくださった社内関係者（特にメンバーの上司）の方々に対し、この場を借りて厚く御礼申し上げたいと思います。（連載完）
Copyright © ITmedia, Inc. All Rights Reserved.