AIの試験導入で良い結果が出ても、日々の業務へ自動的に組み込まれるわけではありません。試験環境と本番環境では、対象データ、既存システム、例外処理、承認手順が異なるためです。
以下は特定の事務所で起きた実話ではなく、試験導入から本番運用へ移す際の確認点を、業務の入口・途中・終わりに分けて整理したものです。
課題の起点が、書類を扱う方ご本人にあるか
試験導入の課題設定は、所長の方やIT担当の方が考えた問いから始まることが多いです。一方、実際に書類を処理しているのは現場のスタッフの方で、日々の業務で困っている場面は別のところにあることもあります。
たとえば、所長の方が「議事録の自動生成で月◯時間は削減できそうだ」と考えて試験を立ち上げたとします。現場の方に伺うと、「議事録より、契約書チェックの差し戻し対応に時間を取られている」という声が出てくることがあります。精度の高いモデルを用意しても、現場の方が「困っているのはそこではない」と感じている場面では、日々の業務に組み込まれにくくなります。
課題を立てる前に、対象業務の時間ログを確認し、実際に処理する担当者へ聞き取ります。人数を固定するのではなく、例外処理と承認判断を把握できる範囲まで対象者を含めます。
検証用の環境と、日々の業務システムの間
試験は専用の環境で動きます。日々の業務に組み込む段階では、既存の業務システム・帳票・手順書とつながる必要が出てきます。この間には、セキュリティ・データ品質・例外処理・承認の流れなど、検証段階では見えにくい論点がいくつも出てきます。
ベンダーの方から試験報告書を受け取った時点で、ここから先を誰が進めるのか、という問いが残る場面があります。所内のIT担当の方は実装の知見が十分でないこともあり、ベンダーの方は契約の範囲外で動きにくい、という構図です。日々の業務に組み込むための工数が、どの予算にも乗らないまま、案件が止まってしまうことがあります。
試験契約の段階で、日々の業務への組み込みまで含めた契約形態を選択肢として置いておく、という運用を取っている事務所もあります。試験単発で終わる契約では、その先を進める主体が決まりにくい流れになりやすいです。
成功の見方と、業務で何が変わったかの間
「AI出力の精度98%」 は試験の中で見やすい指標ですが、業務でどう変わったかとは別の話になります。日々の業務に組み込んだあとに、件数や所要時間がどう動いたかを最初に設計しておかないと、「結局、何が良くなったのか」という問いに答えにくくなります。
逆の場面もあります。業務側の指標を決めていても、試験前の現状値を計測していないと、変化があったのかを確認しにくくなります。試験を立ち上げる前の1〜2週間で、対象業務の所要時間・件数・差し戻しの頻度を実測しておく、という事務所もあります。あとから振り返る材料を、業務の流れの中に置いておく工夫です。
「最後まで見届ける方」が決まっているか
試験から日々の業務に組み込むまでの場面では、関わる方の役割が分かれていることが多いです。コンサルの方は提言を出して終わり、ベンダーの方は要件定義どおりのものを納品し、AI提供事業者はモデルを渡し、所内のIT担当の方は本業のかたわらで関わり、現場の方は呼ばれたら答える、という流れです。
「最後まで見届ける方」がどなたなのかが決まっていないまま試験が走り始めると、日々の業務に組み込む場面で、誰が次の手を打つのかが見えにくくなります。
立ち上げの段階で取られやすい選択肢として、次のような形があります。
- 試験単発ではなく、日々の業務への組み込み・運用伴走まで含めた段階的な契約にしておく
- 所内に「日々の業務に組み込むまでを見届ける担当の方」を1名置く (= 所長・IT担当・現場リーダーのいずれか)。兼務でも、試験開始の時点で決めておく
- 業務側の指標と現状値を、試験の成功条件とは別に設計しておく
いずれも特別な技術投資が必要な話ではなく、契約条項と所内合意の話に近いものです。一方で、試験が先に走り始めると、あとから差し込みにくくなる場面もあります。立ち上げの最初の1〜2週間で、関係者の方と合意しておきたい論点です。
日々の業務に乗ることを前提にした試験の組み立て方
試験そのものを、日々の業務に組み込むための検証として組み立て直すなら、立ち上げの場面で握っておきたい論点がいくつかあります。
対象業務を、日々の業務に組み込みやすいものに絞る、という選択肢があります。試験で良い数字が出ても、例外処理が多すぎる・既存システム連携が前提・属人化が強い場面では、組み込みに移りにくくなることがあります。対象業務を選ぶ段階で、「日々の業務に乗る前提で動かせるか」を一度確認しておく事務所もあります。
ベンダーの方との契約に、日々の業務への組み込みの概算を含めておく、という運用も見ます。試験契約と組み込み契約が完全に分かれていると、組み込みの段階で「もう一度RFP・見積もり・稟議」のサイクルを回すことになり、判断までの時間が長くなりがちです。試験完了の時点で組み込みの概算が出ている形にしておくと、その後の段取りが軽くなることがあります。
試験期間中から実際の業務担当者が触り、操作性・例外処理・既存業務との整合を確認します。参加人数は業務の役割分担に合わせ、試験作業を正式な業務時間として確保します。
「試験で終わる」という判断を、最初から選択肢として置いておく、という形もあります。検証の結果、対象業務が向かない・組み込み後の運用が現実的でない、という判断が出ることはあります。その場面で「ここまでで止める」という選択肢を、立ち上げの段階で関係者の方と握っておくと、後の判断がしやすくなる場面があります。
振り返るときの確認点
試験から日々の業務に組み込むまでの場面で、繰り返し詰まる箇所があります。所内の案件が止まっていると感じたときに、振り返る材料として並べておきます。
- 課題設定の起点が、所長の方の見立てだけになっていないか。現場の業務時間のログや、日々の困りごとが、課題定義の材料に入っているか
- 日々の業務に組み込むための予算が、どの予算にも乗っていない状態になっていないか。試験予算と組み込み予算が別年度に分かれていないか。組み込みの見積もりを取れる契約になっているか
- 業務側の指標と、試験前の現状値が言葉になっているか。「精度◯%達成」だけで成功条件を設計していないか
- 「最後まで見届ける方」が、試験開始の時点で決まっているか
試験そのものは検証の道具として有用です。日々の業務に組み込むことを最初から流れの中に置いておくと、「デモは良かったのに、現場には入らなかった」という場面が起きにくくなります。