【移行地獄】20年運用した物理ネットワークをGCPに移行して6ヶ月炎上した全記録
プロローグ：軽く見ていたクラウド移行
2025年1月15日（月曜日）午前10時
「物理ネットワークからクラウドへの移行？簡単じゃないですか。VPC作って、サブネット切って、VMインスタンス立てるだけ。3ヶ月もあれば余裕でしょ」
経営陣の前でそう胸を張って宣言した私。まさか、その後6ヶ月間地獄を見ることになるとは夢にも思いませんでした。
これは、20年間蓄積されたレガシーな物理ネットワークをGCPに移行しようとして炎上した、血と汗と涙の記録です。
第一章：「20年の負債」という現実
移行対象：想像を絶するレガシー環境
私たちが移行しようとしていたのは、創業時から20年間拡張し続けてきた物理ネットワークでした。
本社オフィス（従業員280名）の構成：
1
2
3
4
5
6
7
8
9
10
11
| インターネット (複数回線)
↓
[古いCisco Router] 192.168.1.1 (2005年製)
↓
[L2スイッチ群] (カスケード接続)
├─ 営業部: 192.168.10.0/24 (50台)
├─ 開発部: 192.168.20.0/24 (80台)
├─ 経理部: 192.168.30.0/24 (30台)
├─ 総務部: 192.168.40.0/24 (40台)
├─ サーバー群: 192.168.100.0/24 (15台)
└─ プリンター他: 192.168.200.0/24 (35台)
|
支社3箇所：
- 大阪支社（50名）
- 福岡支社（30名）
- 札幌支社（25名）
工場2箇所：
- 千葉工場（製造ライン制御システム）
- 群馬工場（品質管理システム）
「これをクラウドに移すだけでしょ？楽勝じゃん」
1月16日：最初の衝撃
実際に既存環境の詳細調査を開始して、愕然としました。
発見した問題群：
1. ネットワーク設計の無秩序さ
1
2
| # 実際のルーティングテーブル
ip route show
|
1
2
3
4
5
| 192.168.10.0/24 via 192.168.1.10 # 営業部（なぜかゲートウェイが違う）
192.168.20.0/24 via 192.168.1.1 # 開発部（標準）
192.168.30.0/24 via 192.168.1.15 # 経理部（また違う）
192.168.40.0/24 via 192.168.1.1 # 総務部（標準）
192.168.100.0/24 via 192.168.1.20 # サーバー（また違う）
|
「なんで各部署でゲートウェイが違うんだ…？」
2. レガシーシステムの依存関係
製造ライン制御システム（千葉工場）：
- OS: Windows Server 2003（サポート終了済み）
- アプリケーション: VB6で書かれた専用ソフト
- 通信: 特定のIPアドレス（192.168.100.5）にハードコード
- ベンダー: 既に倒産
品質管理システム（群馬工場）：
- OS: Red Hat Enterprise Linux 4（古すぎ）
- データベース: Oracle 9i（これも古い）
- ネットワーク: 固定IPでしか動作しない仕様
「これ…移行できるの？」
3. 謎の自作システム群
20年間で退職した歴代のIT担当者が作った「秘伝のタレ」システムが至る所に。
1
2
3
4
| # 謎のcronジョブ発見
crontab -l
0 2 * * * /home/legacy/mystery_sync.sh >> /dev/null 2>&1
30 3 * * * /usr/local/bin/old_backup.pl 192.168.100.10
|
mystery_sync.sh の中身：
1
2
3
4
5
6
7
8
9
10
11
| #!/bin/bash
# 作成者不明、作成日不明
# 何をやってるかわからないが、止めると何かが壊れる
rsync -av 192.168.100.5:/mysterious/data/ 192.168.100.10:/backup/
if [ $? -eq 0 ]; then
echo "Success" | mail -s "Daily Sync" someone@company.com
else
# 失敗時は何もしない（なぜ？）
exit 0
fi
|
「これ誰が作ったの…？何のためのスクリプト…？」
1月20日：移行計画書の提出
上司への報告：
「移行対象システムを調査した結果、予想より複雑でした。移行期間を6ヶ月に延長したいと思います」
上司：「何言ってるの？3ヶ月って約束したじゃない。4月1日の新年度から新システムでスタートする計画だから」
「でも、レガシーシステムが…」
上司：「言い訳しないで。できる方法を考えて」
追い込まれた私の無謀な判断：「フォークリフト移行」
第二章：2月の楽観 - 小規模から始める罠
移行戦略：段階的アプローチ
せめて段階的に移行しようと、以下の計画を立てました：
Phase 1（2月）: 札幌支社（25名、最小構成）
Phase 2（3月）: 大阪・福岡支社（80名）
Phase 3（3月後半）: 本社オフィス（280名）
Phase 4（4月）: 工場システム（最難関）
「小さいところから始めれば、問題も小さいはず」
2月5日：札幌支社移行開始
札幌支社の既存構成：
1
2
3
4
5
| [ルーター] 192.168.1.1
└─[スイッチ]
├─ PC: 192.168.1.100-125 (25台)
├─ サーバー: 192.168.1.10 (ファイルサーバー)
└─ プリンター: 192.168.1.200-202 (3台)
|
GCP移行後設計：
1
2
3
4
5
6
7
| Project: company-sapporo
VPC: sapporo-vpc (10.1.0.0/16)
Subnets:
- office-subnet: 10.1.1.0/24
- Compute Engine: 10.1.1.10-50
- server-subnet: 10.1.2.0/24
- File Server VM: 10.1.2.10
|
「シンプルで綺麗な設計。これならすぐできる」
2月10日：最初の地雷踏み
移行作業開始から5日目、最初の大問題が発生。
朝9時、札幌支社から緊急の電話：
「ファイルサーバーにアクセスできません！仕事になりません！」
調査の結果判明した問題：
1. Active Directoryドメインの依存関係
札幌のファイルサーバーは、東京本社のActive Directoryドメインコントローラーに依存していました。
1
2
3
| 東京本社 DC: 192.168.100.10 (物理)
↓ (VPN経由でドメイン認証)
札幌ファイルサーバー: 192.168.1.10 → 10.1.2.10 (GCP移行済み)
|
問題：
- GCP上のファイルサーバーから物理DC（192.168.100.10）への接続ができない
- VPN設定がActive Directory認証に対応していない
- 認証が通らないため、全ユーザーがファイルアクセス不可
2. 固定IPアドレスへの依存
1
2
| # 札幌支社の各PCに設定されていた共有ドライブ
net use Z: \\192.168.1.10\shared /persistent:yes
|
問題：
- 全PCで共有ドライブが192.168.1.10でハードコード
- 新しいIP（10.1.2.10）に変更する必要があるが、25台すべて手作業
- DNSも未整備で名前解決できない
3. プリンター設定の複雑怪奇な依存関係
1
2
| # 謎のプリンター管理システム
cat /etc/cups/printers.conf
|
なんと、札幌のプリンターの設定情報が東京のプリンター管理サーバー（192.168.100.15）で管理されていました。
依存関係の連鎖：
1
2
3
4
5
6
7
| 札幌PC → 札幌プリンター設定要求
↓
東京プリンター管理サーバー（192.168.100.15）
↓
設定ダウンロード → 札幌PC
↓
札幌プリンター（192.168.1.200）で印刷実行
|
「なんで札幌のプリンターが東京のサーバーに依存してるの…？」
2月12日：緊急回復作業
土日を使った緊急対応：
1
2
3
4
5
6
7
8
9
10
11
12
| # 1. VPN接続の緊急設定
gcloud compute vpn-gateways create sapporo-to-tokyo \
--region=asia-northeast1 \
--network=sapporo-vpc
# 2. 一時的なDNS設定
echo "10.1.2.10 fileserver.company.local" >> /etc/hosts
# 3. 全PCの設定変更（25台手作業）
# 各PCで実行：
net use Z: /delete
net use Z: \\10.1.2.10\shared
|
結果：
- 土日2日間徹夜作業
- 札幌支社は月曜から通常業務再開
- しかし、プリンター問題は未解決
「小規模な支社でもこんなに大変なんて…」
第三章：3月の崩壊 - 複雑さの爆発
3月1日：大阪・福岡支社の同時移行
札幌での経験を活かし、今度は事前調査を綿密に実施。
大阪支社（50名）の発見された複雑さ：
1. 部門間VLANの複雑な設定
1
2
3
4
5
6
7
8
9
10
| # 大阪支社のVLAN構成
vlan 10: 営業部 (192.168.10.0/24) - 30台
vlan 20: 技術部 (192.168.20.0/24) - 15台
vlan 30: 管理部 (192.168.30.0/24) - 5台
# 部門間通信制限
# 営業部 → 技術部：HTTP/HTTPSのみ許可
# 技術部 → 営業部：すべて拒否
# 管理部 → 全部門：全許可
# 全部門 → 管理部：特定ポートのみ
|
問題：
GCPのVPCファイアウォールルールで、この複雑なVLAN間通信制御を再現する必要がある。
2. 謎の業務システム群
大阪独自の顧客管理システム：
- 開発言語：Visual Basic 6.0
- データベース：Microsoft Access（.mdb形式）
- ネットワーク：特定の共有フォルダ（\192.168.10.5\database\）
- 作成者：10年前に退職したベテラン社員
1
2
3
4
5
6
7
8
9
10
11
| ' 実際のVB6コード（一部）
Private Sub ConnectToDatabase()
Dim dbPath As String
dbPath = "\\192.168.10.5\database\customer.mdb" ' ハードコード！
Set db = OpenDatabase(dbPath)
If db Is Nothing Then
MsgBox "データベースに接続できません", vbCritical
End
End If
End Sub
|
「IPアドレスがハードコードされてる…しかもアクセスファイル…」
3. 福岡支社の「独立王国」問題
3月5日、福岡支社調査で判明した事実：
福岡支社は、他の拠点とは完全に独立したネットワーク設計になっていました。
1
2
3
4
5
6
| 福岡支社独自システム:
- 独自ドメイン: fukuoka.local (本社とは別)
- 独自Active Directory: fukuoka-dc.fukuoka.local
- 独自メールサーバー: mail.fukuoka.local
- 独自ファイルサーバー: files.fukuoka.local
- 独自業務システム: sales.fukuoka.local
|
なぜこうなったのか？
2018年に福岡支社が独立採算制になった際、「本社のシステムに依存したくない」という支社長の判断で、完全に独立したシステムを構築していました。
問題：
- 福岡支社だけ移行方式が全く違う
- 統合的なGCPプロジェクト設計との整合性なし
- ユーザー管理、権限管理も独立
「これ、移行じゃなくて新規構築じゃん…」
3月15日：複数拠点同時移行の悪夢
準備期間1ヶ月で強行した結果：
移行当日のタイムライン
午前9時：移行開始
1
2
3
4
5
| # 大阪支社VPC作成
gcloud compute networks create osaka-vpc --subnet-mode=custom
# 福岡支社VPC作成
gcloud compute networks create fukuoka-vpc --subnet-mode=custom
|
午前11時：最初のトラブル
大阪支社のVLAN間通信制御ルールでミス。営業部から技術部への通信が完全遮断される。
午後1時：データ移行でエラー多発
大阪の顧客管理システム（VB6 + Access）のデータ移行で、文字エンコーディングエラーが多発。
1
2
3
| ERROR: Invalid character encoding in customer.mdb
ERROR: Record corruption detected in table [顧客マスタ]
ERROR: Primary key violation in [営業履歴]
|
午後3時：福岡支社で認証システム全滅
独立したActive Directoryの移行で設定ミス。全ユーザーがログインできない状態に。
午後5時：緊急ロールバック決定
「今日中に復旧させる！」という気持ちはあったものの、現実を受け入れることに。
1
2
3
4
5
6
7
| # 緊急ロールバック
# 大阪支社を物理環境に戻す
gcloud compute instances stop osaka-fileserver
gcloud compute instances stop osaka-dc
# 福岡支社も物理環境に戻す
gcloud compute instances stop fukuoka-systems --zone=asia-northeast1-a
|
3月16日：ステークホルダーからの総攻撃
緊急役員会議招集
経営陣：「なぜ移行に失敗したのか？」
私：「既存システムが想定以上に複雑で…」
営業部長：「大阪支社の顧客データが一部欠損した。どう責任取るの？」
技術部長：「福岡の独立システムの件、事前に把握してなかったの？」
総務部長：「移行費用が予算の2倍に膨らんでる。説明して」
追加で判明した問題：
- データ移行時の顧客情報230件が破損
- 福岡支社のメールシステムが12時間停止
- 大阪支社の給与計算システムが月末処理不可に
「完全に詰んだ…」
第四章：4月の絶望 - 本社移行の大惨事
4月1日：新年度開始と同時に本社移行強行
経営陣からの最後通牒：「新年度開始までに移行完了。これ以上延期は認めない」
本社（280名）の移行対象システム：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 部門別ネットワーク:
├─ 営業部: 192.168.10.0/24 (50台)
├─ 開発部: 192.168.20.0/24 (80台)
├─ 経理部: 192.168.30.0/24 (30台)
├─ 総務部: 192.168.40.0/24 (40台)
├─ 役員専用: 192.168.50.0/24 (10台)
└─ サーバー群: 192.168.100.0/24 (30台)
重要システム:
├─ Active Directory (Windows Server 2012)
├─ Exchange Server (メール)
├─ SAP ERP (基幹業務システム)
├─ 会計システム (弥生会計サーバー版)
├─ 人事システム (自社開発)
└─ ファイルサーバー群 (5台)
|
4月1日午前9時：移行開始
チーム体制：
- 私（プロジェクトリーダー）
- ネットワークエンジニア 2名
- システムエンジニア 3名
- 外部委託業者 5名
移行スケジュール：
- 09:00-12:00: システム停止・データバックアップ
- 12:00-15:00: GCPインスタンス作成・設定
- 15:00-18:00: データ移行・システム設定
- 18:00-20:00: 動作確認・調整
- 20:00: 新システム稼働開始
「今度こそ成功させる！」
4月1日午前11時：最初の致命的問題
SAPシステムの移行で想定外の事態：
1
2
3
4
5
| # SAP移行作業中のエラー
SAP System Copy Error:
Cannot connect to database instance
Network path not found: 192.168.100.20
License validation failed: Hardware fingerprint changed
|
判明した問題：
1. SAPライセンスの厳格な制限
SAPシステムは、サーバーのハードウェア固有情報（CPU ID、MAC アドレス等）でライセンス認証を行っていました。
物理サーバー:
- CPU ID: Intel-Xeon-E5-2680-v3-12C-24T
- MAC Address: 00:1B:21:A4:32:F8
- License Key: これらの情報から生成された固有キー
GCP Compute Engine:
- CPU ID: Google-Custom-CPU (仮想)
- MAC Address: 42:01:0A:80:00:XX (動的)
- License Key: 物理サーバーとは完全に異なる
「SAPライセンスの再取得が必要…でも手続きに2週間かかる…」
2. 会計システムの謎仕様
弥生会計サーバー版の隠された依存関係：
1
2
3
4
5
6
7
8
9
10
11
| ; 設定ファイル（隠しファイル）
[Network]
ServerIP=192.168.100.25
BackupPath=\\192.168.100.30\backup\accounting\
TempPath=C:\Windows\Temp\Yayoi\
PrinterServer=192.168.100.35
[Security]
AllowedClients=192.168.30.0/24
DenyOtherNetworks=TRUE
HardwareValidation=ENABLED
|
問題：
- IPアドレスが多数の箇所にハードコード
- 経理部のサブネット（192.168.30.0/24）からのみ接続許可
- ハードウェア認証も有効
4月1日午後2時：連鎖的システム障害
人事システムで発見された致命的欠陥：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| # 人事システムの一部（Python 2.7）
def get_employee_data():
# 直接IP指定でのデータベース接続
conn = psycopg2.connect(
host="192.168.100.40", # PostgreSQL Server
port=5432,
database="hr_system",
user="hr_user",
password="hr_pass_2019" # 古いパスワード
)
return conn
def print_salary_report():
# プリンターサーバーに直接出力
printer_server = "\\\\192.168.100.50\\HP_LaserJet_5000"
os.system(f"copy salary_report.pdf {printer_server}")
|
発見された深刻な問題：
- Python 2.7: サポート終了済み、GCPのイメージに存在しない
- PostgreSQL 8.4: 古すぎてGCPのマネージドサービス対象外
- プリンター直結: ネットワークプリンターとの直接通信
- ハードコードまつり: 設定ファイルではなくソースコードに直書き
4月1日午後4時：全社システム停止
エラーの連鎖：
1
2
3
4
5
| 16:00 - SAP ERP停止 → 営業・経理業務停止
16:15 - 会計システム接続不可 → 経理部作業不可
16:30 - 人事システムエラー → 給与・勤怠管理不可
16:45 - Exchange Server移行失敗 → 全社メール停止
17:00 - ファイルサーバー認証エラー → 共有フォルダアクセス不可
|
社内の状況：
- 営業部：「顧客対応できない！見積もりシステム使えない！」
- 経理部：「月末処理が今日までなのに、会計システム動かない！」
- 人事部：「給与計算システムが止まってる！今日給与振込日だよ！」
- 開発部：「ソースコード管理サーバーアクセスできない！」
4月1日午後8時：緊急事態宣言
CEO直々の緊急指示：
「明日の業務開始（9時）までに全システム復旧。できなければプロジェクト中止、担当者処分」
午後8時からの緊急対応：
1
2
3
4
5
6
7
8
9
10
| # 全GCPリソース緊急停止
gcloud compute instances stop --all --quiet
# 物理システム緊急復旧
for server in $(cat physical_servers.txt); do
ssh root@$server "systemctl start all_services"
done
# ネットワーク設定復旧
./restore_physical_network.sh
|
徹夜の復旧作業：
- 午後9時〜午前3時: 物理システムの緊急復旧
- 午前3時〜午前6時: データ整合性チェック
- 午前6時〜午前8時: 動作確認
4月2日午前9時：辛うじて業務再開
復旧結果：
- 基幹システム: 95%復旧
- メールシステム: 100%復旧
- ファイルサーバー: 90%復旧（一部データロス）
しかし、残された問題：
- SAP ERPの一部データが破損（受注データ50件）
- 会計システムの3月締め処理が未完了
- 人事システムの勤怠データが一部消失
「なんとか最低限は動いているが…」
第五章：工場システム移行の断念と方針転換
4月15日：工場システム移行の中止決定
本社移行の大混乱を受け、最も危険度が高い工場システム移行は中止となりました。
千葉工場の製造ライン制御システム：
- Windows Server 2003（20年稼働中）
- VB6製の制御ソフトウェア（ソースコード紛失）
- 製造機械との専用通信プロトコル
- 停止 = 生産ライン完全停止 = 日産3000万円の損失
群馬工場の品質管理システム：
- Red Hat Enterprise Linux 4（17年稼働中）
- Oracle 9i（メーカーサポート終了済み）
- 計測機器との直接通信（RS-232C, Ethernet）
- 停止 = 品質検査不可 = 出荷停止
「これを移行するなんて自殺行為だ…」
4月20日：プロジェクトの抜本的見直し
新方針：段階的ハイブリッド化
完全移行を諦め、以下の方針に転換：
Phase 1: 新規システムのクラウド化（即座に開始）
- 新しく導入するシステムはGCPネイティブ
- 既存システムとの連携は最小限
Phase 2: 移行可能システムの個別移行（6ヶ月計画）
- リスクが低く、移行メリットが明確なシステム
- 十分な検証期間を確保
Phase 3: レガシーシステムの現状維持（当面継続）
- 工場システム等、リスクが高すぎるもの
- 段階的なモダナイゼーション検討
Phase 4: ハイブリッドインフラの最適化（1年計画）
- オンプレミスとクラウドの適切な連携
- セキュリティとパフォーマンスの両立
第六章：学習と改善 - 正しい移行戦略
5月〜10月：段階的改善の実施
失敗から学んだ教訓を活かし、正しい移行戦略を実践しました。
成功例1: 新規Webアプリケーションのクラウド化
6月：顧客ポータルサイト新規開発
1
2
3
4
5
6
7
8
9
| # 正しいクラウドネイティブ設計
Project: customer-portal
Architecture:
Frontend: React (Cloud Run)
Backend: Node.js API (Cloud Run)
Database: Cloud SQL (PostgreSQL)
Storage: Cloud Storage
CDN: Cloud CDN
Monitoring: Cloud Operations Suite
|
結果：
- 開発期間: 3ヶ月（予定通り）
- 運用コスト: 従来の60%削減
- パフォーマンス: レスポンス時間50%改善
- 可用性: 99.95%達成
成功例2: 営業支援システムの段階的移行
7月〜9月：営業支援システム（SFA）移行
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Stage 1 (7月): データレプリケーション開始
- 物理DB → Cloud SQL 同期設定
- 既存システム継続稼働
- データ整合性検証
Stage 2 (8月): アプリケーション移行
- Web UI を Cloud Run に移行
- バックエンドAPI を Cloud Functions に分割
- 段階的ロードバランシング
Stage 3 (9月): 完全移行
- 物理システム停止
- DNS切り替え
- モニタリング強化
|
移行結果：
- ダウンタイム: 2時間（計画内）
- データロス: 0件
- ユーザー満足度: 向上（レスポンス時間改善）
成功例3: ファイルサーバーのクラウド移行
8月〜10月：ファイルサーバー統合
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| 移行戦略:
Old: 5台の物理ファイルサーバー
New: Cloud Storage + Cloud Filestore
Phase 1: データ分析・分類
- アクセス頻度分析
- データ分類（Hot/Cold/Archive）
- 権限マトリクス整理
Phase 2: 段階的移行
- Archive データ → Cloud Storage (Coldline)
- Cold データ → Cloud Storage (Nearline)
- Hot データ → Cloud Filestore (NFS)
Phase 3: アクセス方式最適化
- 直接アクセス: Cloud Filestore
- Web経由: Cloud Storage + CDN
- モバイル: Cloud Storage APIs
|
正しい移行戦略の教訓
1. 事前調査の重要性
失敗時の調査：
- 表面的なシステム構成のみ
- 依存関係の把握不足
- 利害関係者へのヒアリング不十分
改善後の調査：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| ## システム移行事前調査チェックリスト
### 技術的調査
- [ ] ネットワーク構成図（物理・論理）
- [ ] システム依存関係マップ
- [ ] データフロー図
- [ ] API・通信プロトコル一覧
- [ ] ライセンス・認証方式確認
- [ ] パフォーマンス要件定義
### 業務的調査
- [ ] 利用部署・ユーザー特定
- [ ] 業務フロー・利用パターン
- [ ] ピーク時間・処理量
- [ ] SLA・可用性要件
- [ ] コンプライアンス要件
### 組織的調査
- [ ] ステークホルダー特定
- [ ] 意思決定プロセス
- [ ] 予算・リソース確認
- [ ] リスク許容度
- [ ] 成功指標定義
|
2. 段階的移行の原則
失敗時のアプローチ：
- フォークリフト移行（一括移行）
- 大きなスコープで一気に実行
- バックアップ戦略不十分
改善後のアプローチ：
1
2
3
4
5
6
7
8
9
10
11
12
| 段階的移行戦略:
Phase 0: 調査・計画 (1-2ヶ月)
Phase 1: 非重要システム先行移行 (1ヶ月)
Phase 2: 重要度中システム移行 (2ヶ月)
Phase 3: 重要システム移行 (3-4ヶ月)
Phase 4: 最適化・統合 (1-2ヶ月)
各Phaseの原則:
- 小さなスコープ
- 十分な検証期間
- ロールバック戦略
- ステークホルダー承認
|
3. リスク管理フレームワーク
移行リスクマトリクス：
| システム | 移行難易度 | 業務影響度 | 優先度 | 戦略 |
|---|
| 新規システム | 低 | 中 | 高 | クラウドネイティブ |
| Web アプリ | 低 | 高 | 高 | 段階的移行 |
| ファイルサーバー | 中 | 中 | 中 | ハイブリッド |
| 基幹システム | 高 | 高 | 低 | 現状維持 |
| 工場システム | 極高 | 極高 | 除外 | モダナイゼーション検討 |
第七章：1年後の振り返りと成果
2026年1月：プロジェクト完了報告
最終的な移行結果（1年間）:
移行完了システム
- 新規システム: 100% クラウドネイティブ
- Webアプリケーション: 85% 移行完了
- ファイル・ストレージ: 70% 移行完了
- 開発・テスト環境: 100% クラウド化
現状維持システム
- 基幹システム（SAP/会計）: オンプレミス継続
- 工場制御システム: オンプレミス継続
- レガシー業務システム: 段階的モダナイゼーション中
ハイブリッド環境
- オンプレミス ⟷ GCP間: 安定したVPN接続
- 統合監視システム: Cloud Operations Suite
- 統合ID管理: Google Cloud Identity
数値で見る成果
コスト効果：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 従来（物理環境のみ）:
- インフラコスト: ¥15M/年
- 運用人件費: ¥25M/年
- メンテナンス費: ¥8M/年
- 電力・設備費: ¥5M/年
Total: ¥53M/年
現在（ハイブリッド環境）:
- GCPコスト: ¥8M/年
- 物理インフラコスト: ¥6M/年（縮小）
- 運用人件費: ¥18M/年（効率化）
- メンテナンス費: ¥3M/年（削減）
- 電力・設備費: ¥2M/年（削減）
Total: ¥37M/年
年間削減効果: ¥16M（30%削減）
|
パフォーマンス改善：
1
2
3
4
5
6
7
8
9
10
11
| システム可用性:
- 移行前: 97.8%（月間約16時間停止）
- 移行後: 99.5%（月間約4時間停止）
Webアプリケーション応答時間:
- 移行前: 平均 2.3秒
- 移行後: 平均 0.8秒（65%改善）
開発・デプロイ時間:
- 移行前: 新機能リリースまで平均 3週間
- 移行後: 新機能リリースまで平均 1週間
|
組織的改善：
1
2
3
4
5
6
7
8
9
10
11
| IT部門の業務配分:
- 移行前: 運用保守 70%, 新規開発 30%
- 移行後: 運用保守 40%, 新規開発 60%
エンジニア満足度:
- 移行前: 6.2/10（レガシー運用の負担）
- 移行後: 8.1/10（モダンな技術での開発）
事業部門の満足度:
- 移行前: 7.0/10（安定だが改善速度遅い）
- 移行後: 8.5/10（新機能の迅速な提供）
|
最も価値のあった学び
1. 完璧な移行より、実用的なハイブリッド
従来の思考：
「全てをクラウドに移行しなければ意味がない」
学んだ真実：
「適切なシステムを適切な場所に配置することが重要」
2. 技術的課題より組織的課題の方が困難
技術的問題:
組織的問題（より困難）:
3. 小さな成功の積み重ねが信頼を作る
初期の大失敗で失った信頼を、小さな成功の積み重ねで回復。
信頼回復のプロセス：
1
2
3
4
| Month 1-3: 大失敗（信頼度 2/10）
Month 4-6: 小さな成功×3（信頼度 4/10）
Month 7-9: 中規模成功×2（信頼度 6/10）
Month 10-12: 大きな成功×1（信頼度 8/10）
|
まとめ：¥3,000万円と6ヶ月の地獄で学んだこと
プロジェクトの総コスト
直接コスト：
- 移行作業費用: ¥12M
- システム復旧費用: ¥8M
- 外部コンサル費用: ¥6M
- GCP利用料（失敗分）: ¥2M
間接コスト：
- 業務停止による機会損失: ¥15M
- データ復旧作業: ¥3M
- 追加人件費（残業・休日出勤）: ¥4M
総コスト: ¥50M
うち無駄になった費用: ¥30M
最も重要な教訓
1. 「簡単でしょ」は技術者の最大の罠
20年蓄積されたレガシーシステムの移行は、決して簡単ではない。
- 見えない依存関係
- 失われた知識（作成者の退職）
- ハードコードされた設定
- 業務フローとの密結合
2. 段階的アプローチは面倒だが、結果的に最速
一括移行の誘惑:
- 「一気にやった方が効率的」
- 「切り戻しのコストを考えると…」
- 「プロジェクト期間を短縮したい」
現実:
一括移行の失敗リスクを考慮すると、段階的移行が最も確実で最終的に最速。
3. 技術的解決策より、組織的解決策が重要
成功の要因:
利害関係者との調整、期待値管理、変化管理が移行成功の鍵。
他の組織への提言
クラウド移行前のチェックリスト
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ## レガシーシステム移行前必須チェック
### Level 1: 移行可能性評価
- [ ] システム作成年度・技術スタック確認
- [ ] 作成者・保守担当者の在籍確認
- [ ] ソースコード・設計書の有無確認
- [ ] ライセンス・契約条件の確認
### Level 2: 依存関係調査
- [ ] システム間通信の完全マッピング
- [ ] データフロー図の作成
- [ ] ネットワーク依存関係の特定
- [ ] 外部システム・サービスとの連携確認
### Level 3: ビジネス影響度評価
- [ ] 停止時の業務影響範囲特定
- [ ] SLA・可用性要件の確認
- [ ] ピーク時間・処理量の把握
- [ ] 法規制・コンプライアンス要件確認
### Level 4: リスク評価・対策
- [ ] 移行失敗時の影響度算出
- [ ] ロールバック戦略の策定
- [ ] 緊急時連絡体制の整備
- [ ] バックアップ・復旧テストの実施
|
推奨移行戦略
Green Field（新規開発）優先アプローチ:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| Priority 1: 新規システム
- 100% クラウドネイティブ
- 最新のアーキテクチャ・技術選択
- 既存システムとの最小限連携
Priority 2: Web フロントエンド
- 比較的移行リスク低
- ユーザー体験改善効果大
- 段階的移行可能
Priority 3: データ・ストレージ
- バックアップ・DR効果大
- 段階的移行可能
- 既存システムとの共存可能
Priority 4: 基幹システム
- モダナイゼーション検討
- 長期計画（3-5年）
- 現状維持も選択肢
|
最後に：失敗から学ぶ価値
この6ヶ月の地獄は確かに辛い経験でしたが、結果的に私たちのIT組織を大きく成長させました。
得られたもの：
- レガシーシステムへの深い理解
- リスク管理の重要性の認識
- 段階的アプローチのスキル
- ステークホルダーマネジメント力
- チーム結束力の向上
最も大切な学び：
失敗を恐れてチャレンジしないより、失敗から学んで改善し続けることの価値。
同じような移行プロジェクトに取り組む皆さんが、私たちと同じ失敗を繰り返さないことを祈っています。
そして、もし失敗しても諦めずに改善し続けることで、必ず成功に辿り着けることを信じています。
関連記事：
注意： この記事は実際の移行プロジェクト経験に基づいていますが、企業名やシステム詳細は匿名化・一般化しています。
