ASIS業務フロー

業務フローの3ポイント

業務フローは、ロール（縦）×時系列（横）の二軸に、INPUT/OUTPUTと確信度を併記して書く。ここまで揃って初めて、ベンダーと現場の両方が議論の対象にできる「共通言語」になる。

• ─① ロール×時系列フォーマット（縦に部門／役割、横に時系列）
• ─② INPUT/OUTPUTを各ステップに明記（紙・ファイル・口頭の別も）
• ─③ 確信度を○△×で付記（ヒアリング後に潰す論点を可視化）

なぜロール×時系列か

「フローチャート」を書くと、誰がやるかが落ちる。「組織図」を書くと、いつやるかが落ちる。ロール×時系列は、両者を同時に見せる唯一の形式。誰が読んでも同じ業務理解になる。

INPUT/OUTPUTの粒度

「受注確認」というステップに「INPUT: 受注書、OUTPUT: 確認済み受注書」と書いても何も伝わらない。INPUT/OUTPUTは媒体まで分解する。

• ─媒体：紙／PDF／Excel／システム画面／口頭／メール
• ─状態：未処理／処理中／確認待ち／完了
• ─保管場所：自席／共有フォルダ／システムDB／ファイリング
• ─次の受け手：誰に（ロール）／どうやって（媒体）／いつまでに

ステータス×CRUD俯瞰マップ

業務フローの上流／下流の「境界」は、ステータス遷移とCRUD（作成・更新・削除）の組み合わせとして整理できる。例：「出荷済」のあとに返品が来た場合、ステータスは何に戻すか、伝票はUPDATEかDELETEか、入金は返金可能か——これは要件定義の必須論点で、ASISの段階で論点として可視化しておく。

境界の論点（要件定義の漏れ予防）

ASISを書く時点で、次の境界を必ず洗う。要件定義で抜けると現場で爆発する。

• ─受注 → 受注確認：取消はいつまで／誰が／どう記録するか
• ─出荷 → 配送：配送中の追跡情報は誰が更新するか
• ─納品 → 検収：検収NG時の差し戻しは何ステータス／何日以内か
• ─請求 → 入金：入金後の返金は何ステータスまで可能か
• ─月次締め：締め後の修正は別伝票か／元伝票UPDATE可か

「モノ・情報・お金」の3レイヤーで描く

業務フローを「作業の連続」として描くと、抜けるのが「情報」と「お金」のレイヤー。実用上、3レイヤーを並走で描くと、要件定義の論点が立体的に見える。例：返品では、モノは戻ってくるが、情報（売上計上の取消）と、お金（返金）は別タイミングで動く。これを1レイヤーで描こうとすると、必ずどれかが落ちる。

「やったつもり」を防ぐ確信度の付け方

業務フローを書いて満足する最大の罠が、「全部○のつもり」になること。確信度は3段階で付けるが、「△と×が3割以上ない」フローは怪しい。新規プロジェクトで初版に書く業務フローは、ほぼ必ず△と×が4〜5割を占める。それを「集まる論点」として可視化することが目的なので、○ばかりにしないこと。