Kakusillで作るTo-Be業務フロー｜合意する5項目
目次
はじめに
会議メモをAIへ渡すと、数分で業務フローが出てくる。箱と矢印は整い、承認も自動化されている。ところが現場へ見せると、「月末だけ別の担当者が処理する」「その確認は法務上なくせない」と指摘が続いた。
図はきれいだ。だが、業務としてはまだ動かない。As-Isが現実の観察なら、To-Beは変更の意思決定である。廃止する作業、移行期間、顧客が承認する条件まで決める必要がある。
AIによる業務フロー作成で難しいのは、描画ではなく未来の業務を決めることだ。KakusillのTo-Be業務フローも、AIの初稿を完成品にしない。目的、廃止、例外、責任、効果の5項目を人が合意して初めて、開発へ渡せる仕様になる。
AIに図を描かせる前に、改善の目的を一文にする
As-Isは現在の業務を映す。To-Beは、改善後に誰が何をするかを決める。似た図に見えるが、役割は違う。
IPAのユーザのための要件定義ガイドでは、As-Is業務フローは現状の本質的な課題を見つけるため、To-Be業務フローは新しいビジネスプロセスを共通認識するために役立つと整理されている。つまり、To-Beは「AIが考えた理想図」ではない。関係者が引き受ける新しい仕事の合意書である。
最初の入力は長い指示でなくてよい。次の3行を用意する。
- 対象：注文メールの受信から出荷指示まで
- 目的：二重入力をなくし、当日中に出荷判断する
- 制約：高額注文は人が承認し、既存の在庫管理は残す
対象が「受注業務」だけでは広すぎる。「効率化する」だけでは成功を判定できない。開始と終了、変えたい結果、変えられない条件まで書くと、AIが勝手に埋める余白が減る。
現状の整理がまだなら、Kakusillとは｜要求整理から仕様化まで の5つの働きから確認してほしい。Kakusillは会議メモや既存資料を材料に、業務フローと不足論点を整理し、要求・設計・テストのつながりを扱うことを目指している。
KakusillのTo-Be業務フローに入れる5項目
1. 到達点と開始・終了条件
一つ目は、この流れが何を達成すれば終わるかだ。
たとえば「受注処理を自動化する」では足りない。「注文メールを受信し、在庫と与信を確認して、出荷可否を担当者へ返す」とする。開始はメール受信、終了は出荷可否の通知だ。対象外は、価格交渉と配送計画と明記する。
さらに、成功条件を数字にする。入力作業を1件15分から5分へ、翌営業日だった判断を当日16時までへ、といった具合だ。数字はAIに決めさせず、As-Isの実測値と責任者の判断から置く。
2. 廃止・統合・自動化する作業
To-Beを描くとき、すべての現行作業を新しいシステムへ移す必要はない。手入力を自動化する前に、その入力自体をなくせないか考える。
GXOのAs-Is/To-Beフロー図の書き方では、改善案を排除、統合、順序変更、自動化の4つ に分けている。この順番は実務でも使いやすい。
受注台帳への転記は廃止する。同じ顧客情報の確認は統合する。在庫確認を承認前へ動かす。定型注文だけ自動判定する。レビュー時は各ステップに「残す・やめる・まとめる・動かす・自動化する」を付記する。何を作るかだけでなく、何を作らないかが見える。
3. 例外と人へ戻す条件
AIが作る初稿は、正常系が滑らかになりやすい。実際の業務を止めるのは、例外だ。
在庫データが更新されていない。新規顧客で与信情報がない。注文書とメールの金額が違う。担当者が休んでいる。外部システムが応答しない。このとき、誰へ戻し、何を表示し、何分待ち、どこから再開するかを決める。
「エラーなら担当者が対応」では曖昧だ。「在庫APIが30秒以内に応答しなければ自動判定を止め、受注担当の共有キューへ注文番号と失敗理由を送る」と書く。答えがなければ推測で埋めず、利用者が担当者と期限を未決事項として記録する。
4. 責任者と権限
箱には処理名だけでなく、実行者と承認者が必要だ。人、AI、システムのどれが動くのかを分ける。
AIは注文内容を抽出する。在庫管理システムは数量を返す。受注担当は不一致を修正する。営業部長は高額注文を承認する。運用担当は連携失敗を再実行する。ここまで分けると、必要な画面と権限が見える。
注意したいのは「確認」と「承認」を同じ箱にしないことだ。確認は情報の正しさを見る作業、承認は結果の責任を引き受ける判断である。自動化してよい確認と、人に残す承認を区別する。担当者が不在のときの代理、差し戻し、取消権限も忘れやすい。
5. 効果指標と測定方法
最後は、To-Beへ変えた結果をどう測るかだ。処理時間だけでは偏る。時間、品質、利用、例外の4面を見る。
- 時間：注文受信から出荷判断までの中央値
- 品質：転記ミスと差し戻しの件数
- 利用：新しい流れを通った注文の割合
- 例外：人へ戻した割合と、その主な理由
測定元も決める。開始時刻はメール受信ログ、終了時刻は出荷判断ログ、差し戻しはワークフロー履歴から取る。目標値だけあり、データの取得元がない指標は運用後に測れない。
業務フロー図の作り方でも、To-Beに沿った変更を実行し、処理時間や承認待ち時間で効果を測る流れが示されている。図へ指標を結び付けると、改善案が投資判断へ変わる。
AIが作ったTo-Be案を現場でレビューする
AIの初稿が出たら、関係者を集めて3つだけ質問する。
一つ目は「この流れで困る人は誰か」。営業には速くても、経理の照合作業が増えるなら全体最適ではない。顧客、現場、管理部門、運用担当の順で見る。
二つ目は「繁忙期と障害時にも回るか」。月末の件数、担当者不在、連携停止をフローへ当てる。例外時だけ紙やExcelへ戻るなら、その復旧後にデータをどう合わせるかも必要だ。
三つ目は「移行途中でも仕事を止めないか」。すべてを一度に変えず、対象部門や注文種別を絞る。旧手順と新手順が並ぶ期間の正本、切り替え日、戻す条件を決める。
業務フローからシステム要件へ渡す
合意したTo-Beを図のまま開発へ渡すと、また解釈が分かれる。利用者が各ステップへ要件IDを付け、少なくとも5種類へ展開する。
- 機能：注文取込、在庫照会、承認、通知、再実行
- データ：注文、顧客、在庫、判断結果、履歴
- 権限：閲覧、修正、承認、取消、再実行
- 運用：監視、問い合わせ、障害対応、代理担当
- 受け入れ条件：入力、期待結果、例外、測定値
たとえば「在庫を確認する」という箱には、在庫照会API、商品コード、タイムアウト時の扱い、利用できる役割、テスト条件がぶら下がる。AIが読める仕様書の7項目も合わせると、図から実装へ渡す情報を揃えやすい。
SIer案件では、発注者、業務部門、開発側の承認を分ける。発注者は改善目標と予算を承認し、業務部門は例外と新しい役割を確認し、SIerは実現方法と検証条件を確定する。承認者、日時、対象版を残せば、後の変更で「誰と何を合意したか」を追える。
To-Beの承認後に高額注文の条件が変わったとしよう。対象の判断箱から、権限要件、承認API、通知、異常系テストまで同じ要件IDでたどる。変更差分を設計とテストへ渡すところまでが、仕様駆動開発における業務フローの役割だ。
KakusillのTo-Be業務フローを扱う価値は、図の清書だけではない。要求、フロー、仕様、テストを同じ文脈でつなぎ、変更の影響を確認できる点にある。AIに渡す仕様と、人が承認する判断を分けておけば、実装が速くなっても責任は曖昧にならない。
図を完成品ではなく、仕様の入口にする
良いTo-Be業務フローは、箱の配置が美しい図では ない。目的が測れ、不要な作業が消え、例外時の戻り先があり、責任者が決まり、効果を追える図だ。
Kakusillで作るときも、AIには初稿と不足質問を任せる。現場は5項目をレビューし、決まった内容を要件へつなぐ。この分担なら、会議のたびに図を描き直す時間を減らしつつ、合意の密度を上げられる。
株式会社Atsumellでは、既存資料とAs-Isの整理から、Kakusillを使ったTo-Be設計、要件定義、AI開発への受け渡しまで支援している。業務フローはあるが開発要件へ落ちない、AIの提案をどうレビューすべきか迷う。そんな段階から相談してほしい。
