AI業務変革リードとは？導入を現場の成果につなぐ仕事

答えは、任せる範囲から考えず、取り消せない判断を先に人の側に固定し、残りを渡す順番を決める人である。

「何をAIに任せるか」から考えると範囲が決まらず、現場ごとに線が揺れる。逆に「人がやり続ける仕事」を先に書くと、残りが自動的に渡す候補になる。線を引く基準は、取り消せるかどうかである。

当社も自社の運用で、人に残す仕事を先に決め、準備・調査・下書き・集計を渡す順番を取っている。この線を文書にしておくと、現場が「これもAIでいいのか」と迷うたびに責任者へ聞きに行く回数が減る。線を引く仕事は一度で終わるが、線が無いままの導入は毎回の判断を現場に押し付ける。

答えは、一つの作業を速くするのではなく、その前後にある入力・確認・引き継ぎを含めた流れを組み直すことである。

提案書の下書きが速くなっても、商品仕様の照合、価格の承認、提出後の記録が別々のままなら、案件全体の進みは変わらない。変革リードが見るのは作業ではなく流れで、症状から直す場所を特定する。

既製ツールが何をしないかも、変革リードが確認する。たとえばHubSpotの公式ヘルプでは、連携したカレンダーの会議は既に登録済みの連絡先にだけ記録され、未登録の参加者の連絡先は自動作成しないと説明されている。初回商談は相手がまだCRMにいない場面なので、ここは人か自前の連携で埋める。「連携できる」と書いてある機能が、自社で一番件数の多い場面を扱うとは限らない。

答えは、対象を一つの業務に絞り、指示書と確認の仕組みを作り、引き継ぎ先を決めてから次の業務に進むことである。

1. 一つの業務を選ぶ。件数が多く、同じ形で繰り返し、取り消せない約束が少ない業務から始める。
2. 一件たどる。開いた画面、コピーした内容、確認を頼んだ相手まで書き出し、人に残す工程と渡す工程を分ける。
3. 指示書を作る。入力の置き場、完成形の見本、確認する項目を文書にする。用語は範囲まで定義し、無い用語は推測させず人に確認させる。
4. 確認の仕組みを置く。「処理しました」の報告ではなく、保存先の件数と主要項目で完了を判定する。
5. 引き継ぎ先を決める。手で直した箇所を手順に書き戻す担当と、止まったときに戻す先を決めてから次へ進む。

現場が使わなくなる理由も、この順番で消える。使っても確認が自分に戻り、失敗の責任だけが自分に残るなら、使わない方が合理的になる。確認の範囲を誤りの影響の大きさで絞り、書き戻しを作成者一人に負わせず、最初の業務は当人が減ってほしいと言った仕事から選ぶ。変革リードの仕事は、現場に使わせることではなく、使う方が得な状態を作ることである。

答えは、ログイン数や生成回数ではなく、完了までの時間、確認・修正の時間、差し戻しの件数で測り、二巡しても減らない業務は対象から外すことである。

「動いた」と「業務に乗った」は別である。デモで動いた仕組みでも、明日も同じ条件で動くか、誰が権限を持つか、止まったとき誰が戻すかが決まらないなら、業務には乗せない。動いたものを捨てられるかどうかで、変革リードとツール担当は分かれる。 捨てた理由を記録に残すと、次に同じ実験を繰り返さずに済む。

明日からやることは3つで足りる。人に残す仕事を上の表に沿って書き出す。導入済みのAIツールについて、一つの業務を一件たどり、承認待ち・手直し・転記のどこで止まっているかを見る。その一つに指示書と確認の仕組みを置き、引き継ぎ先を決める。判断に使う情報の整理は業務ナレッジ設計者、経営者の隣で事業開発ごと担う役割はForward Deployed Business Builderで扱っている。