人とロボットの役割分担設計（ToBe業務設計）

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

• ロボット導入とは機械を置くことではなく、人の仕事の境界を引き直すことである。境界を決めずに機械だけ決めると、現場は「ロボットの世話をする係」を新設することになる。
• 役割分担は動作単位では設計できない。「誰がどの判断を持つか」まで分解して初めて割り当てが決まる。ピッキングという作業名の中には、掴む動作と「これは不良か」という判断が混在している。
• 分担は二択ではない。ロボット単独／人単独／協働／保留（当面は人のまま）の4象限に割り当て、保留を明示的に残すことが、投資を膨らませない最大のコツである。
• プロジェクトが崩れるのは定常業務ではなく境界業務——例外処理・段取り替え・異常停止からの復旧である。ここを誰がやるかを決めていない要件定義書は、必ず追加費用を生む。
• ToBe業務設計の成果物は絵ではない。業務フロー図・役割分担表・例外処理一覧・要員計画の4点セットであり、これがそろって初めて要件定義書に落とせる。

ロボット導入の相談を受けて現場に入ると、驚くほど高い頻度で同じ状態に出会う。機種は絞り込まれ、レイアウト案も描かれ、投資額の概算も出ている。しかし「導入後、この工程で人は何をしているのか」を尋ねると、答えが返ってこない。「補助的な作業を」「監視を」といった曖昧な言葉で埋められている。

これは担当者の怠慢ではない。設備投資の検討プロセスが、機械の仕様を決めることに最適化されているからである。仕様は測れるが、人の役割は測りにくい。結果として、人の仕事の設計だけが最後まで空欄のまま残り、稼働開始後に現場が即興で埋めることになる。即興で埋めた役割は属人化し、その人が異動した瞬間に運用が止まる。

RobiZyはロボットを売らないNPO法人であり、中立のコーディネーターとして導入企業の側に立つ。だからこそ、機種選定より前に「人の仕事をどう変えるのか」を詰めることを勧めている。本稿は、導入7工程のうち③構築スケジュール／ToBe業務設計にあたる役割分担設計を、実際に手を動かせる手順として示すものである。

役割分担設計とは、何を決めることなのか

役割分担設計を「人とロボットのどちらが作業するかを決めること」と理解していると、必ず浅い設計になる。決めるべきものは4つある。

第一に作業の実行主体。物理的に誰が手を動かすか。これは分かりやすいが、全体の一部にすぎない。

第二に判断の帰属。良品か不良か、続行か停止か、通常手順か例外手順か。判断をロボット側に持たせるなら判定基準を数値で定義しなければならず、人側に残すなら人がその判断をするための情報がいつどこに提示されるかを設計しなければならない。判断を宙に浮かせたまま導入すると、現場は「とりあえず止めて呼ぶ」を選ぶ。呼ばれる人が一人しかいなければ、その人が新しいボトルネックになる。

第三に責任の所在。ロボットが起こした品質不良の責任を誰が持つか。稼働率の目標を誰が背負うか。責任者が決まっていない設備は、誰も改善しない。

第四に異常時の権限。ラインを止める権限、手動モードに切り替える権限、リセットして再起動する権限。これらを現場のどの職位まで下ろすかは、稼働率に直結する。権限が上位者にしかなければ、夜勤帯の停止は朝まで復旧しない。

この4つを工程ごとに埋めた表が、役割分担表である。逆に言えば、この4列が埋まっていない資料は役割分担表ではない。

AsIs業務を「判断」の単位まで分解する

割り当ての前に、現状業務を分解する。ここでの原則はひとつ、作業名で止まらないことである。

「検品」は作業名である。この中身を開くと、たとえば次のように分かれる。ワークを取り出す（動作）、外観を見る（知覚）、傷の大きさが許容範囲か決める（判断）、不良なら区分して記録する（動作＋記録）、同種の不良が続いたら上工程へ連絡する（判断＋コミュニケーション）。この5つは、それぞれ自動化の難易度がまったく違う。作業名のまま「検品を自動化する」と言うと、いちばん難しい判断とコミュニケーションが見落とされる。

分解には次のシートを使う。工程ごとに1枚ではなく、1行1要素で通し番号を振る。

判断基準の欄に「経験で」「見れば分かる」と書かれた行は、自動化の可否を決める分岐点である。この判断は、突き詰めれば言語化できるもの（照度と角度を揃えれば数値化できる）と、現時点では言語化しきれないもの（複合要因を総合して決めている）に分かれる。前者は自動化候補、後者は当面人に残す候補である。ここを曖昧にしたまま「AIで何とかなる」と処理すると、PoCの設計そのものが成立しなくなる。

分解の粒度をどこまで細かくするかは、悩みどころである。実務的な目安は、「その要素だけを取り出して、誰か別の人に引き継げるか」である。引き継げる最小単位まで割れば十分であり、それ以上細かくすると表が使われなくなる。

割り当ての4象限——保留を残すことが投資を守る

分解した要素を、次の4象限に割り当てる。

多くの検討会で抜け落ちるのが4つ目の保留である。保留を象限として明示しないと、議論は「自動化する／しない」の二択になり、判断が難しい要素はなし崩しに自動化スコープへ入れられる。入れられた要素は要件定義で難易度を上げ、見積を膨らませ、最終的にPoCで躓く。

保留には必ず、再検討のトリガー条件を書く。「生産量が現在の1.5倍になったら」「対象品目の荷姿が統一されたら」「画像判定の教師データが半年分たまったら」。条件つきで先送りすることは、判断の放棄ではなく段階的投資の設計である。

割り当ての優先順位に迷ったら、次の順に見る。①安全リスクが高く人がやりたくない要素、②反復性が高く時間を大量に消費している要素、③熟練依存で属人化している要素のうち判断が数値化できるもの。逆に、頻度が低く例外が多い要素から手をつけると、投資回収は成立しにくい。この考え方はROIの語り方とも直結する。

境界に落ちる仕事——ここで大半のプロジェクトが崩れる

定常業務の分担は、たいてい設計される。崩れるのは境界業務である。境界業務とは、定常フローの外側にありながら、必ず発生する仕事を指す。

例外処理。想定外の対象物が来たとき、ロボットは止まるか、誤った処理をする。止まった後に誰が来て、何を見て、どう判断し、どこに記録するか。この一連が設計されていないと、現場は自己流の回避手順を編み出す。回避手順は記録に残らないため、改善の材料にもならない。

段取り替え。多品種を扱う現場では、切り替え作業そのものが大きな工数になる。ロボット側の設定変更、治具の交換、プログラム切り替え、初品確認。これを誰がやるのかを決めていないと、「オペレーターが呼ばれるまで待つ」時間がそのまま稼働率を削る。段取り替えの担当と所要時間は、導入前に必ず見積もっておく。

異常停止からの復旧。復旧は、原因究明・安全確保・物理的な復旧作業・再起動・初品確認という複数の段階からなる。それぞれに必要な権限と技能が異なるため、「誰が復旧するか」ではなく「どの段階を誰が担うか」で設計する。

日常点検と清掃。地味だが、これを誰の業務時間に組み込むかを決めないと、必ず誰もやらなくなる。稼働率が落ちてから原因を探すと、たいていここに行き着く。

上流下流とのつなぎ。ロボットが速くなった結果、前後の人手工程が詰まることがある。工程単体の最適化が全体のスループットを改善しないのはよくあることで、これは分担設計の失敗ではなく、分担設計の範囲を工程内に閉じたことによる失敗である。

境界業務を洗い出す実務的な方法は、現場のベテランに「この工程で、去年一年間に起きた困ったことを全部挙げてください」と聞くことである。頻度の低い事象ほど、設計時に落ちている。挙がった事象を先の分解シートに追記し、それぞれに主体・判断・責任・権限を割り当てる。この作業をやるかやらないかで、稼働後の混乱量が大きく変わる。失敗パターンの解剖で挙げた典型的な失敗の多くは、この境界の設計漏れに帰着する。

ToBe業務フローの成果物と粒度

役割分担が決まったら、それをToBe業務フローとして文書化する。成果物は4点である。

①業務フロー図。スイムレーンで人・ロボット・上位システムを分ける。分岐は正常系と例外系を必ず両方描く。正常系だけの美しいフロー図は、設計書としては半分の価値しかない。

②役割分担表。分解シートの要素番号ごとに、実行主体・判断の帰属・責任者・異常時権限の4列を埋めた表。これが本体である。

③例外処理一覧。想定される異常事象ごとに、検知方法・一次対応者・対応手順・エスカレーション先・記録先を並べた表。稼働後はこれがそのまま運用マニュアルの骨格になる。

④要員計画。工程ごとの必要人数を、導入前・立ち上げ期・定常期の3時点で書く。立ち上げ期は定常期より人が要ることをここで明示しておかないと、「自動化したのに人が減らない」という誤解を経営層に与える。

粒度は、「この4点を渡された別の担当者が、運用ルールを起草できるか」を基準にする。フロー図の矢印の数を増やすことに時間を使うより、例外処理一覧の行を増やすほうが、実務では効く。

人側の再設計——空いた時間を何にするか

役割分担設計のもう半分は、人の仕事の再設計である。ここを設計しないと、導入は「省人化」としてしか語れなくなり、現場の協力は得られない。

まず、削減される作業時間を工程別・職位別に集計する。次に、その時間を何に振り向けるかを決める。選択肢は概ね次のいずれかになる。

• 増産に充てる——需要があるなら最も分かりやすい。売上増として効果を語れる
• これまで手が回らなかった業務に充てる——品質改善、予防保全、標準化、教育
• 多能工化に充てる——他工程を担当できる人を増やし、繁閑差を吸収する
• 要員の自然減を吸収する——採用が困難な現場では、これが最も現実的な回答になる
• 残業・休日出勤の削減に充てる——労務費として金額換算しやすい

どれを選ぶかで、KPIも要員計画も変わる。「余った時間の使い道」が空欄のままでは、効果は測定できない。

同時に、新しく生まれる仕事を明示する。ロボットの日常点検、消耗品の交換、稼働データの確認、簡単なティーチング修正、異常時の一次対応。これらは誰かの業務時間を消費する。新設される役割には名前をつけ、担当者を決め、必要な教育を計画する。教育を「メーカーの操作説明会を受ければよい」で済ませている計画は、たいてい足りない。操作の説明と、異常時に自分で判断できる状態とは別物である。

評価制度との接続も忘れてはならない。従来「速く正確に作業する」ことで評価されていた人が、ロボットの監視役に回ったとき、その人は何で評価されるのか。ここが不明確だと、優秀な人ほど新体制に非協力的になる。詳しくは定着化・運用設計で扱っているが、役割分担設計の段階で人事側を巻き込んでおくことが望ましい。

三者レビューで合意を固める

ToBe業務設計は、設計した瞬間には合意されていない。現場・管理・経営の三者でレビューし、それぞれ異なる観点で潰す。

レビューの進め方として有効なのは、異常時のシナリオを声に出して通すことである。「金曜の夜勤帯に、ロボットが異物を検知して停止しました。ここから誰が何をしますか」と問い、フロー図の上を全員で辿る。詰まった箇所が設計の穴である。定常フローを眺めているだけでは、この穴はまず見つからない。

指摘は必ず分解シートの行番号に紐づけて記録する。「現場から反対意見が出た」ではなく「要素番号17の判断帰属に反対」と記録できれば、それは設計への入力になる。現場の抵抗は、多くの場合わがままではなく、設計側が知らない制約の指摘である。

よくある落とし穴

作業名のまま割り当てる。「梱包はロボット」と決めたつもりが、緩衝材の量の判断が誰にも割り当てられていない。分解を飛ばした設計は必ずここで詰まる。

協働を「なんとなく一緒に働く」で済ませる。協働とは、受け渡し点・タイミング・待ち時間・安全方策を定義することである。定義がなければ、それはただの同居である。

例外を「そのときに考える」で送る。稼働後に考える羽目になり、考える人は現場の当直者になる。

人が減る前提で計画を組む。立ち上げ期は人が増える。この前提を経営に説明していないと、立ち上げの谷で計画そのものが疑われる。

現場に最後に見せる。設計が固まってからのレビューは、修正コストが高すぎて指摘を受け入れられない。分解の段階から現場を入れる。

教育を後回しにする。稼働日に操作できる人が一人しかいない状態で立ち上げると、その一人が休んだ日にラインが止まる。

役割分担表を納品後に更新しない。運用は必ず変わる。更新されない表は、半年で現実と乖離して誰も見なくなる。四半期ごとの見直しを運用ルールに書き込んでおく。

まとめ

役割分担設計は、ロボット導入プロジェクトの中でいちばん地味で、いちばん飛ばされやすく、いちばん結果を左右する工程である。要点を繰り返す。作業名で止めず判断まで分解すること。ロボット単独／協働／人単独／保留の4象限に割り当て、保留にはトリガー条件を書くこと。境界業務——例外・段取り替え・復旧・点検・前後工程——を明示的に設計すること。成果物は業務フロー図・役割分担表・例外処理一覧・要員計画の4点であり、これを構想策定と要件定義の間に置くこと。そして、空いた人の時間の使い道と、新しく生まれる仕事を、同じ精度で設計すること。

この設計は、機械のことだけを知っていてもできないし、現場のことだけを知っていてもできない。両方を突き合わせ、利害の異なる関係者の合意を取りつける作業である。

RobiZyはロボットを売らない中立のコーディネーターとして、導入企業の側に立ってこの突き合わせを支援している。特定のメーカーやSIerの都合ではなく、貴社の業務にとって最適な境界線を一緒に引く立場である。「自動化したいが、人の仕事をどう変えればいいか分からない」「現場から反対が出ていて前に進まない」——そうした構想段階のご相談を歓迎する。図面も機種も決まっていない段階こそ、いちばん打ち手が多い。まずは現状の工程を一緒に眺めるところから始めていただきたい。