部署間の受け渡しを聞くとき、何をそろえればよいですか？
仕事の開始と終了、受け渡す物、受取条件をそろえ、渡す側と受ける側の両方に聞きます。
社内AIインタビューを業務改善に使うなら、「何に困っていますか」だけで終えず、部署をまたぐ仕事の受け渡しを聞き取ります。
部署ごとの仕事を並べても、渡した後に誰が何を待つかは見えません。筆者が避けたいのは、各部署の説明は詳しいのに、仕事を渡した後の待ち時間だけが図から消えることです。
先に一つの業務の始まりと終わりを決め、両側の説明を照合します。
聞き取りは実行記録の代わりになりません。業務図の重要な矢印は、資料、システム記録、現場観察で確かめます。
AIの聞き取りで業務図をつくるサービスには、何がありますか？
CompanyMap AIは、AIの聞き取りで部署の業務フローを業務図にするサービスです。
CompanyMap AIは、AIの聞き取りで、部署の業務フローを業務図にするサービスです。
この記事は、受け渡しの聞き取りを業務図へつなぐ考え方を整理しています。
手順1：部署名でなく、仕事の始まりと終わりをどう決めますか？
調べる範囲は部署名で区切らず、仕事が始まる出来事と、最後に得る結果で決めておきます。
受け渡しの記録例では、「受注表を送った」を営業の完了条件として残します。その隣に経理の着手条件「請求先と締め日がそろった」を置きます。二つが一致しなければ、どちらかを消して一本の矢印にしません。不足項目を確かめる工程を残した業務図の設計例として扱います。
「営業部の業務を教えてください」では、見積もり、受注、請求の話が混ざります。
例えば受注から請求までを対象にするなら、開始を「注文の確定」、終了を「請求書の送付」と置きます。これは質問を作るための仮の例で、特定企業の実測ではありません。
業務管理の研究機関APQCは、業務全体の図に、部門間の受け渡し、判断点、役割、入力、出力を含める方法を示しています。関係者が確かめる方法も示しています。業務の分類表と、具体的な流れを描く図も区別しています。分類表だけでは、「どの注文を誰へ渡すか」は書けません（APQCの業務図作成ガイド、業務分類の枠組み）。
筆者は、最初の聞き取りでは一つの流れに対象を絞る方法を勧めます。複数部署をまたぐ骨組みを描く場合も、それぞれの流れの始点と終点を置きます。同じ仕事の重複や、どの部署にも載っていない仕事を確認できます。
手順2：普段の説明に加えて、直近の一件をどう聞きますか？
通常の手順を聞いた後に直近の一件をたどり、受け渡した物と受け取った条件を具体的に確かめます。
質問例は「直近で注文が確定した一件について、最初に受け取ったものから教えてください」です。続けて、一問ずつ尋ねます。
- 「誰に何を渡しましたか」
- 「相手が受け取ったと分かったのはいつですか」
案件名や顧客名を出さず、資料の種類や状態で答えてもらいます。
聞きたいのは、作業内容の長い説明だけではありません。渡す物の完成条件、渡す先、受取確認、差し戻しの条件です。「メールを送った」と「必要な情報がそろって次の作業を始められた」は、別の出来事として記録します。
過去の一件を聞く方法にも限界があります。利用者調査を扱うNN/gは、インタビューが記憶や将来の推測に頼ることを指摘しています。難しかった出来事やうまくいった出来事を、具体的に聞く方法も紹介しています。思い出した一件を、通常の発生率として報告してはいけません（NN/gのインタビュー解説）。
例外を聞くときも、「よく差し戻されますよね」と前提を入れません。「同じ進め方では処理できなかった例はありますか」と聞き、ないという回答も残します。聞き返しの一般的な基準は、AIインタビューの聞き返し設計で扱っています。
手順3：渡す側と受ける側の説明を、なぜすぐに統合しないのですか？
両側の説明が違う受け渡しは未確認として残し、同じ案件や資料を照合してから業務図に反映します。
仮の例として、営業側が「受注表を送れば引き継ぎ完了」と答えたとします。経理側は「請求先と締め日がそろわないと着手できない」と答えました。
AIが「営業から経理へ受注情報を渡す」と要約すると、食い違いが消えます。
この場合、業務図には営業から経理への矢印を引き、渡す物を「受注表」とします。その横に、次の3つを別々に残します。
- 営業側の完了条件
- 経理側の着手条件
- 根拠となる回答箇所
何が不足しているかは、未確認です。同じ期間・同じ種類の案件について、両側へ追加確認します。
説明の違いには、案件による条件差、役割分担、古い手順、記憶違いなど、複数の可能性があります。先に誰かのミスと判定しません。APQCも、図の検証に作業者と上流・下流の関係者を含め、一部門の視点だけに寄らない方法を示しています。
不満や人事評価の調査とは、目的を分けます。少人数の部署では、発言から個人が分かる場合があります。回答原文の閲覧範囲を、先に決めます。取り扱いの説明は、AIインタビューの同意設計を参照してください。
手順4：ログがある工程と聞き取りで補う工程を、どう分けますか？
システムに残る実行順序や時間はログで確認し、記録にない判断や連絡は聞き取りと観察で補います。
Celonisは、基幹業務や顧客管理のシステムにあるデータから、業務を分析する製品を提供しています。MicrosoftのPower Automateも、システムのイベントデータから業務を可視化する仕組みを説明しています（Celonisのプロセスマイニング、Microsoftの公式説明）。
こうした分析で時刻や順序を確認できる部分に、記憶から推測した時間を上書きする必要はありません。
一方、ログに残らない電話の確認や、資料を見て判断した理由は、別の証拠が必要です。筆者は、業務図の各工程に、根拠が「聞き取り」「資料」「ログ」「観察」のどれかを記す方法を勧めます。
英国政府の実務ガイドは、普段の環境、資料、機器を使う様子を観察し、不明な行動を尋ねる方法を示しています。ただし、説明を求めることで普段の行動が変わるとも指摘しています。観察を加えても、すべてが客観的に確定するわけではありません（英国政府の現場観察ガイド）。
手順5：自動化の前に、受取条件をどう確かめますか？
業務図を自動化の指示に使う前に、次の担当者が着手できる条件と、例外時の行き先を確かめます。
前の仮の例なら、「受注表を送る」を自動化しても、請求先と締め日が空欄のままなら、経理は待ち続けます。
受け渡しを自動化する工程の決め方は、AIに任せる業務の決め方（業務図ラボ）で扱っています。
確認するのは、送信作業だけではありません。必要項目がそろった状態と、不足時に誰へ戻すかです。
聞き取りから作った図は、現状の仮説です。法令上の承認、契約上の権限、例外処理を省いてよいという判断は含みません。海外製品の説明も、自社のログが十分にそろっていることや、導入後の効果を保証しません。
受け渡しの聞き取りで、うまくいかない例には何がありますか？
部署名での区切り、普段の説明だけの聞き取り、AIによる統合、記憶の時間の実測扱いが典型です。
- 部署名で範囲を区切る。見積もり、受注、請求の話が混ざります。
- 普段の手順だけを聞く。受け渡した物と、受け取った条件が具体化しません。
- AIに一つの話へまとめさせる。両側の食い違いが消えます。
- 前提を含む質問をする。「よく差し戻されますよね」のように聞くと、答えが誘導されます。
- 記憶から答えた時間を実測として使う。重要な工程は、ログや時間計測で確かめます。
根拠の種類ごとに、何を確認できますか？
聞き取り、資料、ログ、観察で確認できることが異なり、業務図の各工程に根拠を記します。
| 根拠の種類 | 確認できること | 限界 |
|---|---|---|
| 聞き取り | 受け渡す物、受取条件、判断の理由、両側の認識の違い | 記憶や推測に頼る。思い出した一件を通常の発生率として報告しない |
| 資料 | 実物の資料の項目や状態 | 資料を見て判断した理由は、別の証拠が必要 |
| ログ | システムに残る実行順序や時間 | 電話の確認や、資料を見て判断した理由は残らない |
| 観察 | 普段の環境、資料、機器を使う様子 | 説明を求めると普段の行動が変わる場合がある |
表：業務図の根拠の種類と限界（本記事の整理）。
よくある質問
同じ質問だけでは不十分です。仕事の始まりと終わり、受け渡す物、受取条件をそろえ、つながる部署の説明を照合します。回答が多くても、一方の部署しか答えていない受け渡しは未確認です。
すぐには一方を採用しません。同じ案件や期間かを確認し、原文を残したまま資料やログと照合します。案件条件が違えば、一本の流れへ平均せず、条件ごとの分岐として扱います。
記憶から答えた時間は実測ではありません。参考値として出典とともに残し、重要な工程はログや時間計測で確かめます。待ち時間と実作業時間も分けてください。
次の一歩は何から始めればよいですか？
手戻りを減らしたい受け渡しを一つ選び、両側の回答と実物の資料を並べて確かめます。
- 手戻りを減らしたい受け渡しを、一つ選びます。
- 始まりと終わりを決め、渡す側と受ける側の両方に、直近の一件を聞きます。
- 両側の回答と実物の資料を並べ、食い違いを未確認として残します。
根拠資料の一覧
資料確認日：2026年10月1日。本文中の手順例は編集部の提案で、導入効果の実測値ではありません。