エグゼクティブ・サマリー
- ロボットは設置すれば使われるわけではない。現場の手順・判断・責任範囲が変わるということであり、そこを設計しなければ運用は回らない。
- 導入直後には必ず「立ち上げの谷」がある。期待どおりに動かない数週間〜数か月をどう越えるかで、定着するかどうかが決まる。
- 運用設計は導入後に考えるものではない。構想・要件定義の段階で決めておくべき項目が7つある。
- 現場の抵抗は「わがまま」ではなく情報である。抵抗の中身を分解すると、たいてい設計の欠陥を指している。
- 効果測定のKPIは、導入前に測定方法まで決めておく。導入前の実測値がないと、効果は永遠に証明できない。
なぜ導入したロボットが使われなくなるのか
「半年前に導入したロボットが、いまは隅に置かれている」——この状態に至る経路は、驚くほど定型的である。
稼働開始直後、ロボットは想定どおりには動かない。パラメータが現場に合っていない、想定外の対象物でエラーが出る、既存の動線と干渉する。これは正常な現象であり、どんな導入でも起きる。問題はその先だ。
エラーが出たとき、現場の担当者はマニュアルを見る。しかし復旧手順が書かれていない、あるいは書かれていても分かりにくい。ベンダーに連絡すると「明日伺います」と言われる。その間、業務は止められないので、手作業に切り替える。この「切り替え」が一度でも起きると、現場は手作業のほうが確実だと学習する。
数回それが繰り返されると、ロボットは使われなくなる。技術的には解決可能な問題であっても、心理的に元へ戻せなくなる。そして「ロボットは使えない」という結論が社内に定着し、次の投資提案が通らなくなる。
この経路は、運用設計で断ち切れる。
導入前に決めておくべき7項目
運用設計は、稼働後に考えるものではない。要件定義の段階で決め、要件定義書に「運用要件」として記載しておく。
① 誰が起動・停止するか
日々の始業・終業でロボットをどう扱うか。担当者は誰か、その人が休みのときは誰か。単純だが、決めておかないと初日から止まる。
② エラー時の一次対応者と手順
最も重要な項目である。次を決める。
- 一次対応者：現場の誰が最初に対応するか（複数名、シフト全時間帯をカバー）
- 判断基準：どこまで現場で対応し、どこからベンダーを呼ぶか
- 復旧手順書：現場の人が見て動ける粒度で。写真つき、専門用語なし
- 連絡先とレスポンス基準：ベンダーの一次窓口、駆けつけ時間、夜間・休日の扱い
- 業務継続手順：ロボットが止まっている間、業務をどう回すか
「業務継続手順」を決めておくことが、実は定着化の鍵になる。止まっても慌てない状態をつくると、現場はロボットを信頼できる。
③ 日常のメンテナンス
清掃、消耗品交換、点検の頻度と担当。バッテリー式なら充電の運用も。1日あたり何分の作業が発生するかを見積もり、それを誰の業務時間に入れるかまで決める。
④ 教育と引き継ぎ
初期教育を誰が誰に行うか。新任者への引き継ぎ手順。担当者の異動でノウハウが消えることが、定着化の最大の敵である。属人化させないため、手順書と教育プログラムを資産として残す。
⑤ 改善提案の吸い上げルート
現場から出る「ここをこうしたい」を、誰がどう受け取り、どう反映するか。この経路がないと、現場は諦める。月次の振り返りの場を設けるのが実務的である。
⑥ ベンダーとの保守契約
契約内容を具体的に確認する。定期点検の頻度、部品代の扱い、オンサイト対応の条件と時間、リモート監視の有無、ソフトウェア更新の扱い。「保守一式」の見積は、中身を分解してもらう。
⑦ 効果測定の方法
KPI、測定方法、測定頻度、報告先。詳細は後述する。
立ち上げ90日——谷を越える進め方
稼働開始から90日間を、フェーズを分けて設計する。
第1〜2週：伴走期
ベンダーのエンジニアが現場に常駐、または高頻度で訪問する期間を契約に含めておく。この期間に、パラメータ調整と例外パターンの洗い出しを集中的に行う。
この期間の設定を契約に入れていない導入が多い。「据付・調整」の項目に含まれていると思っていたら、実際は初期セットアップまでだった、というケースは頻繁に起きる。契約前に「立ち上げ支援は何日分含まれるか」を明示的に確認する。
第3〜6週：自走準備期
現場の担当者が自分で対応できる範囲を広げる。ベンダーは呼べば来るが、まず現場で対応してみる。この期間に、実際に起きたエラーをもとに復旧手順書を現場の言葉で書き直す。
ベンダーが作った手順書は、たいてい現場では使えない。専門用語が多く、想定している読み手が違う。現場の担当者が自分で書き直したものが、最終的に定着する。
第7〜12週：安定化期
数字を取り始める。稼働率、処理件数、エラー発生率、人の介在時間。この時点の数字が、導入前の想定とどれだけ乖離しているかを把握する。
乖離があるのは正常である。重要なのは、乖離の原因を特定し、埋められるものと埋められないものを切り分けることだ。埋められないものは、運用設計で吸収する（例：例外は人が引き取る前提で工程を組み直す）。
90日レビュー
導入前の想定と実績を突き合わせ、経営に報告する。ここで「想定どおりにいっていない部分」を隠さないことが、次の投資判断のために重要である。
現場の抵抗にどう向き合うか
「現場が使ってくれない」という相談は多い。しかし抵抗の中身を分解すると、たいてい正当な理由がある。
| 表面的な言葉 | 実際に指している問題 |
|---|---|
| 「手でやったほうが早い」 | サイクルタイムが実際に遅い／段取りに時間がかかる |
| 「エラーばかりで使えない」 | 例外率が想定より高い／復旧手順が分からない |
| 「自分の仕事がなくなる」 | 再配置先が示されていない |
| 「操作が難しい」 | 教育が不足／UIが現場向きでない |
| 「壊しそうで怖い」 | 責任範囲が不明確／触ってよい範囲が示されていない |
これらはいずれも、設計または説明の欠陥を指している。抵抗を「意識の問題」として扱うと解決しない。具体的な指摘として受け取り、設計側で対応する。
特に「自分の仕事がなくなる」への対応は、導入前に済ませておくべきものである。省人化した人員をどこへ配置するかを経営が示していなければ、現場が協力する理由がない。ロボット導入を成功させたい企業ほど、再配置先を先に決めて現場に伝えている。
KPIと効果測定
導入前の実測値が命
効果を証明できない導入が非常に多い。理由は単純で、導入前の数字を測っていないからだ。
導入後に「作業時間が減った気がする」と言っても、経営は次の投資を承認しない。構想策定の段階（RX構想策定参照）で現状を実測しておくことが、ここで効いてくる。
測るKPIの例
| 分類 | KPI | 測定方法 |
|---|---|---|
| 効率 | 工程あたり作業時間、歩行距離、処理件数/時 | ログ、実測 |
| 稼働 | 稼働率、停止時間、MTBF（平均故障間隔） | 稼働ログ |
| 品質 | エラー率、手戻り率 | 業務システム |
| 運用負荷 | 人の介在時間/日、復旧回数/週 | 実測、記録 |
| 人員 | 対象工程の投入人時、再配置人数 | 勤怠 |
| コスト | 運用コスト/件、保守費用実績 | 会計 |
このうち運用負荷は最も見落とされ、最も重要である。省人化した時間より、ロボットの世話に費やす時間のほうが長いという事態は実際に起きる。
測定の頻度と報告
立ち上げ期は週次、安定後は月次。報告先は現場責任者と経営の両方。数字を出し続けること自体が、定着化の推進力になる。
運用を誰が担うか
ここまでの内容を、発注者の現場担当者が本業のかたわらで担うのは、現実的には難しい。かといってSIerの契約範囲は通常、導入完了までである。定着化・運用は、契約の隙間に落ちやすい領域だ。
選択肢は3つある。
- 社内に運用担当を置く：最も望ましいが、人材と工数の確保が必要。
- 運用業者に委託する：保守・監視・一次対応を外部化する。費用は発生するが、確実性は高い。
- 導入支援者に立ち上げ期だけ伴走してもらう：90日の谷を越えるまで支援を受け、その後は自走する。
いずれにせよ、導入前に「誰が運用を担うか」を決めておくことが要件である。決めていない状態で稼働開始すると、担当者不在のまま最初のトラブルを迎えることになる。
まとめ
- 稼働開始はゴールではない。運用設計は導入前に決めておく。
- 特にエラー時の一次対応と業務継続手順。止まっても慌てない状態が信頼を生む。
- 立ち上げ90日を3フェーズで設計し、ベンダーの伴走期間を契約に含める。
- 現場の抵抗は設計の欠陥を指している。意識の問題として扱わない。
- 導入前の実測値がなければ、効果は証明できない。構想段階から測る。
- 「誰が運用を担うか」を導入前に決める。契約の隙間に落とさない。
RobiZyは、定着化・運用設計を導入計画の一部として設計し、立ち上げ期の伴走まで支援します。すでに導入済みで「使われていない」状態からの立て直しのご相談も承ります。