3ヶ月前に描いたワークフローが、誰も見ないダイアグラムになった理由
先日、ある製造業の会議室に座っていたとき、ホワイトボードの片隅にマーカーの跡がうっすらと残っていました。「あれは自動化パイロットを始めたときに描いたプロセス図なんです」という説明が続き、その次の一言が長く心に残りました。「でも、担当者が変わってから、うちのチームでは誰も見ていません。」
前回の第6回では、LLMを組み合わせた自動化のセキュリティ・ガバナンスを扱いました。今日は一歩引きます。そもそもガバナンスを載せる場所自体が消えてしまうプロジェクト — 自動化導入が崩れる5つのパターンを整理してみます。
マッキンゼー・アーンスト&ヤング・ガートナーの複数の調査で、第1世代RPAプロジェクトの失敗率は30〜50%と報告されています。ガートナーは最近、2027年末までにエージェンティックAIプロジェクトの40%以上が中止されると予測しました。原因のほとんどは技術ではありません。以下の5つのうち1つ、あるいは2〜3つが重なっているケースがほとんどです。
パターン1. ツールを先に買い、プロセスは後で整理する
最もよく見られるパターンです。経営層の席で「隣の会社がUiPathを導入したらしい」「最近はn8nが主流だそうだ」といった話が出て、すぐにライセンスの見積もりから取り始める流れです。肝心の「どの業務を自動化するか」は、見積書を受け取った後に決まります。
現場で観測されるシグナルはいくつかあります。キックオフの場で「とりあえずツールを入れてから、何を自動化するか見てみましょう」という言葉が出るとき。ベンダーデモを見た役員がその場で「これいいね、導入しよう」と決めてしまうとき。対象業務が文書として整理されたことがないのに、導入スケジュールだけ先に確定しているとき。マッキンゼーの最近の資料によれば、プロセス自体が整っていない状態で自動化を載せた事例は、73%が目標未達で終わっています。
回避チェックリストはシンプルです。第一に、自動化候補プロセスを最低3つ以上、紙の上に地図として描きます。第二に、各プロセスの月次反復回数と所要時間を実測します — 担当者の勘ではなく実際の数字で。第三に、この2つの資料が揃うまでツールの見積もりを取りません。
パターン2. 決定は上から、使用は下から — なのに現場は会議に呼ばれていなかった
2番目のパターンはもう少し密やかです。パイロットの決定、ベンダーミーティング、予算承認まですべて部門長・役員のレベルで完結し、実際に毎日その自動化を使うチームは、導入完了時点になってようやく通達を受けるケースです。
この数年の間に実際に耳にした言葉を書き留めておきます。「うちのチームはあれ、使いません。うちには自分たちのやり方があります。」「使えと言われたので使ってはいますが、隣にExcelをもう1つ開いて二重入力しています。」ツールが悪いのではなく、そのツールが自分たちの手に馴染むよう調整される機会を逃したのです。日本の調査機関Gronの2026年DX失敗調査でも、失敗原因の上位に「現場未使用41%」が挙がっており、韓国の中小企業でもほぼそのまま再現されます。
回避チェックリスト。第一に、キックオフの場に必ず、その自動化を実際に毎日使う担当者を最低1人座らせます — 部門長ではなく実務担当者を。第二に、パイロット期間中、週1回、30分でも良いのでユーザビリティレビューのミーティングを入れます。第三に、実務担当者が「これはこう変えないと使い物にならない」と発言した項目を別途記録します。この記録が2回目のイテレーションのバックログになります。
パターン3. 「効率化されたら嬉しいですね」 — 指標なしで始まったプロジェクト
3番目のパターンは、導入から4ヶ月ほど経った頃に浮かび上がります。役員が「で、どれくらい良くなった?」と尋ねたとき、担当者が答えられない状況です。
シグナルは導入初期から出ています。成功基準を尋ねると「業務が楽になることです」といった抽象的な答えが返ってくるケース。自動化前のベースライン所要時間・処理件数を誰も測定していないケース。KPIが10個、15個と広がってしまい、結局誰も見なくなるケース。
回避チェックリストは3つに絞ります。導入前に対象業務のベースライン所要時間と件数を必ず測定します。KPIは3つ以下に絞ります — 例:処理時間の短縮、エラー件数の削減、担当者の週次再作業時間。毎月第1週にKPIレビューを30分ずつカレンダーに固定します。指標は作っておくものではなく、毎月見る場があってこそ生きているのです。
パターン4. 監査・ロールバック・権限のない自動化
4番目のパターンは、事故が起こるまで誰も問題だと感じません。ある日、データが誤って送信されたり、誤ったメールが配信されたり、ボットアカウントが妙なファイルを触り始めたりして初めて、「これ、どうやって元に戻すんだ?」という質問が出てきます。
よく見るシグナル。LLMのプロンプトに顧客名・電話番号・マイナンバーの下4桁がマスキングなしで入っているケース。自動化ボットのアカウントが管理者権限をそのまま持っているケース。実行ログが残らず、事故の後に「昨日何時に何を処理したのか」を再構成できないケース。
前回整理した監査ログ・PIIマスキング・ガードレールの体制がなければ、この4番目のパターンは導入3ヶ月以内に必ず再現されます。詳細な実行項目はLLM結合自動化のセキュリティ・ガバナンス編を再度ご参照ください。ここでは要点だけ整理します。最小権限原則でボットアカウントの権限を狭めます。すべての自動化実行に監査ログを残します — 最低でも実行時刻・トリガー・処理対象・結果コード。そしてロールバック手順を文書にしておきます。「この自動化を今日午後3時に止めなければならない」という指示が下りてきたとき、誰がどのスイッチを押すのか、事前に定義されている必要があります。
パターン5. 作った人が抜けたら、誰も直せない
最後のパターンは、最も静かに近づいてきます。導入初年度はうまく回ります。作った担当者が社内にいて、問題が起きればその人がすぐ手を入れます。問題はその担当者が転職したり、部署を移った後からです。
ある流通企業で目撃した場面です。自動化の導入担当者が転職した後、対象サイトのログイン画面がリニューアルされ、スクリプトが止まりました。残ったチームメンバーの誰も、そのスクリプトを修正できませんでした。結局2ヶ月間、担当者が再び手作業で処理し、そのプロセスは自動化前に戻ってしまいました。IDGのRPA失敗調査でも「社内専門知識の不足」が最大の失敗原因として挙げられている理由です。
回避チェックリスト。導入時点から運用担当者を2人以上指定します — 1人が抜けてももう1人が把握している状態で。自動化対象システムに変更が発生したときに通知を受け取るチャネルを定めます(例:サイトUI変更の検知、APIバージョン変更告知の購読)。そして導入成果物には必ず最低限の運用ドキュメントを含めます — 実行スケジュール、トリガー条件、障害時の連絡先。ドキュメントなしで引き継がれた自動化は、引き継がれていないのと実質同じです。
5つのうちいくつ当てはまるか、今日30分だけ点検してみるだけでも構いません
マッキンゼーが2026年に発表した資料では、デジタルトランスフォーメーション予算のうち、わずか5%程度しかチェンジマネジメント — つまり人とプロセスの側に配分されていないとされています。推奨値は20〜30%です。5つの失敗パターンがほとんど技術ではなく、人・プロセス・ガバナンスの側で発生する理由です。
この5つのパターンのうち3つ以上が重なるプロジェクトは、残念ながら着手前に一度立ち止まって再設計する方が、結果的に安く済みます。当社5years+で診断を依頼されたプロジェクトの中にも、ツール導入の直前にプロセス図を描き直して3ヶ月を節約できたケースがいくつもありました。各項目を30分ずつだけチーム内部で点検してみるだけでも、3ヶ月後の後悔をかなり減らせます。自己点検が難しい、あるいは外部視点が必要な場合は、自動化導入の診断相談までお気軽にお問い合わせください。
次回の第8回では、診断からPoC、運用へとつながる実際の実行プランを段階別に整理します。本シリーズの最終回として、これまで7回の議論を実行順序の上に載せてみる予定です。