ロボット導入の失敗パターンと回避——「とりあえず導入」の解剖

エグゼクティブ・サマリー

• 導入したロボットが使われない原因は、機種選定の失敗ではなく、その手前の意思決定の欠落にある。カタログ比較から始めたプロジェクトは、着手時点でほぼ勝敗が決まっている。
• 現場で繰り返し観測される失敗は5つに集約される——①ありたい姿の不在 ②要件定義を飛ばした選定 ③PoCの目的化 ④プロマネ不在のコンソーシアム ⑤定着化の未設計。
• この5つは独立していない。①が欠けると②〜⑤がドミノ式に崩れる。逆に言えば、上流の1工程を正すだけで下流の失敗確率が大きく下がる。
• ロボット導入は7つの工程に分解できる。SIer・メーカーが担うのは中央の「設計・開発」だけであり、その前後を誰が担うかを決めていないプロジェクトが、最も高い確率で失敗する。
• 対策は投資額を増やすことではない。順番を戻すことである。構想→要件→PoC→選定→組成→導入→定着化。この順番を守るだけで、同じ予算でも結果が変わる。

なぜ「とりあえず導入」が起きるのか

ロボット導入の相談を受けるとき、最初に聞く質問はいつも同じだ。「そのロボットを入れて、何がどう変わっていればプロジェクトは成功ですか」。この問いに即答できる企業は、経験上、半分に満たない。返ってくるのは「人手不足が解消される」「省人化できる」といった、目的というより願望に近い言葉である。

これは担当者の怠慢ではない。むしろ構造的な問題だ。ロボット導入の検討は、多くの場合「現場が回らない」という切迫した状況から始まる。採用が追いつかず、既存社員の残業が慢性化し、経営から「自動化を検討しろ」と指示が降りてくる。担当者は展示会に足を運び、メーカーのデモを見て、カタログを集める。ここまでは自然な流れに見える。

問題は、この流れの中に「自社の業務をどう変えるか」を考える工程が一度も現れないことだ。展示会で見えるのはロボットの性能である。デモで示されるのはメーカーが最も得意とする条件下での動作である。カタログに書かれているのは仕様であって、自社の現場でそれが成立するかどうかではない。それでも、目の前に動くロボットがあると、人は「これを入れればなんとかなる」と感じてしまう。

そして稟議が通り、導入が決まる。設置され、しばらくは物珍しさで使われる。やがて「思ったより手間がかかる」「例外ケースは結局人がやる」「担当者が異動して誰も触らなくなった」という声が出はじめ、半年後には隅に置かれている——このパターンは、業種を問わず驚くほど同じ形で繰り返される。

失敗パターン①：ありたい姿（RXビジョン）がない

最も根が深い失敗である。「人手不足だから」は動機であって、要件ではない。

要件になるには、少なくとも次の3つが決まっていなければならない。どの業務を（対象範囲）、どの水準まで（目標値）、いつまでに（期限）。たとえば「倉庫内のピッキング歩行距離を、2027年3月までに現状比40%削減する」であれば要件になる。「人手不足を解消したい」では、導入後にそれが達成されたかどうかを誰も判定できない。

判定できないということは、評価軸が存在しないということだ。評価軸のないプロジェクトは、うまくいっているのかどうかが分からないまま進み、誰も止められないまま完了する。そして完了後に「で、結局どうだったのか」を問われて、答えられない。

さらに悪いことに、ありたい姿がないと投資判断の基準も作れない。3,000万円のロボットが高いのか安いのかは、それによって何がどれだけ改善するかが分からなければ決まらない。結果として「予算内に収まるか」だけが判断基準になり、本来必要な周辺投資（設備改修、システム連携、教育）が削られる。削られた部分が、後から失敗の原因になる。

手当てする工程： 工程01「RXビジョン設定／RX構想策定」。ここで現状業務を可視化し、ありたい姿と事業計画を先に置く。この工程を飛ばして進んだプロジェクトは、後から戻ることが極めて難しい。

失敗パターン②：要件定義を飛ばして機種を選ぶ

「どのロボットがいいですか」という質問は、実は答えられない質問である。要件がなければ、良し悪しを判定する基準がないからだ。

ロボットは汎用機ではない。搬送、ピッキング、清掃、警備、案内、検査——用途ごとに全く違う製品カテゴリがあり、同じカテゴリの中でも可搬重量、走行環境、通信方式、安全規格への対応が異なる。「うちの現場に合うか」は、現場側の条件を数値で書き出して初めて判断できる。床の平滑度、通路幅、段差、照明条件、Wi-Fi環境、稼働時間、扱う対象物の形状・重量・ばらつき——こうした条件が要件定義書に落ちていなければ、メーカーも正確な回答ができない。

要件を渡さずに相談すると、メーカーは「一般的にはこう使われています」という答えしか返せない。それを比較しても、比較していることにはならない。カタログスペックの数字を並べた表が意思決定資料として出てくるとき、そのプロジェクトはすでに危うい。

手当てする工程： 工程02「要件定義／PoC／ロボット選定／プロジェクト組成」。構想を要件に翻訳し、その要件でベンダーに問い合わせる。順番が逆になっていないかを常に確認する。

失敗パターン③：PoCが目的化する

PoC（実証実験）は本来、投資判断のための情報を得る手段である。ところが実際には、PoCそのものがゴールになっているケースが少なくない。

症状は分かりやすい。PoCの成功基準が「ロボットが動くこと」になっている。評価レポートに書かれているのが動作の可否だけで、投資判断に必要な数字——サイクルタイム、稼働率、例外発生頻度、人の介在時間、想定運用コスト——が測られていない。あるいは、メーカーが用意した理想条件で実施され、実際の現場条件（繁忙期の物量、イレギュラーな荷姿、人が行き交う状況）が再現されていない。

こうしたPoCは「成功」で終わる。そして本番導入して初めて、現実の条件では成立しないことが分かる。PoCにかけた時間と費用が、意思決定の役に立たなかったことになる。

正しいPoCは、最初に「どの数字が、どの水準を超えたら本番に進む」を決めてから始める。そしてその数字が取れる条件で実施する。うまくいかない条件をあえて含める——例外ケースを混ぜる、繁忙期の物量で回す——ことが、PoCの価値を決める。

手当てする工程： 工程02の中のPoC設計。評価設計を先に固め、複数機種を同一条件で比較できるようにする。

失敗パターン④：コンソーシアムにプロマネがいない

ロボット導入は、一社との取引で完結しない。機体メーカー、システムインテグレータ、周辺設備業者、施工業者、既存システムのベンダー——複数社が関わるコンソーシアム型が普通である。

この形態には固有のリスクがある。責任の隙間だ。ロボットは仕様どおり動く。倉庫管理システムも仕様どおり動く。しかし両者をつなぐ部分の仕様が誰の担当でもなく、統合したら動かない——という事態が起きる。各社は自分の契約範囲を果たしているので、誰も悪くない。しかしプロジェクトは止まる。

このとき、全体を見て調整する役割が必要になる。ところが発注者側の担当者は、本来の業務を抱えながら片手間で対応することが多く、専門知識も限られる。結果として、最も声の大きいベンダーの言い分が通る、あるいは調整が滞って納期が延びる。

手当てする工程： 工程02のプロジェクト組成と、全工程を貫くプロジェクトマネジメント。責任分界表を最初に作り、統合部分の担当を明示する。コーディネート役がプロマネを兼ねるケースも多い。

失敗パターン⑤：定着化を設計していない

導入完了がゴールになっているプロジェクトは、必ずここで躓く。

ロボットは設置すれば自動的に使われるわけではない。現場のオペレーションが変わるということは、そこで働く人の手順、判断、責任範囲が変わるということだ。誰が起動し、誰がエラーに対応し、誰が消耗品を交換し、誰が改善提案を吸い上げるのか。これらが決まっていなければ、最初の小さなトラブルで運用が止まる。

さらに、導入直後は必ず期待どおりに動かない期間がある。パラメータの調整、レイアウトの微修正、例外処理のルール決め——この立ち上げ期を乗り切る体制がないと、現場は「やっぱり使えない」と結論づけてしまう。一度そうなると、技術的に解決可能な問題でも、心理的に元へ戻せなくなる。

手当てする工程： 工程06「定着化」と工程07「運用」。ただし手当ての設計自体は工程01〜03で行う必要がある。運用体制と教育計画を導入前に決めておくことが、定着化の実質である。

5つの失敗は連鎖する

ここまで5つを個別に見てきたが、実際にはこれらは独立した事象ではない。

ありたい姿がない（①）と、要件が書けない（②）。要件がないと、PoCの評価基準も作れない（③）。評価基準がなければ、どのベンダーがどこまで責任を持つかも定義できない（④）。そして目標値がないので、定着化の到達点も設定できない（⑤）。

つまり①の欠落が、②〜⑤すべての原因になっている。逆に言えば、上流の一工程を丁寧にやるだけで、下流の失敗確率が大きく下がるということでもある。導入プロジェクトの費用対効果を最も高めるのは、追加の設備投資ではなく、最初の構想策定に時間をかけることである。

導入7工程と、誰が担うのか

ロボット導入は次の7工程に分解できる。

加えて、01〜07の全体を貫くプロジェクトマネジメントが必要になる。

ここで重要なのは、SIer・メーカーが担うのは工程04〜05だけだという事実である。工程01〜03（事前検討）と工程06〜07（定着・運用）は、彼らの契約範囲の外にある。この前後を誰が担うかを決めていないプロジェクトが、最も高い確率で失敗する。

多くの企業がここで詰まる理由も明快だ。この役割を担える人材が社内にいない。ロボットの知識と業務の知識の両方を持ち、複数ベンダーを束ねた経験がある人材は、そもそも市場に少ない。だから外部の力を借りるという選択肢が現実的になる。ただしその外部が特定メーカーの系列であれば、選定の中立性は期待できない。

自己診断——いま、どこにいるか

自社のプロジェクトが健全かどうかは、次の問いで確認できる。5問中3問以上に即答できなければ、上流に戻ることを勧める。

1. このロボットを入れて、何がどれだけ変わっていれば成功か。数字で言えるか。
2. その数字は、誰がいつ測るのか。測定方法は決まっているか。
3. 候補機種を比較した軸は何か。カタログスペック以外の軸はあるか。
4. 統合部分（既存システム連携・周辺設備）の責任者は、契約上どの会社か。
5. 導入3か月後、現場でトラブルが起きたとき、誰が一次対応するのか。

これらに答えられない状態で発注に進むと、後から取り返すコストは着手時の数倍になる。逆に言えば、着手前の数週間をここに使うことが、最も投資対効果の高い工程である。

まとめ——順番を戻すだけでいい

ロボット導入の失敗は、技術の問題ではない。順番の問題である。

カタログから始めるのではなく、ありたい姿から始める。機種を選んでから要件を書くのではなく、要件を書いてから機種を選ぶ。PoCを「動くかどうか」ではなく「投資判断に足るか」で設計する。契約前に責任分界を決める。導入前に運用体制を決める。

どれも特別なことではない。しかし、切迫した状況で検討が始まるロボット導入では、この順番が崩れやすい。だからこそ、順番を守ること自体を役割として引き受ける存在——中立のコーディネーター——が要る。

RobiZyは、ロボットを売らないNPO法人です。だからこそ、機種にも会社にも中立の立場で、発注者側に立った判断ができます。構想段階でのご相談を歓迎します。