業務可視化・図解の進め方完全ガイド――AI導入の合意形成を3枚で変える
AIを導入したい——そう思ったとき、最初にぶつかる壁は技術でも予算でもなく、「うちの業務、どこから手をつければいいのか分からない」という霧です。現場に聞けば「忙しいのはわかるけれど、何が問題かと言われると…」と返ってくる。役員に説明しようとしても「で、何が変わるの?」で終わる。
その霧を晴らすのが、業務可視化の図解です。
図解と聞くと、きれいなフローチャートをツールで作るイメージが先に来がちです。ただ、AI導入の文脈で図解が効く理由はビジュアルの美しさにはなく、「現場が自分の口で滞りを語り出す」という副作用にあります。紙に書いてもらうだけで、それまで口にしなかった「実はここ、毎回詰まってるんです」が出てくる。その声こそが、AI導入の設計を始める一次情報です。
ここでは、業務可視化を進めるためのAs-Is・To-Be・判断ツリーの3種類の図解について、作る順序・問いかけの仕方・AIエージェント実装への繋げ方を順番に整理します。
なぜ「口頭説明」では現場の滞りが見えないのか
業務改善の打ち合わせで「どんな業務が大変ですか?」と聞くと、たいてい「全部大変です」という答えが返ってきます。これは現場が不誠実なのではなく、口頭で業務を整理すること自体が難しいからです。
人は自分がやっていることを、やりながらでないと順序立てて説明できません。「月末の請求書処理はどんな手順ですか?」と聞かれても、頭の中では同時並行で走っているルーティンを言葉で一本道に並べることは、想像以上の認知負荷を要します。その結果、「エクセルで管理して、メールで送って、確認してもらって」という大づかみな答えしか出てこない。
図解がこの課題を解く理由は、「書く」という行為が思考の外部化を強制するからです。ノートに四角と矢印を書きながら「あ、ここ抜けてた」と担当者自身が気づく。その気づきの瞬間が、コンサルタントが何時間インタビューしても引き出せない現場の実態です。
私自身、自社の業務(議事録の処理・コンテンツ生成・営業管理)をAIエージェントで自動化する前に、必ず手書きのAs-Is図解を作ります。書き始めると「こんな手順を踏んでいたのか」と気づく箇所が必ず出てきます。滞りは、書いて初めて見える。この実感が、図解を起点に据える理由です。
3枚の図解が担う役割
業務可視化で使う図解をすべて同じ目的で扱うと、議論が迷子になります。As-Is・To-Be・判断ツリーはそれぞれ目的が異なり、この順序で作るからこそ合意が積み上がります。
出典: 自社作成
As-Isで「今何が起きているか」を全員で確認し、To-Beで「AIが入った後の姿」に合意し、判断ツリーで「どこは人が判断するか」の境界線を引く。3枚を通して初めて「では、ここから実装に入りましょう」という次の一手が見えてきます。
この3枚は別々のタイミングに作ります。一度の会議で全部仕上げようとせず、As-Is → 滞りの確認 → To-Be → 判断ツリーという流れで、少なくとも2〜3回に分けて進める方が、合意の精度が上がります。
As-Is図解:現状の流れを「声に出させる」技術
As-Is図解は、今の業務プロセスを図にしたものです。ただし、精巧なフロー図を作ることが目的ではありません。目的は「担当者が自分の手で書く」という経験を通じて、滞りを声に出させることです。
作り方の基本
まず、対象業務を1つの動詞フレーズで定義します。「受注処理」ではなく「注文を受けてから出荷指示を出すまで」。「営業管理」ではなく「名刺交換からSFA入力が完了するまで」。終点を決めることで、図の範囲が決まります。
次に、担当者自身に手書きさせます。付箋とホワイトボードでも、A4の紙でも構いません。「一番最初に何をしますか?」から始めて、「その次は?」「それはどこで止まることがありますか?」と問い続ける。書けない箇所が出てきたら、そこが滞りの候補です。
問いかけの3パターン
As-Is図解を描きながら現場に投げる問いには型があります。
頻度を聞く:「この手順、週に何回くらいありますか?」——頻度が高く手間がかかる箇所は自動化の筆頭候補です。
属人度を聞く:「この判断、あなた以外の人でもできますか?」——「自分しか分からない」が出てきた箇所は、ルール化とAI化を同時に検討する必要があります。
例外を聞く:「いつもこの通りに進みますか?例外はありますか?」——例外が多い業務はAI化より先に整理が必要です。例外の洗い出しはしばしばAs-Is図解の中で最も時間がかかる工程ですが、ここを省くと実装後に「こんなケースが来たらどうするんだ」という問題が必ず出てきます。
業務の可視化と滞り特定のさらに詳しい進め方は業務フロー図解の作り方に整理しています。
To-Be図解:AIが入る場所を「合意の形」で決める
As-Is図解で滞りが見えたら、次はTo-Be図解です。「AIを入れた後、この業務はどう変わるか」を図で示します。
ここで大切なのは、To-Be図解は経営者やコンサルタントが一方的に描くのではなく、担当者を交えて作るという点です。「このステップを自動化します」と宣言しても、現場が「それって本当に動くの?」と感じている限り、導入後の定着率は下がります。一緒に描くことで、担当者は「これは自分たちが決めたプロセスだ」という感覚を持てます。
AIを入れる箇所の判定基準
To-Be図解を作るとき、どのステップにAIを入れるかを決める基準が必要です。目安は次の3つです。
ルールが書ける:「〇〇の場合は△△する」と文章で書けるか。書けるなら、AIに任せやすい。
インプットとアウトプットが明確:何を受け取って、何を出すか。この両端が決まっていない業務は、AIより先に整理が必要です。
頻度が高い:週1回の例外処理より、毎日発生する定型業務の方が自動化の効果が出やすいです(モデルケースとして、頻度が高いほど改善の恩恵が積み上がります)。
逆に、「上長の最終判断が必要」「顧客との関係性を読む必要がある」「前例がない状況への対処」は人が担う箇所として、To-Be図解でも明示して残します。「AIにできないことが分かった」は、導入前の大切な成果です。全部AIにしようとする必要はなく、人とAIの役割を明確に分けることが、To-Be図解の本来の仕事です。
滞りがお金にどう関わっているかの整理は業務の滞りをお金に換算する方法が手がかりになります。
判断ツリー:「ここはAIではない」を明文化する
3枚目の図解が判断ツリーです。これは業務の中で「誰が、どの条件で、どう判断するか」の分岐を木構造で描いたものです。
なぜ判断ツリーが合意に効くのか
AI導入の議論でよく起きる対立は、「どこまでAIに任せるか」という境界線の不明確さから来ます。「最終確認は人間がする」と口では言っていても、その「最終確認」の範囲が曖昧なまま実装に進むと、後から「こんな判断までAIがするのか」という反発が起きます。
判断ツリーは、この境界線を図として固定します。「金額がある閾値を超える場合は人が承認する」「定型の問い合わせはAIが回答し、クレームの場合は担当者にエスカレーションする」——このような分岐を図にしておくと、実装の設計にも社内説明にも使えます。
作り方
最初に「この業務で一番リスクが高い判断は何か?」を現場に聞きます。そこから逆算して分岐を描く。「〇〇の場合は?」「それ以外は?」という問いを繰り返すだけで、木の形になっていきます。
注意点は、最初から完璧な判断ツリーを作ろうとしないことです。実装後に「こんなケースがあった」と現場から報告が上がるたびに追記する前提で、まず「メインルート」だけ描く。完成より「使い始める」ことが優先です。判断ツリーは、運用しながら育てるドキュメントです。
業務可視化の進め方4ステップ
3種類の図解の使い方がわかったところで、実際の進め方を整理します。
出典: 自社作成
ステップ1:対象業務を1つに絞る
業務可視化でよくある失敗は、最初から「全社の業務を見える化しよう」と始めることです。範囲が広すぎると図解が発散し、誰も何も決められないまま会議が終わります。
最初の対象は「1人の担当者が、1つの業務を、1サイクル分」に絞ります。「請求書を受け取ってから経費精算を完了するまで」——このくらいの粒度が、1〜2時間のワークで図解できる適切な範囲です。欲張らないことが、最初のステップで最も効くルールです。
ステップ2:As-Is図解を手書きで描く
ツールは後でいいです。最初は紙とペンです。担当者に「自分が毎日やっていることを四角と矢印で書いてみてください」と依頼する。書けない箇所、書いてみて「あれ、ここ実は曖昧だな」と気づく箇所が、そのまま次の問いになります。
きれいに書こうとする必要はなく、むしろ汚い図ほど現場の実態に近い場合があります。清書はTo-Beが決まってからで十分です。
ステップ3:滞りに優先度をつける
As-Is図解が完成したら、各ステップの「頻度×所要時間」に着目します。数値で出す必要はなく、担当者自身に「大変な順に3つ挙げてください」と聞くだけでも十分です。上位3件だけを次のTo-Be図解のインプットにします。
全部を一度に改善しようとしない。上位3件に絞ることで、実装後の変化が体感しやすくなり、「もっとやってみよう」という次のサイクルが生まれます。
ステップ4:To-Be図解と判断ツリーを重ねる
優先度上位の滞りについて、To-Be図解と判断ツリーを描きます。ここは担当者だけでなく、その業務に関係するステークホルダー(上長、他部門の担当者)を交えて行います。図解を囲んで話すだけで、「そうか、あの部門はここを待っていたのか」という気づきが生まれることがあります。この場で出た「そうは言っても、こんな場合は?」という声が、判断ツリーの分岐として追加されていきます。
よくある失敗パターンと立て直し方
業務可視化を進める中で、同じような詰まり方をするケースがあります。代表的なものを整理します。
「きれいな図を作ること」が目的になる
PowerPointや図解ツールできれいなフロー図を作ることに時間を使いすぎると、本来の目的——滞りを見つけて合意を作ること——が後回しになります。図の精度より、現場の担当者が「これは自分たちの業務だ」と思えるかどうかの方が大切です。
立て直し方:手書きのまま関係者に見せる。「これで合ってますか?」と聞く。修正が入った箇所が、次の問いになります。
「全部AIにできそう」という楽観
As-Is図解を見て、「これは全部自動化できる」と感じることがあります。ただ、図解に書いた手順は「書けた部分」であり、「書けなかった暗黙の判断」は図の外に存在します。
立て直し方:「この手順を、入社1週間の新人がマニュアルなしでできますか?」という問いを挟む。「それは無理」という箇所が、暗黙の判断が残っている場所です。そこはAIより先に標準化が必要で、その整理ができたときに初めてAIが機能します。
「図解したが何も変わらなかった」
図解ワークショップで現場の滞りが見えたのに、次のアクションが決まらないまま数週間が過ぎる——これが最ももったいないパターンです。図解はあくまで意思決定の材料であり、完成物ではありません。
立て直し方:ワークショップの最後に「次の2週間で誰が何をするか」を図解の横に書く。担当者・期限・成果物の3点を決めてから終わる。この3点が揃わないうちは、次の作業に進まないというルールを持つと、会議が締まります。
図解の後にやること――AIエージェント実装への橋渡し
As-Is・To-Be・判断ツリーの3枚が揃ったら、次のステップはAIエージェントの実装設計です。ここで図解が活きてくるのは、「何をどの順序でAI化するか」の優先順位が、図の中に既に刻まれているからです。
実装の設計では、To-Be図解のうち「AIが担う箇所」として色をつけた部分が最初のスコープになります。判断ツリーは「どこまで自律させるか」のルール定義に使います。As-Is図解は「現状のシステム連携・データの在り処」を確認するために参照します。
この3枚を持った状態で実装に入ると、「何を作るか」の議論より「どう作るか」の議論に早く移れます。実装の設計から運用までの全体の流れはAIエージェント構築代行 完全ガイドで整理しています。
実装を外部に依頼する場合も、この3枚は「依頼書」の代わりになります。「うちの業務をAIで効率化してほしい」ではなく、「この図のTo-Be状態を実現するAIエージェントを作ってほしい」と伝えることで、見積もりの精度も、完成後のズレも小さくなります。
図解を「一度作って終わり」にしない運用
業務は変わります。担当者が変わる、システムが変わる、顧客の要望が変わる——その度に業務の実態とTo-Be図解の間にズレが生まれます。ズレたまま放置すると、AIエージェントは「ルール通りに動いているのに現場の役に立っていない」という状態になります。
対処は難しくなく、四半期に1回、担当者と図解を見直す時間を30分取るだけです。「この部分、今も同じ手順ですか?」「判断ツリーのこの分岐、最近使いましたか?」——その問いから始まる更新の積み重ねが、業務可視化を「一度作った資料」から「生きたドキュメント」に変えます。
AIエージェントを実装した後も、図解の更新が止まらないチームは、自動化の恩恵を継続的に受け取り続けます。逆に、実装して満足したチームは、半年後に「なんか最近ちゃんと動いてるのかな」という感覚と向き合うことになります。
業務可視化の進め方は、技術の話より先に「現場の人が自分の言葉で語れる状態を作る」という設計の話です。図解はそのための道具であり、AIはその後の話です。As-Is・To-Be・判断ツリーの3枚を順番に作ることで、現場・経営者・実装担当者の間に同じ地図が生まれます。その地図から出発するAI導入と、霧の中から始めるAI導入では、到達点が変わります。
自社の業務をどこから可視化すべきか迷う場合は、無料AI診断で現状の課題と優先順位の整理から始めることもできます。