As-Is/To-Be業務フローの書き方｜現状と理想の描き分け方
As-Is/To-Beの業務フローとは、現状の業務の流れ(As-Is)と、改善後のあるべき流れ(To-Be)を、それぞれ図にして比べる手法です。
システム化や業務改善の検討で使う理由は単純で、「今どうなっているか」と「どう変えたいか」を関係者の頭の中でそろえないと、投資の判断も開発の依頼もぶれるからです。
書き分けのコツは、As-Isを美化しないこと、To-Beを一足飛びに描かないことの2つに尽きます。
本記事では、2つの図を描く手順、現状ヒアリングのコツ、そしてギャップの整理をシステム化の要件につなげる方法を解説します。
As-IsとTo-Beの役割。なぜ2枚に分けるのか
| 図 | 描くもの | よくある失敗 |
|---|---|---|
| As-Is(現状) | 実際に行われている業務の流れ。例外・手戻りも含む | 建前の手順書どおりに描いてしまい、実態と違う |
| To-Be(あるべき姿) | 課題を解消した後の業務の流れ | 実現手段の裏付けなく理想だけを描く |
As-Is/To-Beという言葉自体は業務フローに限らず、組織や制度の現状と理想の対比にも使われますが、本記事はシステム化・業務改善の検討で使う業務フローに絞って解説します。
1枚の図に現状と改善案を混ぜると、「これは今の話か、将来の話か」が読み手に伝わらず、認識合わせの道具として機能しません。2枚に分け、その差分(ギャップ)を一覧にする。この3点セット(As-Is図・To-Be図・ギャップ一覧)が、検討と発注の共通資料になります。
図の描き方(記号や粒度)自体は、標準記法を使うと誤解が減ります。基礎はBPMNの記号と業務フロー図の基礎で解説しているため、本記事は「何を描くか」に集中します。
As-Isの描き方。例外を集めることが本体
As-Isで価値があるのは、きれいな正常系ではなく、例外と手戻りです。描く手順は次の通りです。
第1に、対象業務の開始と終了を決めます(例: 注文を受けてから請求書を送るまで)。第2に、正常な流れを担当者ごとに並べます。第3に、ここからが本体で、例外を集めます。「急ぎの案件はどうしていますか」「情報が足りないときは誰に聞きますか」「月末はやり方が変わりますか」といった質問で、図に載っていない実態を引き出します。第4に、各作業に「かかる時間」「使っている道具(Excel・紙・システム)」「困りごと」を注記します。この注記が、後のギャップ一覧の材料になります。
あわせて、件数・頻度の数字も注記してください。「月に何件」「1件に何分」が入ったAs-Isは、To-Beの効果(削減時間)を見積もる材料になり、投資判断の説得力が変わります。
ヒアリングのコツは、その業務を毎日やっている担当者に、実際の画面や帳票を見せてもらいながら聞くことです。管理者だけへのヒアリングは、建前のAs-Isになりがちです。描いた図は必ず現場に見せ、「この通りか」を確認してから確定します。確認済みかどうかを図の欄外に記録しておくと、後工程で図の信頼度を判断できます。
To-Beの描き方。一足飛びに理想を描かない
To-Beの失敗の典型は、現状の制約を無視した理想図です。「すべて自動化」と描くのは簡単ですが、実現手段・費用・移行の裏付けがない図は、検討を前に進めません。
現実的な手順は、As-Isの困りごとに優先順位をつけ、効果の大きい箇所から変えることです。具体的には、ギャップ一覧を「課題/原因/変えた後の流れ/実現手段の候補(運用変更・既存ツール・システム化)/効果」の列で作り、実現手段が運用変更で済むものと、システム化が必要なものを分けます。システム化が必要なものだけがTo-Be図の変更点になり、それ以外は運用改善として先に着手できます。
なお、To-Beが複数システム・複数部門にまたがる大きな話になる場合は、個別のフロー図より先に全体像を描く段階です。
作成例。小さな題材で流れをつかむ
流れをつかむための説明用の例として、経費精算業務を挙げます(実在の事例ではなく、記入イメージです)。
As-Isでは、紙の申請書に領収書を貼り、上長の押印を経て経理がシステムへ手入力している、と描いたとします。例外として、上長不在時は代理承認の慣行があり、月末は件数が集中して経理の入力が翌月にずれ込む、という実態も注記します。課題は、紛失・差し戻しのやり取り・二重入力の3つです。
To-Beでは、フォームからの申請と画像添付、承認の自動通知、承認済みデータの会計システム連携、と描きます。ギャップ一覧には、「紙申請→フォーム化(実現手段: 既存ワークフローツール)」「二重入力→連携開発(実現手段: システム化)」のように、課題・変更点・実現手段の候補を行で並べます。
この規模の題材で一度3点セットを作ってみると、自社の本命業務(受注管理・生産管理など)に取り組む際の勘所がつかめます。
ギャップ一覧を発注につなげる
As-Is図・To-Be図・ギャップ一覧の3点セットは、そのまま見積もり依頼の添付資料として機能します。開発会社は、現状と変更点が図で示されると、対象範囲と難所を見積もりに反映しやすくなり、「聞いていなかった例外」による後からの増額を減らせます。
図とギャップ一覧には作成日と版を入れ、業務が変わったときの更新責任者を決めておきます。検討が数か月に及ぶ場合、古い図が独り歩きすることを防ぐためです。
発注に進む際は、ギャップ一覧の各行に「今回のシステム化に含む/含まない」を明記してください。全部を一度に変えようとせず、含まない項目を明示することが、範囲の膨張を防ぎます。フロー図を文書(業務の定義・要件)へ落とし込む書き方は業務定義書の書き方で、要件定義工程の全体は要件定義の進め方と書き方で解説しています。
As-Is/To-Be業務フローに関するFAQ
As-IsとTo-Beはどちらから描くべきですか？
As-Isからです。現状の例外・困りごとを集めないままTo-Beを描くと、理想はきれいでも移行できない図になります。ただしAs-Isの完璧を目指しすぎず、対象業務の範囲に絞って早めにTo-Be検討へ進むバランスも重要です。
どのくらい細かく描けばよいですか？
「1つの箱=担当者が一度に行う作業のまとまり」を目安にし、クリック単位の操作手順は描かないでください。細かすぎる図は作るのも直すのも重く、検討の道具として使われなくなります。
専用ツールは必要ですか？
必須ではありません。ホワイトボードや手書きで始めて、確定段階で清書すれば十分です。大事なのは図の美しさではなく、現場に確認済みであることと、As-Is/To-Be/ギャップの3点がそろっていることです。
現状の整理からシステム化の判断まで一緒に進められます
ノーコード総研では、ノーコードやAIを活用した業務システムの受託開発をご相談いただけます。「As-Isを描き切れていない」という段階でも、業務の聞き取りとフローの整理から一緒に進め、運用で直せる部分とシステム化すべき部分を切り分けられます。
発注先の検討はシステム開発会社のタイプ別比較も参考に、まずは対象業務の開始と終了を決めて、ノーコード総研に相談することから始めてみてください。