どうも．ysugaです．
国際ロボット展が行われて，僕も最終日にようやくNEDOのブースのRTミドルウエア関連の展示を見ることが出来ましたが，いろいろと突っ込むところが合って，まとめて書くにはTwitterやFacebookは狭いので，こちらに書くことにしました．
ソフトウエアは展示するのは難しい
あの場所に来られる方は，多くは動くモノを見に来ているので，かなりソフトウエアのアドバンテージを示すのは難しかったと思います．画像処理を行って，ロバストに把持戦略を行うマニピュレータという意味では，FANUCのロボットなどには負けてます．単純にパフォーマンスだけで比べたらダメっす．
ですので，RTMなりに何がすごいのか，をプレゼンするのが大事な場所で，それについてはプレゼンターの方々はわかっていらしたと思います．
今回の展示について
そもそも，あのNEDOブースでのRTミドルウエア関連の展示は，何が目的だったのか良く解りませんでしたね．ひろく一般にNEDOの仕事を理解してもらって，次回の仕分けの対策にするんでしょうか？それならそれなりのプレゼンがあったと思いますよ．
また，RTミドルウエアのユーザを増やしたかったんですかね？それにしてはRTミドルウエアのユーザ視点でのアドバンテージについて良く解りませんでした．メーカー視点であってもそうです．その辺の目的意識はあったのでしょうか？
今回の大阪大学や豊橋技科大のプレゼンテーションでは，コンポーネントの代替という部分についての話が取り上げられていたと思います．
つまり，同一機能を有する異なるハードウエアやソフトウエアを入れ替えることができる，という機能です．
この部分は，豊橋技科大では，位置を検出するセンサをステレオカメラにするか，デプスセンサ（スイスレンジャーとか）にするか，というプレゼンで，大阪大では，画像処理のアルゴリズムを入れ替えて使っていました．
正直，この部分は，聞いている人に良く伝わっていなかったと思います．これが出来て，何が嬉しいのか．そういうプレゼンがありませんでした．これは，正直失敗だったと思います．
（ほぼ）静態展示だった他の作品なども，やはりソフトウエアがすごい，というプレゼンにはなっていなかったと思います．
RTミドルウエアのアドバンテージ
RTミドルウエアのアドバンテージを考えると，
- オープンで，フリーで無償で使える
- 対応製品の試用までのハードルが低い
- コンポーネントの代替が可能
などが考えられますね．
今回のプレゼンでは，代替可能という部分にフォーカスがあったようですが，それがどの程度のアドバンテージになるのかをもう少し上手く説明してほしかった．
たとえば，共通仕様とすることによる新規事業者の参入障壁の低減や，製品の代替によるシステムのサステイナビリティの担保といった視点で話をすべきだったと思います．誰にとって，どんなふうに嬉しいのか．そういう話があるべきですが，それがプレゼン中に一言だけ触れられているだけ，というのは日本人にありがちなプレゼンの仕方で下手だと思います．
僕なら，10分あれば，6分はこの説明に時間を割いて，具体例などを交えて，いかにRTMを使うとハッピーになるかを説き，残り二分くらいでデモします．興味を持ってもらうには，別にやって見せるという部分はほとんど要りませんよ．
今必要なのは問題意識の共有
問題なのは問題意識の共有部分だと思いますね．ソフトウエアに限らず，各社，勝手な仕様で作って行って，グローバルに展開する際に独自仕様という部分が参入障壁になり得るという事をもう少し多く話してほしかった．今は「ガラパゴス」という便利な言葉もありますからね．
僕個人としてはガラパゴスは単純に悪とは思っていません．たとえばケータイですが，今はandroid使ってますが，次はガラパゴスケータイにしようと思っています．日本の厳しいユーザの視点で作られた独自仕様は，非常に安定していて，満足度が高いです．
では何が悪いのか．それは，仕様が表に出てこない事に加えて，ベンダーロックインを狙うばかりに，ユーザにとっては使いにくいものになっている点です．ユーザは選択肢が多い方に流れると思います．日本の工業用のロボット製品はほとんどがこういう仕様になっています．各社が自社の加工機械やネットワーク機器，制御機器を使ってもらうために独自規格，独自言語でのプログラミングを強要しています．もちろん，サードパーティからブリッジと呼ばれる変換機器を介して，別の通信規格を使うこともできますが，通信のリアルタイム性が損なわれたり，双方向性すら担保されない製品もあり，やはり使いにくいのが現状です．今回のiREXでは，僕も展示側に居たのと，普段お世話になっている方々とのコミュニケーションに時間を使ったので，あまり工業製品側のセクションを見れなかったのが残念です．
また，研究関連のみでなく，日本のロボット関連機器のソフトウエアは非常に貧弱です．普段，僕が扱っているのはすべて海外製品です．一人多国籍軍です．海外製品には，細かい仕様だけでなく，簡単に使い始められるソフトウエアがあり，また，他のソフトウエアと繋げるためのインターフェースがあります．さらに気のきいたものでは，独自のミドルウエアが用意されていて，多数の言語やＯＳを選んで使うことができ，ネットワークに対応していて遠隔操作が簡単にできるようなものもあります．日本でこのレベルに達している機器がいくつあるでしょうか・・・
つまり，これくらいソフトウエアに力を注がなければ，海外では製品として売れないのです．
なんでこうなったのか
一つは日本の人間が，形が無いものに対する価値を認められなかった点にあると思います．マニュアルやソフトウエアに関して，それがお金を払う価値があるもので，製品の一部であるという認識が欠落しています．オマケ程度にしか見ていないのです．
もちろんソフトウエアを扱う会社はこの限りではありませんが，ロボットという事に関して言えば，モノがありき，なのは仕方ありません．ただ，モノを作っている会社に，この意識があるのかどうか，はなはだ疑問です．
買う側にも問題があります．こういうソフトウエアやサービスについて，価値を認める仕組みになっていますか？単純に相見積もりする際に，ソフトウエアやサービスで比べることって出来てますかね？モノがあって，サービスは二の次なのが現状だと思います．
でも，作る側，とくに海外に製品を出そうと思っている人がこう思っていてはダメです．製品にはそれに付帯するソフトウエアやマニュアルを含めた，「サービス」が含まれています．この辺をどれだけの人が理解できているでしょうか．
開発資金が無い，というのは非常にツライ意見ですが，ハードは90点，ソフトは30点という製品Aと，ハードは70点，ソフトも70点という製品Bなら，製品Bを選ぶのがこれからの潮流になると思います．前者を選ぶのは骨董品の考えをしている人かエキスパートかどちらかです．ハードウエアの70点を90点にするコストと，30点のソフトウエアを70点にするコストは，どう考えてもソフトのコストの方が低くなります．まずはそういう仕事が出来る若いエンジニアを雇ってください．
どういうソフトウエアがいいのか
では，どうしたらいいのでしょうか．まずは，どういうソフトウエアがウケるのか，についてまとめます．
一言で言うなら，噛めば噛むほど味が出るソフトウエアです．
まず，その日のうちに動かすことができるソフトウエアが必要です．
出来れば15分．なるべくなら一日で，ロボット製品の動作の確認ができること．
次に，一週間くらいで，自分自身のプログラムを作成できるようにする工夫です．
これはAPIを単純に用意するのだけではなく，それを使ってデモプログラムを作るための環境設定方法などをまとめたチュートリアルです．
最後に，使いこなしてきた時に参照できるAPIのリストです．
このレベルのユーザの要求は多岐にわたるので，周到な用意が必要になりますが，いちばん簡単なのはすべてオープンにすることでしょうか．APIがアウトプットする際に使うさまざまな付加機能が邪魔になることがありますから，これらを取り除くことすら彼らは要求します．このレベルのユーザは，自身で開発することのリスクも十分に理解したユーザですから，デベロッパは渡り合いやすい相手だと思います．
とにかく，3・4日，時には一週間以上，スペックシートとにらめっこして本体が動かない，というのはストレスです．ユーザにとってもそうですし，そのユーザの上司が先にパンクしますwww．良く解ってない人ならなおさら，というわけです．
RTミドルウエアが解になり得るか
どちらかといえばこの答えはNOです．単純にRTCに対応させただけでは，このようなソフトウエアにはなりません．
ただ，上記の枠組みを提供する方法の一つになり得ると考えています．つまり上記の枠組みになぞらえてRTCを使えば，この答えはYESになります．
私がこれまで考えたシナリオだと，こうなります．
まず，ユーザにRTCをサンプルとして提供します．RTCはこれまで提供していたAPIをラップした，単純なもので良いです．機能のすべてをRTCのレベルでアクセス出来る必要はありません．また，そのRTCを使ったサンプルプログラムを提供します．これらはインストーラでインストールが出来，単一のexeファイルやbatファイルなどから起動が出来るようにします．決して，ユーザにRT System Editorを使わせてはなりません．下手です．
これで最初の関門をクリアさせます．
次の関門では，RTCを再利用してもらいます．この辺はRTCを自身で作る作業が必要になってしまいますが，いずれRTミドルウエアのような仕組みを使うことがロボットを作ることと同義になるのは間違いありませんから気にしてはいけません(笑)
最後の難関ではユーザが直接APIに触れます．このレベルでは隠された機能が解放されます．
APIを使ったデバイスの初期化や終了処理の例としてRTCは最適です．RTCのソースコードをユーザにサンプルとして提供することで，どの部分が初期化なのか，エラー処理なのか．どのAPIでデータを取得できるのか．それがわかるはずです．
もちろん，使っていないAPIに関するマニュアルが必要ですが，このレベルのユーザはdoxygenなどがコメントから自動的に生成するマニュアルで十分です．
誰がRTミドルウエアのユーザなのか
最後に，ロボット展のプレゼンに話を戻すと，誰がRTミドルウエアのユーザなのか，プレゼンする側が良く解っていたのか疑問です．
前節でお話しした内容は，RTMに対応した製品を提供するデバイスメーカーのためのストーリです．短い時間の中でこのストーリを言うのは無理ですが，何がハッピーなのかをもう少し具体的にイメージ出来れば，よりわかりやすく話が出来るはずですし，聞いている人がたとえ第三者であったとしても違うものです．
まとめ
僕はRTミドルウエアは，同じような目的を持つ海外のロボット用ミドルウエアに比べて多くの点でアドバンテージを持っているモノだと確信していますが，イマイチ浸透していないのが残念でなりません．
日本発のものを皆で育てようという人こそ，国際化ってことに理解がある人だと思うんですがね．
このウェブに入門記事を載せてるのはそういう意味です．これからロボットまで，海外の規格や技術のマネをするんですかね？
ここまで読んでいただいてありがとうございます．
ぜひ，一度，OpenRTMを使ってみてください．質問があればOpenRTMのメーリングリストにメールを送るなり，僕にtwitterで話しかけるなり，なんでも周りの人を使ってみてください．
（2011/11/14 用語を間違えてました．ベンダーロックアウト×→ベンダーロックイン○）