【移行地獄】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. 技術的課題より組織的課題の方が困難

技術的問題:

IP アドレス変更
システム間連携
データ移行

組織的問題（より困難）:

部門間の利害調整
変化への抵抗
責任範囲の曖昧さ

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. 技術的解決策より、組織的解決策が重要

成功の要因:

技術的な正確性: 30%
組織的な調整力: 70%

利害関係者との調整、期待値管理、変化管理が移行成功の鍵。

他の組織への提言

クラウド移行前のチェックリスト

 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組織を大きく成長させました。

得られたもの：

レガシーシステムへの深い理解
リスク管理の重要性の認識
段階的アプローチのスキル
ステークホルダーマネジメント力
チーム結束力の向上

最も大切な学び： 失敗を恐れてチャレンジしないより、失敗から学んで改善し続けることの価値。

同じような移行プロジェクトに取り組む皆さんが、私たちと同じ失敗を繰り返さないことを祈っています。

そして、もし失敗しても諦めずに改善し続けることで、必ず成功に辿り着けることを信じています。

関連記事：

注意： この記事は実際の移行プロジェクト経験に基づいていますが、企業名やシステム詳細は匿名化・一般化しています。