As-Is/To-Be分析のやり方｜業務フローと課題整理テンプレート

As-Is/To-Be分析とは、現状の業務（As-Is）とあるべき業務（To-Be）をそれぞれ描き、その差を課題として整理して、差を埋める施策を決める手法です。 うまく進めるコツは、2枚の図を別々に眺めるのではなく、課題に番号を振って2枚をつなぐことです。

この記事では、架空の備品貸出業務を題材に、As-Is と To-Be の業務フロー（スイムレーン）を Mermaid のコードで並べ、課題整理表のテンプレートと記入例、工数削減の計算例までを載せます。フローチャートの記号の説明は省き、「2枚の差分をどう出し、どう表にまとめるか」に絞ります。

確認環境：Ubuntu 24.04、Python 3.11.15（対応漏れの点検と工数の計算を実行）、@mermaid-js/mermaid-cli 11.14.0＋Chromium（2枚のフローが描画できることを確認）。確認日 2026-10-06。業務・件数・時間はすべて架空の例です。

この記事の結論

課題整理表の1行が1課題になり、その行に「現状・原因・あるべき姿・施策・効果指標」が横に並びます。As-Is と To-Be の両方に同じ課題IDが出てくれば、差分の説明に抜けがありません。

As-Is/To-Be分析の早見表

As-Is/To-Be・Can-Be・Fit&Gap・KPTの違い

どれを使うかの判断表

As-Is/To-Be分析は「流れ」を扱う手法です。担当者が1人で完結する作業や、原因が1点に絞られている問題には、フローを2枚描くほどの手間は要りません。

手順1：As-Is を事実で描く

As-Is は「こうなっているはず」ではなく「実際にこうしている」を描きます。担当者に聞くだけでなく、申請書や台帳などの実物を見て確かめると、口頭では出てこない手戻りが見つかります。

題材は、社内でノートPCやプロジェクターを借りる備品貸出業務です。レーンは申請者・上長・総務担当の3つです。

flowchart LR
    subgraph L1[申請者]
        A1["紙の申請書に記入<br>P-01"] --> A2["上長へ持参<br>P-02"]
        A4[総務へ申請書を提出]
        A9[備品を受け取る] --> A10[使用後に返却]
    end
    subgraph L2[上長]
        A3["押印<br>P-02"]
    end
    subgraph L3[総務担当]
        A5["台帳で空きを確認<br>P-03"] --> A6{空きあり}
        A6 -- はい --> A7["台帳へ転記<br>P-04"] --> A8[備品を手渡し]
        A11[台帳に返却を記入] --> A12["月末に台帳を見て催促<br>P-05"] --> A13["利用状況を手集計<br>P-06"]
    end
    A2 --> A3 --> A4 --> A5
    A6 -- いいえ・電話で連絡 --> A1
    A8 --> A9
    A10 --> A11

工程の2行目に書いた P-01 などが課題IDです（手順2で振ります）。空きが無いと申請者に戻る矢印が、As-Is で見落としやすい手戻りです。

As-Is の工程と数字

手順2：課題に番号を振る

As-Is を見ながら、困っている点を1つずつ取り出して課題ID（P-01、P-02…）を振り、フローの該当する工程にもそのIDを書き込みます。

課題は「現状」と「原因」を分けて書きます。現状は起きている事実、原因はその事実が起きる仕組み上の理由です。原因を人ではなく仕組みに求めると、施策が「気をつける」で終わりません。

手順3：課題ごとに To-Be の変更点を対応づける

To-Be は、課題を1つずつ解消する形で描きます。変更した工程には、解消する課題のIDを As-Is と同じ番号で書きます。

flowchart LR
    subgraph L1[申請者]
        B1["予約画面で空きを見て申請<br>P-01 P-03"]
        B6[備品を受け取る] --> B7[使用後に返却]
    end
    subgraph L2[上長]
        B3["画面で承認<br>P-02"]
    end
    subgraph L4[予約システム]
        B2{"高額備品か<br>P-02"}
        B4["予約を台帳に自動登録<br>P-04"]
        B9["期限前日に自動通知<br>P-05"]
        B10["利用状況を自動集計<br>P-06"]
    end
    subgraph L3[総務担当]
        B5[備品を手渡し・貸出を記録]
        B8[返却を記録]
    end
    B1 --> B2
    B2 -- はい --> B3 --> B4
    B2 -- いいえ・自動承認 --> B4
    B4 --> B5 --> B6
    B4 --> B9
    B7 --> B8 --> B10

To-Be には「予約システム」のレーンが1つ増えました。人のレーンにあった作業がどこへ移ったかが、レーンの増減で読み取れます。

2枚の差分を表にする

2枚を並べただけでは変更点を見落とすので、工程ごとに「どう変わったか」を1行ずつ書き出します。変更の種類は次の6つに分けると整理しやすくなります。

「変更なし」の工程も表に残しておくと、To-Be の説明で「ここは変わらない」と示せます。

課題整理表テンプレート（空欄）

課題ID    工程  現状（As-Is）   原因  あるべき姿（To-Be）    施策  効果指標    優先度
P-01                            
P-02                            
P-03                            

上のコードブロックはタブ区切りなので、表計算ソフトにそのまま貼ると列に分かれます。

「あるべき姿」と「施策」を分けておくのが要点です。あるべき姿は状態、施策は手段で、あるべき姿が決まっていれば、施策は予算に合わせて差し替えられます。

記入例：備品貸出業務の課題整理表

課題ID    工程  現状（As-Is）   原因  あるべき姿（To-Be）    施策  効果指標    優先度
P-01    申請  紙の申請書に手書きし、記入漏れの差し戻しが月8件ある  必須項目を確かめる仕組みが無い 画面で入力し、漏れはその場で分かる   予約画面に必須入力の確認を付ける    差し戻し件数 月8件→0件   高
P-02    承認  全件を上長へ持参して押印をもらい、不在時は平均1日待つ 金額に関係なく全件が承認対象で、手段が紙だけ  高額備品だけ上長が画面で承認し、ほかは自動で承認される 承認の対象を高額備品に絞り、画面で承認する   申請から貸出可までの時間 平均1日→当日    高
P-03    空き確認    申請後に総務が台帳を見るまで空きが分からず、再申請が月12件ある    空き状況が総務の台帳にしか無い 申請者が申請の前に空きを見られる    予約画面に備品ごとの空き状況を表示する 再申請件数 月12件→0件   高
P-04    台帳転記    申請書の内容を台帳へ手で写し、写し間違いが月3件ある  申請と台帳が別の媒体で、二重に入力している   申請内容がそのまま台帳になる  予約を台帳に自動で登録する   転記の作業時間 月6時間→0時間    中
P-05    返却管理    返却の遅れに月末まで気づかず、催促に月60分かかる   期限を知らせる仕組みが無く、月1回の目視に頼っている  期限の前日に借りた人へ自動で知らせる  返却期限の前日に自動通知を送る 返却遅れ件数、催促の時間 月60分→10分   中
P-06    集計  利用状況を台帳から手で数え、月90分かかる   台帳が集計しにくい形になっている    備品ごとの利用回数がいつでも見られる  利用状況を自動で集計する画面を用意する 集計の時間 月90分→5分   低

対応の漏れを点検する

課題IDが3か所（課題整理表・As-Is・To-Be）にそろっているかは、目で追うより機械的に確かめる方が確実です。フローを asis.mmd と tobe.mmd、課題整理表を issues.tsv として保存し、次のコードを実行します。

import csv
import re

def ids(path):
    return set(re.findall(r"P-\d{2}", open(path, encoding="utf-8").read()))

with open("issues.tsv", encoding="utf-8", newline="") as f:
    table = {r["課題ID"] for r in csv.DictReader(f, delimiter="\t")}
as_is, to_be = ids("asis.mmd"), ids("tobe.mmd")

print("課題整理表:", sorted(table))
print("As-Is に印が無い課題:", sorted(table - as_is) or "なし")
print("To-Be に対応が無い課題:", sorted(table - to_be) or "なし")
print("課題整理表に無い To-Be の変更:", sorted(to_be - table) or "なし")

課題整理表: ['P-01', 'P-02', 'P-03', 'P-04', 'P-05', 'P-06']
As-Is に印が無い課題: なし
To-Be に対応が無い課題: なし
課題整理表に無い To-Be の変更: なし

3つとも「なし」なら、すべての課題に To-Be の変更点が対応しています。「課題整理表に無い To-Be の変更」が出た場合は、課題の裏づけが無い変更が紛れ込んでいる合図です。

工数削減を計算する

効果指標のうち作業時間は、As-Is の数字と To-Be の見込みから計算できます。月120件の貸出を前提にした計算例です。

CASES = 120  # 1か月の貸出件数（例）

# (課題ID, 作業, As-Is の分, To-Be の分)  ※1か月あたりの合計
rows = [
    ("P-01", "申請の記入",         5 * CASES,  2 * CASES),
    ("P-01", "差し戻しの書き直し", 10 * 8,     0),
    ("P-02", "上長への持参",       4 * CASES,  0),
    ("P-02", "押印・承認",         1 * CASES,  1 * 12),   # To-Be は高額備品の12件だけ
    ("P-03", "空きの確認",         5 * CASES,  0),
    ("P-03", "再申請",             10 * 12,    0),
    ("P-04", "台帳への転記",       3 * CASES,  0),
    ("P-04", "写し間違いの修正",   15 * 3,     0),
    ("P-05", "返却の催促",         60,         10),
    ("P-06", "利用状況の集計",     90,         5),
]

total_a = total_b = 0
by_issue = {}
for pid, name, a, b in rows:
    print(f"{pid} {name}: {a}分 → {b}分（削減 {a - b}分）")
    total_a += a
    total_b += b
    by_issue[pid] = by_issue.get(pid, 0) + (a - b)

saved = total_a - total_b
print(f"合計  As-Is {total_a}分（{total_a / 60:.1f}時間） → To-Be {total_b}分（{total_b / 60:.1f}時間）")
print(f"削減  {saved}分（{saved / 60:.1f}時間／月、{saved * 12 / 60:.0f}時間／年）  削減率 {saved / total_a:.1%}")
print("課題ごとの削減（大きい順）")
for pid, v in sorted(by_issue.items(), key=lambda x: -x[1]):
    print(f"  {pid}: {v}分（{v / saved:.1%}）")

P-01 申請の記入: 600分 → 240分（削減 360分）
P-01 差し戻しの書き直し: 80分 → 0分（削減 80分）
P-02 上長への持参: 480分 → 0分（削減 480分）
P-02 押印・承認: 120分 → 12分（削減 108分）
P-03 空きの確認: 600分 → 0分（削減 600分）
P-03 再申請: 120分 → 0分（削減 120分）
P-04 台帳への転記: 360分 → 0分（削減 360分）
P-04 写し間違いの修正: 45分 → 0分（削減 45分）
P-05 返却の催促: 60分 → 10分（削減 50分）
P-06 利用状況の集計: 90分 → 5分（削減 85分）
合計  As-Is 2555分（42.6時間） → To-Be 267分（4.5時間）
削減  2288分（38.1時間／月、458時間／年）  削減率 89.5%
課題ごとの削減（大きい順）
  P-03: 720分（31.5%）
  P-02: 588分（25.7%）
  P-01: 440分（19.2%）
  P-04: 405分（17.7%）
  P-06: 85分（3.7%）
  P-05: 50分（2.2%）

計算結果の読み方

作業時間の削減と、待ち時間（申請から借りられるまでの時間）の短縮は別の指標です。作業時間だけで優先度を決めると、P-05 のように「時間は小さいが困りごとは大きい」課題が後回しになります。課題整理表の効果指標に、時間以外の数字（件数・日数）も書いておくのはそのためです。

To-Be を先に描く進め方との使い分け

To-Be から描く場合も、差分を課題IDでつなぐ点は同じです。As-Is の調査は「To-Be と違うところ」に絞れるので、短い期間で済ませられます。

仕上げのチェックリスト

確かめて分かったこと

• Mermaid の flowchart では、レーン（subgraph）の並び順が書いた順にならなかった。今回の2枚では、申請者・上長・総務担当の順に書いても、描画では矢印のつながりに合わせて上長や総務担当が上に配置されました。レーンの並びを2枚でそろえたい場合は、描画結果を見て確かめる必要があります。
• 課題IDを工程のラベルに書いておくと、正規表現で取り出して対応の漏れを点検できた。図と表を別々に直しているうちにずれる、というつまずきを機械的に防げます。
• 作業時間の削減の57.2%が、6課題のうち2課題に集まっていた。優先度を付ける前に課題ごとの内訳を出すと、力を入れる場所が決めやすくなります。
• 待ち時間は作業時間の合計に表れなかった。上長の押印は1件1分ですが、申請者にとっては平均1日の待ちです。指標を分けて書く必要があります。
• To-Be の1つの工程が複数の課題を解消することがあった（予約画面での申請が P-01 と P-03 に対応）。工程と課題は1対1とは限らないので、IDで対応づける形が向いています。

つまずきやすい点と直し方

よくある質問

Q. As-Is/To-Be分析とは？ A. 現状の業務とあるべき業務を描き、その差を課題として整理して施策を決める手法です。業務フロー2枚と課題整理表が成果物になります。

Q. As-Is と To-Be はどちらから描く？ A. いまの業務を土台に改善するなら As-Is から描きます。業務を大きく作り替える場合は To-Be から描き、As-Is の調査を差のある箇所に絞ります。

Q. As-Is/To-Be と Can-Be の違いは？ A. To-Be は制約を置かずに描くあるべき姿、Can-Be は期限や予算の中で到達できる姿です。To-Be が一度で届かないときに、中間の到達点として Can-Be を置きます。

Q. As-Is/To-Be分析と Fit&Gap分析の違いは？ A. 比べる相手が違います。As-Is/To-Be分析は自社の現状とあるべき姿を比べ、Fit&Gap分析は自社の要件と既製品の標準機能を比べます。To-Be で決めた業務が、Fit&Gap分析の要件になります。

Q. To-Be が描けないときは？ A. 課題整理表の「あるべき姿」の列を先に埋めます。課題ごとに「どうなっていれば困らないか」を1文で書き、その文を満たす工程を As-Is に上書きしていくと、To-Be のフローになります。

まとめ

• As-Is/To-Be分析は「As-Is を事実で描く → 課題に番号を振る → 課題ごとに To-Be の変更点を対応づける」の3段で進めます。
• 課題IDを As-Is・To-Be・課題整理表の3か所に書くと、差分の説明に抜けが無くなります。
• 課題整理表は8列・1行1課題で、現状と原因、あるべき姿と施策を分けて書きます。
• 2枚の差分は、工程ごとに変更の種類（廃止・自動化・移管・条件つき・前倒し・新設）を付けて表にします。
• 効果は作業時間・件数・待ち時間を分けて測り、課題ごとの内訳を出してから優先度を決めます。
• 対応の漏れは、課題IDを機械的に突き合わせて点検できます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。