Level 0：既存オンプレミスCRM

Architecture Journey「Business Systems」の出発点です。まだAWSは登場しません。ここでは、これから移行していく架空企業と、そのCRM・SFAが抱える課題を確認します。

今回の企業・業務状況

• 業種：法人向けサービス企業（中堅B2B）
• 社員数：300人
• CRM利用者：80人（営業・管理者）
• 顧客データ：約10万件
• 主な利用時間：平日8時〜20時
• 開発・運用担当：3〜5人
• 扱う情報：顧客、担当者、商談、営業履歴、添付資料

この後のLevel 1以降でも、扱う業務内容そのものは変わりません。変わるのは、これをどう安全に・止めずに・拡張しやすく動かすかというアーキテクチャ側です。

現在のアーキテクチャ

社内ネットワークに設置されたWebサーバーとデータベースサーバーで構成されており、添付資料（提案書・見積書など）は別のファイルサーバーに保存されています。

システム構成の詳細

大企業の情報システム部門が外部SIerに構築を委託した、典型的なオンプレミス3層構成です。

役割	台数・構成	スペック	OS	ミドルウェア／DB	備考
Webサーバー	2台（負荷分散なし、片系は障害時の手動切替用）	物理サーバー、4コア／メモリ16GB	Windows Server 2012 R2	IIS 8.5、.NET Framework 4.5	OSは既にメーカーサポート終了（EOS）済み
APサーバー	Webサーバーに同居	-	-	業務ロジックはASP.NETアプリケーションとして実装	Web層とアプリ層が分離されていない
DBサーバー	1台（単一構成、クラスタなし）	物理サーバー、8コア／メモリ32GB、RAID5	Windows Server 2012 R2	SQL Server 2014 Standard Edition	ライセンスの都合でAlways On等の高可用機能は未使用
ファイルサーバー	1台	NAS、RAID5、実容量2TB（残容量約20%）	-	SMB共有	提案書・見積書等の添付資料を保管
バックアップ	テープ装置1台	LTO6、週次フル＋日次差分	-	-	過去1年間、リストア試験は未実施

運用体制の実態

• 保守は社内情報システム部門（3〜5人）と、構築を担当した外部SIerとの年間保守契約の組み合わせで成り立っている
• 検証環境が存在しないため、OS・ミドルウェアのパッチは四半期に一度、深夜メンテナンス枠で本番環境へ直接適用している
• 変更作業の記録は情報システム部門内の口頭確認・個人メモにとどまり、変更履歴を追跡する仕組みがない
• 監視は、Windowsサーバー標準のイベントログとリソースモニタを担当者が定期的に目視確認するのみで、自動アラートは存在しない

情報システム部門・現場からの要望

発信元	要望
経営層	障害による営業機会の損失を防ぎたい。IT投資を「守りの保守」から「攻めの投資」へ転換したい
営業部門（現場）	外出先や客先からリアルタイムに商談情報を確認・更新したい
情報システム部門	OSのサポート終了に伴うセキュリティリスクを解消したい。ハードウェア保守契約の更新コストを削減したい
情報システム部門（運用担当の本音）	属人化した運用から脱却し、変更履歴が残る仕組みにしたい。深夜メンテナンスの負担を減らしたい

発生した課題

課題	具体的な影響
老朽化	Windows Server 2012 R2は既にEOS済みで、脆弱性が発見されてもベンダーからの修正パッチが提供されない。故障時の交換部品調達にも時間がかかる。
属人化	バックアップ運用・変更作業が特定の担当者の記憶と個人メモに依存しており、変更履歴を追跡できない。
拡張困難	顧客データと添付ファイルが別サーバーに分散しており管理が煩雑。開発環境と本番環境が分離されておらず、変更のたびにリスクを伴う。
社外アクセス不可	社内ネットワークからしか利用できず、外出中の営業担当が使えない。
監視体制の不足	自動アラートの仕組みがなく、担当者の目視確認が遅れると障害の発見自体が遅れる。障害発生時の復旧にも時間がかかり、業務が長時間停止する。
検証環境の不在	パッチ適用や変更を検証する環境がなく、本番環境へ直接適用せざるを得ない。結果として、パッチ適用自体を先送りする判断につながっている。

この構成の限界

社内ネットワーク前提の構成では、リモートワークや外出先からの利用に対応できません。単一のサーバー群・単一データセンターに依存しているため、障害・災害への耐性が低く、事業継続性の観点でもリスクを抱えています。加えて、OSがEOS済みであることは、機能面より先にセキュリティ面の限界として扱うべき問題です。検証環境がないままパッチ適用を続ける、あるいは先送りし続けるという運用のどちらも、リスクを増やす方向にしか働きません。

次のLevelで改善する点

まずはアプリケーションを大きく作り変えず、安全にAWSへ移行することを目指します。Level 1：AWSへの初期移行で、VPC・EC2・RDSを中心とした最小構成での移行を扱います。