業務システムの刷新やAI組み込みを任されたとき、最初につまずきやすいのが「今の業務をどう整理し、どこを目指すのか」を言葉にする工程です。ここが曖昧なまま要件定義に進むと、ベンダーとの認識がずれ、完成したシステムが現場で使われない原因になります。

その整理に使われる代表的なフレームワークがAs-Is To-Beです。この記事では、As-Is To-Beの意味と関連用語との違い、業務システム刷新で使うときの手順、よくある失敗と防ぎ方を解説します。

この記事を読むと理解できること

• As-Is To-Beの意味と、ギャップ分析・Can-Be・Before/Afterとの違い

• As-Is To-Be分析が役立つ場面と、向いていない場面

• 業務システム刷新でAs-Is To-Be分析を進める6つの手順

• As-IsとTo-Beをどちらから描くべきかの判断基準

• ギャップを維持・新規・廃止に分けて抜け漏れを防ぐ方法

• As-Is To-Be分析でよくある失敗と、発注者が先回りできる対策

As-Is To-Beとは何か、ギャップ分析とどう違うのか

結論から言うと、As-Is To-Beは「現状」と「あるべき姿」を同じ物差しで並べ、その差を解決すべき課題に変換するためのフレームワークです。ギャップ分析は、その差を洗い出す工程そのものを指す言葉として使われることが多く、As-Is To-Beの中核の作業と考えると整理しやすくなります。

As-Isは現状、To-Beはあるべき姿

現状を表すAs-Isは「今どうなっているか」を示します。業務の流れ、担当者、使っているツール、処理にかかる時間、例外対応の頻度などを、評価を交えず事実として書き出したものです。

To-Beは「どうなっていたいか」を表します。目標とする処理時間やミスの件数といった数値と、「承認待ちで止まる案件がない」のような観察できる状態の組み合わせで書くのが基本です。

As-IsとTo-Beを並べたときに生まれる差がギャップです。このギャップを「誰が、何を、いつまでに変えるか」という行動の言葉に置き換えたものが、プロジェクトで取り組む課題になります。

似た用語との違い

As-Is To-Beの周辺には、意味の近い言葉がいくつかあります。社内やベンダーとの会話で混同しないよう、役割の違いを押さえておきましょう。

Before/Afterは施策の結果を振り返るための言葉で、As-Is To-Beは施策を計画するための言葉です。時間軸で見ると、As-Is To-Beで計画し、実行後にBefore/Afterで検証するという順につながります。

Can-Beは、To-Beが現状からあまりに遠いときに置く中間目標です。To-Beを捨てるのではなく、To-Beに向かう途中の到達点として期限とともに設定すると、現場の納得感を保ちやすくなります。

As-Is To-Be分析はどんな場面で必要になるのか

As-Is To-Be分析が最も効果を発揮するのは、業務の流れそのものを変える判断が必要な場面です。特に業務システムの刷新、業務改善、AIの組み込みでは、現状と目標を言語化しておかないと投資判断の根拠を説明できません。

業務システムの刷新

基幹システムや業務システムを入れ替えるとき、現状を整理しないまま要件を決めると、現行システムでひっそり処理されていた例外業務が新システムから抜け落ちます。一方、To-Beを描かずに進めると、古い業務をそのまま新しい画面に置き換えるだけの刷新になりがちです。

As-Is To-Beを描いておくと、どの業務を残し、どの業務を変え、どの業務をやめるのかを要件定義の前に合意できます。進め方の全体像は業務システム開発の進め方もあわせて参考にしてください。

業務改善とAIの組み込み

生成AIやAIエージェントを業務に組み込む場合も、As-Is To-Beは有効です。現状の業務で判断が発生している箇所を洗い出し、To-Beで「AIに任せる作業」と「人が確認する作業」を線引きすることで、導入後の責任範囲が明確になります。

As-Is To-Beが向いていない場面

一方で、原因不明の障害対応のように一刻を争う場面や、まだ業務プロセスが存在しない新規事業の立ち上げ期には、As-Is To-Beは向きません。前者は分析より復旧が優先であり、後者はそもそも比べるべき現状が存在しないためです。

新規事業の場合は、現状分析の代わりに想定顧客の行動を観察し、仮説としてのTo-Beを素早く検証するほうが適しています。手法を目的に合わせて選ぶことが、分析を形骸化させない第一歩です。

As-Is To-Be分析はどう進めればよいのか

As-Is To-Be分析は、テーマ設定からAs-Isの再測定までを1サイクルとして進めます。ここでは業務システム刷新を想定し、6つの手順に分けて解説します。

手順1 テーマと範囲、期限を決める

最初に「どの業務を、いつまでに、どこまで変えるか」を1文で決めます。たとえば「受注から出荷指示までの業務を、来期末までに手作業の転記なしで回せる状態にする」といった形です。

範囲を広げすぎると、現状調査だけで数か月が過ぎてしまいます。最初は部門をまたぐ1つの業務プロセスに絞り、成果を見せてから範囲を広げるほうが確実です。

手順2 To-Beを指標と状態で定義する

To-Beは「効率化する」「使いやすくする」といった形容詞で終わらせず、測定できる指標と観察できる状態の組で書きます。指標は処理件数、所要時間、差し戻し件数など、後で現状と同じ単位で比べられるものを選びます。

状態のほうは「担当者が不在でも承認が止まらない」「月末に残業が集中しない」のように、現場の人が見て判断できる表現にします。数値だけでは伝わらない目標を補う役割があります。

手順3 To-Beと同じ軸でAs-Isを測る

次に、To-Beで定めた指標と同じ軸でAs-Isを測ります。軸がずれると比較ができず、ギャップが見えなくなるためです。

現状の把握には、担当者へのインタビュー、実際の作業の観察、ログや工数データの確認を組み合わせます。インタビューでは「普段どうしていますか」ではなく「直近で困った案件はどう処理しましたか」と具体的な出来事を聞くと、例外処理や暗黙の手順が出てきやすくなります。

手順4 ギャップを課題文に変換する

As-IsとTo-Beを並べ、差を「〜する」という動詞で終わる課題文にします。「承認に時間がかかる」は現象の記述であり、「承認ルートを3段階から2段階に減らす」まで落とし込むと課題になります。

このとき、ギャップの原因を一段掘り下げることが重要です。承認が遅い原因が承認者の多さなのか、承認に必要な情報が画面にそろっていないことなのかで、打ち手はまったく変わります。

手順5 打ち手に優先順位をつける

洗い出した課題に対して打ち手を考え、効果の大きさと実行の難しさの2軸で並べます。効果が大きく実行しやすいものから着手し、早めに成果を見せることで関係者の協力を得やすくなります。

打ち手を選ぶときは、改善によって悪化しうる指標も書き添えておきます。入力項目を減らせば作業は速くなりますが、後工程で必要なデータが欠けるかもしれません。

手順6 実行後にAs-Isを測り直す

施策を実行したら、同じ指標でAs-Isを測り直します。新しい現状とTo-Beの差が次の課題になり、改善のサイクルが回り始めます。

ここまでの流れを1枚にまとめるには、次のようなテンプレートが便利です。

As-Isの列には評価ではなく事実を、To-Beの列には形容詞ではなく数値や状態を書くのがポイントです。表中の値は記入の仕方を示すための例で、実際の目標は自社の業務データから設定します。

As-IsとTo-Beはどちらから描くべきか

As-IsとTo-Beをどちらから描くかは、目的によって変わります。目標そのものを決めたい場合はTo-Beから、既存の業務やシステムを作り替える場合はAs-Isから始めるのが基本です。

To-Beから描くべきケース

中期計画や新しいサービスの方向性を決める場面では、To-Beから描きます。As-Isから始めると、現状の延長線上で「今より少し良い」程度の目標にまとまりやすいためです。

As-Isから描くべきケース

業務システムの刷新のように、既存の仕組みを置き換える場面ではAs-Isから描きます。現行業務を十分に理解しないままTo-Beを描くと、例外処理や法令対応のための手順を見落とし、新システムの稼働後に業務が回らなくなるおそれがあります。

システム刷新では両方向から挟み込む

実務では、どちらか一方に決めるより、両方向から挟み込む進め方が現実的です。まず経営層や事業責任者とTo-Beの方向性を短時間で合意し、その後にAs-Isを詳しく調べ、最後にTo-Beを現実に合わせて調整します。

FAKEが業務システムの刷新を支援するときも、現場に入り込んでAs-Isを画面操作や例外処理の単位まで観察し、To-Beは業務フロー図だけでなく画面のプロトタイプとして現場に見せながら合意を取ります。業務フローの矢印だけでは見えない「この画面でこの情報が足りない」という気づきが、To-Beの精度を上げるためです。

As-Is To-Be分析でよくある失敗と防ぎ方は

As-Is To-Be分析の失敗は、手法そのものより、書き方と進め方の癖から生まれます。発注者として特に注意したい4つのパターンと防ぎ方を整理します。

失敗1 As-Isがマニュアルの写しになる

業務マニュアルや規程をもとに現状を書くと、「本来こうなっているはずの業務」が並ぶだけで、現場の実態とずれます。実際には、マニュアルにない確認作業やExcelでの二重管理が日常的に行われていることが少なくありません。

防ぐには、担当者の作業を実際に横で見ることが一番です。観察が難しい場合でも、直近1か月の具体的な案件を1件ずつたどってもらうと、実態に近い現状の姿が得られます。

失敗2 To-Beが願望リストになる

「すべて自動化する」「ミスをゼロにする」といったTo-Beは、方向性としては正しくても、計画には使えません。測定できず、達成したかどうかを誰も判断できないからです。

To-Beが遠すぎると感じたら、Can-Beとして中間目標を置き、期限を添えます。最終形としてのTo-Beと、今期中に届くCan-Beを分けて示すと、現場の抵抗感も下がります。

失敗3 廃止される業務の検証が漏れる

ギャップを洗い出すときは、As-IsとTo-Beの要素を突き合わせ、維持するもの、新しく加えるもの、廃止するものの3つに分けると抜け漏れを防げます。中でも見落とされやすいのが廃止の区分です。

廃止に分類された業務が、意図した廃止なのか、To-Beに書き忘れただけなのかを必ず確認します。後者を見逃すと、新システムの稼働後に「あの作業はどこでやるのか」という混乱が起きます。

失敗4 現場の担当者が分析に参加していない

情シスやDX推進の担当者だけでAs-Is To-Beをまとめると、現場から「実態と違う」と反発されることがあります。分析の正しさ以上に、関係者が自分ごととして納得しているかが実行段階の成否を分けます。

最低限、As-Isの確認とTo-Beのレビューには現場の担当者に入ってもらいましょう。システムが現場で使われない構造的な理由はDXが失敗する構造でも解説しています。

ベンダーに渡すときの注意点

As-Is To-Beの成果物は、そのまま要件定義やRFPの土台になります。発注者側でAs-Isとギャップまで整理しておくと、ベンダーからの提案の質がそろい、比較もしやすくなります。

逆に、To-Beの実現方法までを発注者が細かく決めすぎると、ベンダーの知見を活かす余地がなくなります。RFPへの落とし込み方はRFPの書き方、上流から伴走できる依頼先の探し方は業務システム・DXに強い開発会社の選び方を参考にしてください。

まとめ

As-Is To-Beは、現状とあるべき姿を同じ物差しで並べ、その差を課題として行動に落とし込むフレームワークです。ギャップ分析はその中核の作業であり、Can-Beは途中の到達点、Before/Afterは実行後の検証に使う言葉として区別できます。

進め方は、テーマと期限の設定、To-Beの定義、同じ軸でのAs-Isの測定、ギャップの課題化、優先順位づけ、再測定の6つの手順が基本です。業務システムの刷新では、To-Beの方向性を先に合意し、As-Isを詳しく調べてからTo-Beを調整する挟み込みの進め方が現実的です。

失敗を防ぐ鍵は、As-Isを実際の作業から拾うこと、To-Beを測定できる言葉で書くこと、廃止される業務を検証すること、現場を巻き込むことの4点です。As-Is To-Beを丁寧に整理しておけば、その後の要件定義やベンダー選定の精度が大きく変わります。

As-Is To-Beに関するよくある質問

As-Is To-Beは日本語で何と言いますか

As-Isは「現状」、To-Beは「あるべき姿」や「理想像」と訳されるのが一般的です。社内資料では「現状とあるべき姿」と併記しておくと、用語に慣れていない関係者にも伝わりやすくなります。

As-Is To-Beとギャップ分析は同じものですか

完全に同じではありません。As-Is To-Beは現状とあるべき姿を描いて比べる枠組み全体を指し、ギャップ分析はその差を洗い出して課題にする作業を指すことが多いです。実務では一連の流れとしてまとめて扱われることもあります。

As-Is To-Be分析にはどのくらいの期間がかかりますか

対象範囲によって大きく変わるため、一律の期間は示せません。1つの業務プロセスに絞れば短期間で一巡できますが、部門横断の基幹業務を対象にすると現状調査だけで長期化しがちです。最初は範囲を絞り、主要な業務の大部分が見えた段階で次の工程に進むと停滞を防げます。

As-Is To-Beの成果物は何を作ればよいですか

基本は、現状と理想の業務フロー図、観点ごとにAs-Is・To-Be・ギャップ・課題を並べた一覧表、例外処理の一覧の3点です。業務システムの刷新では、To-Beの画面イメージや簡単なプロトタイプを加えると、現場とベンダーの双方で認識をそろえやすくなります。