「プロローグ」では、よく見られる失敗パターン例として3つを示したが、まず多く見られるのが、あるサービスプロセスのごく一部（局部）を置き換えようとする試みである。

　そもそも、サービス業は一連のプロセスを通じて価値を創出するシステム（設計）になっている。ゆえに、ごく一部のプロセスやサブプロセスの置き換えを、サービスロボットやRT応用システムで提案されても、サービス事業者にとっては魅力ある内容には思われない。

　価格を極限にまで低減した、単純な自動化システムであれば、このような提案でも導入の余地はあるが、一定レベルのインテリジェンスさ（知能）を備えるこれらのシステムでは、そう容易（たやす）いことではない。また、人による作業を圧倒的に超えるシステムであれば可能性があると思われるかもしれないが、このような作業は単純労働である場合がほとんどで、アルバイトの人件費との熾烈なコスト競争を強いられる（詳細は「失敗パターン2」で説明）。結果、物別れに終わってしまう。
　このパターンに陥ってしまったのが、かつて、ダイヘンが開発・提案した患者移動支援装置「C-Pam」である。

　看護の現場では、人手による重労働がなされている。特に患者をベッドからベッドへ、またはストレッチャーからベッドへと移乗させる作業は、患者を落とさないように支えながら行うため大変な労力がかかる。そのために、看護師の多くが腰痛に悩まされていると言われる。そこで彼らを、このような重労働から解放し、患者のメンタルケアに専念させることを狙って開発したのがC-Pamだった。

　C-Pamは、患者移乗装置としての要件を備えるべく、非常によく作り込まれた設計がなされていた。
　外周をエンドレスベルトが回転する機構を上下2段に重ねた4組のユニットから構成され、それらを身長方向に連結させている。下部ベルトでC-Pam自身が自走しながら、上部ベルトを逆回転させることで、患者とC-Pam上面との水平方向の相対速度を生じさせずに患者の下に滑り込み、持ち上げることができる。C-Pamを乗せたストレッチャーをベッドに横付けし、C-Pamがベッドへ移動しながら患者さんを乗せてストレッチャーに戻るという、ごく簡単な手順で移乗することができる（動画）。

　安全にも万全を期しており、同社独自の「RINGSERVO（リングサーボ）（*1）」により、常にモータの位置・速度・トルクの情報を送信したり、それぞれの制御方式に切り替えたりすることができるうえ、上位に組み込んだSHマイコンで監視することにより、衣服を引っかけるといった異常を感知したときには即座に停止できるようにしている。また、ベッドの下に入り込む薄く、かつワイドな板状の構造に、すなわち本質安全設計にすることで、万一、落下防止を検出するセンサが故障しても、患者を落下させるリスクを回避している。機械設計の観点から見れば「100点満点」の設計と言えるものだった。

　ところが、2004年10月の発売以来１台も納品には至らず、2008年度には開発中止を決断した。
　関西地区の病院を中心にデモを実施し、「随所でC-Pamの必要性を実感してもらえた」（当時の開発担当）一方、「『患者の移乗に時間がかかる』『従来と同様、人の手で移乗させる方が効率的』といった声も寄せられた」（同）。

　病院などの医療機関や介護福祉施設では分刻みで様々な作業をこなしている。安全性に配慮して低速で移乗作業を行うC-Pamの利用は、看護師1人が1日で看られる患者や担当できる作業項目の減少につながるし、これではメンタルケアに専念することはできない。現場の強く要求する基本機能を備えていないうえ、移乗作業というごく一部の作業の置き換えは、ユーザー側から賛同を得られなかった。

　その後、開発の方向性を変更し、院内サービスを手がける事業者と共同で、介護用マットやC-Pamなどを組み合わせた最適な移乗作業の検討および構築を試みたが、実を結ぶことはなかった。作業プロセスの見直しによるプロセス革新も見据えた取り組みだったようだが、運用モデルの検討が「後付け」となっていたために、仕様の見直しをはじめ抜本的な変更が不可能だったからと推定される。

　ダイヘンの例では、もう1つ重要な話題を提供している。それは、ニーズを聞く相手を見極めることの重要性である。当時の開発担当は、ある大学病院と共同開発しながらもC-Pamが導入されなかった原因の1つとして、次のような言葉を残している。

　「著名な先生が言うことだから、こうした（移乗作業支援）ニーズが必ずあると、盲信してしまった･･･。」

　看護婦や看護師の多くが、移乗作業などの重労働による腰痛に悩まされているという話しを聞かされたことを契機に、ダイヘンではその開発に取り組んだ。確かに、そうしたニーズはあるのだろうが、現場に精通しているわけではない先生から聞かされる重要なニーズと、現場の看護婦や介護士からあがる重要なニーズとが一致する保証はない。

　一方で、現場にニーズを聞いて開発すれば導入に至るかと言うと、そうでもない。いくら現場が必要性を訴えても、予算権限をもつセクション（例えば、本社経営）が首を縦に振らなければ導入には至らない。多くの方が普段の業務で経験している当たり前の話だろうが、ロボット／RTシステムの開発でも、現場からニーズを聞き出したうえで開発に取り組み、かつ予算権限を持つ関係者を絡ませなければ導入には至らない。

　予算権限を持つユーザーを絡ませた開発の好例と言えば、富士重工業のオフィスビル共用部向け清掃ロボットがあげられる。富士重工の技術レベルと、開発パートナーである住友商事（住商）側の要望との擦り合わせをしたうえで開発に取り組み、同時に、ビル管理会社の住商ビルマネージメント、ビル清掃会社のエス・シー・ビルサービス（SCB）(*2)などグループ企業を総動員することで晴海トリトンスクエアへの導入を果たした。

　ただし、最終的な意思決定を行う住商と、現場での住商ビルマージメントとSCBとの思いが必ずしも一致していたわけではない。
　住商は「21世紀初のビッグプロジェクトにふさわしい先進的な取り組みを･･･」という強い決意で臨んでおり、清掃ロボットの導入を早々に決めていた。が、共益費の大幅な低減を課せられていた住商ビルマネージメントと、清掃効率と品質の両立を課せられていたSCBは、清掃ロボットの導入は有力な選択肢の1つに過ぎなかった。特に、坪当たりの共益費を、試算上の6,700円から5,000円に低減することを要求されていた住商ビルマネージメントは、光触媒の外壁面への全面適用をはじめ、あらゆる方法を模索しており、様々な技術調査を実施していた。

　最終的には、清掃スタッフの作業量や人件費との比較、労務管理にかかるコストなど、総合的な判断から清掃ロボットの導入が決定されるが、最終意思決定を行う住商が主体的に開発および導入に関与したからこその結果である。

【失敗パターン2：ターゲットが肉体労働・単純労働に集中（＋フロントステージ支援の重要性）に続く】

■関連サイト
ロボナブル2008年8月特集
「先進事例に見る サービスロボットによるプロセス革新」
－サービス事業者の取り組みから学ぶ開発の押さえどころ－
ビル管理コストの低減と品質維持を果たした住友商事グループ
http://www.robonable.jp/monthly/2008_08/index.html#p003

ロボット開発最前線2007
ロボットを看護の現場に適用するためには、その文化を変えることが大切です　ダイヘン
http://robonable.typepad.jp/robot/2007/07/post_11de.html

Robotコンサル小西の「超・思考法」
第17回　移乗介助ロボットの実用化に向けた課題と解決ポイント
http://robonable.typepad.jp/column/2010/01/post-091119.html#tp