ASIS業務フローは、縦にロール（誰が）、横に時系列（いつ）を取り、各ステップにINPUT・処理・OUTPUTと確信度を書き込んだ図です。見た目のきれいさより、「どの資料のどの項目が誰から誰へ渡るか」が読み取れることが大事です。
この記事では、実装担当として仕様書を受け取る側だったエンジニアが、自分で現状業務を描くときの手順と、よくある抜け漏れを説明します。
ASIS業務フローを書く目的は2つ
目的を決めずに描き始めると、きれいだけれど何も決まらない図ができあがります。ASISを書く目的は、基本的に次の2つです。
- 改善やシステム化の範囲を決めるため：どのロールのどの処理を、人が続けるのか、システムに任せるのか、連携で済ませるのかを、ステップ単位で判断する
- ヒアリングの前提をそろえるため：「私たちはこう理解していますが、合っていますか？」と見せて、現場との認識のずれを効率よく直す
どちらの目的で描くのかによって、細かさや見せ方が変わります。最初に一言で書いておきましょう。
業務はバトンの受け渡しとして描く
業務は、前の工程から受け取ったものを処理して、次の工程に渡す流れの連続です。リレーのバトンのように考えると分かりやすくなります。各工程は「次の工程が動けるもの」を渡す責任を持っています。
だから業務フローでは、矢印の上で何が渡されているかを必ず書きます。矢印だけの図は、誰が何を受け取って困っているのかが分かりません。
描き終えたら、最後の工程から逆向きにたどる点検も有効です。「請求書を出すにはこの情報が要る。その情報は前の工程で作られているか？」と確認していくと、どこかで手入力や問い合わせが発生している箇所が見つかります。
ロール×時系列で描く
フローチャートだけだと「誰がやるか」が抜け、組織図だけだと「いつやるか」が抜けます。両方を同時に見せられるのが、ロール×時系列（スイムレーン）の形です。
| 要素 | 表すもの |
|---|---|
| 縦の帯（レーン） | 誰が：社内の担当者、社内システム、取引先や顧客、外部システム |
| 横の流れ | いつ：左から右へ時間が進む |
| 矢印 | 情報やモノの受け渡し |
ロールは4種類に分けておくと、後の判断がしやすくなります。社内の担当者が手を動かしているステップは、改善やシステム化を検討する中心になります。取引先や顧客のステップは、こちらで置き換えることはできず、連携の対象になります。
各ステップにINPUT・OUTPUTを「どの資料のどの項目か」まで書く
各ステップには次の3行を添えます。
[ステップ名]
INPUT ：このステップに必要なもの（資料名・保存場所・項目）
処理 ：このステップで行うこと
OUTPUT ：このステップで生まれるもの（資料名・保存場所・項目）
ここで粒度が粗いと、要件定義で手戻りが起きます。
- 粗い例：INPUT「申込情報」
- 十分な例：INPUT「Webフォームの申込メール本文の『利用開始日』『台数』」
帳票やPDFの場合は、さらに「どの欄か」まで書きます。同じ「金額」でも小計、税、合計、値引き後が並んでいることが多く、口頭の「金額」は当てになりません。書き方の型は「帳票名（媒体）の位置『ラベル名』」です。たとえば「請求書PDF 右下『合計金額』欄」「管理表Excel シート"明細"のD列『数量』」のように書きます。実物の帳票の画像に枠で印を付けて添付しておくと確実です。
あわせて次の2点も書いておきます。
- トリガー：何をきっかけにこの業務が始まるか（「毎朝9時に前日分を確認」「在庫が一定数を下回ったら」など）。ここが曖昧だと、自動化しても何を合図に動かすかが決まりません
- データの保存先：処理の隣に「基幹システムの受注テーブル」「共有フォルダの管理表」などを付記します。保存先が分かると、連携先や移行対象が見えます
確信度をつけて、分からない部分を見える化する
ASISは最初から正確には描けません。各ステップに確信度の印を付けます。
| 印 | 意味 |
|---|---|
| ◎ | データや資料から明確に読み取れる事実 |
| ○ | 高い確度で推測できる |
| △ | 推測したが別の解釈もありうる |
| ？ | 手元の情報では判断できない |
△と？は、そのまま次のヒアリングで聞く項目になります。初めて描くフローに◎と○しかない場合は、確認していない部分を確認済みだと思い込んでいる可能性が高いので疑ってください。
細かさは目的で使い分ける
| 粒度 | ステップ数の目安 | 使う場面 |
|---|---|---|
| 経営層向け | 5〜10 | 全体構造の把握、承認 |
| 管理者向け | 15〜30 | 部門や担当の分担の把握 |
| 詳細設計向け | 30〜100 | 要件定義、画面や処理の設計 |
1枚に収まらないときは、粒度を上げるか、業務領域で分けます。
具体例：法人向け機器レンタルの申込から請求まで
法人向けにPCや計測機器を貸し出す会社の、申込から請求までを管理者向けの粒度で描くと、次のようになります。
| 順 | ロール | 処理 | INPUT | OUTPUT | 確信度 |
|---|---|---|---|---|---|
| 1 | 顧客 | 申込 | 必要台数と利用期間 | Webフォーム申込メール | ◎ |
| 2 | 受付担当 | 在庫確認 | 申込メールの「機種」「台数」、在庫管理表 | 引当可否の判断 | ○ |
| 3 | 受付担当 | 受注登録 | 引当可の申込 | 基幹システムの受注データ | ◎ |
| 4 | 倉庫担当 | 出荷 | 受注データから出力した出荷指示書 | 出荷済み機器、配送伝票 | ○ |
| 5 | 顧客 | 返却 | 利用期間の終了 | 返却品 | ◎ |
| 6 | 倉庫担当 | 返却検品 | 返却品、出荷時の記録 | 検品結果（破損の有無） | △ |
| 7 | 経理担当 | 請求 | 受注データの「期間」「単価」、検品結果 | 請求書PDF | ？ |
トリガーは「顧客の申込メール受信」、保存先は「申込メール受信箱」「在庫管理表（Excel）」「基幹システム」です。確信度△と？の6と7が、次に確認すべき箇所だと分かります。
ロールをまたぐ瞬間に、修正と取消の境界を点検する
業務フローには、モノ・情報・お金のどれかが流れています。ロールをまたぐところでは、次の3つを必ず確認します。
- 後から修正できるか
- 後から取消・返品・返金できるか
- できるなら、どの状態まで可能か
レンタルの例で、顧客からの「期間延長」と「キャンセル」をステータスごとに整理すると、次のようになります。
| ステータス | 顧客が延長できるか | 顧客がキャンセルできるか | 社内で修正できるか |
|---|---|---|---|
| 受注登録済み | 可 | 可 | 可 |
| 出荷済み | 可 | 条件付き（往復送料） | 可 |
| 返却済み | 不可 | 不可 | 請求前のみ可 |
| 請求済み | 不可 | 不可 | 別伝票で訂正 |
このステータスと操作の対応表は、要件定義で必ず必要になります。ASISの段階で作っておくと、「キャンセル機能を作ったが、出荷後に押されたときの扱いが決まっていなかった」「請求後の訂正は経理が手作業でやっていた」といった漏れを防げます。返品のように、モノは戻っても売上の取消や返金は別のタイミングで動く業務は、モノ・情報・お金を分けて描くと抜けが見えやすくなります。
よくある失敗
- ステップが抽象的：「業務処理」「確認」だけでは何をしているか分かりません
- 業務と手段が混ざる：「Excelに入力する」ではなく「受注内容を記録する（手段：Excel）」と書くと、手段を変える検討ができます
- 分岐や例外を書かない：在庫切れ、キャンセル、差し戻しを省くと、実装段階で一番時間がかかる部分が抜けます
- 誰がやるか書かない：「発注を行う」ではなく「現場担当者が発注する（10万円未満）」のように、ロールと条件を書きます
- 外部から来る形式を全部対応しようとする：取引先ごとに書式が違う書類を全パターン自動化しようとすると費用が膨らみます。件数の分布を集計し、上位の形式だけを対象にして残りは人が対応する設計を検討します
- 最初から完璧を目指す：叩き台を作って関係者と議論するほうが早く正確になります
この記事のまとめ
- ASIS業務フローは、範囲の決定とヒアリングの前提共有のために書く
- ロール×時系列の形で、矢印の上に何が渡るかを書く
- INPUT・OUTPUTは「どの資料のどの項目か」まで、トリガーと保存先も添える
- 確信度を付け、△と？をヒアリング項目にする
- ロールをまたぐところで、修正と取消がどの状態まで可能かを表にする
データしか手元にない段階でフローを描くにはデータから業務を推測する方法、描いたASISを持って確認しにいく段階ではASIS・TOBE・GAPをそろえるヒアリング、次のあるべき姿を描く段階ではTOBE業務フローの設計が参考になります。
業務フローを描く力は、FDE Guildのロードマップ ステップ1「業務を読む」の中心になるスキルです。元になった手順はFDEガイド「ASIS業務フロー」にまとまっており、スライド・演習問題・テストはlecture.iplot.jpで取り組めます。