なぜ従来の業務棚卸は時間がかかるのか
従来の業務棚卸は、担当者へのヒアリング、資料の読み込み、フロー図への清書、確認と修正——という手作業の往復で成り立っている。ここに時間がかかる理由は三つある。第一に、聞き手が「何を聞けば構造になるか」を分かっていないと、話が発散する。第二に、担当者本人が無意識に行っている判断や例外は、質問されないと言葉にならない。第三に、集めた情報を構造に整理し直す清書工程が重い。結果として、棚卸が終わる前に息切れし、BPRまで進まない。
AIとの一問一答で、業務情報を引き出す
ATBSは、業務情報の収集にAIを使う。あらかじめ「構造として何を集めるか」を設計したうえで、AIが担当者と一問一答を重ねる。「その作業の前に、誰から何を受け取りますか」「例外的に扱うのはどんなケースですか」「迷うのはどこですか」——構造を埋めるための問いを、抜け漏れなく、担当者の負担を抑えながら投げかける。人手のヒアリングでは発散しがちな聞き取りが、構造化を前提とした収集に変わる。
SIPOCとIGOEで構造化する
集めた情報は、SIPOC（受け渡しと境界）とIGOE（判断の根拠と実行基盤）を土台に構造化する。どちらか一方ではなく、両者を組み合わせることで、連携・作業・判断基準・使用する人やシステムまでを一枚の構造として捉える。可視化する要素は次のとおりだ。
依頼元・情報提供者
誰から情報や依頼を受け取るか。受け渡しの起点。
受け取る情報・材料
業務に入ってくる情報や成果物。
作業・判断・分岐・例外
作業手順に加え、判断分岐・例外処理・差戻しまで詳細化する。
成果物・処理結果
何が生成され、次工程へ渡されるか。
提出先・利用者
成果物を誰が受け取るか。依頼元と同じか異なるか。
判断の根拠
規定・基準・参照情報・経験・暗黙知など、判断の拠りどころ。
実行基盤
担当者・組織・システム・設備・ツール。
SIPOCで「連携と責任の受け渡し」を、IGOEで「判断根拠と実行手段」を押さえ、ATBSはこれにProcessの詳細を加えて、AIが参照できる形に構造化する。
「モヤモヤ」から原因を切り分ける
現場の困りごとは、最初は「なんとなくうまくいかない」というモヤモヤの形で語られる。棚卸の役割は、このモヤモヤを構造の上に置き直し、問題（今どうなっているか）と課題（何を変えるべきか）に切り分けることだ。構造化された業務の上でモヤモヤを位置づけると、「どの受け渡しで滞っているのか」「どの判断でばらついているのか」が特定できる。原因が特定できれば、対策は具体になる。
例外処理・差戻し・判断基準を抽出する
業務の質は、平常時の手順よりも、例外時の扱いに現れる。棚卸では、この見えにくい部分を意図的に掘り起こす。
例外処理
標準手順から外れるケースを、いつ・誰が・どう判断して扱うか。
差戻し
どこで、何を理由に差し戻しが起きるか。手戻りの発生源。
判断基準
迷う場面で、何を根拠に判断が分かれるか。属人化しやすい核。
これらを言語化して構造に組み込むことで、属人的な判断が組織で参照できる情報になる。
自動化候補と改善対象を特定する
構造が見えると、次の判断ができるようになる。AIや自動化に任せるべき業務、人が判断すべき業務、そもそも無くす・統合すべき業務の切り分けだ。可視化なしに自動化候補を選ぶと、無駄な業務を高速化してしまう。構造の上で判断するからこそ、投資対効果の高い対象に絞れる。
ワークショップと伴走支援の進め方
対象業務の選定と設計
全社一斉ではなく、一つのチーム・一種類の意思決定から始める。何を構造として集めるかを設計する。
AI一問一答による情報収集
担当者の負担を抑えながら、構造を埋めるための情報を収集する。
ワークショップで構造化・合意
集めた情報をSIPOC／IGOEに整理し、現場と一緒に構造を確認・合意する。
切り分けと次アクション
自動化候補・改善対象・判断ポイントを特定し、プロセス再設計や内製化へつなぐ。
構造化が、誠実構造のAI照合を支える
業務棚卸で判断基準（Guide）と判断分岐・例外（Process）が構造化されると、それはそのまま「どこで判断が起きるか」の地図になる。誠実構造では、この地図の上で判断の前提・根拠・修正トリガーを記録し、AIが現場の動きを経営の前提と照合する。可視化があるほど、AIの照合は点から線・面へと広がり、記録の空洞化も防げる。
誠実構造とは何か →