－我流ながらもソフトウエアの品質確保に注力－
最後に、東の「小結」には富士重工業の清掃ロボット事業を選びました。先月（2009年11月）、CADとの連携により清掃ロボットの走行プログラムを自動生成できる「走行プログラム自動生成システム」（以下「自動生成システム」）を発表し、併せて、2012年以降には清掃ロボットに基本的なRTコンポーネント（RTC：知能化モジュール）を実装し、自動生成システムおよびプログラム管理機能をライセンス販売することで、清掃事業者が任意に経路変更できるようにする方針も示しました。さらに、これらを清掃ロボットと一体でビル管理会社などに提供し、これらのプロバイダーと一体となって運用方法および清掃ノウハウなどを清掃事業者に提供する新たなビジネスモデル(*1)も示しました。
清掃ロボットのさらなる普及が期待されますが、ロボナブルでは自動生成システムおよびRTCの外部提供を可能にする同社のソフトウエア開発手法および管理手法に注目しています。“我流”ではありますが、こうした取り組みがきちんとなされていない現状のロボット開発に一石を投じると思い、番付に加えました。
＊1：東京・晴海のトリトンスクエアで清掃ロボットを利用した清掃業務を担うエス・シー・ビルサービス（SCB）の宮田敏紀氏は、清掃業務を発注するビルオーナーの考え方により「清掃仕様は大きく変更する」と話す。例えば、単純にコストを重視するのか、品質を重視するのかなど、それともセキュリティを重視するのかという具合に。ゆえに、「清掃ロボットを第一に売り込む先はビルオーナーの方がよい」とし、「清掃ロボットを導入した場合のコストメリット、初期投資にかかる費用など、オーナーを巻き込んでの見積もりを提示したうえで購入してもらい、オーナーが委託する清掃会社に清掃ロボットを買い与えるという流れになれば普及するのでは」という私見を披露していた(2008年7月取材時）。SCBは清掃ロボットを自前で購入しており、提示されたビジネスモデルは現状と宮田氏の考えの折衷的なものと言えるかもしれない。
上述の富士重工の方針は、「次世代ロボット知能化技術開発プロジェクト（移動知能）」（NEDO、2007～2011年、以下「知能化プロ」）で取り組んでいるオフィスビル清掃ロボット用RTC化の成果によるものです。
同プロジェクトに参画する以前よりソフトウエアのモジュール化に取り組んでいましたが、参画後はその見直しに着手し、体系化がなされているかどうか、独立性を確保しているかどうかなどを検証してきました。2008年度からは、次の段階として産業技術総合研究 知能システム研究部門の指導のもとRTC化に取り組み、2009年5月の「ROBOMEC」では「画像によるライントレース」など計8つのRTC化を終えたことを、2009度には「磁気タグ認識」など計7のRTC化（モジュール化）に取り組むことを紹介していました（詳細はこちら）。
2010年度以降は、走行プログラムの作成を可能にする「走行プログラム自動生成モジュール群」の開発に取り組むことを予定していましたが、それが早くも完成し、かつCAD連携機能を備えたのが上述の自動生成システムになります。建物のCAD図面上に「清掃エリア」「清掃開始地点および終了地点」「走行経路」を入力すれば該当するRTCが接続され、走行経路が自動的に生成されます。
 |
図1 「次世代ロボット知能化技術開発プロジェクト」の成果物の一覧 |
|---|
富士重工では、おもに3つのフェーズを経て、開発した各種システムを清掃事業者に提供する方針を掲げています。第1フェーズが、経路地図にもとづいてRTCを選択すれば走行プログラムが生成される対話式システムの開発。第2フェーズが、CAD連携機能により対話式システムでの入力作業を自動化するもので、今回の自動生成システムの開発に当たります。そして、上述のビジネスモデルが第3フェーズに相当します。
第2フェーズでは、走行プログラム管理機能を開発することも予定しています。清掃ロボットの導入時は、清掃現場（清掃事業者側）でのプログラムの調整・変更がなされ、結果、管理側（富士重工）が保有している走行プログラムと一致しないという問題が生じるからです。そこで、作成した走行プログラムは、清掃現場で調整した後に富士重工の管理サーバに取り込み、認可したうえでユーザーに引き渡すという手順を含め、走行プログラム管理機能の準備を進めています。第3フェーズでは、これを清掃事業者向けに改良し、併せて提供することを予定しています。
 |
図2 ユーザー展開を検討している走行プログラム管理システム。第3フェーズでは、これもユーザーに展開する |
|---|
なお、第3フェーズでは開発したシステムのほとんどを清掃事業者に展開しますが、システムの安全性および信頼性を確保するために新規RTCの作成およびRTCの論理変更は不可としています。また、開発したRTCの外販も計画しており、実証実験を通じて、信頼性および再利用性が確認されたものから順次提供する予定です。同プロジェクトに参加し、各参加機関にRTミドルウエアの利用方法などを紹介した産総研の比留川博久氏は「企業の場合、バイナリでの供給になるだろう」としており、その形式での提供になると思われます。
ここからが本題となりますが、富士重工では開発したRTCのユーザーへの展開、それを活用したユーザー側による走行プログラムの変更を可能にすることを表明しています。さらにはRTCの外販も明らかにしています。それを可能にしているのが同社の独特のソフトウエア開発手法および管理手法にあります。
同社ではクリーンロボット部の青山元部長の持論から、また品質を確保する意図から、ソフトウエアはすべてアセンブラで記述していることがよく知られています。RTC化に当たっては、これに加え、各モジュールの粒度は100行程度（A4用紙2枚分）に制限しています。コーディング後の確認作業は、プリントアウトしたものを青山部長が目視で行っており、確実に実行できる目安としてこの分量に定めたからです（「知能化プロ」では粒度を小さくするよう指導されていたとことも関係しています）。
これに伴い、管理モジュール（RTC群）が増えることになりますが、JIS機械製図に従い「総組立図」「部品相関図」「部品組立図」「部品図」･･･という具合に管理しています。バグが発生した場合は、総合モジュール図（ロボナブル側で名付けた）から、あるいは1つひとつのモジュールの両方から追跡できるようにしています。このような紙ベースの管理によりソフトウエア開発の可視化、品質確保に努めています。
また、ソフトウエア設計およびレビューなどの進め方などは、2007年に「サービスロボットの設計」として認証取得したISO 9001に則して実施し、さらに、開発スタッフのコンピテンシーの管理も徹底しています。このような独特の開発および開発管理に異を唱えるスタッフがいたそうですが、すぐに開発から外したそうです。厳しい措置のように思われるかもしれませんが、品質確保という観点からすれば正しい対応(*2)と言えます。
＊2：中国でのオフショア開発が流行始めた頃、多くの組込みシステム開発企業がソフトウエアの品質確保に苦慮した。その1つが、ソフトウエアに付加価値をつけることがペイのアップにつながると考える中国人特有の思考によるもので、仕様に定められていない機能を実装したり設計と異なる記述をしたりしたことがバグの原因になっていた。“余計なこと”をするスタッフの排除は、バグを防ぐうえで必要な措置と言える。
 |
図3 富士重工が明らかにしているソフトウエア開発管理の一部 |
|---|
広義では、ロボットも含まれる組込みシステム開発では、2000年以降ソフトウエアの品質確保が重要な課題になり、様々な開発手法や管理手法が提案、実践されてきました。ただ、携帯電話や情報家電などバーチャルな世界で完結する（アクチュエーションを伴わない）製品やシステムをターゲットにした手法だったため、富士重工ではロボット開発に適した手法として、上述のような取り組みを試行錯誤的に構築しました。
これらの内容はほんの一部であり、ほかにも様々な方法を実践しているとのことです。また、各種システムのユーザー展開を見据え、ここ数年間は新規開発を凍結し、このような開発手法および管理手法の構築に専念してきたそうです。
これら一連の取り組みは知能化プロを活用することで推進してきたものですが、研究機関などが開発した各種RTCは、研究用途でしか使えない見込み(*3)です（詳細はこちら）。実際の製品開発に使える状態で外部提供されるのは「富士重工とセックぐらいなのでは？」という声も聞かれます。開発要求に合致するRTCが少ないという問題もありますが、ソフトウエアの品質管理がなされていないことに原因があります。
＊3：そもそも、RTミドルウエアのようなプラットフォーム戦略の成功条件は、一般に狭い範囲に対し豊富なアプリケーションがあることと、アプリケーション同士の類似性が高いことと言われる。知能化プロではそれを考慮し、典型例のロボットを対象にRTC化に取り組んだが、開発範囲が大きいために、上述の条件を満たせていないのかもしれないし、再利用性が高くなく、かつ「使えるRTCがない」（ある大学研究者）と言われる原因になっているのかもしれない。
現在、知能化プロでは秋葉原に「RTC再利用技術研究センター」を設置し、リファレンスハードなどを用いて各参加企業・研究機関で開発されたRTCの検証を実施しています。RTCを提出しないと次年度以降の補助金が得られないという事情もあり、多くのRTCが集まりつつあると聞きますが、ここでなされているのはRTCの再利用性の確認であり、「RTC提供企業が品質保証を行う」（日本ロボット学会での富士ソフトの見解）ことになります。が、多くのRTCはソフトウエア開発管理が実践されたうえでの成果物ではないため、品質保証がなされた状態で外部提供されるかは不明です。知能化プロが立ち上がった当初、「RTCの品質確保に向けた取り組みが必要であり、管理を担う部隊の設置も構想されていた」（知能化プロ参加企業）そうですが、これが設置され、ソフトウエア開発管理が徹底されていれば外部提供は可能になったかもしれません。
また、「RTミドルウエア」プロジェクト、それを引き継ぐかたちで取り組まれた「次世代ロボット共通基盤開発プロジェクト」や知能化プロでは、RTミドルウエアを活用した開発の高効率化、すなわちロボット開発の「オープン化」を目指していたわけですが、その達成も難しそうです。
組込みシステムもそうですが、基本的にはソフトウエアの品質は「単体テスト」「結合テスト」「システムテスト」をクリアすれば品質は保証されたとされます。しかし、システムとして安全認証を受けるとなると、例えば機能安全規格「IEC 61508(*4)」が開発プロセスを重視しているように、「計画」「設計」「実装」「検証」の各工程で安全コンセプトに従い、どのような開発・管理手法にて開発したが問われます。「生活支援ロボット実用化プロジェクト」で検討される安全認証システムでも、同様の内容が問われるはずです。そういう意味で、富士重工の活動は基本的な取り組みが実践されており、好感が持てます。
ただし、同社の取り組みは我流であり、必ずしもベストな方法ではありません。すでに外販している専用部向けオフィス清掃ロボットも我流で安全性を確保しています。対応する安全規格がないため致し方がないのでしょうが･･･。彼らも十分承知しており、生活支援ロボット実用化プロジェクトではIEC 61508などに対応した開発を実践し、安全技術を実装した清掃ロボットの開発を予定しています。
＊4：機能安全規格IEC 61508が規定する設計工程は、①本質安全設計、②リスク分析、③リスク基準設定、④安全要求仕様、⑤ハードウエアの機能安全設計、⑥ソフトウエアの機能安全設計、⑦機能安全管理、⑧残留リスク対応、という手順をとる。サービスロボットの開発に適用するためには、各工程でいくつかの課題があり、例えば、②では「ヒューマンファクター」を研究している分野は原子力などに限られ、ロボットと人間との協調作業におけるリスクの分析が困難。⑤と⑥ではそれぞれベストプラクティス（設計技法）が示されているが、簡素化しないと膨大な開発コストを要する。⑦ではサプライヤーを含め設計・製造に従事した人のコンピテンシー（資質）まで問われており、その管理が求められるが、それを行うのは困難。⑧では既存の機能安全規格が対象とする産業システムと異なり、一般消費者向けへの対応は困難、といったものがある。少なくとも、③が明確になされていないと次工程への移行は困難であり、利用対象および環境、マーケットなどに区切って、リスク基準を明確にしておくことが求められる。生活支援ロボット実用化プロジェクトは、4つの典型例（ロボット）をもとに取り組もうとしており、このような問題を的確に捉えた取り組みであると言える。
■関連サイト
2009.11.30 富士重工、新開発の走行プログラム自動生成システムを披露、使い勝手に課題
http://robonable.typepad.jp/news/2009/11/30subaru.html
2009.11.25 富士重工、オフィスビル専用部向け清掃ロボ開発、レーザ三角測量で自律移動
http://robonable.typepad.jp/news/2009/11/25subaru.html
2009.11.21 富士重工、CADと連携可能な走行プログラム自動生成システム開発、ライセンス販売へ
http://robonable.typepad.jp/news/2009/11/21subaru.html
2009.09.16 富士重工、知能化モジュール提供へ、ユーザー側で清掃ロボの走行プログラム作成可
http://robonable.typepad.jp/news/2009/09/20090916-2f08.html
2009.05.27 富士重工、RTM化するソフトウエアモジュール紹介、磁気およびジャイロ走行可能に
http://robonable.typepad.jp/news/2009/05/20090527-rtm-bd.html
2008.09.10 【RSJ学術講演会】富士重、2段構えの開発でRTM準拠知能モジュールの提供を検討
http://robonable.typepad.jp/news/2008/09/20080910-rsj2rt.html
