As-Is/To-Beとは｜基幹システム刷新での業務分析の進め方と書き方の例

As-Is/To-Beは、現状（As-Is）と将来の姿（To-Be）を並べ、その差を「誰が・何を変えるか」という施策に落とすための整理法です。基幹システム刷新で効くのは、現状をきれいに図にすることではなく、「現象→原因→To-Be→施策」を1行でつなげて書くことです。この記事では、As-Is/To-Be分析の進め方、調査票と記入例、「今と同じでいい」の扱い方を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

As-Is/To-Beとは：現状と将来の差を「施策」に変える作業

As-Isは「今どうなっているか」、To-Beは「刷新後にどうなっているべきか」です。As-Is/To-Be分析は、この2つを同じ切り口で並べ、差（ギャップ）を埋めるために何をするかを決める作業を指します。基幹システムの刷新では、構想策定と要件定義の間に置かれることが多い工程です。

この工程を軽く扱うと、どこで苦しくなるかは調査データにも表れています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書2026」では、システム開発の品質・予算・工期が予定どおりにならなかった要因として、「想定以上の現行業務・システムの複雑さ」が品質で48.8％、予算で51.4％、工期で48.8％にのぼりました。同じ調査で、QCDの悪化に影響した工程として「要件定義」を挙げた割合は57.4〜69.0％です。この調査は上場企業を中心とした回答ですが、現状の複雑さを読み違えたまま要件を決めると後工程で崩れる、という構図は企業規模を問いません。

一方で、As-Isの調査そのものが目的になると、分厚い現状報告書ができるだけで何も決まりません。IPA（情報処理推進機構）の「実務に活かすIT化の原理原則17ヶ条」は、原理原則14として「今と同じ」という要件定義はありえないと掲げ、現行システムは機能だけでなく「どう使っているか」まで調べるよう求めています。As-Isは「使われ方」を知るために調べ、To-Beは「何を変えるか」を決めるために書く。この役割分担を最初に押さえておきます。

似た言葉との違いも整理しておきます。As-Is/To-Beは「自社の業務をどう変えるか」を決める作業で、製品はまだ前提にしません。フィットアンドギャップ分析は、決めたTo-Beと製品の標準機能を突き合わせる作業です。要件定義は、To-Beとギャップへの対応方針をもとに、システムで実現する内容を文書にして合意する作業です。この順番が入れ替わると、製品の画面に業務を合わせるだけの刷新になったり、逆に製品で実現できないTo-Beを描いてしまったりします。

全体の流れの中での位置づけは基幹システムの構想策定、要件定義の手順は要件定義の進め方で解説しています。

As-Is/To-Beで整理する5つの層

As-Is/To-Beは業務フローだけの話ではありません。基幹システムでは、次の5つの層で現状と将来を並べると抜けが減ります。すべてを同じ深さで調べる必要はなく、刷新の目的に近い層ほど厚く書きます。

中小企業で抜けやすいのは3と5です。業務フローは描いても、「得意先別の掛率表はどのExcelが正か」「値引きは誰の判断で決まっているか」が書かれていないと、To-Beで決めるべき論点が見えません。稼働後に「数字が合わない」「承認が止まる」といった形で表に出る問題は、この2つの層の決め漏れから起きることが少なくありません。

刷新の目的によって、厚く書く層を変える

5つの層のどれを厚くするかは、刷新の目的で決まります。たとえば「月次決算を早めたい」が目的なら、情報の層（売掛・買掛の残高をどこで持っているか）と、組織・ルールの層（締め日、承認の順番）を厚く調べます。「受注から出荷までのリードタイムを縮めたい」なら、業務の層で件数と待ち時間を細かく押さえます。「老朽化したオフコンを入れ替えたい」が出発点の場合は、システムの層で連携と手作業の箇所を洗い出し、そのうえで業務の層の例外処理を確認します。

目的が複数あるときは、経営と優先順位を1つに決めてから調査を始めます。全部を同じ深さで調べると、調査の期間だけが延び、To-Beの議論に使える時間が減ります。

As-Is調査の進め方：誰に・何を・どこまで聞くか

As-Is調査は、部門長へのヒアリングだけでは足りません。部門長が把握している業務と、担当者が実際にしている作業には差があるからです。主要業務ごとに、部門長1人と実務担当者1〜2人の両方から話を聞くのが基本です。

調査票に入れる12項目

ヒアリングの前に、業務ごとに次の項目を埋める調査票を配っておくと、当日は例外処理の深掘りに時間を使えます。

※記入例は説明用の例です。

この12項目のうち、もっとも価値があるのは「件数」「時間」「例外処理」「やめられない理由」の4つです。件数と時間がわかれば、To-Beの効果を数字で見積もれます。例外処理とやめられない理由は、ERPの標準機能に合わせられるかどうかの判断材料になります。標準機能との比較はフィットアンドギャップ分析で行います。

どこまで細かく調べるか

As-Is調査の粒度は、「1つの作業が1人の担当者の、ひと続きの操作になる」程度で止めます。画面のボタン操作まで書き出す必要はありません。それより、同じデータを何回入力・転記しているかを数えるほうが、To-Beの効果が大きい箇所を見つけやすくなります。業務フローの描き方と粒度の決め方は業務フローの書き方で詳しく扱っています。

ヒアリングで使う6つの質問

「業務の流れを教えてください」と聞くと、多くの担当者は正常な流れだけを説明します。例外や判断は、質問の形を変えないと出てきません。次の6つは、どの業務にも使える聞き方です。

• 「昨日の作業を、朝から順に教えてください」：一般論ではなく、実際の1日を聞くと、手順の抜けや転記が見えます。
• 「この作業ができないと、誰が困りますか」：後工程と、その作業が存在する理由がわかります。
• 「いつもと違う処理をするのは、どんなときですか」：特定の得意先、月末、繁忙期、返品などの例外が出てきます。
• 「最近あったミスと、その直し方を教えてください」：手戻りの手順と、チェックの仕組みの弱い箇所がわかります。
• 「あなたが休んだら、誰が代わりにやっていますか」：属人化の度合いがわかります。代わりがいない作業は優先して文書にします。
• 「このExcelは、誰が見ていますか」：台帳の利用者と、二次加工の流れがわかります。IPAの原理原則が求める「使われ方」の調査にあたります。

課題からTo-Beを導く書き方：4列の分析表

As-Isを調べたあと、To-Beを「あるべき姿」として白紙から描こうとすると、抽象的な理想像になりがちです。おすすめは、As-Isで見つかった現象を起点に、現象→原因→To-Be→施策の4列で1行ずつ書く方法です。施策の列には、システムでやること・運用でやること・ルールでやることを分けて書きます。

次の表は、従業員80名・2拠点（本社倉庫と営業所）の食品卸を例にした分析表の抜粋です。

※説明用の例です。実際の分析表では、各行に効果（削減時間など）と優先度を加えます。

この表の書き方で大事なのは3点です。

• 原因の列を空けない：現象から直接To-Beを書くと、「在庫が合わない→在庫が合う」のような裏返しの文になります。原因を書くと、打ち手が具体的になります。
• 施策の区分を分ける：システムで解決すること、運用やルールの変更で解決することを分けて書きます。すべてをシステムで解決しようとすると、アドオン（追加開発）が増えます。
• To-Beに数字を入れる：「締めを早くする」ではなく「月次の締めを3営業日に短縮する」のように書くと、稼働後に効果を確かめられます。

To-Beの効果を数字で見積もる

調査票で件数と時間を押さえておくと、To-Beの効果を簡単な掛け算で示せます。上の食品卸の例で、単価マスタの一元化を見積もると次のようになります。

• 受注1件あたりの入力時間：As-Isは約3.2分（単価のExcel参照を含む）、To-Beは約2.2分（単価は自動で引く）。差は1件あたり約1分です。
• 1日の受注件数：約150件で変わりません。
• 1か月（20営業日）の入力時間：As-Isは約160時間、To-Beは約110時間。差は約50時間です。
• 単価誤りによる訂正：As-Isは月に十数件（1件30分程度）、To-Beでは原則なくなり、月に数時間が浮きます。

※説明用の例です。実際には、繁忙期の件数や、訂正にともなう得意先への連絡の手間も加えて見積もります。

この程度の粗い数字でも、施策の優先度を決めるには十分です。効果を時間で示すと、経営会議で「その機能は本当に必要か」と問われたときにも答えられます。逆に、効果の数字が出せない施策は、To-Beの記述がまだ抽象的だという合図です。

To-Beの書き方でよくある失敗と書き直し例

To-Beの記述で起きやすい失敗は、読む人によって受け取り方が変わる書き方です。要件定義書にそのまま引き継がれるため、この段階で直しておきます。

「今と同じでいい」をどう扱うか：現行踏襲の判定表

As-Is/To-Beの議論では、たいてい「ここは今と同じでいい」という声が出ます。これを全部受け入れると、刷新の意味がなくなります。全部断ると、現場の協力が得られません。IPAの「システム再構築を成功に導くユーザガイド 第2版」（2018年）は、現行と同じにするかどうかの対応方針として、「現行踏襲しない」「現行踏襲しない（運用を変更する）」「コストと時間をかけて現行踏襲を実現する」の3通りを示しています。同ガイドは、「現行踏襲」の中身があいまいなためにベンダ企業がそれを認識できず、テスト工程になって初めて実現できていないと分かる問題を挙げています。

この3通りを、中小企業の基幹システム刷新で使いやすい判定表に置き換えると次のようになります。

※判定表は説明用に整理したものです。実際の判断は、影響範囲と費用を見たうえで決裁者が行います。

判定で「現行を維持」となったものも、何を維持するのかを要件定義書に書きます。IPAの同ガイドは、現行踏襲の内容は設計ドキュメントに仕様として明記し、それを正とすることを関係者で合意しておくよう勧めています。「今と同じ」とだけ書いた要件は、作る側にとっては中身のない要件です。

判定表の2行目にある「相手と交渉する」は、中小企業では後回しにされがちな施策です。得意先指定の伝票やEDIの形式は、こちらから標準の様式を提案すると受け入れられることもあります。交渉の結果が出るまで帳票の追加開発を保留にしておき、要件定義の締め切りまでに結論を出す、という段取りにしておくと、不要な開発を避けられます。

なお、維持すると決めた処理の一覧は、稼働前のテストでも使います。現行と新システムで同じ結果になるかを確かめる対象がはっきりするからです。要件定義書の書き方は要件定義書の書き方を参照してください。

As-Is/To-Be分析の進め方：5つのステップ

1. 刷新の目的と調査範囲を決める
   経営と「何の数字を変えたいか」を確認し、調べる業務の範囲を決めます。範囲外の業務は、名前だけ一覧に載せておきます。後から「その業務も対象だと思っていた」という話を防げます。
2. 業務一覧と調査票を作る
   受注・出荷・請求・購買・在庫・会計などの業務を一覧にし、業務ごとに12項目の調査票を配ります。この時点で、Excel台帳や紙の帳票も集めます。
3. ヒアリングとAs-Isの図にする
   部門長と実務担当者の両方に話を聞き、業務フローと帳票一覧を作ります。描いた図は担当者に見せ、「実際はこうではない」という指摘を受けて直します。
4. 4列の分析表でTo-Beを書く
   現象→原因→To-Be→施策の順に1行ずつ書き、施策をシステム・運用・ルールに分けます。効果の大きさと実現の難しさで優先度をつけます。
5. 決裁者と合意し、要件定義へ渡す
   現行踏襲の判定結果も含めて、決裁者が承認します。承認されたTo-Beが要件定義の入力になり、製品の候補選びにも使われます。

ステップ3で手間がかかるのは、Excel台帳の扱いです。台帳ごとに「誰が作り、誰が見て、どこから転記しているか」を書き出しておくと、To-Beで正とするデータと、移行時に整理するマスタが見えてきます。マスタやコードの整理はマスタデータ整備とコード体系の決め方で解説しています。

To-Beを書き終えたら確認する10のチェックポイント

• 刷新の目的が、変えたい数字と目標値で書かれている
• 主要業務ごとに、件数と所要時間が把握できている
• 部門長だけでなく、実務担当者からも話を聞いている
• 例外処理（特定の得意先・月末・繁忙期）が洗い出されている
• Excel台帳と紙の帳票が一覧になり、正とするデータが決まっている
• 分析表の全行で「原因」の列が埋まっている
• 施策がシステム・運用・ルールに分けて書かれている
• To-Beが製品名ではなく、業務の状態で書かれている
• 「今と同じ」とされた項目に、維持する中身が書かれている
• To-Beを決裁者が承認し、承認日と範囲が記録されている

よくある質問

まとめ

As-Is/To-Beは、現状と将来を並べて終わりではなく、その差を施策と担当にまで落とすための整理法です。As-Isでは件数・時間・例外・やめられない理由を押さえ、To-Beは「現象→原因→To-Be→施策」の4列で書く。「今と同じでいい」には判定表で答え、維持する中身を要件定義書に残す。この3つを押さえると、要件定義と製品選定の議論が具体的になります。

自社の場合、どの業務からAs-Is/To-Beを整理すべきかわからないという方は、無料診断で現状の課題と、最初に手をつける範囲を整理できます。