As-Is/To-Be分析は、現状の業務（As-Is）と、あるべき業務の姿（To-Be）を並べて比べ、その差分から「システムで実現すること」と「運用やルールを変えること」を決める方法です。業務システムの要件を固める場面で使うと、現状の手順をそのままシステムに写してしまう失敗を防ぎ、システム化の効果を最大にできます。
この記事は、業務システムの導入や刷新を控えて要件を整理している担当者、または業務改善のプロジェクトでAs-Is/To-Be分析を任された方に向けて書いています。分析の目的、As-Isの把握の範囲と深さ、To-Beの描き方、差分を要件と運用変更に振り分ける手順、分析が空回りする原因と対策を、架空の例を交えて説明します。
要点を先にまとめると、As-Isは「事実」を集めることに徹し、To-Beは「目的」から描き、両者の差分を一つずつ「誰が、何を変えれば埋まるのか」に分解することが分析の中心です。To-Beを描く段階で理想を広げすぎず、実現の順番まで含めて決めることが、分析を要件定義につなげるための鍵になります。
As-Is/To-Be分析とは何か
As-Isは「現在あるがまま」、To-Beは「あるべき姿」を意味します。業務改善やシステム導入の文脈では、次のような手順で使われます。
- As-Is：現状の業務の流れ、担当、使っている帳票やシステム、所要時間、課題を把握する
- To-Be：目的を達成するために、業務がどうなっているべきかを描く
- ギャップ：As-IsとTo-Beの差分を洗い出す
- 施策：差分を埋めるために、システムの機能、業務ルールの変更、組織や役割の変更などの施策を決める
この方法の価値は、システムの要件を「現場の要望の寄せ集め」ではなく「目的とのギャップ」から導けることにあります。現場の要望をそのまま集めると、現在の手順を前提にした要望になりがちで、非効率な手順がシステムの中に固定されてしまいます。業務の流れそのものを根本から見直す考え方はBPR（ビジネスプロセス・リエンジニアリング）とも呼ばれますが、As-Is/To-Be分析はその規模の大小を問わず使える基本の進め方です。
なぜ現状業務をそのままシステム化してはいけないのか
現状の業務をそのままシステムに置き換えると、一見すると現場の混乱が少なく、受け入れられやすいように思えます。しかし、次のような問題が起きます。
- 紙やExcelの制約から生まれた手順が残る：たとえば「印刷して押印して回覧する」という手順は、紙で承認の記録を残すために生まれたものです。システムで承認の記録が残せるなら、その手順をそのまま画面で再現する必要はありません。
- 二重チェックや転記がそのまま残る：過去のミスへの対策として追加された確認作業が、システムの入力チェックで不要になっても、手順として残り続けます。
- 例外のための手順が標準になる：一部の取引先のための特別な処理が、全件に適用される手順になっていることがあります。
- 改善の機会を逃す：システム導入は業務の流れを変える数少ない機会です。現状を写すだけでは、費用をかけた割に効果が小さくなります。
一方で、現状を無視して理想だけを描くのも危険です。現場の事情や法令上の要件、取引先との約束など、現状の手順には理由があることも多いからです。As-Is/To-Be分析は、この「現状の理由」と「あるべき姿」を突き合わせる作業です。
分析を始める前に、誰が分析を進め、誰が結果を承認するのかも決めておきます。推進担当がAs-Isの調査とTo-Beの原案作りを担い、現場の代表者が内容を確認し、責任者が最終的に承認する、という分担が一般的です。承認者が決まっていないと、To-Beの議論がいつまでも収束しません。
As-Isの把握：どこまで、どの深さで調べるか
As-Isの把握では、事実を集めることに徹します。この段階で「こうすべき」という議論を始めると、事実の収集が中途半端になります。
調べる範囲を決める
まず、分析の対象とする業務の範囲を、始まりと終わりの出来事で決めます。範囲が広すぎると分析が終わらず、狭すぎると前後の業務との関係を見落とします。システム化の対象として想定している業務に加え、その前後で情報を受け渡している業務までを含めるのが目安です。
集める情報
| 項目 | 内容 | 集め方 |
|---|---|---|
| 業務の流れ | 作業と判断の順番、担当者 | ヒアリング、業務フロー図の作成 |
| 帳票・データ | 使っている書類、ファイル、システムの画面と項目 | 実物の収集 |
| 量と時間 | 件数、作業時間、待ち時間、繁閑の波 | 担当者への聞き取り、記録の確認 |
| ルール | 判断の基準、承認の条件、締め日 | 規程・マニュアルの確認、聞き取り |
| 課題 | ミス、手戻り、問い合わせ、担当者の負担 | 聞き取り、過去のトラブル記録 |
| 手順の理由 | なぜその手順になっているのか | 担当者や管理者への聞き取り |
この中で見落とされがちなのが、最後の「手順の理由」です。「なぜこの確認をしているのか」「なぜこの帳票を作っているのか」を聞いておくと、To-Beを描くときに「なくしてよい手順」と「形を変えて残すべき手順」を区別できます。理由が誰にも分からない手順は、見直しの有力な候補です。
業務の流れの図にまとめる方法は、業務フロー図の書き方：システム化の前に現状を可視化する手順で詳しく説明しています。
To-Beの描き方：目的から逆算する
To-Beは、現場の要望を集めて描くものではなく、目的から逆算して描くものです。
- 目的を決める：システム化や業務改善で何を達成したいのかを、具体的な状態として書きます。「業務を効率化する」ではなく、「受注から出荷指示までを当日中に完了できる」「担当者が休んでも見積もりの進捗が分かる」のように書きます。
- 目的に照らして、As-Isの各作業を見直す：各作業について、「なくせないか」「まとめられないか」「順番を入れ替えられないか」「簡単にできないか」を検討します。この観点はECRS（改善の4原則）として知られています。
- 新しい業務の流れを描く：見直しの結果を反映した業務の流れを、As-Isと同じ形式の図で描きます。形式をそろえることで、差分が比較しやすくなります。
- システムの役割を書き込む：To-Beの流れの中で、システムが行うこと（自動計算、通知、データの受け渡し）と、人が行うこと（判断、例外対応）を区別して書き込みます。
- 制約を確認する：法令、取引先との契約、社内規程、予算、期間など、To-Beの実現を制約する条件を確認し、現実的な姿に調整します。
To-Beを描くときの注意
To-Beは理想を描く場ですが、理想を広げすぎると実現できない計画になります。「最終的に目指す姿」と「最初のリリースで実現する姿」を分けて描く方法が有効です。最終的な姿を見据えつつ、最初の段階では効果の大きい部分に絞ることで、要件を現実的な範囲に収められます。
また、To-Beは現場の担当者と一緒に描くことが重要です。管理者や推進担当だけで描いたTo-Beは、現場の事情を見落としていることが多く、導入後に「現実には回らない」という反発を招きます。
ギャップを要件と運用変更に振り分ける手順
As-IsとTo-Beが描けたら、その差分を一つずつ洗い出し、どう埋めるかを決めます。ここが分析の中心です。
- ギャップを一覧にする：As-IsとTo-Beを並べ、作業、担当、帳票、ルール、量・時間の各観点で違いを書き出します。
- ギャップの種類を分類する：システムで埋めるもの、業務ルールの変更で埋めるもの、組織や役割の変更で埋めるもの、教育で埋めるものに分けます。
- システムで埋めるギャップを要件にする：「誰が」「どの場面で」「何をできるようにするか」の形で書き直し、要件一覧に載せます。
- 運用で埋めるギャップに担当と期限を付ける：ルールの変更や役割の変更は、誰が決めていつまでに実施するかを決めます。システムの完成を待たずに実施できるものも多くあります。
- 優先順位を付ける：目的への効果、実現の難しさ、依存関係（このギャップを埋めないと次が進まない）を基準に、実施の順番を決めます。
- 関係者と合意する：ギャップと施策の一覧を、管理者と現場の代表者に確認してもらい、合意したものを要件定義に引き継ぎます。
ギャップの振り分けで特に重要なのは、システムで埋める必要のないギャップを見極めることです。ルールを一つ決めれば解消するギャップを、システムの機能で吸収しようとすると、開発費用が膨らみ、画面も複雑になります。
ギャップ一覧の例
| As-Is | To-Be | ギャップの種類 | 施策 |
|---|---|---|---|
| 注文内容をメールからExcelに転記 | 注文フォームの内容がそのまま受注データになる | システム | 注文フォームと受注データの連携 |
| 金額にかかわらず部長が承認 | 一定額以上のみ承認 | ルール | 承認基準の改定（規程の変更） |
| 承認は押印した紙で回覧 | 画面上で承認し、記録が残る | システム | 承認機能と履歴 |
| 在庫確認を倉庫に電話で依頼 | 受注担当が画面で在庫を確認 | システム＋役割 | 在庫照会機能、倉庫との役割分担の見直し |
| 新人は先輩の横で手順を覚える | 手順書と画面のガイドで覚えられる | 教育 | 手順書の整備、操作研修 |
このように整理すると、システムの要件と、システム以外で進めるべき施策が分かれ、開発の範囲が適切に絞られます。決まった要件は、要件定義書の書き方：発注側が埋めるべき項目とテンプレートの使い方を参考に文書化します。
架空の例：経費精算の見直し
ある中小企業で、経費精算の業務を見直すことになったとします。As-Isを調べると、社員が紙の申請書に領収書を貼り、上長が押印し、経理が内容を確認して会計ソフトに手入力している、という流れでした。経理の確認作業には、申請書の記載と領収書の突き合わせ、勘定科目の判断、記入漏れの差し戻しが含まれ、月末に作業が集中していました。手順の理由を聞くと、上長の押印は「内容の妥当性の確認」、経理の突き合わせは「金額の誤りを防ぐため」でした。
To-Beでは、「経理の月末の作業を平準化し、差し戻しを減らす」を目的に置きました。社員がスマートフォンで領収書を撮影して申請し、金額や日付は入力時にチェックされ、上長は画面で承認し、承認済みのデータが会計ソフトに連携される流れを描きました。ギャップを分類すると、申請・承認・連携はシステムで埋めるもの、勘定科目の判断基準を一覧にするのはルールで埋めるもの、一定額以下は上長承認を省略するかどうかは規程の見直しで判断するもの、に分かれました。経費精算は共通の業務であるため、システムで埋めるギャップについては個別開発ではなく既製のサービスの導入を前提に検討することになりました。パッケージやサービスと業務のずれを確認する進め方は、パッケージ導入のフィット＆ギャップ分析：カスタマイズを減らす方法で扱っています。
なお、経費精算のように電子帳簿保存などの制度が関わる業務では、To-Beを描く際に、制度上の要件を公的機関の情報や税理士などの専門家に確認することが欠かせません。
To-Beを導入計画と移行期間につなげる
To-Beとギャップ一覧ができても、それだけでは業務は変わりません。As-IsからTo-Beへどう移るか、その途中の期間をどう過ごすかまで計画しておく必要があります。
まず、ギャップを埋める施策の順番を決めます。ルールや役割の変更のうち、システムの完成を待たずに実施できるものは先に始めます。たとえば承認基準の改定や、判断基準の一覧化は、システムがなくても効果が出ます。先に運用を変えておくと、システム導入時に変わる部分が少なくなり、現場の負担が分散されます。
次に、システムの導入後しばらくの間、As-IsとTo-Beが混在する期間をどう扱うかを決めます。一部の部署だけ先に新しい流れに移る場合、部署間で受け渡すデータの形式が違うことになります。旧帳票と新システムの両方からデータを集める必要がある期間、誰がどのように突き合わせるかを決めておかないと、移行期間に混乱が起きます。過去のデータを新システムに移すのか、旧システムで参照できるようにしておくのかも、この段階で決めます。
最後に、To-Beが実現したかどうかを確かめる指標を決めます。目的を具体的な状態として書いておけば、その状態になっているかを測る方法も決めやすくなります。「当日中に出荷指示まで完了した件数の割合」「差し戻しの件数」「月末の残業時間」など、As-Isの段階で測っておいた数値と比べられるものを選びます。導入後に数値を比べることで、分析で描いたTo-Beが実際に実現したのか、どこにまだギャップが残っているのかが分かり、次の改善の手がかりになります。
分析が空回りする原因と対策
As-Is/To-Be分析は、進め方を誤ると時間をかけた割に要件につながらない作業になります。よくある原因と対策を挙げます。
- As-Isの調査に時間をかけすぎる：細部まで調べ尽くそうとして、何か月も調査が続くことがあります。To-Beを描くのに必要な深さは、目的によって決まります。目的に関係する部分を重点的に調べ、それ以外は粗く把握するにとどめます。
- To-Beが抽象的すぎる：「情報が一元化され、リアルタイムで共有される」のようなTo-Beは、要件に落とせません。誰が、どの場面で、何をするのかが分かる粒度まで具体的にします。
- To-Beが理想に寄りすぎる：予算や期間、現場の受け入れ能力を無視した姿を描くと、実現の段階で大幅に縮小され、分析の意味が薄れます。最初のリリースで実現する範囲を明確に分けます。
- ギャップをすべてシステムで埋めようとする：ルールや役割の変更で済むギャップまでシステムの要件にすると、開発範囲が膨らみます。ギャップの種類を分類する工程を省かないようにします。
- 現場を巻き込まない：推進担当だけで分析を進めると、現場の事情が抜け落ち、導入後に反発が起きます。As-Isの確認とTo-Beの検討の両方に、現場の代表者を参加させます。
- 分析の結果が共有されない：分析の資料が推進担当の手元にとどまり、開発会社や現場に伝わらないことがあります。ギャップ一覧を共通の資料として、要件定義と導入計画の両方で使います。
As-Is/To-Be分析のチェックリスト
- 分析の対象業務の範囲を、始まりと終わりの出来事で決めている
- As-Isで、業務の流れ、帳票・データ、量と時間、ルール、課題を把握している
- 主要な手順について「なぜそうしているのか」の理由を聞いている
- 目的を具体的な状態として書いている
- To-Beを、As-Isと同じ形式の図で描いている
- 最終的な姿と、最初のリリースで実現する姿を分けている
- ギャップを一覧にし、システム・ルール・役割・教育に分類している
- 運用で埋めるギャップに担当と期限を付けている
- 管理者と現場の代表者の合意を得ている
よくある質問
Q. As-Isの把握を省略して、いきなりTo-Beを描いてはいけませんか？
業務が単純で関係者が少ない場合は、To-Beから描き始めることもできます。ただし、現状の手順の理由を知らずにTo-Beを描くと、法令上必要な確認や取引先との約束を見落とすおそれがあります。少なくとも主要な手順とその理由だけは押さえてからTo-Beを描くことをおすすめします。
Q. To-Beは誰が決めるべきですか？
目的と優先順位は責任者が決め、具体的な業務の流れは現場の代表者と一緒に描くのが基本です。外部の支援者は、他の業務での一般的なやり方や、システムでできることの選択肢を示す役割を担います。
Q. 分析にはどのくらいの期間がかかりますか？
対象業務の範囲と関係者の数によって大きく変わります。目的に関係する部分に絞って進めれば、一つの業務領域であれば数週間程度で要件定義に引き継げる形にまとめられることもあります。調査が長引いている場合は、目的に照らして調べる深さを見直してください。
Q. パッケージを導入する場合もAs-Is/To-Be分析は必要ですか？
必要です。パッケージ導入では、To-Beの業務の流れをパッケージの標準的な流れに寄せることが多く、As-Isとの差分は大きくなりがちです。その差分を、パッケージの設定、業務の変更、周辺の開発のどれで埋めるかを判断するために、分析の結果が役立ちます。
Otsumuに相談できること
対象業務が一つの部署の中で完結していて、目的が明確な場合は、この記事の手順に沿って社内でAs-Is/To-Be分析を進めることができます。業務フロー図とギャップ一覧を作るところまでを社内で行い、その資料をもとにツールの選定や開発会社への相談に進むのが効率的です。
外部の力を借りた方がよいのは、部署をまたぐ業務で関係者の利害が分かれている、To-Beを描こうとしても目的が定まらない、ギャップをシステムで埋めるべきか運用で埋めるべきかの判断がつかない、といった場合です。業務とシステムの両方を見ながら、第三者の立場で論点を整理する役割が求められます。
Otsumuは、現状の把握から一緒に行い、目的から逆算してTo-Beを描き、ギャップを「作るもの」と「作らずに済むもの」に切り分けたうえで、必要な機能に絞った開発につなげます。業務システムの開発については業務システム開発のページをご覧ください。費用は範囲に応じて個別にお見積もりします。
分析をどこから始めればよいか迷っている段階でも構いません。30分の無料相談で、対象の業務と目的をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01