公式スキル · AI 活用
AI パイロットのための業務フロー調査
顧客やチームの業務を1つ FDE 流に洗い出す。同席観察の質問、時間と困りごとつきのスイムレーン、データ、例外、AI の使いどころ、パイロット案まで。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- チームの業務に同席して、AI が役立つところを探す前
- 「X に AI を使いたい」と言われたのに、X の流れを誰も整理していない
AI に渡すもの
- 業務の開始と終了
- 実際に作業する人2〜3人
- 入力と出力の実物
できあがるもの
スイムレーン表、データと例外、AI の使いどころの表、成功指標1つ、パイロット案をまとめたディスカバリーノート。
手順
- 業務の範囲を決める 開始のきっかけ、終了の状態、関わる人、件数（週あたり何件か）を書く。1回の調査で扱う業務は1つ。途中で2つの仕事に分かれるなら分ける。
- まず同席し、見ながら聞く 実際の作業を30〜60分見る。その場で聞く:「いま何を探していますか」「この欄が空だとどうなりますか」「このやり方はどこで覚えましたか」「うまくいかないときはどうしていますか」。抜け道の作業を書き留める: コピー＆ペースト、手元の Excel、付箋、同僚へのチャット。
- 現状の工程をスイムレーン表にする 1工程1行で、担当、工程、ツール、1件あたりの分数、困りごと（待ち、手戻り、ミス、単調さ）を書く。時系列に並べる。分岐点を書く（「金額が100万円超 → 部長」）。
- 入出力データを並べる 工程ごとに、入ってくる情報（どこから、どの形式で）と出ていく情報を書く。個人情報、機密情報、規制対象のデータに印をつける。
- 例外を集める 10件に1件、100件に1件起きること: 項目の欠け、見慣れない形式、差し戻しやトラブル、急ぎの案件。数えられるなら数える。時間をいちばん食うのはたいてい例外で、単純な自動化を壊すのも例外だ。
- AI の使いどころに印をつける 工程ごとに、AI が下書きや抽出をして人が確認する／AI だけで処理する／人が続ける、のどれかを決める。このスキルの既定ルール: AI だけに任せるのは、結果を確かめやすく、間違えても簡単に戻せる工程に限る。お金、契約条件、人についての判断に関わる工程には、人の承認を残す。
- 成功指標を1つとパイロットを決める 指標は1つ。基準値はフロー図から取る（1件あたりの分数、ミス率、処理日数）。パイロットは、1工程か数工程、2〜4週間、少ない件数、顧客側の担当者の名前、「続行／中止」の判断基準をそろえる。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: fde-workflow-discovery
description: 顧客や社内チームの業務フローを1つ、FDE（Forward Deployed Engineer）流に調べてディスカバリーノートにまとめる。同席観察とヒアリングの質問、担当・ツール・所要時間・困りごとを並べたスイムレーン表、入出力データ、例外、AI が向く工程と向かない工程、成功指標、小さなパイロット案まで出す。顧客や社内チームの業務に同席して AI の使いどころを探す前、または業務フローの洗い出し、業務可視化、現状フロー図、As-Is 整理、同席観察ガイド、AI パイロットの提案を頼まれたときに使う。
---
# FDE 流の業務フロー調査
Forward Deployed Engineer（FDE）は顧客のチームに入り込み、相手の実際のシステムと業務の中でプロダクトを動かす役割。その最初にある調査は、誰にでもできる部分だ。仕事をしている現場を見て、工程を一つずつ所要時間と困りごとつきで書き出し、そのあとで AI の使いどころを決める。自分の仕事を記憶で説明すると、抜け道の作業や例外が抜け落ちる。AI パイロットの成否を分けるのはまさにそこで、作業を横で見ればそれが拾える。
## 使う場面
- 顧客の業務や自チームの業務に、AI ツールやエージェントを提案する前。
- 「X に AI を使いたい」と言われたのに、X の流れを誰も整理していないとき。
- パイロットが止まったあと、見落とした工程を探すとき。
- 多数の業務を一度に点数づけして対象を選ぶ用途には使わない（先に automation-opportunity-scan を使う）。
## 用意するもの
- 業務フローを一文で。始まりと終わりのきっかけつき（「請求書メールの受信から支払い完了まで」）。
- 実際に作業する人2〜3人に会えること。できれば作業中に。
- 入力と出力の実物（帳票、メール、ファイル）。個人情報は消しておく。
- 観察できないときは質問をヒアリングとして行い、フロー図に「[ヒアリングによる。未観察]」と書く。
## 手順
1. **業務の範囲を決める。** 開始のきっかけ、終了の状態、関わる人、件数（週あたり何件か）を書く。1回の調査で扱う業務は1つ。途中で2つの仕事に分かれるなら分ける。
2. **まず同席し、見ながら聞く。** 実際の作業を30〜60分見る。その場で聞く:「いま何を探していますか」「この欄が空だとどうなりますか」「このやり方はどこで覚えましたか」「うまくいかないときはどうしていますか」。抜け道の作業を書き留める: コピー＆ペースト、手元の Excel、付箋、同僚へのチャット。
3. **現状の工程をスイムレーン表にする。** 1工程1行で、担当、工程、ツール、1件あたりの分数、困りごと（待ち、手戻り、ミス、単調さ）を書く。時系列に並べる。分岐点を書く（「金額が100万円超 → 部長」）。
4. **入出力データを並べる。** 工程ごとに、入ってくる情報（どこから、どの形式で）と出ていく情報を書く。個人情報、機密情報、規制対象のデータに印をつける。
5. **例外を集める。** 10件に1件、100件に1件起きること: 項目の欠け、見慣れない形式、差し戻しやトラブル、急ぎの案件。数えられるなら数える。時間をいちばん食うのはたいてい例外で、単純な自動化を壊すのも例外だ。
6. **AI の使いどころに印をつける。** 工程ごとに、AI が下書きや抽出をして人が確認する／AI だけで処理する／人が続ける、のどれかを決める。このスキルの既定ルール: AI だけに任せるのは、結果を確かめやすく、間違えても簡単に戻せる工程に限る。お金、契約条件、人についての判断に関わる工程には、人の承認を残す。
7. **成功指標を1つとパイロットを決める。** 指標は1つ。基準値はフロー図から取る（1件あたりの分数、ミス率、処理日数）。パイロットは、1工程か数工程、2〜4週間、少ない件数、顧客側の担当者の名前、「続行／中止」の判断基準をそろえる。
## 出力の形式
```markdown
# 業務フロー調査 — [業務名]、[チーム／顧客]
**きっかけ → 終了:** [開始] → [終了] · **件数:** [週n件] · **観察:** [誰を、日付] または [ヒアリングによる]
## スイムレーン: 現状
| # | 担当 | 工程 | ツール | 分/件 | 困りごと |
|---|---|---|---|---|---|
| 1 | [役割] | [工程] | [ツール] | [n] | [待ち／手戻り／ミス／なし] |
## 入出力データ
| 工程 | 入力（出どころ、形式） | 出力 | 機密性 |
|---|---|---|---|
## 例外
| 例外 | 頻度 | いまの対応 |
|---|---|---|
## AI の使いどころ
| 工程 | AI の役割 | 人の確認 | 理由 |
|---|---|---|---|
| [#] | 下書き／抽出／単独で処理／なし | [確認する人] | [理由] |
## 成功指標
[指標]: 基準値 [n] → 目標 [n]
## パイロット案
- 範囲: 工程 [#]、[件数]、[週数]
- 担当（顧客側）: [名前]
- 続行の条件: [基準] · 中止の条件: [基準]
## 未解決の質問
- [質問]
```
## 例
**入力:** 「丸和フーズ経理部の買掛金担当、佐藤さんの作業に1時間同席。請求書は PDF でメールに届く（週120件ほど）。メールを開いて PDF を保存するのに30秒ほど。仕入先、金額、発注番号を ERP に手入力する（1件4分ほど）。本人いわく単調で、入力ミスも出る。請求書には仕入先の口座情報が載っている。発注番号がなければ購買担当にメールして（書くのに2分ほど）返事を待つ（8件に1件ほど、待ちは1〜2日）。100万円超は ERP で中村部長の承認が要る。仕入先によってはスキャン画像で送ってきて、読みにくい。」
**出力:**
```markdown
# 業務フロー調査 — 仕入先請求書の入力、丸和フーズ 経理部（買掛金）
**きっかけ → 終了:** 請求書メールの受信 → ERP で請求書を承認 · **件数:** 週120件ほど · **観察:** 佐藤さん、1時間
## スイムレーン: 現状
| # | 担当 | 工程 | ツール | 分/件 | 困りごと |
|---|---|---|---|---|---|
| 1 | 買掛金担当 | メールを開き、PDF を保存 | メール | 0.5 | なし |
| 2 | 買掛金担当 | 仕入先、金額、発注番号を ERP に入力 | ERP | 4 | 単調、入力ミス |
| 3 | 買掛金担当 | 発注番号がなければ購買担当にメールして待つ | メール | 2 ＋ 待ち1〜2日 | 待ち |
| 4 | 部長（中村さん） | 100万円超なら承認 | ERP | [要確認] | 待ち |
## 入出力データ
| 工程 | 入力（出どころ、形式） | 出力 | 機密性 |
|---|---|---|---|
| 2 | PDF またはスキャン画像 | ERP の請求書データ | 仕入先の口座情報: あり |
| 3 | 発注番号のない請求書 | 購買担当へのメール | なし |
## 例外
| 例外 | 頻度 | いまの対応 |
|---|---|---|
| 発注番号の記載なし | 8件に1件ほど | 購買担当にメールし、1〜2日待つ |
| PDF ではなくスキャン画像 | [要確認: 件数] | 読みにくい |
## AI の使いどころ
| 工程 | AI の役割 | 人の確認 | 理由 |
|---|---|---|---|
| 2 | 項目を抽出して確認画面に出す | 佐藤さんが1件ずつ確認 | PDF と見比べやすい。支払いに関わるデータは人が見る |
| 3 | 購買担当へのメールを下書き | 佐藤さんが送る | リスクが低く、入力の手間が減る |
| 4 | なし | 中村部長 | 支出の承認は人が続ける |
## 成功指標
工程2の1件あたりの分数: 基準値4 → 目標1.5未満
## パイロット案
- 範囲: 工程2、きれいな PDF を送ってくる仕入先2社分、3週間
- 担当（顧客側）: 佐藤さん。中村部長にも共有
- 続行の条件: 1件1.5分未満で、ミスがいまより増えない · 中止の条件: ミスが増える
## 未解決の質問
- いまの入力ミスはどこで見つけていて、支払いまで残るものは何件あるか
- ERP はデータの取り込みに対応しているか。それとも手入力しかないか
```
## 送る前のチェック
- [ ] 業務の開始のきっかけ、終了の状態、週あたりの件数がそれぞれ1つずつ書いてある。
- [ ] スイムレーンの各行に担当、ツール、分数（または「[要確認]」）がある。
- [ ] 例外に頻度が書いてある。
- [ ] お金、契約条件、人についての判断に関わる工程には、すべて人の確認が残っている。
- [ ] 成功指標の基準値がフロー図から取ってある。
- [ ] パイロットに顧客側の担当者と、続行／中止の基準が書いてある。
## よくある失敗
- 実際の作業ではなく、マニュアル上の正式な手順を図にする。抜け道の作業こそが本当の業務。
- 業務全体の自動化を提案する。パイロットは、時間のかかり方がいちばんはっきりしていて、確認がいちばん簡単な1工程で行う。
- めったに起きないからと例外を無視する。パイロットが信頼されるかどうかは例外で決まる。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.1 · · Example: the observation notes now give the 30 seconds to open and save each invoice, the 2 minutes to write the buyer email, the clerk's own word on tedium and typos, and the bank details on invoices, so every figure in the swimlane comes from the input; the scanned-image exception says only what the notes say (harder to read).
- v1.0.0 · · First release.
出典
出典は英語のページです。