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