エグゼクティブ・サマリー
- 本稼働後のロボットで止まる原因の一つは、故障ではなく「更新」である。 ベンダーのリモート更新、上位システムの改修、OSの自動アップデート、地図の書き換えなど、誰かが良かれと思って入れた変更が、現場の業務を止める。
- 「ソフトウェア」を一括りにせず、層に分けて台帳にする。 制御ソフト・ファームウェア、アプリケーション、上位システムとの連携、AIモデル、地図・ティーチング・パラメータ、OSと周辺機器では、更新の頻度も壊れ方も責任者も違う。
- 更新は重さで3段に分類し、承認の手順を変える。 安全機能や動作に関わる変更、業務の結果が変わる変更、影響が閉じた軽微な変更を同じ手続きで扱うと、重い変更が素通りするか、軽い変更が溜まって放置される。
- 「ベンダーが試験済み」は、自社の現場で試験済みという意味ではない。 自社のワーク・レイアウト・業務量・連携先で確かめる受入試験の項目を、更新ごとに使い回せる形で持っておく。
- 更新は「入れ方」と「戻し方」を一組で決める。 適用の時間帯、1台から全台への段階展開、旧版の保管と切り戻し手順を事前に決め、ベンダー任せの自動更新は契約で止める。
ロボットの導入計画では、本稼働の日が一つのゴールとして描かれる。ところが、本稼働した瞬間のソフトウェアがそのまま何年も使われることはない。メーカーは不具合修正や機能追加の版を出し続け、上位の倉庫管理システムや生産管理システムは自社の都合で改修され、現場は新しい品種や棚の配置に合わせて地図やティーチングを直す。AIを使うロボットであれば、認識モデルの再学習も入る。
問題は、これらの変更が別々の人の判断で、別々のタイミングで入ることである。ベンダーは夜間にリモートで更新をかけ、情報システム部門は月例のOS更新を流し、現場の担当者はパラメータを少しだけ変える。どれも単独では正しい判断だが、組み合わさった結果を誰も確かめていない。翌朝、ロボットが特定の棚の前で止まる、上位システムからの指示を取りこぼす、認識率が下がる、といった症状が出て、原因の切り分けに数日かかる。
本稿は、導入7工程のうち⑥定着化と⑦運用の中で、ソフトウェアの更新を「変更管理」として仕組みにする方法を示す。ただし、仕組みの土台は②要件定義・選定と④システム設計の段階で決まる。更新の権限や検証環境を契約や設計に入れておかなければ、運用に入ってから整えることは難しい。