導入（問題提起）

「現場を止めずに移行したい」「過去データも活かしたい」「属人マクロから脱却したい」。Excel/Access/紙/メールで回してきたレガシー運用を、より安全・確実なWebシステムへ移行する相談が増えています。とはいえ、いきなり“全部作り替え”は現実的ではありません。業務が止まる、教育が間に合わない、予算が膨らむリスクが大きいからです。

本記事では、止めずに変えるための段階移行（フェーズド・マイグレーション）の実践手順を、Webシステム開発の観点から解説します。キーワードは「最小から」「並走運用」「データを先に整える」。基盤はPythonで小さく始めて、必要に応じて拡張（Excel Web化→本格Webアプリ）します。

課題の詳細説明

レガシー運用からの移行でつまずくポイントは、技術よりも“運用の設計”にあります。典型的な課題を原因と影響に分けて整理します。

  • Excel/Accessマクロへの依存

    • - 参照ライブラリや32/64bit差で突然動かなくなる - 仕様が個人の記憶にあり、ドキュメントが無い

  • ルール・例外の暗黙知化

    • - 「この取引先だけは特別」などの例外がスプレッドシートに埋没 - 暗黙ルールを画面やバリデーションに起こせず、品質が不安定

  • データ品質のばらつき

    • - 名寄せ（表記ゆれ）、重複、欠損、型不一致 - ID体系が無く、同一人物・同一案件を判定できない

  • 教育コストと反発

    • - 画面が増え手順が変わると、移行前に拒否反応が出やすい

  • 連携の分断

    • - 会計・在庫・CRMなど周辺システムとのデータ往復が“手運び”

解決方法（ロードマップ）

“一気に置き換えない”前提で、8ステップの移行手順を提示します。

  1. 現状整理（棚卸し）

    2. - 業務フロー、入力帳票、出力レポート、関係者、締切、例外を洗い出す - 依存マクロの入出力・前提・リスク（停止可能性）を可視化

  2. 最小スコープの確定

    3. - 価値の大きいボトルネック1つに絞る（例：申請、在庫、請求のいずれか） - 1機能×2段階承認（あれば）で到達目標を定める

  3. データ標準化（ここを先に）

    4. - ID体系（顧客ID/商品ID/担当者ID）とコード体系（区分/状態）を定義 - マスタ整備と名寄せ・重複排除をPythonで実行（pandas）

  4. 並走運用の設計

    5. - 旧運用と新運用を一定期間並行稼働。差分の持ち方と責任者を明確化 - 旧→新への片方向同期から開始（CSVエクスポート→インポート）

  5. 最小Web化（Excel Web化）

    6. - Python＋Bottle/FastAPI＋SQLiteで画面2枚（一覧・登録/編集）を先に実装 - サーバ側検証（必須/型/桁/選択肢）と監査ログを標準装備

  6. 双方向連携（必要に応じて）

    7. - APIまたはスケジュールCSVで双方向同期に段階拡張 - 競合ルール（どちらを正とするか）を明示

  7. 教育・展開

    8. - チュートリアル、ショート動画、よくある質問を用意。現場チャンピオンを任命

  8. 効果測定と次フェーズへ

    9. - KPI（処理時間/エラー率/回収率/滞留時間）で効果を確認し、周辺機能へ水平展開

具体例

フェーズでの前進イメージを3パターン示します。

例1：申請ワークフロー

  • フェーズ1：申請の登録/承認のみWeb化、帳票PDFは旧Excelで出力
  • フェーズ2：承認完了トリガで会計システム用CSVを自動生成
  • フェーズ3：稟議・休暇・購買へ水平展開、権限（RBAC）と監査ログを統一

例2：在庫・受発注

  • フェーズ1：入出庫台帳をWeb化（QR/バーコードは後回し）
  • フェーズ2：受発注CSVと突合、欠品/過剰のアラートを自動化
  • フェーズ3：倉庫や店舗へ展開、端末最適化と棚卸しアプリ連携

例3：売上・請求

  • フェーズ1：売上計上をWeb化、請求は旧Excelテンプレ差し込み
  • フェーズ2：請求PDFの自動出力→メール送信、再発行履歴をDB保存
  • フェーズ3：入金消込・督促まで拡張、ダッシュボードで回収率を可視化

技術的な解説（Pythonでの移行基盤）

“小さく強い”移行基盤は、Python＋軽量Web（Bottle/FastAPI）＋SQLite→PostgreSQLです。Excel Web化の設計を土台に、データと状態をサーバ側で正しく管理します。

データモデル（疑似コード）


Table: master_customers
  id TEXT PRIMARY KEY         -- 名寄せ後の一意ID
  name TEXT, kana TEXT, code TEXT UNIQUE
  created_at TEXT, updated_at TEXT

Table: migrations
  id INTEGER PRIMARY KEY
  source TEXT                 -- 'excel','access','csv','mail'
  kind TEXT                   -- 'import','export','sync'
  status TEXT CHECK(status IN ('queued','running','done','failed'))
  started_at TEXT, finished_at TEXT
  stats TEXT                  -- 件数・所要時間など

Table: audit_logs
  id INTEGER PRIMARY KEY
  actor TEXT, action TEXT, entity TEXT, entity_id TEXT
  before TEXT, after TEXT, acted_at TEXT, ip TEXT

ルーティング例（FastAPI）


from fastapi import FastAPI, Depends
from pydantic import BaseModel

app = FastAPI()

class CustomerIn(BaseModel):
    code: str
    name: str
    kana: str | None = None

@app.post('/api/customers')
def create_customer(body: CustomerIn, user=Depends(auth_user)):
    services.validate_customer(body.dict())
    cid = repo.insert_customer(body.dict(), user)
    return {"id": cid}

カットオーバー戦略（停止しない切替）

  • ブルー/グリーンまたは段階ルーティング：新旧画面を併設し、対象部署から切替
  • リハーサル：過去3ヶ月分で移行テスト→差異レポート→再実行
  • ロールバック：致命的問題時は旧運用に即時戻れるよう同報

セキュリティ/運用

  • 認証（社内SSOまたは個別）とRBAC（閲覧/編集/管理）
  • 監査ログと世代バックアップ（SQLiteはファイルコピーで容易）
  • エラー通知（メール/Chat）と死活監視、障害対応手順の整備

導入の流れ

2〜8週間で“止めずに”形にする現実的スケジュールです。

  1. 現状診断（1.5h〜）

    2. - ファイル、帳票、マクロ、関係者、締切、リスクを俯瞰

  2. PoC合意（0.5d）

    3. - 1機能×2段階承認 or 台帳CRUDから開始、成功指標を設定

  3. データ整備（1〜5d）

    4. - 名寄せ・重複排除・コード化、欠損補完、CSV標準化

  4. 最小Web実装（3〜10d）

    5. - Python Webアプリ（一覧/登録/検索/監査）とCSV出力を実装

  5. 並走運用（5〜15d）

    6. - 実データで併走、差異と運用課題を洗い出し→改善

  6. カットオーバー（0.5〜1d）

    7. - 対象部署から段階切替、ロールバック手順を明示

  7. 効果測定＆次フェーズ

    8. - KPIで効果確認、周辺機能へ水平展開

まとめ

“最小から確実に”。データを先に整え、並走運用でリスクを抑えながら移行すれば、現場を止めずに業務システムを刷新できます。実装はPythonを中心に、まずはExcel Web化＝小さなWebアプリでスモールスタート。成果を確認しつつ、必要な機能を段階的に積み上げていきましょう。

問い合わせ導線

Webシステム開発のご相談は monou まで → /contact