As-Is／To-Beとは？業務の棚卸しと業務フローの作り方｜システムを頼む前に自社で作る範囲

「現状を整理してから相談に来て、と言われたけれど…」

「業務フローを描き始めたら、どこまで描けばいいのか分からなくなった」

システムを頼む前の「As-Is／To-Be の整理」で、手が止まっていませんか？

言葉は知っていても、何をどの順で書き、どこまで自社でやってから相談すればよいかは、誰も教えてくれません。

本記事では、棚卸し表の作り方、現状フローの描き方、あるべき姿の決め方、自社で作る範囲と相談先に任せる範囲を解説します。

As-Is／To-Be の悩み：こんなことありませんか？

As-Is／To-Be で止まる原因は、書く順番と細かさが決まっていないことです。

「現状を整理して」と言われたが、何から書くか分からない

上司や開発会社から「まず現状を整理してください」と言われます。やる気はあるのに、白い紙の前で止まります。

業務の一覧から書くのか、図から描くのか、困りごとから書くのか。順番が決まっていないと、どれも中途半端に終わります。

業務フローを描き始めたら、きりがなくなった

1つの業務を描くと、例外の流れが次々に出てきます。「月末だけ違う」「この取引先だけ紙」。全部を描こうとすると、1枚に収まらず、誰も読まない図になります。

あるべき姿を描いたら、今のシステムの作り直しになりそうで怖い

理想を描けば描くほど、変える範囲が広がります。「ここまで変えるなら、いくらかかるのか」が分からず、社内に出せないまま止まります。

As-Is／To-Be とは？今の業務とあるべき姿の差

As-Is は今の業務の動き、To-Be はあるべき姿です。2つを並べて初めて見える「差」が、システムに頼む中身になります。どちらか片方だけ作っても、頼む内容は決まりません。

As-Is（現状）は、良い悪いを言わずに今の動きを書く

As-Is は「今、実際にこう動いている」をそのまま書きます。マニュアルに書いてある手順ではなく、担当者が本当にやっている手順です。

ここで「この作業は無駄だ」と評価を入れると、現場の人が本当のことを話さなくなります。評価は To-Be を決めるときまで取っておきます。

To-Be（あるべき姿）は、理想ではなく「次に目指す形」

To-Be は、5年後の理想像ではありません。次のシステム化で実現する形です。

理想を描きすぎると、費用も期間も膨らみ、社内の合意が取れません。「今より手作業がこれだけ減る」と言える範囲に絞ります。

差（ギャップ）が、システムに頼む中身になる

As-Is と To-Be を並べると、変わる所と変わらない所が見えます。変わる所だけが、開発会社に説明する内容です。

この差が書けていれば、相談の場で「何をしたいのか」を一から説明しなくて済みます。見積もりの精度も上がります。

次の章から、As-Is を作る2つの道具（棚卸し表と業務フロー）の作り方に入ります。

業務の棚卸しのやり方：表1枚に、6つの列で書き出す

業務の棚卸しは、表1枚に6つの列で足ります。図を描く前に、まず表です。表があれば、どの業務のフローを描くべきかが決まります。

書く列は6つ：増やすほど埋まらない

次の6つに絞ります。

「回数×かかる時間」で、どの業務に手間が集中しているかが見えます。ここが To-Be で先に手を付ける所の候補になります。

聞く相手は、実際に手を動かしている人

棚卸しでは、管理職の記憶ではなく、担当者の机の横で聞きます。管理職が知っている手順と、現場の手順は違うことが多いからです。

このとき「この業務、どこから始まってどこで終わりますか」「この作業、なくなったら困りますか」の2つを必ず聞きます。現場に何を聞くかの詳しい進め方は、要件定義のヒアリングで使う質問7項目のシート例で解説しています。

細かさは「人が替わっても同じ手順でできる」単位まで

「受注処理」では大きすぎ、「注文書の2行目を確認する」では細かすぎます。目安は、新しく入った人がその行を読めば、同じ手順でできる単位です。

この単位でそろえると、表の行数が業務の量と合い、あとでフローを描くときに1行が1つの箱になります。

業務フローの作り方：現状（As-Is）を1本だけ描く

業務フローは、棚卸し表でいちばん手間が集中している業務を1本だけ描きます。1本描けば、残りは相談しながら増やせます。

ステップ①：範囲を決める（始まりと終わりを1つずつ）

「お客さまの注文が届く」から「入金を確認する」まで、のように始まりと終わりを1つずつ決めます。ここが決まっていないと、例外の流れで図が広がります。

例外は描きません。「月末だけ違う」のような流れは、図の外にメモで残します。

ステップ②：担当ごとに横の帯を作り、左から右に並べる

紙でもスプレッドシートでも構いません。担当者ごとに横の帯（レーン）を作り、作業の箱を左から右へ時間の順に置きます。

帯をまたぐ矢印が、部署間の受け渡しです。受け渡しの所で、紙やメールで情報が形を変えていないかを見ます。

ステップ③：手作業・紙・転記に印を付ける

箱のうち、人が手で打ち直している所、紙に出している所、同じ内容を別の道具に写している所に印を付けます。

この印の付いた箱が、システム化で減らせる候補です。印の数を数えるだけで、To-Be の話が具体的になります。

ステップ④：困っている所を、その場に書き込む

「ここで毎月間違いが出る」「この確認に半日かかる」のような困りごとを、該当する箱の横に書きます。棚卸し表の「困りごと」の列と同じ言葉を使います。

きれいな図は要りません。印と困りごとが書いてある1枚があれば、相談の場でそのまま使えます。

To-Be の決め方：差を「なくす・自動化する・残す」に分ける

To-Be は、現状フローの箱を1つずつ「なくす・自動化する・残す」のどれかに分けて作ります。全部をシステムにしないことが、費用を抑え、現場に受け入れられる To-Be の条件です。

なくす：誰も使っていない作業は、システム化より先に消す

棚卸しで「なくなったら困りますか」と聞いたとき、答えに詰まった作業があるはずです。誰も見ていない報告書、念のための二重チェック。これは自動化するのではなく、やめます。

やめる作業をシステム化すると、無駄をそのまま高い費用で固定してしまいます。

自動化する：転記・集計・通知は、システムが得意

ステップ③で印を付けた箱のうち、同じ内容を別の道具に写す作業、数字をまとめる作業、決まった相手に知らせる作業は、システム化の効果が出やすい所です。

この3種類だけを To-Be の候補にしても、頼む中身として十分です。

残す：人の判断や、業界で決まった流れは変えない

見積もりの金額を決める、取引先ごとに対応を変える。こうした判断は人に残します。

業界の商習慣で決まっている流れも、無理に変えると現場が回らなくなります。「残す」と決めることも To-Be の一部です。

業務の流れそのものを見直してから道具を選ぶ進め方は、BPR（業務の作り直し）から始める DX の進め方で解説しています。

始める前に知っておきたい注意点とコツ

As-Is／To-Be がうまくいかないのは、順番が逆になるときです。道具を先に選ぶ、今の画面に合わせて描く、頭の中の手順を拾わない。この3つを避けます。

道具（ツール）を先に選ばない

「このツールを入れたいので、業務を合わせて整理する」という進め方では、差が見えないまま道具が決まります。

道具を決めるのは、差が「なくす・自動化する・残す」に分かれたあとです。自動化する箱の数と中身が決まれば、既製のサービスで足りるか、作る必要があるかも見えてきます。

今のシステムの画面に合わせて描かない

As-Is を描くとき、今のシステムの画面の順番をなぞってしまうことがあります。それはシステムの流れであって、業務の流れではありません。

人が何を決め、何を誰に渡しているかで描きます。画面の順番は、あとから変えられます。

担当者の頭の中にしかない手順を拾う

「この取引先は電話で確認してから進める」のような手順は、マニュアルにも画面にもありません。担当者が辞めると消える手順です。

棚卸しで担当者の横に座る理由は、ここにあります。頭の中の手順を As-Is に書き出せた時点で、属人化の対策が半分進んでいます。

今のシステムの中身が分からないなら、それも As-Is に書く

既存のシステムが何をしているか分からない、作った人がもういない。これも立派な現状です。「中身が分からない」と As-Is に書いておけば、相談先はそこから調べる前提で進め方を組めます。

中身が分からなくなったシステムをどう解きほぐすかは、システムのブラックボックス化と属人化の原因・解消の方法で解説しています。

どこまで自社で作ってから相談するか

自社で作るのは棚卸し表と現状フロー1本まで。To-Be と要件は、相談先と一緒に作ります。ここを分けておくと、自社の手間が減り、相談先の提案も具体的になります。

自社で作る：棚卸し表と、現状フロー1本

この2つは、社内の人にしか作れません。開発会社が外から見ても、担当者の頭の中の手順や、本当の困りごとは分からないからです。

この2つがあれば、相談の初回から「どこを変えるか」の話に入れます。

一緒に作る：To-Be と、変える順番

To-Be は、何がシステムで実現できて、何にいくらかかるかを知っている人と一緒に作ったほうが早く決まります。「なくす・自動化する・残す」の分け方を、技術の目で確かめてもらう場です。

変える順番も、ここで決めます。全部を一度に変えず、手間の集中している所から始めます。

相談先に任せる：要件定義書と提案依頼書

To-Be が決まれば、それをシステムの言葉に直すのは相談先の仕事です。要件定義書（何を作るかを決めた文書）や、複数の開発会社に見積もりを頼むための提案依頼書（RFP）は、自社で一から書く必要はありません。

発注する側が要件定義で何を決め、どこで失敗しやすいかは、要件定義とは何か、要件定義書の10項目と記入例で解説しています。

効果は何で測るか：手作業の時間と転記の回数

効果は、棚卸し表の「回数×かかる時間」と、フローで印を付けた手作業の箱の数で測ります。システムを入れる前にこの2つを記録しておけば、入れたあとに同じ物差しで比べられます。

「業務が楽になった」という感想ではなく、減った時間と減った転記の数で社内に報告できます。

DX の相談を支援会社・開発会社のどこに持ち込むか、外に任せる範囲をどう決めるかは、DX支援はどこに頼むか、支援会社と開発会社の使い分けで解説しています。

まとめ：表1枚とフロー1本から始める