PoC成功後、最初に作るもの

PoCで良い結果が出た。現場の反応も悪くない。費用の見込みも立った。ここで、「では全社に展開しよう」と進めたくなります。

この判断が、本番化が失敗する最も多い分岐点です。PoCと本番運用の間には、検証では見えない課題が横たわっています。本記事では、その間に何を挟むべきか、そこで何を作るべきかを整理します。

PoCでは見えないこと

PoCは、限られた期間に、関心のある人が、意識して使う環境で行われます。本番運用はその反対です。何年も続き、関心のない人が、日常業務の流れの中で使います。この違いから、次のような問題が本番運用の側にだけ現れます。

慣れによる確認の省略。 最初の2週間は出力を丁寧に確認していた担当者が、精度が高いと分かると確認しなくなります。そして、確認しなくなった頃に間違いが混ざります。

例外処理の量。 PoCでは対象外にしていた変則的なケースが、日常には一定の割合で存在します。この処理をどうするかが決まっていないと、現場は「AIを使う場合と使わない場合」を判断しながら仕事をすることになり、かえって負担が増えます。

費用の実態。 実際の利用パターンは、想定より偏ります。一部の担当者が大量に使う、特定の時間帯に集中する、といった偏りは、PoCの規模では見えません。

人の入れ替わり。 導入時にいた担当者は、いずれ異動します。新しく入った人が、その機能の意図を理解しないまま使うことになります。

これらは、小さい規模で実際に運用しない限り分かりません。だから、限定した本番運用を挟みます。

限定本番運用の設計

限定本番運用とは、1部署・1業務に絞って、実際の業務として使う期間のことです。PoCと違うのは、その出力が実際の業務に使われる点です。責任が伴うぶん、PoCでは見えなかったことが見えます。

範囲の決め方には原則があります。

対象は一つに絞る。 「営業部の見積書作成」のように、部署と業務を一つずつ指定します。二つ以上に広げると、問題が起きたときに原因の切り分けができません。

期間は業務の周期を一巡できる長さにする。 月次処理が絡むなら最低2か月、繁忙期があるならそれを含めます。短すぎる期間では、定常状態の姿が見えません。

対象部署は、成果の大きさではなく率直さで選ぶ。 最も業務量の多い部署を選びたくなりますが、この段階で必要なのは問題が正確に見えることです。うまくいかないときに「使えません」と言ってくれる部署を選んでください。

終了時の判断基準を先に決める。 何が確認できたら横展開に進むのか、何が起きたら戻すのかを書いておきます。書いていないと、期間が終わっても「もう少し様子を見よう」となります。

この考え方は、MVP開発で扱った「検証したい仮説から逆算する」設計と同じです。違うのは、確かめる対象が「価値があるか」から「運用が回るか」に移っていることです。

この段階で作るべきもの

限定運用に向けて開発する範囲は、思っているより小さくて構いません。優先すべきは機能の充実ではなく、次の三つです。

止められる仕組み。 何か問題が起きたとき、従来のやり方に戻せる手順を用意します。技術的には、機能を無効にする切り替えを一つ入れるだけのことが多いのですが、これがないと問題発生時に業務ごと止まります。あわせて、戻したときに誰が何をするかを、紙一枚の手順書にしておいてください。

人が確認する工程。 AIの出力をそのまま使うのではなく、担当者が確認して確定する工程を挟みます。この確認を「面倒だから省く」方向に設計してはいけません。むしろ、確認しやすい見せ方を作るほうに労力を使います。どこをAIが判断したのかが分かる表示、元データとの並列表示などが有効です。

記録の仕組み。 何件処理したか、確認で何件修正されたか、誰がどれくらい使ったか、費用はいくらかかったか。これらを自動で記録します。この数字が、横展開の判断材料になります。記録がないと、期間終了時に「感覚としては良かった」という話しかできません。指標の選び方はプロダクトのKPI設計とダッシュボードの考え方が参考になります。

逆に、この段階で作らなくてよいものもあります。細かい権限管理、他システムとの完全な連携、管理画面の作り込み。これらは横展開が決まってからで間に合います。

期間中に集めるもの

限定運用の期間中は、数字と同じくらい、現場の言葉を集めます。窓口を一人決めて、気づいたことを気軽に言える状態にしておいてください。

特に注意して拾うのは、次のような発言です。

• 「これ、結局自分でやったほうが速いんですよね」
• 「この場合だけは使わないようにしてます」
• 「前の担当者がこう言ってたので、そうしてます」

一つ目は、業務全体としては負担が増えている可能性を示します。二つ目は、例外処理の存在を示します。三つ目は、運用ルールが伝承になっていることを示し、人が変わったときに崩れる兆候です。

どれも数字には現れません。だから聞きに行く必要があります。

横展開の条件を、期間の前に書く

限定運用が終わったときに、何をもって横展開に進むかを、開始前に書いておきます。たとえば次のような形です。

• 確認工程での修正率が、想定の水準を下回っていること
• 対象業務の担当者が、従来のやり方に戻ることを望んでいないこと
• 例外処理の扱いが手順として定まっていること
• 月額の実績費用が、想定の範囲に収まっていること
• 担当者が入れ替わっても回る手順書があること

このうち二つ目は、数字より重い指標です。使える機能なら、取り上げられることを人は嫌がります。「別にどちらでも」という反応が返ってくる場合は、まだ業務に入り込めていません。

小さく本番に出すことが、速い道になる

PoCの次にいきなり全社展開すると、問題が起きたときの影響が全社に及びます。巻き戻しには、導入より大きな労力がかかります。1部署・1業務の限定運用を挟むことは、遠回りに見えて、結果的に速い道です。

この段階で作るのは機能ではなく、止める仕組みと、確認する工程と、記録する仕組みです。この三つがあれば、問題が起きても業務は止まらず、判断に必要な事実が手元に残ります。

弊社はAI活用開発およびWebシステム開発として、既存のAIサービスを組み込んだ機能の実装をお引き受けしています。限定運用の範囲に絞った実装から、横展開に向けた設計まで、段階を分けてご相談いただけます。オンラインで全国対応しており、ご相談・お見積りは無料です。お問い合わせからご連絡ください。