自動化のアイデアを、着手できる依頼範囲へ。

担当者が各問い合わせを読み、顧客情報を確認し、対応先を決めています。今回の自動化案は振り分け先の提案だけです。削減時間はまだ測定しておらず、AIモデルが必要だと決めつけていません。

この架空の例では、個人情報を除いた少量のサンプルと分類案を用意できます。一方、過去の分類が一貫しているか、誰がデータ利用を承認するかは未確認です。開発を発注する前に、その不足を見える形にします。

1. 01問い合わせを読む→
2. 02背景を確認する→
3. 03対応キューを選ぶ→
4. 04担当者を決める

資料名は引き継ぎ構成の例です。ダウンロードは説明用文書であり、ソフトウェアのリポジトリではありません。

以下は次の依頼で合意する確認項目案で、実施済みのテスト結果ではありません。入力と期待動作を業務責任者とそろえます。最終の受入記録では、ビルド、実際の観察、判断を追記します。

診断は用意できる証拠に沿って進めます。以下は作業の段階であり、確約した日程ではありません。パッケージの期間と最終範囲は、入力資料を確認してから合意します。

1. 準備

   実際の作業を一つ持ち寄る

   きっかけ、手順、ツール、責任者を説明します。合意した経路で代表例を共有し、必要に応じて機密情報を除きます。

2. 確認

   判断の流れをたどる

   通常の作業と例外を一つずつ確認します。合意済みのルールと、データ、アクセス、量、利用者の行動に関する仮定を分けます。

3. 定義

   最初の境界を引く

   有用な結果を一つ選び、確認項目、対象外、依存関係を書きます。手作業の改善、決まったルール、AIによる支援を対象の業務に照らして比べます。

4. 判断

   提案を文書で渡す

   業務図、不足する証拠、次の作業をまとめます。開発が妥当なら、成果物、費用、受入条件を別途合意します。

1. 1

   サポートの例を、現在チームが行っている作業に置き換えます。始点と有用な結果を、同僚が観察できる言葉で書き、出力を確認する担当者を決めます。

2. 2

   用意できる証拠と不足する情報を列挙します。処理量、費用、時間は測定するまで未確認のまま残し、仮定を投資効果の根拠に変えないようにします。

3. 3

   通常の例、曖昧な例、失敗する例を選びます。それぞれで人が何を見て何をするかと、初回版が行わない操作を記載します。

4. 4

   事業と技術の責任者に文書を共有します。Markdownには記入例と自社用の空欄を含めています。準備用の資料であり、承認済みの作業契約書ではありません。