解説BUSINESS DEVELOPMENT × AI
AIツールを入れても、仕事が減らないのはなぜ？業務に定着させる設計と進め方
速くなったのは出力だけ。前後の工程を分けて設計する。
この記事の概要
AIツールを入れても仕事が減らないのは、速くなったのが「出力を作る」工程だけで、その前後の入力の準備、出力の確認、次の担当者への引き継ぎが手作業のまま残るからである。本記事は、残る3つの工程の見つけ方、AI・システム連携・人の三分担の決め方、一つの業務で試して手直しを手順に書き戻す進め方、定着を測る指標を解説する。
AIツールを入れても仕事が減らないのはなぜか。出力の前後に3つの工程が残るから
答えは、出力の前にある「入力を揃える」、後にある「確かめる」「次へ渡す」の3工程が手作業のまま残るからである。
| 残る工程 | 現場で起きていること | 最初に確認すること |
|---|---|---|
| 入力を揃える | 毎回長い指示を書く。別の表から元データを集めてくる | 入力の置き場と完成形を手順に固定できるか |
| 確かめる | 出力を読み直し、抜けや誤りを直す | 必要な項目と品質が指示に入っているか |
| 次へ渡す | 別のツールへ転記する。例外のたびに誰かに聞く | 確定したデータを連携で運べるか。戻す先があるか |
「入力を揃える」に負担が残る場合、出力の質を上げても仕事は減らない。直すのは指示文ではなく、元データの置き場である。「確かめる」に残る場合は、次の工程に必要な項目から出力の形式を逆算する。「次へ渡す」に残る場合は、転記そのものを人の仕事から外す。
見落とされやすいのは、負担が移動しているだけの状態である。作成者の時間は減ったが、確認する上司の時間が増えている。ここを数えずに「導入した」と報告すると、減っていない理由が誰にも見えない。
どの工程に残っているかは、次の10項目で見当がつく。当てはまる数が多い工程が、最初に直す場所になる。
- 入力を揃える: 前回と同じ説明を毎回指示に書いている／元データを2か所以上から集めている／完成形の見本が手順に無い
- 確かめる: 出力を毎回最後まで読み直している／直す箇所が毎回同じ／確認する人が作る人より時間を使っている
- 次へ渡す: 出力を別のツールに手で貼っている／例外が出ると誰かに聞くまで止まる／「送った」で完了にして保存先を見ていない／作成者が休むと誰も回せない
AIツールが定着しないのは、AI・システム連携・人の分担を決めていないから
答えは、解釈はAI、確定したデータの転送はシステム連携、取り消せない約束は人、と仕事の性質で分けることである。
| 仕事の性質 | 任せる先 | 例 |
|---|---|---|
| 文章や状況の解釈が要る | AI | 商談メモの要点を抜く。問い合わせ文を分類する |
| 確定したデータを決まった場所へ運ぶ | システム連携（ルール） | 確定した期限と担当者をCRMへ反映する |
| 取り消せない約束をする | 人 | 顧客への金額の返答。契約条件の確定。送信 |
AIに向くのは「解釈」で、向かないのは「転送」である。確定した項目の転送を毎回AIに頼むと、同じ入力でも出力が揺れ、確認の工程が増える。転送は決めたルールで再現できる連携に任せ、AIは解釈の工程に絞る。逆に、取り消せない約束は連携にもAIにも渡さない。金額、期日、顧客名、社外へ出す文章は、誤りの影響の大きさで確認範囲を決め、人が確定する。
分担を決めるとき、既製ツールが何をしないかも確認しておく。たとえばHubSpotの公式ヘルプでは、連携したカレンダーの会議は既に登録済みの連絡先にだけ記録され、未登録の参加者の連絡先は自動作成しないと説明されている。初回商談は相手がまだCRMにいない場面なので、ここは人か自前の連携で埋める必要がある。「連携できる」と書いてある機能が、自社で一番件数の多い場面を扱うとは限らない。
この分け方で当社が支援した例を一つ挙げる。イベント運営会社（企業名非公開）のスタートアップ支援プログラムで、応募フォーム3種・472行を突合し、有効応募211件を確定し、CRMを84件更新した。工程を「突合」「品質フィルタ」「差分更新」に分けていたため、集計方法を誤ったときの作り直しは集計だけで済み、1〜1.5時間で戻せた。手作業で同じ成果物を作る場合の想定は17〜23時間、実所要は1〜2時間の概算で、削減率は約90%と推定している。この比較は推定で、対照実験ではない。数字単独では効果量の証明にならず、件数や難しさが違う仕事に同じ削減率を当てはめることもできない。
AIを業務に定着させる進め方。一つの業務で試し、手直しを手順に書き戻す
答えは、対象を広げず一つの業務で回し、人が直した箇所を次の手順に書き戻すことである。
- 一件たどる。今の仕事を一件分、開いた画面、コピーした内容、確認を頼んだ相手まで書き出す。
- 前後を分ける。入力を揃える、確かめる、次へ渡す、の3工程に切り、それぞれの担当を三分担で決める。
- 小さく回す。数十件で試し、準備・実行・確認・修正の時間を分けて記録する。
- 手直しを手順に戻す。人が直した箇所は、次から同じ手直しが出ないように指示や連携の設定に書き戻す。
- 完了を実物で確かめる。「処理しました」という報告ではなく、保存先の件数と主要項目を見て完了とする。
手戻りは消えない。消えるのは、同じ手戻りの二回目である。 書き戻しを省くと、担当者の頭の中にだけ手順が残り、その人が休んだ日に止まる。
現場が使わなくなる理由も、能力ではなくここにある。使っても確認が自分に戻り、失敗の責任だけが自分に残るなら、使わない方が合理的になる。対策は三つで足りる。確認の範囲を誤りの影響の大きさで絞る。書き戻しの作業を作成者一人に負わせない。最初の一業務は、当人が減ってほしいと言った仕事から選ぶ。
AIツールの定着は、完了までの時間と手戻りで測る。減らなければやめる
答えは、「使っているか」ではなく「減ったか」で判断し、二巡しても減らない業務は対象から外すことである。
| 指標 | 確かめること |
|---|---|
| 完了までの時間 | 出力の前後を含めて短くなったか。別の担当者へ負担が移っていないか |
| 差し戻しと漏れの件数 | 必要な品質を保てたか。例外の理由は手順で直せるものか |
| 作成者不在での利用 | 手順だけで回るか |
記録は担当者ではなく手順の側に残す。手順ごとに所要時間と差し戻し理由が残っていれば、担当者が替わっても同じ条件で比べられる。
やめる基準も先に決めておく。同じ業務を二巡させても確認と修正の時間が減らないなら、その業務は対象から外す。減らない理由が「解釈」ではなく「判断」にあるなら、それは人の仕事に戻すのが正しい。やめる基準が無い導入は、減らない仕事を抱えたまま次のツールを探し始める。
明日からやることは3つで足りる。減らしたい仕事を一件たどる。出力の前後の工程を3つに分ける。そのうち一つだけを三分担で置き換え、時間を4つに分けて記録する。CRMの突合と差分更新の具体はCRM一元管理の事例、数字の定義と区分の揃え方は売上と利益のダッシュボードで扱っている。
LET’S MAKE MOVES.
AIツールは増えた。でも、現場の仕事は減っていない。
Scratch Secondは業務の流れと既存ツールを確認し、AIに渡す処理、システム連携、人が判断する工程を分けて設計します。手直しを手順に書き戻す運用と検証まで含め、負担が残る作業を一つ選んで支援します。
AIが定着しない業務を相談する
