ExcelやAccessを使っているという理由だけで、Webシステムへ移す必要はありません。少人数で扱い、業務が安定し、データの正本と復元方法が明確なら、現在の仕組みを改善して続ける選択もあります。Webシステム化を検討するのは、同時入力、拠点間共有、承認、権限、外部連携、担当者への依存などが業務の制約になっている場合です。
重要なのは、ファイルを画面へ置き換えることではなく、どの業務とデータを共通化するかです。現在のExcel・Accessに含まれる計算や例外処理を理解しないまま開発すると、見た目は新しくなっても、転記や確認作業が残ります。残す、修正する、既製品へ移す、個別開発するという選択肢を比較するための確認事項を整理します。
1. Webシステム化を検討するサイン
まず、現場で起きている問題を、製品名ではなく作業単位で記録します。
- 誰が最新版を持っているか分からない
- 同じ情報を複数ファイルへ転記している
- 入力の競合や上書きを避けるため、作業の順番待ちがある
- 部門や拠点ごとに項目名、コード、計算方法が違う
- 閲覧・変更権限をファイル単位だけでは分けにくい
- マクロやクエリを修正できる担当者が限られる
- 承認や変更の履歴を別のメールで管理している
- 他システムとの連携で手作業が繰り返される
一時的なファイルの置き場所の混乱と、業務全体のデータ管理の問題は分けます。保存ルールや入力規則で解決できる部分まで個別開発すると、保守する仕組みを増やしてしまいます。問題が起きる頻度、担当者、やり直し時間、締め切りへの影響を確認してください。
2. 残す・直す・移すを比較する
現在の運用を残す
試算や一時的な分析など、担当者が自由に変更することに価値がある作業は、表計算に残す方が自然な場合があります。利用者やデータの範囲が限られ、入力・確認・バックアップの責任が明確なら、すべてをシステム化する必要はありません。
Excel・Accessを修正する
入力様式の統一、データの分離、重複項目の整理、マクロやクエリの見直しで改善できるかを調べます。ただし、現在の担当者しか変更できない状態が残るなら、修正内容と運用の記録まで含めて対策します。
既製品やローコードを使う
業務が既製品の標準機能に近い場合は、有力な候補です。利用料だけでなく、権限、外部連携、データ出力、将来の移行、設定を保守する担当まで確認します。「設定だけでできる」という説明でも、データ整備や業務調整が不要になるわけではありません。
Webシステムを個別開発する
独自の承認、部門横断の処理、既存システムとの連携など、標準機能に合わせることが難しい場合に検討します。自由度と引き換えに、設計、テスト、運用、改修の責任を持つ必要があります。現在の帳票をそのまま再現する費用だけでなく、導入後に変更し続けられるかを比較します。
3. ファイルではなく業務フローを棚卸しする
対象ファイルを集めたら、入力元、作業者、確認者、出力先、締め切りを対応させます。一つのブックが複数の仕事を兼ねている場合は、登録、集計、申請、分析などへ分けます。
Accessの場合は、テーブルだけでなく、クエリ、フォーム、レポート、マクロ、VBA、外部リンクを確認します。Excelでは、数式、名前定義、非表示シート、外部参照、入力規則、マクロ、手作業の補正が対象です。使われていないように見える処理も、年次業務で必要な場合があるため、削除前に利用部門へ確認します。
利用者へ「欲しい画面」を聞くだけでは、例外処理を把握できません。「通常と違う注文を受けたとき」「入力後に条件が変わったとき」「担当者が休んだとき」に、誰が何をしているかを確認します。システムへ移す業務ルールと、人が判断し続ける例外を分けるためです。
4. データの正本と識別方法を決める
同じ顧客や商品が別名で登録されていると、新しい画面を用意しても重複や集計差異は残ります。どのデータを正本とするか、何を識別番号にするか、誰が登録・変更するかを決めます。
- 顧客、商品、案件、担当者などのマスター
- 日付、金額、数量、単位、状態の定義
- 重複、空欄、廃止済みデータの扱い
- 履歴として残す項目と上書きしてよい項目
- 外部システムで使うコードとの対応
過去データをすべて新システムへ移すかも別の判断です。日常処理に必要なデータ、参照だけでよいデータ、保存義務や契約上保持するデータを分けます。業務上必要な履歴を落とさず、不要な重複を持ち込まない範囲を決めてから移行量を見積もります。
5. 画面・権限・承認を業務に合わせる
Web化では、誰がどの画面を使えるかに加え、どのデータを閲覧・変更できるかを設計します。管理者と一般利用者だけでなく、部門、担当案件、承認段階による違いを確認します。
入力を制限し過ぎると、例外処理が再びExcelへ戻ります。通常入力、差し戻し、代理入力、取消、訂正などを整理し、変更履歴と承認記録を残す範囲を決めます。承認前の値が帳票へ出ないか、確定済みデータを誰でも変更できないかもテスト対象です。
現場へは、完成後の画面だけでなく、早い段階で入力から確認までの流れを見せます。画面の使いやすさだけでなく、紙やメールへ戻る作業が残っていないかを確認すると、開発後の大きな手戻りを減らせます。
6. 既存システムとつなぐ範囲を決める
販売管理、会計、在庫、CRMなどに既に正本がある場合、新システムで同じ情報を別管理しないようにします。API、CSV、ファイル受渡し等の選択肢から、更新頻度と失敗時の対応に合う方法を検討します。
「毎日取り込めればよい情報」と「操作直後に反映しなければならない情報」を区別します。同期が必要な場合は、正本、更新方向、重複、削除、再実行時の扱いを決めます。連携先のAPI仕様や認証方式によって作業範囲が変わるため、API・SaaS連携の費用を左右する要素も確認してください。
外部連携の完成を待たず、初期段階は確認済みCSVを取り込むなど、段階導入が適切な場合もあります。ただし、その暫定運用を誰が行い、いつ終了するかは決めておきます。
7. 移行とテストは開発とは別に計画する
データ変換のテストでは、件数が一致するだけでなく、金額、数量、関連データ、帳票結果などを旧環境と照合します。現行Excelの計算式自体に問題がある場合は、現行結果を無条件の正解とせず、業務責任者が正しい計算ルールを確認します。
切替時は、どの時点から新システムを正本とするかを決めます。旧ファイルと新システムの両方を自由に更新すると、差分の回収が難しくなります。並行確認が必要でも、二重入力の範囲、照合者、終了条件を明確にします。
障害時に旧運用へ戻る場合は、新環境で発生した入力をどう扱うかも必要です。「バックアップへ戻す」とだけ決めず、業務データの差分を回収できるか確認します。利用者への案内、操作教育、問い合わせ窓口も切替計画に含めます。
8. 費用と効果を判断する
費用は、画面数だけでは決まりません。既存ファイル調査、データ整理、業務ルール、権限、承認、外部連携、帳票、移行、テスト、運用保守が見積範囲になります。移行後も残すExcel作業があれば、その受渡し方法も含めます。
効果は、転記時間、確認待ち、入力や集計の誤り、担当者への問い合わせ、月次作業の負担などで比較します。操作時間が短くなっても、保守負荷や例外対応が大きく増える場合は、業務全体で判断する必要があります。
相談前には、代表ファイルの構成、利用者、処理頻度、現在の問題、連携先、残したい作業、希望時期を整理します。顧客データや認証情報をそのまま送るのではなく、安全な確認方法を先に相談してください。何を残し、何を共通化するかが分かると、自社に合う移行範囲を検討しやすくなります。
