エグゼクティブ・サマリー
- PoC(Proof of Concept/実証実験)は、投資判断に必要な情報を得るための手段である。「ロボットが動くこと」の確認ではない。
- 最も多い失敗は、成功基準を決めずに始めることだ。「どの数字が、どの水準を超えたら本番に進むか」を開始前に文書で決める。
- 理想条件でのPoCは「成功」で終わり、本番で破綻する。あえて悪条件——繁忙期の物量、イレギュラーな対象物、人が行き交う状況——を含める。
- 複数機種を比較するなら、同一条件・同一測定方法でなければ比較にならない。各社が用意した条件でのデモを並べても意思決定はできない。
- 評価レポートには「動いた/動かない」ではなく、サイクルタイム・稼働率・例外発生率・人の介在時間・想定運用コストを記載する。
PoCは何のための工程か
PoCの目的を一文で書くなら、こうなる。
本番投資を実行してよいかどうかを判断するために必要な情報を、最小の費用と期間で取得すること。
この定義から、いくつかのことが導かれる。
第一に、PoCの成功とは「情報が取れたこと」であって、「ロボットが動いたこと」ではない。むしろ「この条件では成立しない」と分かったPoCは、数千万円の誤投資を防いだという意味で、大成功である。ところが実務では、動かなかったPoCは「失敗」と扱われ、担当者が責任を問われることがある。この評価構造が、理想条件でのPoCを生む温床になっている。
第二に、情報の取得先が明確でなければならない。何を知りたいのかが決まっていなければ、何を測ればよいかも決まらない。だから成功基準の先決めが要る。
第三に、最小の費用と期間という制約がある。PoCに数か月と数百万円をかけるなら、その分本番導入を前倒ししたほうがよいケースもある。PoCの規模は、判断に必要な情報の量に見合わせる。
失敗するPoCの症状
現場で観測される典型は次の4つである。自社のPoC計画に当てはまるものがないか確認してほしい。
症状①:成功基準が「動くこと」になっている
計画書の成功基準欄に「対象物を正しく搬送できること」とだけ書いてある。これでは、1回でも成功すれば成功になる。99回失敗して1回成功しても、基準上は達成である。
症状②:メーカーが用意した条件で実施している
対象物はメーカーが持参したサンプル、物量は少量、時間帯は日中の空いている時間、立ち会うのはメーカーのエンジニア。この条件で動かないロボットは存在しない。
症状③:測っているのが動作の可否だけ
レポートに書かれているのが「◯◯を実施し、正常に動作することを確認した」という文章だけで、数字がない。サイクルタイムも稼働率も、人がどれだけ介在したかも記録されていない。
症状④:複数機種の条件が揃っていない
A社は月曜の午前に軽量物で、B社は金曜の午後に重量物で実施した。この2つを並べた比較表には意味がない。
PoC設計の5ステップ
ステップ1:判断したいことを1文で書く
まず、このPoCで何を決めるのかを1文で書く。例:
「第2倉庫の出荷ピッキング工程に自律搬送ロボットを導入した場合、繁忙期の物量下でも目標処理能力(120件/時)を維持でき、作業者の歩行距離を40%以上削減できるかを判断する。」
この1文が書けなければ、PoCはまだ設計できていない。
ステップ2:成功基準を数値で先決めする
判断したいことを、合否判定可能な数値に落とす。開始前に、発注者側とベンダー側の双方が署名する形で合意しておくのが望ましい。
| 評価項目 | 合格基準 | 測定方法 |
|---|---|---|
| 処理能力 | 120件/時 以上を4時間連続で維持 | 完了件数のログ |
| 歩行距離削減 | 現状比 40%以上 | 作業者の歩数計測 |
| 稼働率 | 90%以上(停止時間を除く) | 稼働ログ |
| 例外発生率 | 5%以下 | 人が介入した回数/総件数 |
| 人の介在時間 | 1シフトあたり15分以下 | ストップウォッチ実測 |
| 復旧時間 | エラー1件あたり平均3分以内 | 実測 |
数値だけでなく、測定方法まで決めておく。「稼働率90%」は、何を分母に何を分子にするかで大きく変わる。
ステップ3:条件を設計する——あえて悪条件を入れる
PoCの価値は、条件設計で決まる。次を必ず含める。
- 繁忙期のピーク物量:平常時で動いても、ピークで詰まるなら本番では使えない。
- イレギュラーな対象物:荷姿の乱れ、規格外サイズ、汚れ、ラベルの位置ずれ。現場では必ず出る。
- 人が行き交う状況:他の作業者、フォークリフト、台車が同時に動く実際の環境。
- 連続稼働:1時間動くことと、8時間動き続けることは別の話。バッテリー、発熱、精度の劣化が出る。
- 例外からの復旧:わざとエラーを起こし、現場の人が復旧できるかを見る。
「本番で起きる困りごとを、PoCで先に起こす」——これがPoC設計の勘所である。
ステップ4:測定体制をつくる
測る人を決める。ベンダーに測定を任せない。発注者側が自分で測るか、少なくとも立ち会って記録する。
記録するのは数値だけでなく、次も含める。
- 発生したトラブルの内容と、その都度の対処
- 現場作業者の所感(使いやすさ、不安、抵抗感)
- 想定していなかった副作用(他工程への影響、動線の干渉)
現場作業者の所感は、定着化の予測材料として非常に価値がある。PoCの時点で強い抵抗があるなら、本番導入では運用が回らない可能性が高い。
ステップ5:複数機種を同一条件で回す
比較が目的なら、条件を揃える。同じ対象物、同じ物量、同じ時間帯、同じ測定方法。実施順による学習効果(現場が慣れて数字が良くなる)を避けるため、可能なら順序を入れ替えるか、その影響を記録に残す。
ベンダーによっては「うちのやり方でやらせてほしい」と言ってくることがある。その要望自体が情報である。標準条件でしか性能が出ない製品であることを示している可能性がある。
PoCの規模と期間
過剰なPoCも問題である。判断に必要な情報が得られる最小規模にとどめる。
| 目的 | 規模の目安 | 期間の目安 |
|---|---|---|
| 技術的成立性の確認 | 1台・限定エリア | 1〜2週間 |
| 処理能力の検証 | 1〜2台・実工程 | 2〜4週間 |
| 運用含めた検証 | 実運用に近い構成 | 1〜3か月 |
| 複数機種の比較 | 各社1台 | 各2週間+比較分析 |
費用については、無償デモで済ませられる範囲と、有償PoCが必要な範囲を切り分ける。有償にすることでベンダー側の本気度が上がるという効果もある。ただし有償PoCでは、実施内容と成果物(データの帰属を含む)を契約で明記しておく。
評価レポートに書くこと
PoC終了後のレポートは、投資判断の資料である。次を含める。
- 判断したいこと(ステップ1の1文)
- 成功基準と実測値の対比表(合否判定つき)
- 発生したトラブルとその原因分析
- 本番導入時に追加で必要となる対応(設備改修、システム連携、運用ルール整備)
- 現場作業者の所感
- 本番導入の概算費用と回収年数の更新
- 結論と推奨:本番に進む/条件を変えて再検証する/見送る
特に4番が重要である。PoCは限定条件で行うため、本番では追加の対応が必要になることが多い。PoCで見えた「本番で必要になること」を洗い出すことが、PoCの主要な成果のひとつである。
「見送る」という結論を出せる体制にしておく
PoCの結論が「見送り」になったとき、それを言える体制かどうかを、開始前に確認しておく。
すでに経営に「導入します」と報告してしまっている、予算を確保してしまっている、ベンダーとの関係上いまさら断れない——こうした状況では、たとえ数字が基準に届かなくても「概ね良好」というレポートが書かれてしまう。
これを避けるには、PoCの位置づけを「判断のための工程」として経営と事前に握っておくことだ。「PoCの結果次第では見送る」ことを、開始前に明文化しておく。この一手間が、数千万円の誤投資を防ぐ。
まとめ
- PoCは投資判断のための情報取得。「動いた」は成果ではない。
- 成功基準と測定方法を、開始前に数値で合意する。
- あえて悪条件を入れる。本番で起きる困りごとを、PoCで先に起こす。
- 測定はベンダーに任せず、発注者側が行う。
- 複数機種は同一条件で。条件を揃えられない比較に意味はない。
- 「見送る」と言える体制を、開始前につくっておく。
RobiZyは中立の立場で、PoCの設計・立ち会い・評価を伴走します。ベンダーが提示したPoC計画の妥当性を第三者の目で点検することからでも構いません。ご相談を歓迎します。