FOUNDATION 01 / WORK INVENTORY

AI化の前に、仕事を「判断単位」まで分解する

AI導入が止まる最大の理由は、ツール選びではなく、対象業務が大きすぎることです。「営業を自動化する」では設計できません。「問い合わせ文を読み、業種と課題を分類し、返信案を作る」のように、入力・判断・出力が見える単位へ分けます。

最初の1週間は観察に使う

新しいツールを入れる前に、担当者が実際に行った仕事を5営業日だけ記録します。会議名や部署名ではなく、開始のきっかけ、受け取った情報、行った判断、作ったもの、完了条件を一行で残します。たとえば「問い合わせ対応」ではなく、「フォーム通知を受ける／本文から依頼種別を分類する／回答テンプレートを選ぶ／不足情報を尋ねる下書きを作る／担当者が送信可否を決める」です。

記録時間は一件30秒以内に抑えます。精密な工数調査を目指すと続きません。目的は、反復している判断と、人が責任を持つべき判断の境目を見つけることです。顧客名、メール本文、契約情報などの個人情報や秘密情報は棚卸し表へ転記せず、データ種類だけを記録します。

4軸で点数をつける

候補業務は、頻度、所要時間、定型性、失敗時リスクの4軸で評価します。頻度と所要時間が大きく、手順が比較的安定し、失敗しても公開・送信前に人が戻せる仕事が最初の候補です。高頻度でも、価格決定、契約締結、返金、採用合否、医療・法務判断のような責任の重い仕事は、自動実行ではなく情報整理と草案作成に限定します。

優先度は単純な合計では決めません。頻度・時間・定型性が高く、リスクが低いものを上位に置きます。効果が大きくてもリスクが高い場合は、「自動化」ではなく「人の判断材料を30秒で揃える」設計へ変えます。

入力・処理・出力・承認を一枚にする

選んだ業務には、入力元、処理手順、出力形式、承認者、例外時の停止条件を定義します。入力元が複数あるなら最初は一つに限定します。出力は自由文だけでなく、必須項目と状態を決めます。承認者には「全件を見る」のではなく、どの条件なら自動で進め、どの条件なら止めるかを渡します。

例として記事制作なら、入力はSearch Consoleの実クエリと診断結果の匿名集計、処理は意図分類と構成案作成、出力は根拠リンク付きの下書き、承認は公開枠とテーマの事前承認、停止条件は一次情報不足・医療や金融など高リスク表現・既存記事との重複です。これで「AIに記事を書かせる」という曖昧な依頼が、検証可能な工程になります。

最初の対象は一つに絞る

同時に複数業務を自動化すると、品質低下の原因がモデル、入力、手順、承認、計測のどこにあるか分からなくなります。最初の2週間は一つだけ動かし、処理時間、差し戻し率、重大エラー、担当者の確認時間を測ります。基準を満たしてから次へ進みます。

完了条件は「動いた」では足りません。入力不足なら安全に停止する、同じ依頼を二重処理しない、外部送信前に承認を確認する、失敗が3回続いたら人へ通知する、成果物と根拠を後から追える、という運用条件まで含めます。

棚卸しで除外する仕事

• 目的や正解が関係者間で合意されていない仕事
• 個人の暗黙知だけで判断し、基準を説明できない仕事
• 入力データの取得権限や利用目的が確認できない仕事
• 一度の誤操作が契約、課金、公開、削除につながる仕事
• 月に一度も起きず、手作業でも数分で終わる仕事

除外は失敗ではありません。自動化しない判断も、会社の時間とリスクを守る成果です。対象外にした理由と再評価条件を残せば、業務量や制度が変わった時に再検討できます。

翌週に残す成果物

一週間の終わりに必要なのは、候補一覧、優先する一業務、承認境界、測定指標、停止条件の五つです。巨大なDX計画書は要りません。経営者が15分で読み、進める・変更する・止めるを判断できる量にします。この小さな設計書が、AI社員を増やす前の共通OSになります。