# 自動化のアイデアを、着手できる依頼範囲へ。 架空のサポート窓口を、最初に検証できる作業に絞った例です。自社の相談内容を整理するために使えます。顧客案件のレポートではありません。 サポート窓口の手作業から、最初に検証する範囲を決めるまでの例です。入力、未確認事項、確認項目、提案を読み、自社の業務に置き換えて使えます。 **業務フロー診断** · SUPPORT-SCOPE / EXAMPLE-01 提案例：PoCを発注する前に、分類基準をそろえます。 ## 01. 現在の作業を整理する 担当者が各問い合わせを読み、顧客情報を確認し、対応先を決めています。今回の自動化案は振り分け先の提案だけです。削減時間はまだ測定しておらず、AIモデルが必要だと決めつけていません。 この架空の例では、個人情報を除いた少量のサンプルと分類案を用意できます。一方、過去の分類が一貫しているか、誰がデータ利用を承認するかは未確認です。開発を発注する前に、その不足を見える形にします。 問い合わせを読む → 背景を確認する → 対応キューを選ぶ → 担当者を決める ## 02. スコープ文書の中身 ### 業務フロー図 01 / 現状 作業の始点と終点、使うツール、各判断の担当者をまとめます。情報不足の問い合わせにも対応責任者が必要なので、例外の経路も記録します。 ### 入力資料の一覧 02 / 使える証拠 入力例、項目、分類の定義、アクセス上の制約を整理します。すでに使える資料と、承認、匿名化、収集が必要な資料を分けます。 ### 具体的な課題 03 / 検証する問い 繰り返す作業と、初回の開発で答える問いを定めます。この例では、分類提案が確認者に役立つかを確かめます。サポート業務全体の自動化は扱いません。 ### 最初の利用経路 04 / 範囲の境界 問い合わせ、分類案、レビュー状態を画面に表示し、人が判断を確定します。自動返信、CRMへの書き込み、本番展開は初回の範囲から外します。 ### 受入条件のたたき台 05 / 合意する確認項目 通常、曖昧、空、対象外の入力と、それぞれの期待動作を定めます。外部サービスの結果がない場合の手動確認も、実装前に決めます。 ### 次の作業への提案 06 / 次の行動 データを整える、単純なルールを試す、PoCの範囲を決めるという選択肢から提案します。理由、担当者、次に必要な証拠を記録します。開発より準備を勧める場合もあります。 ## 03. 最初の確認項目を決める 以下は次の依頼で合意する確認項目案で、実施済みのテスト結果ではありません。入力と期待動作を業務責任者とそろえます。最終の受入記録では、ビルド、実際の観察、判断を追記します。 ### SCOPE-01: 分類が明確な問い合わせ **確認項目案** - **入力:** サポート責任者が迷わず分類できる、承認済みまたは架空のメッセージ。 - **期待する動作:** 元の本文と分類案を表示します。最終判断はレビュー担当者に残します。 - **確認メモ:** 対象とする全分類の例を用意します。デモだけが証拠にならないよう、別の確認用データも確保します。 ### SCOPE-02: 曖昧または情報不足の問い合わせ **ルールを要合意** - **入力:** 2つのキューに当てはまる、または判断材料が足りないメッセージ。 - **期待する動作:** 人の確認が必要な状態を示し、原文を保持します。提案を出さない条件を分類ルールで定めます。 - **確認メモ:** 責任者が分類の重複を整理します。意見の相違を記録し、不確かなラベルを無理に正解データにしません。 ### SCOPE-03: 空または対象外の入力 **境界を要合意** - **入力:** 空の本文、初回の範囲に含まれない言語や添付形式。 - **期待する動作:** 制約を説明し、修正または手動の経路を示します。有効な分類済み問い合わせとして処理しません。 - **確認メモ:** 対応する項目、言語、形式を文書化します。入力形式を追加する場合は範囲の判断が必要です。 ### SCOPE-04: 外部依存先の失敗 **確認項目案** - **入力:** 有効な本文に対し、分類サービスから使える結果が返らない状態。 - **期待する動作:** 本文を保持し、失敗を表示して、合意した再試行または手動確認へ進みます。判断の重複を避けます。 - **確認メモ:** 本番連携前に障害対応の担当者と復旧ルールを決めます。最初はテスト環境で制御した失敗を再現できます。 ## 04. 問いから書面の範囲へ 診断は用意できる証拠に沿って進めます。以下は作業の段階であり、確約した日程ではありません。パッケージの期間と最終範囲は、入力資料を確認してから合意します。 ### 準備: 実際の作業を一つ持ち寄る きっかけ、手順、ツール、責任者を説明します。合意した経路で代表例を共有し、必要に応じて機密情報を除きます。 ### 確認: 判断の流れをたどる 通常の作業と例外を一つずつ確認します。合意済みのルールと、データ、アクセス、量、利用者の行動に関する仮定を分けます。 ### 定義: 最初の境界を引く 有用な結果を一つ選び、確認項目、対象外、依存関係を書きます。手作業の改善、決まったルール、AIによる支援を対象の業務に照らして比べます。 ### 判断: 提案を文書で渡す 業務図、不足する証拠、次の作業をまとめます。開発が妥当なら、成果物、費用、受入条件を別途合意します。 ## 05. 次の作業を選ぶ ### 判断例：先に分類基準をそろえる 入力例は出発点になりますが、分類が重なるままでは結果を判断しにくくなります。この例では、モデルを使うPoCを発注する前に、ラベルを整理して単純な振り分けルールを確かめるよう提案します。削減効果を裏付ける見積もりはまだ出せません。 ### 分類を定義する 判断が分かれる本文を見直し、振り分けルールと手動確認の条件を書きます。現状の基準と次の試作品で同じ定義を使います。 **対応責任者:** サポート責任者 ### 使えるデータと権限を確認する 共有可能な例、その制約、次の環境の承認者を確かめます。アクセス許可があることと、データに代表性があることは別に確認します。 **対応責任者:** データ責任者と発注側 ## 06. 自社の相談内容に変える 1. サポートの例を、現在チームが行っている作業に置き換えます。始点と有用な結果を、同僚が観察できる言葉で書き、出力を確認する担当者を決めます。 2. 用意できる証拠と不足する情報を列挙します。処理量、費用、時間は測定するまで未確認のまま残し、仮定を投資効果の根拠に変えないようにします。 3. 通常の例、曖昧な例、失敗する例を選びます。それぞれで人が何を見て何をするかと、初回版が行わない操作を記載します。 4. 事業と技術の責任者に文書を共有します。Markdownには記入例と自社用の空欄を含めています。準備用の資料であり、承認済みの作業契約書ではありません。 ## よくある質問 ### 先にAIモデルを選ぶ必要がありますか？ ありません。業務、証拠、確認ルールから始めます。より単純なルールで足りる場合や、先にデータ整備が必要な場合もあります。 ### 利用できるAPIがなくても始められますか？ 個人情報を除いたエクスポートや架空の例で、最初の範囲を考えられます。その資料で何を確認でき、どの連携条件が未検証かを明示します。 ### ダウンロードに有料の診断は含まれますか？ 含まれません。例と空欄の相談シートは無料です。有料の診断では、合意した範囲で貴社の実際の業務と資料を確認し、状況に合う次の作業を提案します。 ### 診断後はどう進めますか？ 社内で文書を使う、不足資料を整える、開発を合意するという選択肢があります。パッケージは出発点であり、成果物、対象外、受入、日程を書面で合意します。 ## 自社用の相談シート ### 業務と事業責任者 [ ] ### 現在の開始条件と手順 [ ] ### 用意できる入力とアクセス責任者 [ ] ### 有用な出力 [ ] ### 通常・曖昧・失敗の例 [ ] ### 対象外 [ ] ### 不足する証拠 [ ] ### 判断責任者と確認予定日 [ ] [次の範囲を相談する](https://urbanodx.com/ja/contact/?package=teardown&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)