AS-IS・TO-BEとは？IT・DX推進で使える書き方を3レイヤー法と記入例で解説

「要件定義で AS-IS と TO-BE を整理しなさい」と上司や開発会社から言われたものの、白紙のドキュメントを前に手が止まっていないでしょうか。フレームワークの名前は聞いたことがあっても、自社の業務にどう当てはめ、どの粒度で書けば開発会社に伝わるのかが分からず、最初の一行が書けない状態に陥る方は少なくありません。

特に IT・DX 推進の文脈で AS-IS / TO-BE を整理する際は、業務フローだけでなく、扱う情報・データ、現行システムやツールまで含めて「いまの姿」と「ありたい姿」を可視化する必要があります。汎用的な経営フレームワークとしての AS-IS / TO-BE 解説記事はたくさんありますが、「自社の受注管理業務をどう書けばよいか」「開発会社が読んだときに認識のズレが起きない記述になっているか」までを示してくれる記事は多くありません。

本記事では、IT・DX 推進プロジェクトで使える AS-IS / TO-BE の書き方を、次の流れで解説します。まず IT・DX 文脈での定義を 30 秒で押さえ、その後で AS-IS と TO-BE を「業務プロセス層」「情報・データ層」「システム・ツール層」の 3 レイヤーで書き分ける独自フレームを提示します。受注管理業務をミニケースとして実際の記入例を示し、ギャップから要件を導く手順、よくある失敗パターン、開発会社への共有方法までを 1 本で解説します。

読み終えた後、その日のうちに AS-IS / TO-BE のドラフトを書き始め、開発会社に「これでは判断できない」と言われない品質の資料を作れる状態を目指します。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

AS-IS・TO-BEとは？IT・DX推進で使う「現状」と「あるべき姿」

AS-IS（アズイズ）は「現状」、TO-BE（トゥービー）は「あるべき姿」を表す英語表現です。経営や業務改善の文脈で広く使われるフレームワークですが、IT・DX 推進プロジェクトで使う際は、扱うスコープが「業務」だけでなく「業務 + 情報・データ + システム」へ広がる点が大きな特徴です。

要件定義で AS-IS / TO-BE を整理する目的は、現状とあるべき姿の差分（Gap）を可視化し、その差分を埋めるための施策をシステム要件・業務変更・運用ルールへと振り分けることにあります。つまり、AS-IS と TO-BE は単独で完結する成果物ではなく、Gap とセットで初めて意味を持つ 3 点セットの分析ツールです（参考: As-Is・To-Beとは？IT 調達における頻出用語の意味と使い方について解説）。

AS-IS（現状の業務とシステムの姿）の意味

IT・DX 推進文脈での AS-IS は、「いま社内で実際に行われている業務と、それを支えているシステム・ツールの実態」を指します。重要なのは「実態」を書くことであり、「手順書に書かれている理想の運用」や「管理職が想像する現場の動き」ではない点です。

たとえば「受注管理業務」を AS-IS で整理するなら、受注メールがどの担当者にどの順で届き、誰がスプレッドシートにコピペし、どのシステムに転記し、誰の承認を経て出荷指示につながっているのか、という時系列の流れと、そこで使われている Excel ファイル名・共有フォルダのパス・SaaS の名称までを含めて書きます。

TO-BE（あるべき業務とシステムの姿）の意味

TO-BE は「DX 施策やシステム導入によって到達したい、業務とシステムの状態」を指します。AS-IS と同じ 3 レイヤー（業務プロセス・情報データ・システムツール）で書くことで、AS-IS との差分が比較しやすくなります。

TO-BE で陥りやすいのが「業務を効率化したい」「データを一元化したい」といったスローガン的な記述です。この段階で抽象度が高いまま固定すると、後工程の要件定義で開発会社に渡したときに「もう少し具体的に教えてください」と差し戻されることになります。後ほど解説する「成果から逆算する」「制約条件を併記する」「優先順位をつける」の 3 原則で、TO-BE の解像度を担保していきます。

Gap（差分）が要件定義の起点になる

AS-IS と TO-BE が同じレイヤーで整理されていれば、両者を並べたときに何が変わるべきか（Gap）が浮かび上がります。この Gap が、システムで何を実現すべきか、業務手順をどう変えるべきか、運用ルールをどう設計すべきかを決める起点になります。

ERP やパッケージシステム導入で使われる「Fit & Gap 分析」も、AS-IS / TO-BE が前提として存在することで初めて成立します（参考: Fit and gap 分析とは？目的から進め方までプロが徹底解説）。Gap が見えないまま「とにかく新しいシステムを入れる」と進めると、現場では「結局これまでと同じ手作業が残った」という状況に陥りやすくなります。

なぜIT・DXプロジェクトでAS-IS／TO-BE整理が必要なのか

「整理しろと言われたから書く」ではなく、なぜ自分が今これを書くべきなのかが腹落ちしていないと、ドキュメントの粒度がぶれます。AS-IS / TO-BE を IT・DX プロジェクトで整理する目的は、大きく 3 つに整理できます。

社内のステークホルダー間で認識を揃える

DX プロジェクトには、経営層・現場部門・情シス・経営企画など、立場の異なる関係者が関わります。それぞれが頭の中で描く「現状の課題」と「あるべき姿」は、同じ言葉で語っていても実は別物であることが少なくありません。

AS-IS / TO-BE を 1 枚の資料に落とすことで、「経営層が考える受注管理の現状」と「現場担当者が日々行っている受注処理の実態」のずれを発見できます。経済産業省の「DXレポート」でも、経営層と現場・IT 部門の認識ギャップが DX 推進の大きな障壁として指摘されています（参考: 産業界のデジタルトランスフォーメーション（DX）（経済産業省））。AS-IS / TO-BE はその認識ギャップを可視化し、議論のテーブルに乗せるための共通言語として機能します。

なお、要求と要件の使い分けに自信がない場合は、関連記事の要求定義と要件定義の違いも合わせて確認してください。AS-IS / TO-BE は「要求」を整理する段階、要件定義はそれを「システムで何をするか」に落とし込む段階という位置関係になります。

開発会社・ベンダーへの依頼の解像度を上げる

外部の開発会社にシステム開発を依頼する際、AS-IS / TO-BE がない状態で要件を伝えると、開発会社は「現在どんな業務が行われていて、それをどう変えたいのか」を毎回ヒアリングで再構築する必要が生じます。これは時間がかかるうえに、ヒアリングする担当者によって解釈が変わるリスクもあります。

AS-IS / TO-BE を整理した資料を渡すことで、開発会社は「自社が解決すべきはこの差分の部分である」と一発で理解でき、見積もり・提案の精度が大幅に上がります。一般社団法人日本情報システム・ユーザー協会の「ソフトウェア・メトリクス調査」でも、システム開発における要件定義工程は全体工数の十数〜数十パーセントを占める重要なフェーズとされています（参考: ソフトウェア・メトリクス調査 2025（JUAS））。AS-IS / TO-BE はその要件定義の前段としての投資です。

Fit & Gap・要件定義の土台になる

AS-IS / TO-BE は単独の成果物ではなく、後工程で次のように展開されます。

• Gap → システム要件 / 業務変更 / 運用ルールへの分類
• パッケージシステム導入の場合は Fit & Gap 分析の入力
• 要件定義書の「業務要件」「現行業務の概要」「目指す業務の姿」セクションの素材

要件定義の全体像についてはシステム開発の要件定義を成功させる完全ガイドで詳しく解説しています。AS-IS / TO-BE を整理した後、どのように要件定義書へ展開するかをセットで把握しておくと、書きながら粒度を判断しやすくなります。

AS-ISの書き方：現状業務を3レイヤーで可視化する

ここからは実際の書き方に入ります。AS-IS を整理する際は、業務プロセス・情報データ・システムツールの 3 レイヤーに分けて書くと、開発会社に伝わる粒度を担保しやすくなります。これは経営フレームワークとしての AS-IS / TO-BE を IT・DX プロジェクトに最適化した整理方法です。

3 レイヤーで何を書くかを先に俯瞰します。

レイヤー1：業務プロセス層（誰が・何を・どの順で）

業務プロセス層では、現状の業務フローを時系列で書き出します。粒度の目安は「担当者」「トリガー（何で開始するか）」「アウトプット」「次に渡す相手」を 1 ステップ単位で記述することです。

書く際のチェックポイントは次の通りです。

• 主語を明示する（「営業担当 A」「経理担当者」など、役割で書く）
• トリガーを明示する（「顧客から受注メールが届いたとき」「月末締日に」など）
• 分岐条件を書く（「金額が 100 万円を超える場合は部長承認」など）
• 例外処理にも触れる（「在庫が足りない場合は仕入れ部門に確認」など）

業務フローを図で可視化する具体的な手順は、関連記事の業務フロー可視化の進め方で詳しく解説しています。図と表を組み合わせて整理することで、後工程での Gap 抽出がやりやすくなります。

レイヤー2：情報・データ層（どの情報がどこに、どの形式で）

業務プロセスを動かしているのは情報です。情報・データ層では、業務の中で扱われている情報がどこに保管され、どんな形式で流通しているかを書きます。

書くべき項目は次の通りです。

• 情報の名称（例: 受注情報、顧客マスタ、在庫情報）
• 保管場所（例: 共有フォルダのパス、SaaS 名、紙の伝票）
• 形式（例: Excel、PDF、SaaS のレコード、メール本文）
• 更新頻度（例: リアルタイム、日次、月次）
• 更新する人（例: 営業担当が直接入力、経理が一括更新）

このレイヤーを丁寧に書くと、「実は同じ顧客情報が 3 か所に分散していて、それぞれ手で同期している」といった、後の要件化につながる重要な事実が浮かび上がります。

レイヤー3：システム・ツール層（どのツール・どのシステムで）

最後にシステム・ツール層です。レイヤー 1・2 で記述した業務と情報が、具体的にどのシステムで動いているかを書きます。

書くべき項目の例は次の通りです。

• 使用しているシステム・ツール名（例: 自社開発の販売管理システム、SaaS の名称、Microsoft 365）
• バージョン・契約形態（例: オンプレ、クラウド、買い切り）
• 他システムとの連携方式（例: API 連携、CSV 一括取り込み、手作業転記）
• 既知の制約・問題点（例: 同時アクセス上限、レスポンスの遅さ、特定ブラウザでしか動かない）

「2025年の崖」と呼ばれるレガシーシステム問題の議論にもあるように、現行システムがブラックボックス化していると DX 推進の大きな障壁になります（参考: レガシーシステム脱却に向けた「レガシーシステムモダン化委員会総括レポート」（経済産業省））。AS-IS のシステム・ツール層を書く過程で、ブラックボックス化している箇所を洗い出すこと自体が大きな価値になります。

ヒアリング手順と「書かないでよい範囲」の見極め方

AS-IS は「現場で実際に何が起きているか」を反映する必要があるため、ヒアリングが欠かせません。次の手順をおすすめします。

1. 整理対象の業務を 1 つに絞る（例: 受注管理業務）
2. その業務の起点と終点を決める（例: 受注メール受信 → 出荷指示完了）
3. 業務の最初から最後までを担当する 2 〜 3 名にヒアリングする
4. 業務プロセス層を時系列で書き出し、その後で情報・データ層、システム・ツール層を埋めていく
5. 書いたものを現場担当者にレビューしてもらい、抜け漏れを補正する

一方で「書かないでよい範囲」も意識する必要があります。プロジェクトのスコープから外れる業務、年に数回しか発生しない例外業務、すでに廃止が決まっている業務などは、簡単に触れるだけで深掘りしません。AS-IS は完璧を目指すと終わらないため、「スコープ内・頻度が高い・関係者が複数」の業務に集中することがコツです。

記入例：受注管理業務のAS-IS

実際に「受注管理業務」を 3 レイヤーで AS-IS 化した記入例を示します。架空のケースですが、自社で書くときのイメージを掴むのに使ってください。

レイヤー1：業務プロセス層

レイヤー2：情報・データ層

レイヤー3：システム・ツール層

このレベルで書けると、後段の TO-BE 設計と Gap 抽出が一気に進めやすくなります。

TO-BEの書き方：あるべき姿を成果で定義する

TO-BE は AS-IS の延長線で書こうとすると、どうしても「現状の小改善」止まりになりがちです。「Excel をもう少し整理する」「ファイル名のルールを統一する」といった、現場目線で実現可能なことだけが並んでしまうのです。

IT・DX プロジェクトの TO-BE は、現状の制約から離れて「成果から逆算する」アプローチで書きます。あわせて、現実に落とし込むための制約条件と優先順位も併記します。

成果（KPI／KGI）から逆算する

TO-BE の出発点は「このプロジェクトで何を達成したいか」という成果指標（KPI / KGI）です。経営層・事業部門に確認すべき問いの例を挙げます。

• 受注処理にかかる時間を、現状の平均 30 分／件から何分にしたいか
• 受注ミス（誤入力・転記漏れ）の件数を、月何件まで減らしたいか
• 受注情報を倉庫に渡すまでのリードタイムを、何時間以内にしたいか
• 担当者が病気で休んでも業務が止まらない、という状態を実現したいか

成果指標を先に決めてから、それを実現する業務とシステムの姿を逆算します。この順番で書くことで、「とりあえず Excel を SaaS に置き換える」のような手段先行の TO-BE を避けられます。

DX 推進においてどの施策を優先するかについては、関連記事のDX推進の優先順位の付け方も参考になります。成果指標と施策を結びつけて整理する考え方を補強できます。

3レイヤーでTO-BEを書く

AS-IS と同じ 3 レイヤー（業務プロセス層・情報データ層・システムツール層）で TO-BE を書きます。AS-IS と TO-BE を同じ構造で記述することで、後工程の Gap 抽出が機械的に行えるようになります。

書く際のポイントは次の通りです。

• 業務プロセス層では「人が手で行う作業」と「システムが自動で行う作業」を分けて書く
• 情報・データ層では「どこにマスタを集約するか」「どの情報をリアルタイムで連携するか」を書く
• システム・ツール層では具体的な製品名よりも「役割」（例: 受注管理システム、与信管理機能）で書く（後段で具体的な製品選定が変わっても、TO-BE そのものは流用できる）

制約条件（予算・期間・人員）を必ず併記する

TO-BE が絵に描いた餅にならないために、最初から制約条件を併記します。代表的な制約条件は次の通りです。

• 予算（例: 年額 500 万円以内）
• 期間（例: 半年以内に稼働開始）
• 人員（例: 社内専任 1 名・現場兼任 2 名）
• 既存システムとの整合（例: 倉庫管理 SaaS は変更しない）
• 法令・社内ルール（例: 押印は段階的に廃止予定）

制約条件を併記することで、TO-BE が「理想だが実現不可能」になるリスクを抑え、開発会社にも実現性を判断する材料を渡せます。

優先順位（Must／Want／Nice to have）をつける

TO-BE で書いた要素にはすべて優先順位をつけます。中小企業の DX プロジェクトでは、最初からすべてを実現しようとすると予算も期間も足りなくなることが大半です。

• Must：今回のプロジェクトで必ず実現したい項目
• Want：できれば実現したいが、Must を満たした余力で対応する項目
• Nice to have：将来的に実現したいが、今回は対象外でも構わない項目

優先順位は、後段の Gap 分類で「システム要件として開発する範囲」を決める際の重要な判断材料になります。

記入例：受注管理業務のTO-BE

先ほどの受注管理業務の AS-IS に対応する TO-BE の記入例です。

成果指標（KPI / KGI）

制約条件

• 予算：初期 300 万円・運用 月 10 万円以内
• 期間：要件定義から稼働まで 6 か月
• 人員：社内 DX 担当 1 名・営業 1 名・経理 1 名で対応
• 既存システム：倉庫管理 SaaS は変更しない

レイヤー1：業務プロセス層（TO-BE）

レイヤー2：情報・データ層（TO-BE）

レイヤー3：システム・ツール層（TO-BE）

ここまで書けると、AS-IS との差分（Gap）が明確に取り出せる状態になります。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

AS-IS／TO-BEのギャップからシステム要件を導く

AS-IS / TO-BE を同じ 3 レイヤーで整理すると、両者を横並びにしたときに差分（Gap）が浮かび上がります。この Gap を要件に翻訳する作業が、AS-IS / TO-BE 整理の到達点です。

ギャップ一覧表の作り方（3レイヤー × ギャップ）

Gap は 3 レイヤーごとに表にして整理します。

このようにレイヤーごとに Gap を抽出することで、「どこが変わるのか」を漏れなく把握できます。

ギャップを「システム要件／業務変更／運用ルール」に分類する

抽出した Gap は、解決の方法によって 3 つに分類します。

• システム要件：システムを開発・導入することで解決する範囲
• 業務変更：業務手順や担当者の役割を変更することで解決する範囲
• 運用ルール：システム外の運用ルール（承認フロー・連絡手段など）で解決する範囲

先ほどの受注管理業務の例では、次のように分類できます。

このうち「システム要件」に分類されたものが、開発会社に発注する範囲です。機能要件と非機能要件の整理軸については、関連記事の機能要件と非機能要件の違いが参考になります。

Fit&Gap分析・要件定義書への接続

「システム要件」に分類した項目は、次の 2 つの経路で活用します。

1 つ目はパッケージシステムやクラウド SaaS を導入する場合の Fit & Gap 分析です。パッケージの標準機能で実現できる範囲（Fit）と、標準では実現できずカスタマイズや業務側調整が必要な範囲（Gap）に再分類することで、導入方針が決まります（参考: Fit and gap 分析とは？目的から進め方までプロが徹底解説）。

2 つ目はスクラッチ開発を選択する場合の要件定義書への展開です。要件定義書に書く項目はテンプレート化されており、AS-IS / TO-BE と Gap 一覧があれば、各項目を効率的に埋めていけます。要件定義書のテンプレートと項目の埋め方は、関連記事の要件定義書の書き方とテンプレートで詳しく解説しています。

よくある失敗パターンと回避策（TO-BEが精神論になる問題ほか）

AS-IS / TO-BE は形だけ整えることができてしまうため、実務では「書いたのに使い物にならない」失敗が頻発します。代表的な 5 つのパターンを取り上げ、それぞれの回避策を示します。

DX プロジェクト全般での失敗パターンは、関連記事のDX失敗事例から学ぶ落とし穴でも紹介しています。あわせて確認すると、AS-IS / TO-BE の整理が後段でどう活きてくるかを理解しやすくなります。

失敗1：TO-BEが精神論になる

最頻出の失敗が、TO-BE が「業務を効率化する」「データを一元化する」「顧客満足度を上げる」といったスローガンで埋まってしまうパターンです。これらは目指す方向としては正しいのですが、開発会社が読んで具体的に何を作ればよいかを判断できません。

回避策は「成果指標で書く」ことです。「業務を効率化する」ではなく「受注 1 件あたりの処理時間を 30 分から 10 分にする」と書きます。さらに「制約条件を併記する」ことで、絵に描いた餅から逃れます。

失敗2：AS-ISが現場と乖離している

AS-IS を管理職や経営層の頭の中だけで書くと、「手順書ではこうなっている」レベルの理想形になり、現場の実態と乖離します。実際には Excel ではなくメモ帳でやり取りされていたり、属人的な手順が残っていたりするものです。

回避策はヒアリングです。整理対象の業務を実際に毎日行っている担当者 2 〜 3 名に時間をもらい、画面を一緒に見ながら作業の流れを追体験させてもらいます。書いた AS-IS は必ず現場担当者にレビューしてもらい、ずれを修正します。

失敗3：機能名でTO-BEを書いてしまう

「Salesforce を導入する」「kintone でアプリを作る」のように、製品名や機能名で TO-BE を書く失敗です。具体的に見えますが、「なぜそのツールなのか」「それで何が達成されるのか」が見えないため、後で別の選択肢に変えた瞬間に TO-BE 全体が崩れます。

回避策は「役割で書く」ことです。「Salesforce を導入する」ではなく「顧客情報を一元管理する受注管理システムを導入する」と書きます。具体的な製品選定は後段の比較検討フェーズに切り出します。

失敗4：制約条件を書かない

予算・期間・人員といった制約条件を書かないまま TO-BE を書き上げると、開発会社から「これは予算と期間では実現できません」と差し戻されます。さらに悪いケースでは、見積もりが出てから「予算オーバーなので機能を削ってください」と判断を迫られ、後戻りが発生します。

回避策はシンプルで、TO-BE を書く際に必ず制約条件のセクションを設けることです。「予算」「期間」「人員」「既存システムとの整合」「法令・社内ルール」の 5 項目をテンプレートとして埋めると抜け漏れがありません。

失敗5：主語が抜けて誰の作業か分からない

「受注情報を入力する」「与信を確認する」のように、主語を省略して書くと、AS-IS / TO-BE のどちらでも「誰がやるのか」が分からなくなります。特に TO-BE では、「人がやる」のか「システムが自動でやる」のかが曖昧になり、要件化したときにどの機能を開発すべきかが見えません。

回避策は、業務プロセス層のすべてのステップに主語を書くことです。役職（「営業担当」「経理担当」）または「システム」のいずれかを必ず明示します。本記事の受注管理業務の記入例で、各ステップに「担当者」列を必ず設けているのもこのためです。

開発会社・ベンダーへの伝え方

AS-IS / TO-BE が書き上がったら、次は開発会社にどう共有するかです。ここで認識ズレが起きると、せっかく整理した内容が活かされず、再度ヒアリングのやり直しになります。

共有資料の3点セット

開発会社に共有する際の標準フォーマットとして、次の 3 点セットをおすすめします。

業務フロー図の作り方は、関連記事の業務フロー可視化の進め方で詳しく解説しています。

3 点セットを揃えることで、開発会社は「全体像（業務フロー図）→ 詳細（対比表）→ 差分（Gap 一覧）」の順で素早く理解でき、初回打ち合わせから具体的な見積もり議論に入れます。

開発会社が読み取りにくい記述パターンを避けるチェックリスト

開発会社の担当者は、その会社の業務に初めて触れる立場です。次のチェックリストで、共有前のドキュメントを点検しましょう。

• すべての業務ステップに主語（役職名 or システム）が書かれているか
• 社内独自の略語・固有名詞には初出時に説明が添えられているか
• システム・ツール名は正式名称（バージョン・契約形態含む）で書かれているか
• 業務プロセスの分岐条件（金額・状態など）は数値・条件式で書かれているか
• TO-BE の優先順位（Must / Want / Nice to have）が明示されているか
• 制約条件（予算・期間・人員）が記載されているか

このチェックリストを通過したドキュメントは、開発会社にとって「読みやすく、見積もりやすい」資料になります。

認識ズレを防ぐQ&A運用

ドキュメントを渡しても、解釈の余地はゼロにはなりません。共有時に Q&A シート（質問・回答を時系列で記録する 1 枚のスプレッドシート）を用意しておくことをおすすめします。

Q&A 運用のポイントは次の通りです。

• 開発会社からの質問は Q&A シートに集約し、口頭でやり取りした内容も後で転記する
• 回答が決まったものは「決定事項」として AS-IS / TO-BE ドキュメントに反映する
• 未決の項目は期限と決定者を明示しておく

この運用により、「あのとき口頭で言ったはず」「メールにそう書いた気がする」といった水掛け論を避けられ、要件定義フェーズへスムーズに移行できます。

まとめ：AS-IS／TO-BE整理から次のアクションへ

ここまで、IT・DX 推進プロジェクトでの AS-IS / TO-BE の書き方を、3 レイヤー法・記入例・失敗パターン・開発会社への共有方法まで解説しました。本記事の要点を 5 行で振り返ります。

• AS-IS / TO-BE は単独ではなく Gap とセットで初めて意味を持つ 3 点セット
• 3 レイヤー（業務プロセス・情報データ・システムツール）で書くと開発会社に伝わる粒度になる
• TO-BE は「成果から逆算」「制約条件併記」「優先順位付与」の 3 原則で精神論を回避する
• Gap は「システム要件 / 業務変更 / 運用ルール」に分類することで次のアクションが見える
• 開発会社には「業務フロー図 + AS-IS / TO-BE 対比表 + Gap 一覧表」の 3 点セットで渡す

次にとるべきアクション

AS-IS / TO-BE のドラフトを書き終えたら、次の 3 つのアクションを順に進めることをおすすめします。

1. 業務プロセスの可視化を深掘りする：AS-IS の業務フロー図を整え、現場担当者と認識を合わせます。詳しい手順は業務フロー可視化の進め方を参照してください。
2. 要件定義書に展開する：Gap で「システム要件」に分類した項目を要件定義書に落とし込みます。テンプレートと記入の仕方は要件定義書の書き方とテンプレートを参照してください。要件定義プロセス全体の進め方はシステム開発の要件定義を成功させる完全ガイドで詳しく解説しています。
3. 優先順位を踏まえて開発スコープを決める：Must / Want / Nice to have で整理した TO-BE を、予算・期間と照らし合わせて開発スコープを確定します。優先順位の付け方はDX推進の優先順位の付け方が参考になります。

AS-IS / TO-BE は、書き終えた瞬間に価値が生まれるドキュメントではなく、その後の要件定義・開発・運用で繰り返し参照されることで価値が積み上がるドキュメントです。今日のうちに、まずは整理対象の業務を 1 つに絞り、業務プロセス層から書き始めてみてください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。