AIによる業務整理をサービスとして売る方法｜改善対象の絞り方

AIによる業務整理をサービスにするなら、最初は「会社全体を効率化する」より、一つの業務でどこに迷い、待ち、重複があるかを整理する仕事として設計します。納品物は業務の流れ、課題、改善候補、試す手順などです。AIの導入を先に決めず、現行業務を把握してから使う場所を選びます。

業務整理と自動化の開発は別の仕事

業務整理は、誰が何を受け取り、どんな判断をして次へ渡すかを可視化する工程です。自動化の開発は、決まった処理を実行する仕組みを作る工程です。前者を担えるからといって、後者も実装、保守できるとは限りません。受託内容には、現状整理、改善案、実装、運用確認のどこまでを含むかを書きます。

顧客が「AIで全部自動化したい」と言っていても、まず仕事の目的を聞きます。二重入力をなくしたい、承認待ちを減らしたい、引継ぎを容易にしたいなど、改善したい結果を具体化します。承認者がいないことや資料の置き場所が不明なことは、文章生成だけでは解決できません。AIを使わず担当や手順を揃える方が適切な場合もあります。

顧客の要望をそのまま機能へ置き換えない聞き取りは困っている仕事を聞く方法で扱います。この支援では、聞き取った情報を工程と責任に分け、改善対象を決められる状態にすることが有料の提供物になります。

仮定例：見積依頼の受付を整理する

仮定として、制作会社で見積依頼の情報がメール、口頭、共有資料へ分散しているとします。担当者はAIによる見積書生成を希望していますが、現状を確認すると、作業範囲が揃っておらず、営業と制作が何度も確認し合っていることが分かりました。この場合、最初の改善は見積文の生成より、受付で確認する項目と情報を置く場所の統一かもしれません。

支援者は、依頼を受ける、情報不足を確認する、制作へ渡す、見積条件を決める、顧客へ返す、という流れを記録します。各段階で、入力、担当、判断、成果物、次に渡す相手を揃えます。実際の案件を見られない場合は担当者の説明を記録し、事実として確認できたことと推測を分けて顧客へ返します。

AIを使う候補は、受付文から必要項目を整理する、抜けを探す、見積条件の下書きを作るなどです。費用や納期の最終判断は会社の担当者へ残します。AIの下書きが完成したから見積りも完成したと扱わない設計です。資料制作の受託範囲は内容確認と見た目の分担へ分けられます。

現状を見る順番を決める

1. 一件の仕事を、受け付けから完了まで追う。
2. 担当者が使う情報と成果物を確認する。
3. 待ち時間と実際の作業時間を分ける。
4. 例外的な案件と通常の案件を区別する。
5. 困りごとの原因と改善候補を顧客に確認する。

担当者が説明する標準手順と、実際の手順が違う場合があります。書類上は一度の承認でも、現場では事前相談が必要かもしれません。公式手順だけをAIへ入力して改善案を出すと、その相談を無駄として消してしまうことがあります。なぜ行っているのかを聞き、業務を維持するための判断まで一緒に省かないようにします。

一方、全案件を細かく見ると調査範囲が膨らみます。どの期間、どの担当、どの種類の案件を見るかを決めてください。例外を一件見つけたから標準手順全部を変えるのではなく、どの頻度で発生し、どの影響があるかを確認します。調査の終了条件は、課題候補が揃い、顧客が事実を確認できたところなど具体的に設定します。

課題はAIが作った一般論と分ける

AIに業務の流れを渡すと「情報共有」「標準化」「効率化」などの案が出ることがあります。その言葉だけでは顧客が何を変えるか判断できません。実際にどの入力を共通にするのか、どの担当が確認するのか、何をしなくてよいのかまで書きます。現場で発生していない課題を、一般的によくあるという理由で提案へ加えないことも大切です。

納品するのは、実行できる判断資料

資料には現行の流れ、確認した課題、改善候補、未確認事項、試行対象をまとめます。提案を一つに決める場合も、選んだ理由と他案を見送った理由を残します。顧客が社内で説明する際に、AIが推奨したからという理由だけにならないようにします。確認に使った資料は、顧客が後から辿れる形にしておきます。

改善案の作成までが契約なら、その後の実装や担当者教育は別の仕事です。顧客が当然含まれると考えないよう、納品後に誰が動くかを示します。外注範囲を決める考え方は依頼する工程と残す判断、役割の情報不足を防ぐ考え方は発注前に揃える条件へ渡せます。

改善の評価に、確認と例外処理を含める

試行では作業時間だけでなく、確認漏れ、差戻し、担当者の負担を見ます。AIに入力する時間が短くても、後で全出力を直すなら工程全体は速くなっていないかもしれません。比較する案件の条件を揃え、初回の学習時間と通常運用の時間を分けます。結果が不明な段階で削減効果を約束しないようにします。

実際の仕事を一部変えるため、顧客側の承認と戻す手順が必要です。既存業務への移行負担は置き換える商品の導入負担で深掘りします。業務整理の契約では、担当者が試す案を選び、必要な権限を得るまでに何を支援するかを決めます。

顧客の内部情報を扱う条件

聞き取りに協力する人の時間も見積もります。支援者の作業だけを計算すると、現場が何度も説明や確認をする負担が見えません。最初に必要な面談、資料提供、現状図の確認、改善案の合意の回数を示し、顧客が用意できるか確かめます。協力時間が取れないなら、対象を広くするより一つの処理に絞ります。AIで資料化が速くなっても、実務の確認者が不在なら正しい現状図は作れません。

担当者ごとに説明が違った場合は、平均的な手順を勝手に作らず、違いを記録します。部署や案件条件によって使い分けている可能性があるためです。その違いを統一すべきか、別の手順として残すべきかは顧客の判断になります。支援者ができるのは、違いの条件と影響を整理し、判断材料を示すことです。

納品前には、改善案を実際に担当する人へ読み合わせを依頼します。管理者が理解できても現場の入力や連絡が増える場合、実施後の負担が偏ることがあります。必要な情報がいつ手に入るか、誰が更新できるか、承認までにどれだけ待つかを確かめ、実行できない前提を修正してください。図を整えることより、現場の条件に合うことを優先します。

反対意見も、実行を妨げるものと決めつけず記録します。過去に同じ変更が失敗した理由、繁忙期に例外が増える事情、外部取引先との制約など、改善案へ反映すべき情報が含まれる可能性があります。すぐに解決できない条件があるなら、今回は対象外と明示し、顧客が次の判断をできるように残します。

手順、担当者、取引先、社内の判断などは、公開できない情報を含む場合があります。AIへ入力する範囲、録音や議事録の扱い、資料の保存と削除を顧客と決めてから聞き取りを行います。単に改善のためという理由で、業務に関係する情報を無制限に集めないようにします。管理項目はAIの入力情報と契約の確認で整理できます。

受託側が作った整理図も、顧客の内部情報を含むなら他社向けの見本には使えません。公開用の見本は仮の業務で作り、実案件の成功事例に見せないことが必要です。業務整理に向くのは、対象工程の担当者が協力でき、改善後の判断を引き受ける会社です。何が問題か分からないまま全社の自動化を求める案件は、まず調査範囲を絞る提案から始めます。