ロボットソフトウエアと標準化

ソフトウエアとモジュール化

　突然ですが皆さんは、ソフトウエア開発の肝はどこにあると考えていますか？

　ざっくりとではありますが、私は、要件定義半分、モジュール（ソフトウエア）分割半分、と考えています。日ごろ皆さんも苦労されていることと思いますが、この2つは奥が深く、表面上はともかくとして、真の意味で問題なくこなせるソフトウエアエンジニアは意外に少ないのです。

　要件定義について語るべき話は多いと思いますが、本連載の趣旨とずれてしまうため、今回は触れません。今回は、モジュール分割の話をお送りします。

　構造化設計にしろ、オブジェクト指向設計にしろ、モジュール分割（ソフトウエア分割）の単位がメンテナンスの容易性を決めます。ここで言うモジュール分割とは、クラス分け、関数分け、サブルーチン分けから、それらを統合した機能の塊、スレッドやタスクの単位、と幅がありますが、これらをすべて含めてモジュールと呼ぶことにします。

　モジュール分割は難しいですが、ソフトウエアが恐ろしいのは、どんな分割であっても動いてしまうことです。10,000行で1本のプログラムでも、10,000行で200本のプログラムでも、バグがなければ同じ結果が出ます。動いてしまえば、コンピューターの利用者にはその違いがわかりません。しかし、こと障害改修、仕様変更対応となると、前者のスタイルでは破たんしてしまいます。

　では、どうやってソフトウエアを分割するのでしょうか？私も若い人から「モジュール分割の仕方がわかりません」と聞かれることがあります。そんな時、私は、「モジュール分割は思想だよ」と言うことにしています。モジュール分割に絶対唯一の解はない、だから「思想」をもって責任範囲を明確にしなさい、ということです。

　例えて言えば、鉛筆をバラ売りするのか、1ダースの箱で売るのか、1グロスの大箱で売るのか、を決めるのが思想です。これを決めることにより、モジュールの粒度が決まり、インターフェースが明確になり、流用や改造の影響範囲が思想化されるのです。

　この話はソフトウエア設計の深遠な話ですが、本論から外れますので、このくらいにとどめておきましょう。

ロボットをモジュール化するRTC

　モジュール分割を上手にできるソフトウエアエンジニアは多くはありませんが、モジュールの積み上げでシステムを作ることはソフトウエアエンジニアの常識です。しかし、ロボットシステムは違います。

　誤解を恐れずに言えば、10,000行を1本のモジュールで作り上げる、これがロボット開発の現状です。少なくとも、流用可能なモジュールを組み上げて作るという発想は、これまでのロボット開発にはありません。

　メカが中心で、ソフトウエアの役割が小さかったことも理由の1つでしょう。また、ビジネスの前に技術課題を克服する研究が主であったことも理由の1つだと思います。いずれにしろ、モジュール化が進んでいないことが、メーカー内のクローズドな垂直統合型開発の温床になっていると思います。

　ですが、ついに、ロボットも10000行を200本のモジュールで作る時代がやってきました。これを実現するのがRTC（Robotic Technology Component）という考え方です。

　RTCとは、ロボットモジュールのことです。ソフトウエアで言うところのモジュールをイメージしていただいてかまいません。ただ、1つ異なるのが、「ハードウエアを伴うことがある」という点です。

　ロボットは機械システムですから、ハードウエアを伴うのは当然ですね。また「伴うことがある」としているのは、純粋なソフトウエアロジックのみでモジュール化されていてもいい、ということです。

　例えば、前回のRTシステムの考え方のところ（http://thinkit.jp/article/950/1/）で書いた、「何かを検知し」「検知した実態に何らかの処理を施し」「結果を実世界にフィードバックする」という処理を1つ1つRTC化した場合、「何かを検知し」「結果を実世界にフィードバックする」RTCはハードウエアを伴いますが、「検知した実態に何らかの処理を施し」というRTCは、ハードウエアを伴わず、純粋なソフトウエアの処理になります。この処理は、画像認識アルゴリズムに代表されるような、センサーデータの処理ロジックをイメージするとわかりやすいと思います。

　RTCは、ロボット開発のモジュール化を進めます。今後のロボット産業のあり方を変えうる重要技術なのです。