Access移行のAs-Is/To-Be分析｜現状の棚卸しと理想像の描き方

結論：As-Is/To-Be分析の目的は「問題を整理すること」ではなく「決める場所を確定させること」

Access移行で「As-Is（現状）を整理してからTo-Be（理想像）を描く」という手順自体は正しい。ただ、当社が支援案件で繰り返し見るのは、この分析を「問題点のリストアップ」で終わらせてしまうケースです。問題を洗い出しても、移行後に何を変えて何を残すかの判断を誰もしていない、という状態になる。

As-Is/To-Be分析の実質的な目的は「判断を先送りにしてきた設計上の問いに、このタイミングで答えること」です。移行の後半で答えを迫られると、手戻りが大きくなります。分析の段階で判断を引き取ることが、設計工程を短縮する最短経路になります。

As-Isで把握する4点

現状分析では、Access上の画面や機能を書き出すより先に、次の4点を確認します。業務フロー調査（各業務の手順と例外処理の洗い出し）とは別の作業で、目的は「移行後の判断材料を用意すること」です。

4番目の「変えたくないこと」は聞き落とされやすい項目です。業務担当者が長年Accessで慣れてきた入力順序・画面の構成・帳票の見た目は、「使いやすい」という感覚と結びついています。移行後に操作性が大きく変わると現場の反発が出ます。As-Isの段階でこの感覚を把握しておくと、To-Beで「どこまでUIを変えるか」の合意が取りやすくなります。

業務フロー調査と同時並行で進めると効率的です。具体的な洗い出し手順は業務フロー調査の進め方で解説しています。

As-Isで陥りやすい罠：「現状の不便をそのまま移植しない」

現状分析を詳細にやるほど、移行仕様書が「今のAccessの完全再現」を目指す方向に引っ張られます。当社がよく見るパターンは3つあります。

• 使われていないフォームや機能がそのまま要件に残る（誰も削除を判断しないため）
• Accessの制約から生まれた手作業（Excelへの転記、印刷→手書き修正など）を新システムにも引き継ぐ
• 担当者が退職した後も残っている処理を「念のため」新システムに実装する

これを防ぐには、As-Isの整理に「この機能は誰がいつ使っているか」「この手作業は新システムで解消できるか」という問いを並走させることです。当社では、機能・画面・帳票の一覧を作るとき、各行に「移行先で再現する／廃止する／変更して再現する」の3択を担当者と合意しながら埋めていきます。これがギャップ分析の素材になります。

To-Beの描き方と「盛りすぎ」の落とし穴

To-Beは「移行後に実現したい状態」の整理です。ここで頻繁に起きる問題が「理想を盛りすぎて予算・期間がはみ出す」パターンです。

Access移行のTo-Beとして現場から出やすい要望の例を挙げると、承認ワークフローの自動化、スマホ対応、会計ソフトとのリアルタイム連携、高度なダッシュボード可視化などがあります。既存のAccessでは対応しにくいか、現行システムでは未実装の機能が多く、「せっかく移行するなら」という心理から出てきます。これらをすべてスコープに入れると、移行プロジェクトは新規システム開発に近い規模になります。

当社の実務では、To-Beを「Accessを脱した段階で得られること（第1フェーズ）」と「その後で取り組む追加機能（第2フェーズ以降）」に分けることを勧めています。第1フェーズは現行構成に起因する問題の解消に絞る——ファイルサイズ上限への接近・単一ファイル共有による同時利用時の破損リスク・サポート終了済みバージョンを使い続けるリスクの解消が第一目標で、機能の拡張は次のフェーズです。

段階移行の考え方はハイブリッド段階移行でも整理しています。

ギャップ分析：「変えること」「やめること」「追加すること」の3列で整理する

As-IsとTo-Beが揃ったら、その差分を整理するのがギャップ分析です。当社では3列の分類を使います。

この3列を埋めながら進めると、提案依頼書（RFP）に書く内容が自然に決まります。移行を外部発注するときのRFPの作り方はAccess移行のRFP・要件定義書の作り方で解説しています。

分析結果をまとめた後、当社では「やめること」リストを担当者に確認してもらいます。ここで異議が出た項目は、実は現役の業務ルールである可能性があるため、改めてヒアリングします。「廃止してよい」という合意は口頭でなく、記録に残しておくことを推奨します（移行後に「なぜなくなったのか」と問われたときの根拠になるため）。

To-Beを決めるのは「担当者個人」ではなく「意思決定できる人」

To-Beの内容に実務担当者と経営層・情報システム担当者の意見が食い違うことがあります。現場は「使い慣れた操作性を維持したい」、経営層は「コストを下げたい」、情シスは「保守しやすい構成にしたい」という具合に、関心の軸が違います。

As-Is/To-Be分析は、この食い違いを放置したまま進めると後半で対立として噴出します。当社では、分析の初期段階で「最終的な移行先の決定は誰が行うか」を確認します。明確な意思決定者がいない場合、分析の成果物（As-Is文書・To-Be草案）を使って合意形成の場を設けることを勧めています。

移行プロジェクトの体制づくりについてはAccess移行プロジェクトの進め方でも触れています。

As-IsとTo-Beの分析を終えた段階で、移行の規模感がかなり具体的になります。この時点で当社の無料の解析可否チェックを活用すると、現行AccessのAs-Is情報を素材に移行先の選択肢と概算費用を整理できます。

よくある質問

Q. As-Is/To-Be分析はどのタイミングで始めるべきですか。

Access移行を正式に決定した直後が適切です。業者への問い合わせ・見積もり依頼の前に分析を始めると、要件をある程度固めた状態で発注できます。逆に見積もりを取ってから分析すると、見積もりの精度が低く、追加費用が発生しやすくなります。社内でどこまで分析できるかわからない段階でも、当社への相談を入口にして並走できます。

Q. As-Isを社内でまとめられる自信がありません。どこから手をつければよいですか。

まずAccessのナビゲーションペインを開いて、テーブル・クエリ・フォーム・レポート・マクロ・モジュールの数を書き出すところから始めてください。次に、各フォームについて「誰が・何のために使っているか」を担当者に1行ずつ確認します。この2ステップだけでも、現状の全体像が相当クリアになります。詳細な解析は技術者と協力する部分ですが、この初期棚卸しは社内でできます。

Q. To-Beを描くのに時間をかけすぎている気がします。どこで切り上げますか。

「移行第1フェーズで実現するか・しないか」の2択に絞ってしまうのが早道です。長期的な理想像を延々と議論するより、「この移行で解決する課題」を5点以内で合意する方が実行に近い。To-Beは完璧な未来像である必要はなく、「このシステムが終わったら何ができているか」を決めるものです。

Q. As-Is/To-Be分析の成果物は何を作ればよいですか。

当社の実務では2つを作ります。1つ目は機能一覧（フォーム・帳票・処理ごとに「再現／廃止／変更」の分類を付けたスプレッドシート）、2つ目はTo-Beの要件一覧（移行後に実現すること・しないことを箇条書きにしたもの）です。この2つが揃えば、外部発注時のRFPの骨格として使えます。