これは何か
業務フロー図は、1つの業務について、誰が、どの順番で、何をし、何を次の人やシステムに渡すのかを、図にした成果物です。
要件を「画面の一覧」や「欲しい機能」から始めると、業務として本当に必要なことが抜けます（04-02）。業務フロー図は、要件を考える前に「今の仕事はどう流れているか」「新しい仕組みでどう流れるようにするか」を、業務の担当とシステムの担当が同じ絵で確かめるための出発点です。
なぜ作るか
- 業務要件の出どころにする（流れの1つずつの作業から、業務として何ができなければならないかを書く）
- 部門と部門、人とシステムの受け渡しの場所を見えるようにする（受け渡しは抜けや食い違いが起きやすい）
- 受入テストで確かめる業務の場面の出どころにする（10-03）
誰が使うか・いつ作るか
- 作る人：業務の担当と、要件をまとめる担当が一緒に作る
- 確かめる人：その業務に責任を持つ人、流れの途中に出てくる他部門の担当
- 使う人：要件をまとめる担当、設計の担当、受入テストを準備する担当
- 一般的には、要件定義の初めに今の流れ（現状）を描き、要件をまとめながら新しい流れ（あるべき姿）を描きます。業務のやり方を変えるたびに更新します
CASE FACTFROZEN正本に記載されたアステリア案件の事実
業務の流れに関係する記載
- 正本には「最重要データチェーン」（11段）が定められている。顧客から始まり、契約・案件・要員・工数・原価・売上・請求などを経て、会計・経営分析に至る
- 約1,500件の要件
- 業務の担当として、P-005 藤本 遥（経理業務リーダー）、P-006 川村 美咲（プロジェクト管理業務リーダー）、P-007 松本 健太（営業・契約業務リーダー）がいる
- 成果物に REQ-001 業務フロー図、REQ-002 要件一覧、REQ-004 要件追跡表がある
最重要データチェーンの全体は システム・連携 で確認できます。
正本のデータチェーンは、データがどの順につながるかを示したものです。それぞれの段で、誰が、いつ、どんな作業をして次の段へ渡すのか（業務の流れ）は、正本に記載がありません。未確定 アステリア案件の業務フロー図の中身、描いた業務の数、描いた人も、正本に記載がありません。未確定
主な要素
一般的には、次の要素で描きます。
- 役割の帯（レーン）：部門・役割・システムごとに横の帯を分け、誰の作業かを示す
- 作業：1つの箱に1つの作業。「誰が・何をする」が読める言葉で書く
- 分かれ道：承認する・差し戻す、条件によって進む先が変わる場所
- 受け渡し：次の作業に渡すもの（データ・帳票・連絡）と、渡す手段
- 始まりと終わり：何がきっかけで始まり、何ができたら終わるか
- 例外の流れ：取り消し・やり直し・差し戻し
- 作業の番号：要件一覧から「この要件はどの作業から出たか」をたどるための番号
- 版と確かめた人：いつの流れか（現状かあるべき姿か）と、確かめた業務の担当
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 業務フロー図を表で書いた例
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。業務フロー図は図で描くことが多いですが、ここでは読み方を学ぶために、図の中身を表に書き出しています。題材は、どの会社にもある経費の立替精算です。
| 作業の番号 | 役割の帯 | 作業 | 次へ渡すもの | 分かれ道・例外 |
|---|---|---|---|---|
| BF-EX-01 | 申請する社員 | 立て替えた経費を、領収書を添えて申請する | 申請の内容と領収書 | ― |
| BF-EX-02 | 上長 | 申請の内容を確かめ、承認する | 承認の記録 | 内容に不足があれば BF-EX-01 へ差し戻す |
| BF-EX-03 | 経理の担当 | 領収書と金額、使った目的の区分を確かめる | 確認済みの申請 | 規程に合わなければ、理由を付けて BF-EX-01 へ戻す |
| BF-EX-04 | 経理の担当 | 支払の予定に入れる | 支払の予定 | ― |
| BF-EX-05 | 申請する社員 | 支払われたことを確かめる | ― | 支払がなければ経理の担当へ問い合わせる（システムの外の作業） |
要件一覧の側では、たとえば「上長は、差し戻す理由を申請した社員に伝えられる」という業務要件に、出どころとして BF-EX-02 を書きます。こうすると、流れを変えたときに見直す要件をたどれます。
読み方
- 1つの箱に、1人（1つの役割）の1つの作業だけが書かれているか
- 帯と帯をまたぐ受け渡しで、何を・どの手段で渡すかが書かれているか
- 分かれ道の先が、すべてどこかへつながっているか（行き止まりがないか）
- 例外の流れが描かれているか
書き方
- 業務の範囲（始まりと終わり）を決める
- 業務の担当に聞きながら、今の流れを描く。困っていること・手作業で補っていることも書き込む
- 業務の担当が「この順番で合っている」と確かめる
- 新しい仕組みでの流れ（あるべき姿）を描き、今の流れとの違いを示す
- 作業に番号を付け、要件一覧（REQ-002）から出どころとして参照できるようにする
- 流れを変えたら、図の版を上げ、つながる要件を見直す
何を書いてはいけないか
- 確かめていない作業や順番を、推測で描くこと
- 主語のない作業（「登録する」だけでは、誰が登録するのか分からない）
- 画面の遷移を業務の流れとして描くこと（画面の順番は設計の話）
要件一覧との関係
- 業務フロー図（この成果物）：業務がどう流れるか。要件の出どころ
- 要件一覧（REQ-002）：流れの中で、業務として・システムとして何ができなければならないかを、番号を付けて並べたもの
- 要件追跡表（REQ-004）：要件から設計・テストまでのつながり
流れの作業の番号と要件の番号がつながっていれば、「この要件はなぜ必要か」を業務の流れで説明できます。逆に、どの作業にもつながらない要件があれば、なぜ必要かを確かめるきっかけになります。
どこを見るか
- 業務の範囲（始まりと終わり）
- 役割の帯と、帯をまたぐ受け渡し
- 分かれ道と例外の流れ
- システムの外の作業
- 作業の番号と、要件一覧とのつながり
赤信号
- 役割の帯がなく、誰の作業か分からない
- 通常の流れしか描かれていない
- 業務の担当が確かめた記録がない
- 要件一覧に、どの作業にもつながらない要件が多い
よくある失敗
- システムの担当だけで描き、業務の担当が見ると実際と違う
- 今の流れだけを描き、新しい仕組みで何が変わるのかが示されない
関係するUnit・成果物・危機演習
- Unit：04-02 業務要件とシステム要件、04-01 要望と要件は何が違うのか、10-03 利用部門が確認するテスト
- 成果物：REQ-002 要件一覧、REQ-004 要件追跡表、TST-006 利用者受入テスト・終了判定報告書
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、業務の担当の話や手順のメモから、流れの下書きを作るのに役立ちます。
「次の聞き取りのメモから、業務の流れを『作業の番号・役割・作業・次へ渡すもの・分かれ道』の表に下書きしてください。メモに書かれていない作業や順番は足さず、『確認が必要』として別に挙げてください。」
REVIEW
- AIが、メモにない作業を一般的な業務として足していないか
- 下書きを、業務の担当が確かめたか
人間が判断すること
- 描く業務の範囲
- 流れが実際の業務と合っているか（業務の担当の確認）
- 新しい仕組みで、業務の流れをどう変えるか
いつ使うか
この教材では STAGE 04｜1,500件の要件を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この図を見た業務の担当は、「自分たちの仕事の順番と受け渡しが、抜けも作り話もなく描かれている」と言えますか？