ある相手から、こう訊かれたことがある。「うちの注文書で、本当に動くんですか」。
もっともな問いだった。診断で効果の見込みは出せる。でも、それは一般論の上での話だ。自分の会社の、あの読みにくいFAXで、本当に項目を抜き出せるのか。そこが確かめられなければ、次の一歩は踏み出せない。当時の私には、その問いに返す手段がなかった。
チェックリストでは、答えになっていなかった
それまでの無料検証は、正直に言えば、チェックリストを配って終わりだった。
「こういう準備をすれば導入できます」という確認項目を、渡す。間違ってはいない。けれど、それは相手のデータを一度も見ていない。読めるかどうかは、結局やってみないと分からない。配ったチェックリストは、安心材料にも、判断材料にもなっていなかった。
自分のデータを、その場で通してもらう
そこで、検証そのものを作り直した。代表的な注文書を、三件から十件、その場でアップロードしてもらう。
PDFでも、画像でも、メールの本文でもいい。何を抜き出したいか、出力の項目だけ選んでもらう。あとはAIがサンプルの出力を作る。利用者は、その結果を見て、合っているか、どこを直すべきかを確認する。一般論のAIではなく、自社のデータでの成立性を、初めてその場で見られるようにした。
数字で、成立するかを見せる
確認が終わると、数字が出る。
十件のうち、修正なしで通ったのが何件か。項目ごとの精度はどれくらいか。例外はどれだけ出たか。一件あたり、確認に何分かかったか。たとえば、十件中八件は修正なし、確認は一件あたり二分、今の十分から八割の短縮。そういう、限定的だが具体的な数字を返す。これなら、導入できるかどうかを、相手が自分で判断できる。
ただし、ここで盛らないことを徹底した。これは限られたサンプルでの参考値であって、実装精度の保証ではない。そう、はっきり書き添える。よく見せたい気持ちはあるが、ここで誇張すれば、あとで信頼を失う。
どこまで自動で、どこから人か
検証は、完全に自動化できると言うためのものではなかった。
むしろ逆で、どこまでが自動で、どこからは人が確認すべきかを、はっきりさせるためにやる。標準的なパターンは、人の確認を残した半自動で十分まわる。取引先ごとに様式が違う分は、ルールを足して詰めていく。重大な読み違いがゼロなら、限られた範囲で運用を始める条件を満たす。最初から無人を狙わず、例外を確認する形から入る。
そう示すと、相手はかえって安心する。AIに丸投げするのではなく、危ないところは人が見る、という前提が見えるからだ。
預かるからには、安全に
人のデータを預かる以上、扱いも設計に含めた。
ファイルの形式や拡張子が、中身と合っているかを確かめる。保存する期間と、自動で消す日を画面に出す。個人情報や機密が含まれる場合の、伏せ方も案内する。アップロードされた資料と結果は、その診断をした本人だけが取り出せる。検証を実体験にするほど、預かるものが増える。そこを軽く見ないようにした。
チェックリストを配っていた頃は、相手に宿題を渡していたようなものだった。今は、その場で一緒に手を動かして、結果を見てもらう。同じ「無料」でも、相手が持ち帰るものがまるで違う。
次の回は、この第3部の山場だ。「売れるか」と「無人で安全に出していいか」は別の話だと気づき、入口に適合判定の仕組みを置いた話を書く。