1．はじめに

近年，東日本大震災によるBCP対策への意識の高まり等を背景に，データセンタの移転を行う企業が増加している．一方，大企業の基幹システムは大規模で複雑なことから，移転プロジェクトには多大な工数と移転時のリスクという2つの課題がある．

本稿では，東京海上日動システムズ（以下，東京海上日動システムズまたは同社）のデータセンタ移転プロジェクトを取り上げる．同社は東京海上日動火災保険（株）（以下，東京海上日動）を親会社とする情報システム子会社である．本稿では，同社の移転プロジェクトに際して，課題解決の実践から得られたプラクティスについて報告する．

同社では，プロジェクト終了後に移転に要した工数を定量的に分析したところ，物理的な情報システムの移転以前に移転プロジェクトの全工数のうち約3割を完了しており，工数の平準化による工数問題の課題解決を実現していた．さらに，プロジェクトメンバにアンケート調査を実施し，さらなる課題（移転方式の検討，メインフレームの問題，広域分散技術への対応）を抽出したので，それも併せて報告する．

本稿の対象範囲と用語の定義は次の通りである．本稿で対象とする情報システムは，大企業または中堅企業の企業情報システムであり，企業の主たる事業の運営を支えるための基幹システム（金融機関は勘定系システム）とする．データセンタとは情報システムを設置するための専用の施設であり，自社保有か外部利用（商用データセンタ）かは問わない．データセンタの移転とは，データセンタ内に設置している情報システムの移設およびそれに付随するシステム運用業務の移行をいう．なお，本稿はデータセンタのユーザである企業の視点から論じるものであり，運営者側から述べるものではない．

2．先行研究・先行事例

データセンタに関する先行研究では，運営サイドによる電力･空調等の設備（ファシリティ）関連の論点を除くと，システム運用に関する応用研究が多く，その中でも近年のデータセンタの「大規模化」と「多拠点化」に対応する研究が多い．まず，大規模化に対する解決策としては，システム運用の効率を上げる方向である．データセンタの運営コストの6割を占める運用管理コストの削減のため運用設計段階での操作手順の作成作業をシンプルにする研究[1]や増大するコンピュータリソースの情報取得時間を短縮する研究[2]などがある．次に，多拠点化に対する解決策としてはリモートでの運用を可能にする方向である．分散配置されるデータセンタのシステム運用のリモート監視による障害原因個所を推定する方式の研究[3]やリモート運行の際のコマンドレベルの研究[4]などがある．海外でもリモート監視のようなシステム運用に関する研究はいくつもあるが，クラウドへの貢献を目的にしたものが多い[5]．

以上，データセンタのシステム運用に関する先行研究をまとめると次の通りである．本稿ではシステム運用におけるこれら2つの流れから，次章の実践内容の着想を得ている．

（1）データセンタの大規模化への対策としては，効率化の流れがある．

（2）データセンタの多拠点化への対策としては，リモート化の流れがある．

先行事例では，データセンタの移転に関して発表されているものは国内外ともに少ない．海外ではスイスの企業がクラウドを用いてリスクを回避した事例が興味深い[6]．国内では用意周到な準備でプロジェクトを成功させた事例[7]や大規模自然災害のリスクを回避するために海外へ移転した事例[8]も出ている．特筆すべきはデータセンタ移転の失敗事例[9]であり，この事例からもデータセンタ移転プロジェクトの難易度が高いことが分かる．

企業にとってデータセンタ移転は数年から十数年に一度のプロジェクトであり，品質やコストや期間などQCDすべての面で難易度の高いプロジェクトである．とりわけ大規模かつ複雑な情報システムの場合には移転が容易ではない．調査会社のガートナー社によるレポート[10]においても，「データセンタ移行プロジェクトの多くは，すべての期待に応えることは困難であり，予定通りに完了することは稀である」との調査結果もある．

3．実践ー移転プロジェクトの内容

3.1　プロジェクトの背景・課題

東京海上日動は従業員数1.7万人，386の営業室･課･支社，243の損害サービス拠点を持つ損害保険会社である．一般事業会社の売上高にあたる正味収入保険料は2.1兆円，総資産は9.7兆円，代理店数は5.1万店である（2018年3月末現在．小数点以下2桁目を四捨五入）．東京海上日動システムズ（同社）は東京海上日動のすべての情報システムの開発および運用を担う情報システム子会社である．東京海上日動のIT体制は，本体のIT企画部が企画部門を担い，同社が開発部門と運用部門を担うという役割分担である．

同社が運用する情報システムは保険業務という「いざというときに役立つためのシステム」であり，以前からバックアップ対策には力を入れてきた経緯であるが，2011年の東日本大震災を機に，2012年にBCP対策の強化を目的にサブセンタの移転プロジェクトが計画された．なお，同社のサブセンタの主たる役割はメインセンタのバックアップ機能であるが，日曜日のみサブセンタで基幹システム（勘定系システム）を稼働させている．それゆえ，その日はサブセンタといえども停止は許されず，メインセンタと同じレベルの高い可用性が求められる．つまり，同社のサブセンタは通常時も情報システムが稼働している重要なデータセンタの1つである．

しかしながら，そのプロジェクトでは次の2つの課題が懸念された．1つ目の課題は工数の問題である．移転プロジェクトはIT部門の中でシステム運用部門が中心に担うことになるが，開発部門に比して人員が少なく，また通常の運用業務を担いながらのプロジェクト遂行となるため，彼らが担うにはプロジェクトの規模が大きすぎると考えられた．特に，キーパーソンとなるシステム運用のスペシャリストは2名しかいなため，彼らをプロジェクトにどのように参画させるかがプロジェクトのポイントの1つであった．

2つ目の課題は，移転に伴うリスクが大きすぎることである．ここで想定されるリスクとは，たとえば，移転時の作業ミスや情報システムの破損によるシステム障害の発生である．同社は国内でも有数の大規模かつ複雑な情報システムを有しており，万が一にも重大なシステム障害が発生すれば社会的な影響は甚大であり，移転時のリスクを極力減らさなくてはならない．

また，同社においてデータセンタの移転プロジェクトは18年振りであったため，経営層から「これを機に次世代のデータセンタの在り方を踏まえたプロジェクトにしてほしい」との指示もあった．

3.2　課題解決のプラクティス

本プロジェクトでは，前節で述べた工数不足と移転リスクという2つの課題を解決するために，以下を実践した．

まず，プロジェクトを2つのフェイズ（フェイズ1とフェイズ2）に分割し，フェイズ1ではシステム運用業務を先に移行し，それが完了した後に情報システム本体の移転を行うことにした．これにより，プロジェクトの期間がやや伸びるものの，運用部門の要員の工数を平準化できる．また，情報システム移転時のリスク軽減の観点からも，さまざまなことを同じ時期にリリースするよりも障害発生時の影響を分散できると考えた．

また，次世代のデータセンタの在り方を踏まえ，今後の情報システムのグローバル化やクラウド化を前提に，新しいサブセンタは完全無人化・ペーパーレス化のデータセンタを志向した．具体的には，新しいセンタではテープ業務・運行業務・印刷業務・監視業務といった人間が介在する業務プロセスは一切行わず，常駐要員のオフィスも設置しない方針とした．これにより将来に向けて「さらに移転しやすい状態」を作り上げることを狙いとした．

以上をまとめると表1の通りである．システム運用業務はすべて「なくす」もしくは「他へ移す」という対応方針とした．なくすためには代替策を実施のうえ業務を廃止した．他へ移行するためには，昨今のリモート技術を駆使して，リモート化（メインセンタからリモートで実施），別拠点化（メインセンタ・サブセンタ以外に拠点を設ける），アウトソース化（業務をベンダへ委託する），クラウド化（ベンダのサービスを利用する）という4つの手法を駆使して実現を図った．情報システム本体はこれを機にスリム化し，それが完了してから移転を行う方針とした．これにより情報システムの移転工数の軽減を図った．

本プロジェクトは以下の2つのフェイズと7つの施策から構成された．プロジェクトの概要を図1に示す．施策①～⑤はシステム運用業務に関する移転であり，本プロジェクトを機にこれらを新しいサブセンタから切り離したことに最大の特徴がある．

以上のようにプロジェクトを2つのフェイズに分けることにより，工数の平準化を図った．また，キーパーソンであるシステム運用のスペシャリスト2名が，フェイズ1とフェイズ2の両方のプロジェクトに参加できるように計画した．

本プロジェクトの構成

【フェイズ1】

• 施策①：テープ業務の廃止
• 施策②：運行業務の移行（リモート化）
• 施策③：オフィスの移転（別拠点化）
• 施策④：印刷業務の移行（アウトソース化）
• 施策⑤：監視業務の移行（クラウド化）
• 施策⑥：情報システムのスリム化

【フェイズ2】

• 施策⑦：情報システムの移転

一方，移転時のリスク軽減を図る目的から，移転対象となる情報システムに対して，今回のプロジェクトを機に最新技術の適用（既存システムへの機能追加や変更）は実施しない方針とした．既存システムへの機能追加や変更によりシステム障害を発生させる可能性があることから，そういった要因は極力排除することとした．つまり，本プロジェクトにおいては，最新技術の適用よりもリスクの排除の方が重要であるとの判断がなされた．さらに，情報システムの移転（施策⑦）を実施する1カ月前からは，変更作業の凍結（いっさいの変更を行わない措置）を実施することとした．

また，移転時のリスク軽減のために，システム障害が発生した場合の代替策の準備も行うこととした．たとえば，移転対象システムの最も重要な機能の1つである保険契約情報の照会については，最悪の場合を想定して，簡便な別システムを新規作成して即座に切り替る計画とした．

3.3　プロジェクトの詳細と工数

本節ではプロジェクトの詳細として7つの施策の内容と各施策で要した工数について述べる．なお，本稿で用いる工数はすべて社員のみの数値であり，外注先のそれは含まれていない．工数の実績は，同社の社員が毎日入力する業務実績システム（15分単位）の集計結果にもとづくものであり，精度の高い数値である．

施策①：テープ業務の廃止

テープ業務とは，メインフレームの外付けテープ装置を使用した業務であり，主に長期保存データのバックアップや社外とのデータ交換でテープ装置を使用していた．これらの業務は従来から少しずつ削減してきた経緯であるが，プロジェクト実施前の時点でまだ12台のテープ装置と約1万本のテープを保有していた．本プロジェクトを機にこれらをすべて廃止した．具体的には，従来はテープに保存していたデータをディスク保存に変更し，社外とのデータ交換を伝送に切り替えた．

この施策には7人月の工数を要した．

施策②：運行業務の移行（リモート化）

運行業務の移行とは，オペレータによる手動でのコマンド投入等の作業を移行する施策である．同社では，運行業務に常時2名の要員（協力会社社員）が従事していた．これらの作業は次々と自動化してきた経緯であるが，例外的な処理や古いシステムのために，いまだに多数の手作業が残っている．運行業務はこれを機にメインセンタからリモートで実施する仕組み・体制とした．運行業務の移行に際してアウトソース化等の手法ではなく自社内での移行（サブセンタからメインセンタ）を選択した理由は，運行業務の集約による要員の効率化を図るためである．

リモートでの運行業務は，オープン系システムについては以前から技術的に可能であったが，メインフレーム系については近年実用化してきた技術である．同社のようにオープン系とメインフレーム系が複雑に絡み合っている巨大システムの場合，遅れた技術に合わせることになり，基本的にはオンサイトで運行を実施していた．

この施策には9人月の工数を要した．

施策③：オフィスの移転（別拠点化）

オフィスの移転とは，サブセンタ内のオフィスに常駐していた要員（同社社員および協力会社社員）と事務室を別の場所に移転する施策である．データセンタ内にオフィスを設けると家賃が高額であること，サブセンタと同じ地方に所在すること（災害時等に駆け付ける必要性がある）という2つの理由から，オフィスはサブセンタと同じ地区の通常のオフィスビルに移転する選択を行った（本稿ではそれを「別拠点化」と称している）．

サブセンタではシステム運用の要員として33名が常駐していたが，そのうち12名が別拠点へ異動した．21名の削減が可能となったのは，施策①②④⑤によってシステム運用の要員が削減できたからである．

この施策に要した工数は38人月である．主に要員を異動するための人事的な作業と事務室を移設するための総務的な作業である．

施策④：印刷業務の移行（アウトソース化）

印刷業務の移行とは，サブセンタで行っていた大型プリンタでの帳票印刷とそれに付随する整備・発送業務をアウトソーサへ移行する施策である．同社では，3台の大型プリンタを保有し，年間約1,000万枚の印刷を行っていた．保険会社のビジネスプロセスは未だに紙が多く，毎年すべてのお客様（保険契約者）に更改申込書や保険証券を送付し，万が一保険事故が起きた場合にはさらに多くの書類を送付している．本プロジェクトではこれらすべての印刷帳票をアウトソーサへ移行した．

本施策のポイントは，社内で移行せずに外部ベンダへアウトソースしたことである．以上の通り保険会社にとって印刷物は重要であるものの，印刷業務は保険会社のコア業務ではないと判断し，全面的なアウトソース化に移行する方針とした．また，アウトソースした方がコスト的に安価となることも，それを採用した理由の1つである．以上によりサブセンタは紙をまったく扱わないペーパーレスのセンタとなった．

この施策には55人月の工数を要した．

施策⑤：監視業務の移行（クラウド化）

監視業務とは，システムが安定稼働しているか，エラーメッセージ等が出力されていないかを確認して，何かあればシステム障害の初動対応へ連携する業務である．同社では，監視業務に常時1名の要員（協力会社社員）が従事していた．

本施策のポイントはクラウド化であり，これを機に監視システムをクラウドへ移行した．施策②の運行業務は本プロジェクトを機にリモート化（社内での移行による業務集約）したが，監視業務については従来からメインセンタへリモート化されていた．本プロジェクトで実施したことは，この監視業務を行うためのシステムをメインセンタでもサブセンタでもない，外部ベンダのクラウドサービスへ移行したことである．これは安価で信頼性の高いサービスの新技術の登場に拠るものであり，今後サブセンタの移行で実績が出れば，メインセンタのそれも移行を検討する予定である．

この施策に要した工数は5人月である．

施策⑥：情報システムのスリム化

情報システムのスリム化とは，サブセンタに設置されているコンピュータのハードウェア（メインフレーム，サーバ等）とソフトウェア（基本ソフトウェア，ミドルウェア，アプリケーション等）とデータ（データベース等）を極力小さくするための施策である．いくつか実施した施策の中で最も効果が大きかったのは，バックアップシステムのスリム化である．コマンド投入の自動化，不要なプロセスの削減，プロセスの並べ替え，稼働確認の省略などの簡素化等である．これらにより，従来約300個あったバックアップへの切替手順のプロセスを半分の約150個にまで減らすことができた．バックアップシステムの立ち上げ時間も127時間から80時間へと約4割削減できた．施策⑦の情報システムの移転はこのスリム化を完了した後に実施された．

この施策に要した工数は121人月であり，本プロジェクトの中では施策⑦に次ぐ大きさである．これは情報システムのスリム化に業務プロセス改革を伴うものがあり，その推進に工数を要したためである．

施策⑦：情報システムの移転

情報システムの移転とは，コンピュータのハードウェア･ソフトウェア･データを物理的に移設する作業である．移転対象の情報システムは，メインフレーム系とサーバ系とネットワーク系の3つに分類できる．このうちメインフレーム3台の移転のリスクが最も大きいため，事前に半年間かけて合計14回に及ぶリハーサルを実施し，プロジェクトの最後に2015年5月のゴールデンウィークを利用して約1週間かけて移転した．

本施策に要した工数は本プロジェクトで最も多く558人月であり，プロジェクト全体の半分以上（55.2%）にあたる．移転した機器の台数と工数は，表2の通りである．サーバ系がメインフレーム系よりも工数が大きい理由は，台数が多いために移設の作業量が膨らんだためである．

全体推進事務局

全体推進事務局とは，以上の施策①～⑦に関する進捗管理やリスク管理や体制構築や企画業務を担う，いわばプロジェクト全体のヘッドクオーター機能である．全体推進事務局の要員はリーダクラス1名（事務局長）と担当者クラス5名から成り，全員が本プロジェクトの専任者である．なお，プロジェクトが長期間に及ぶため，ノウハウ継続の観点から担当者のうち1名は基本計画策定からプロジェクト終了まで一貫して担当させた．

全体推進事務局の重要な機能の1つは，PMO（Project Management Office）である．本プロジェクトは82個のサブプロジェクトから成るが，1つ1つのサブプロジェクトのQCD（品質，コスト，納期）の管理やサブプロジェクト間の調整を行った．もう1つの重要な機能は，体制の構築と運営である．プロジェクトの体制は経営レベルのステアリングコミッティの下に全体推進事務局を設置し，その下に実務レベルの分科会を設置して，3階層の体制とした．ステアリングコミッティは，東京海上日動のIT企画部長と同社役員による情報共有と承認の場である．3年弱のプロジェクト期間に12回開催した．分科会は施策に合わせて設置した．各分科会は数名から数十名の社員から構成され，日々の活動は分科会の単位で行った．

全体推進事務局に要した工数は218人月である．

3.4　各施策で苦労した点

施策①のテープ業務の廃止では，社内利用のテープはスムーズに廃止できたが，社外とのデータ交換で利用しているテープについては，交換先企業の事情等により進捗しない場合もあり，厳しい交渉が必要な場面もあった．

施策②の運用業務の移行と施策⑤の監視業務の移行は，それまで主に手作業で行っていた業務の移行であり，ノウハウの移転に手間取ることがあった．それらの業務は基本的にマニュアル化されているが，マニュアルにも記載されていないコツや秘訣といった詳細なノウハウが存在しており，業務移行しながらそれらを顕在化させることに苦労した．

施策③のオフィスの移転では，新しい拠点が別の地区にあることから，ノウハウ継承の観点から要員全員を段階的に入れ替えていく必要があり，人事異動する社員の人選や説得に苦労した．

施策④の印刷業務の移行では，帳票の種類が多かったことから，印刷テストの確認作業と印字文字の調整に時間を要した．

施策⑥の情報システムのスリム化では，バックアップ手順の業務プロセス変更に際して，大幅な修正が1990年代以来約20年ぶりだったことから，すでにさまざまなノウハウが消失しており，その掘り起こしに苦労した．

施策⑦の情報システムの移転では，リハーサル実施に際して，本番システムの停止スケジュールの確保に苦労した，移転のリハーサルは，メインシステムも含めた本番システムが停止している必要があるが，その日程は限られており，ふだんから停止日に実施する作業は目白押しである．そのような状況の中，リハーサルの日程を確保する社内調整に苦労した．

以上の通り，施策①～⑦の苦労した点を総じて言えば，技術的な側面よりも，ノウハウの継承や要員問題や社内外との調整といった組織的な側面が強く，今後同様のプロジェクトを計画する際には，これらの点を踏まえる必要がある．

4．実績

4.1　工数等の実績

結果的に，本プロジェクトは，予定したスケジュール通りに，重大なシステム障害もなく，コスト的にも予算範囲内で完了することができた．本プロジェクトの実績は以下の通りであった．

• 工数：1,011人月（外注先を含めると約2,300人月）
• 期間：2年11カ月（2012年7月～2015年5月）
• サブプロジェクト数：82個
• コスト：（未開示）

工数については，本プロジェクト全体の実績工数（全体工数）と，それをフェイズ1とフェイズ2に分割した工数を表3に示す．なお，全体推進事務局の工数もフェイズ1とフェイズ2に分割した．フェイズ1の合計は312人月であり，全体の30.9%にあたる．つまり，狭義のデータセンタ移転である施策⑦を実施する前にすでにプロジェクトの約3割を終えていたことになる．

4.2　アンケートによる意識調査

アンケートの対象者は本プロジェクトの全体推進事務局と各分科会のリーダー経験者とした．調査方法は上記対象者にメールで回答を求めた．質問内容は2項目で，各項目の回答は4件法の評定法とした．以下2項目の質問を行った．

• 質問1：本プロジェクトによって「さらに移転しやすい状態」を作りだせたと思いますか？
• 質問2：今回の事例は同社の他の移転プロジェクトでも活用できると思いますか？

回答は全問とも「強くそう思う」「そう思う」「そう思わない」「まったくそう思わない」の4択とした．以上のアンケート調査により，有効回答者数41名の調査結果を得ることができた．回答は次の通りである．

質問1の回答結果が図2であり，「強くそう思う」「そう思う」の合計は86%である．この結果から，多くのプロジェクトメンバが「移転しやすい状態」を作りだせたとの意識があることが分かった．

質問2の回答結果が図3であり，「強くそう思う」「そう思う」の合計は79%である．この結果から，多くのプロジェクトメンバが「この事例は他の移転プロジェクトでも活用できる」との意識があることが分かった．

5．考察

5.1　工数の平準化とリスクの軽減

本プロジェクトには工数の問題と移転時のリスクという2つの課題があったが，それらに対して工数の平準化とリスクの軽減という課題解決を図った．本節では，それらの成果について考察する．

1つ目の工数の平準化に関しては，情報システムの移転を行う前にシステム運用業務を移行したことにより全体の約3割の工数が移転前に完了しており，工数の平準化が実現できたものと考える．特に，キーパーソンであるシステム運用のスペシャリスト2名が運用移行と情報システム移転の両方のプロジェクトに参加できたことが，プロジェクト全体のレベルアップに貢献している．

2つ目の移転時のリスク軽減に関しては，情報システムの移転時に軽微なインシデントがいくつか発生したものの，ユーザに影響を与えるような重大なシステム障害は発生せずにプロジェクトを終えることが出来たことから，各種のリスク軽減策が寄与したものと推定できる．また，重大なシステム障害を想定した別システムは結果的に使用されなかったが，その過程において重大なシステム障害への対処について深く検討したことが，社内のノウハウ蓄積にも寄与した． 以上により，本プロジェクトでは，工数の平準化と情報システムの移転時のリスク軽減を実現できたと考えられる．

また，本プロジェクトを通じて，システム運用部門の人材育成とノウハウの継承を行ったことも成果の1つである．同社では，本プロジェクトを通じて，中堅社員に重要な業務を任せ，人材育成とノウハウの継承が図られていた．

5.2　アンケートの回答結果について

本節では，4.2節のアンケート調査の結果について考察する．3.2節で述べた通り，本プロジェクトでは，次世代のデータセンタの在り方を踏まえ，サブセンタは完全無人化・ペーパーレス化のデータセンタを志向して，将来に向けて「さらに移転しやすい状態」を作り上げることを狙いとした．質問1は本件に関する意識調査であるが，8割を超えるメンバが移転しやすい状態を作れたとの意識があり，プロジェクトの狙いは実現できたものと推測できる．

質問2は他の移転プロジェクトでの活用に関する質問である．約8割のメンバが他の移転プロジェクトでも活用できると回答していることから，本プロジェクトの施策には汎用性があると推測できる．さらに言えば，本プロジェクトで利用したアウトソース化･クラウド化･リモート化･別拠点化といった手法は他社においても利用可能な汎用的な技術や手法であり，他社での活用についても有用性はあると推測できる．ただし，一般性の確度を上げるためには他社でも適用して検証を行う必要がある．

本節では，質問1と2に加え，今後の課題に関して追加のアンケート調査を実施した．対象者は4.2節のアンケート調査と同一とした．質問は1項目で内容は次の通りである．回答は選択式ではなく自由記載とした．

• 質問3：次回データセンタ移転プロジェクトにおいて規模（工数）をさらに小さくするためには，今後どのような課題に取り組む必要があると思いますか？

対象者からの回答をキーワード毎に仕分けした結果が，表4である．回答結果の上位はいずれも本プロジェクトの施策⑦「情報システムの移転」に関する課題であり，次に取り組むべき課題はこの分野であることは明らかである．以下に上位3つの課題について述べる．

1つ目の移転方式の検討とは，物理移転方式や事前設置方式など情報システムの移転方式によるプロジェクト規模の差異を検討することである．物理移転方式はコンピュータの機器本体を実際に移設する方式であり，事前設置方式とは移転先に事前に同じシステムを設置してテストを済ませておき，機器の物理的な移設は行わない方式である．事前設置方式の方がリスクは小さいが，工数･コスト･期間は大きくなるというデメリットがある．

2つ目のメインフレームの問題とは，メインフレームの移転がサーバやネットワークのそれよりも工数やリスクが大きいという課題である．メインフレームは移設など想定されていない超精密機器であるため，大量の要員を投入し，テストとリハーサルを繰り返してやっと移設することができる．一方，サーバやネットワークは1台あたりの単価が桁違いに安価なので事前設置方式を採用しやすく，工数･コスト･期間に加えて移転リスクが少ない，QCDに優れた移転が可能である．しかし，金融機関のように巨大バッチ処理を抱えている場合はメインフレームの方が優れており，今後それをどうサーバへ移行（ダウンサイジング）するかが課題である．

3つ目の広域分散技術への対応とは，新しい要素技術を駆使して情報システムの移転を容易にしようとする検討である．先行研究で述べた通り，昨今，仮想化や広域分散ファイルシステムや負荷分散処理や遠隔データ同期など，地理的に離れた複数のデータセンタ間で処理を行う要素技術がさまざまに論議されている．3.2節で述べた通り今回のプロジェクトにおいては移転時のリスクを軽減するために最新技術の適用を見送った経緯であるが，今後の技術の進展次第ではデータセンタ移転がさらに容易になる可能性があるため，最新技術の適用は検討すべき課題の1つである．

本稿の事例はデータセンタ移転プロジェクトからシステム運用を切り離すことに特徴があったが，この発展へ向けては，次は情報システムの内側へ切り込む必要がある．その際の検討内容は本節で抽出した取り組み課題であり，それらを駆使することにより次回移転の規模をさらに小さくできると推測される．

6．おわりに

本稿では，大企業が保有する大規模かつ複雑な情報システムのデータセンタ移転プロジェクトにおける工数と移転リスクという2つの課題に対して，プロジェクト上の工夫やリモート技術の活用というプラクティスを報告した．また，アンケート調査により，今後の移転へ向けては，移転方式の検討，メインフレームの問題，広域分散技術という検討課題があることも言及した．

本稿の意義は，データセンタ移転プロジェクトに関する詳細な事例報告と定量的なデータを提供した点である．先行研究で述べた通り，大規模なデータセンタ移転プロジェクトに関する事例報告は希少なため，本稿には有用性があると考えられる．