• データセンター移転プロジェクト全体の企画・計画から方針決め、ベンダー選定、推進まで一気通貫で支援し、顧客の一員としてプロジェクト推進リーダーを務めた
• 顧客にとって過去最大のデータセンター移設であったが、入念な検討の積み重ねやさまざまな工夫により、大きなトラブルを発生させずに期間内で完遂した
• 大幅なランニングコスト削減を創出した

データセンター移転プロジェクトの目的と推進計画

事業継続性を確保するために、必要な要件を満たすデータセンターを選定し、リスクを最小限に抑えたうえで、可能な限り早期に各種システムを移設することを目的とし、

• フェーズ1　･･･　データセンター選定
• フェーズ2　･･･　データセンター移設

の、2フェーズに分けて推進する計画となった。

プロジェクトの特徴

1. 同社にとって過去最大の物理的なデータセンター移設
   1980年代に現在のデータセンター拠点への物理移設作業を実施したが、そのノウハウは現在の現場には残っていない。また台数としては今回が過去最大となる。特に基幹勘定系が設置されている拠点は規模が大きいため、週末だけでの実施は不可能であり、長期休暇内での実施をプランニングする必要がある。
2. 20年以上の歴史が蓄積した現システム設置拠点からの移設
   旧センターは長期間利用し続けているため、すべての設備的情報が管理されていない可能性がある。通信回線、電話回線、設備内容、利用状況などの管理情報だけでは”ヌケ、モレ”の恐れがある。
3. 物理移設
   環境移行ではなく物理的な移設（引っ越し）であり、また代替機も用意できないために事前検証は実施できない。障害発生時には顧客社内のみならず、クライアントやカスタマーにまで多大なる影響を与える危険を内包するリスクの高いプロジェクトである。
4. 大量のシステム間インターフェース
   基幹勘定系および情報系DWHは多数のシステムとインターフェースをとっているため、移転調整だけでなく検証調整が必要であり、かつ調整範囲が広い。
5. 選定した新データセンターのベンダーはプロジェクト主幹部門とっては初ベンダー
   同社のプロジェクト主幹部門にとって、提案ベンダーおよびデータセンターベンダーともに初めてのお付き合いになるため、企業文化、推進手法、スキルなどが未知数である。

移設規模

新データセンターへ移設する拠点は、基幹勘定系システムなどを有する拠点A、グループウェアシステムやネットワークシステムの拠点B、ネットワークシステム中心の拠点Cの3つである。
データセンター移設のステップは1st、2nd、3rdの三段階に分けて実施する。1st移設では拠点Aを、2nd移設では拠点Bを、3rd移設では拠点Bと拠点Cのネットワーク系資源の移設を行う計画とした。 

データセンター移転プロジェクトの概要スケジュール

• プロジェクトのキックオフから、3rd移設の予備期間終了まで、約2年半かけて実施するスケジュールを引いた。
• 大きく2つのフェーズに分かれており、フェーズ1ではデータセンターの選定を、フェーズ2では実際の移転を実施する。

データセンター移転プロジェクトの概要スケジュール（別ウィンドウで開きます）

プロジェクト体制

顧客側のプロジェクト体制は、推進ボードと呼ぶ上位組織のプロジェクト全体責任者のもとで、大きくは「標準基盤システム系対応チーム」と「事業システム系対応チーム」に分かれている。この2つの組織と横並びに外部のデータセンターベンダーや運搬物流ベンダーが位置する体制だ。

アークシステムは顧客側の組織に属し、推進ボードおよび標準基盤システム系対応／事業システム系対応の両チームにおいて、プロジェクトリーダー、計数管理、チームリーダーなどの立場でプロジェクトを支援した。

一方、ネットワークシステム、情報系DWHシステム、仮想化サーバーインフラなど、各システム側の担当者としても、定常運用を支援しているアークシステム技術者が移設作業を担当した。

アークシステムの支援内容

顧客側プロジェクト担当者の立場で、全体計画、設計、調整、管理など移設作業全体の取りまとめから、指示、依頼、共有まで幅広く支援を行った。

フェーズ1「データセンター選定」での支援内容

フェーズ2「データセンター移設」での支援内容 

各システム側の担当者として、同社のネットワーク定常運用業務を担当するアークシステム技術者が、以下のネットワーク構築業務も実施した。

プロジェクト効果および顧客評価

• 大きなトラブルを発生させずに期間内で完遂
  代替機のない物理移転で事前検証を行えないため、障害発生時には顧客社内のみならず、クライアントやカスタマーにまで多大なる影響を与えるリスクの高いプロジェクトであった。かつ顧客側にもこの規模の移転の経験やスキル、ノウハウがなかったことから、入念な検討を積み重ねて作業の標準化やテンプレート化を実施し、全体俯瞰とリスク検知が素早く行えるようなフレームを作り上げた。結果として大きなトラブルを発生させずに期間内でデータセンター移転プロジェクトを完遂した。
• 大小さまざまな工夫でリスクを軽減
  • プロジェクトの役割と各システム担当の役割を明確に定義し、各システム担当向けの説明会を何度も設け、おのおのの役割と作業への理解を深めてもらうことにより、効率的で過不足なく移設作業を行った。
  • 当初IBMメインフレームのSystem z10はお盆時期（およそ1週間）に移設する計画であったが、休眠していた旧サーバーz9に切り戻し、z10を先行して新データセンターに物理移設することにより、夏季休暇中の移設リスクを大幅に減少させた。
  • お盆時期の移設作業時に、事前申請した工事の”ヌケ、モレ”などによる突発的な設備工事が必要となるリスクを想定し、相応の人員体制を要請したことにより、残念ながら発生してしまった設計ミスなどによる追加作業にも迅速に対処でき、プロジェクトの大筋に影響を与えることなく移設を完了させた。
• 顧客IT部門における年間MVPを受彰
  当データセンター移転プロジェクトは、顧客企業のBCPに掲げられた事業継続性を確保するために必要な要件を満たしたこと、大きなトラブルを発生させずに期間内で完遂したこと、大幅なランニングコスト削減を創出したことなどが評価され、顧客IT部門の表彰制度において年間MVPを受彰した。

• 既存のDHCPサーバーを有効活用するのみで、社内システムネットワークから不正PCを排除
• 追加投資なく、企業の情報セキュリティ対策として不正PCを排除するしくみを簡単かつ迅速に実現

概要

企業の情報を守るためのセキュリティ対策として、多くの企業が不正なPCを社内ネットワークにアクセスさせないしくみを検討しています。実現方法としてこれまでに様々な製品が発表されており、セキュリティ対策の目的とコスト見合いに応じて選択の幅（実現レベル）が広がっていますが、一般的には、

• 802.1x対応などのためネットワーク機器を高価なものに変更する必要がある･･･
• Macアドレス収集や制御のため追加の制御装置を導入する必要がある･･･
• クライアントPCにエージェントを導入する必要がある･･･

など費用や実装負荷が高まるケースがあるため、選定に多くの時間がかかり迅速な対策が打てない状況にあるようです。

しかし大規模企業A社では、既存のDHCPサーバーを活用するだけで、追加投資なく、簡単かつ迅速に、不正PCを排除するしくみを実現いたしました。

実現方法

DHCPサーバーにはclass ID optionという機能があります。この機能をDHCPサーバーとクライアントPCに実装しておけば、社内システムネットワークから不正PCを排除するしくみが、追加投資なく、簡単かつ迅速に実現できます。

【前提】

• DHCPサーバーに、class ID optionにてIPアドレスのリース可否を制御する機能を実装していること
• クライアントPCに、 class ID optionを設定できること（Windows 2000/XP/vista/7 は設定可能）

【しくみ】

• 管理対象のPCには、事前に企業特有のclass ID値を設定しておきます。DOSコマンド1行で設定が可能です。
• クライアントからのIPアドレスリース要求時に、DHCPサーバー側でclass ID値の整合性を確認し、値の一致したクライアントにのみIPアドレスをリースします。不一致の場合はIPアドレスをリースしません。
• 不正PCはclass ID値の不整合を起すため、ネットワークに接続できたとしてもIPアドレスを取得できません。通信が不可能なので社内システムに不正アクセスすることができません。

リスクと対応

このDHCPサーバーのみで不正PCを排除するしくみのリスクと対応は次の通りです。

◆class ID値が設定されたPCでclass ID値を参照できるため、それらの情報を取得されると不正PCにて成りすまし行為を許してしまう。

 ⇒参照した値だけ見ても同じ値を設定できないよう「ひと工夫」する（工夫内容はセキュリティの要であるため割愛）。

◆この方式は、IPアドレスの動的リースにて不正PCを排除する仕掛けであり、固定のIPアドレスを設定されたPCに対しては、制御の対象とならない。

 ⇒第1段階の安価かつ迅速なセキュリティ対策と割り切る。さらに強固にする必要がある場合は、予算との兼ね合いで別途検討する。

1. 1.開発対象システムの概要
2. 2.開発体制
3. 3.ADE導入の経緯
4. 4.開発環境
5. 5.ADE導入効果

1.開発対象システムの概要

• A社様のお客様向けWebポータルサイト (新規構築)
• オープンソース・プロダクトと商用プロダクトが混在する構成
• システム規模は中規模ながらロジックが大変複雑

2.開発体制

• 開発人員15～20名の体制
• 海外 (オフショア) を含む分散環境開発

3.ADE導入の経緯

4.開発環境

5.ADE導入効果

当初課題だったインターネット経由での電子文書共有を低コストで実現していただけました。 加えて、開発効率アップなどさまざまな効果を実感していただけました。

■分散環境での開発において情報共有に威力
インターネットを経由する分散環境での開発において、ADEを用いることで、安全かつタイムリーに情報やリソースを共有できた。

■プロダクトごとのセキュリティ設定は不要
セキュリティを考慮した状態でインストールが完了するので、プロダクト個別に設定する手間が省けた。

■ライセンス費用の追加なし
当初想定以上に開発要員が増えたが、ユーザー増によるライセンス費用追加もなく、予算内で対応できた。

■想定を上回る高い開発効率
「自動テスト」、「自動ビルド」機能により問題を早期発見、早期解決でき、開発効率アップに繋がった。

■仕様変更の徹底に高い効果
「課題管理」機能を用いた仕様変更の徹底が高い効果をあげた。検索やソートなどできめ細かい条件設定ができるため使用性も抜群。

■管理も簡単
ユーザー／プロジェクト管理機能を用いて、面倒なプロジェクト生成やユーザー登録などの管理業務も簡単に行えた。

• インフラの共用化により社内アプリケーションシステムの品質向上、コスト低減、納期短縮を実現
• 仮想化技術の採用で迅速な立ち上げを、プライベートクラウドによりセキュリティとカスタマイズ性および可用性の確保を実現

ＩＴインフラ環境をめぐる課題

A社様では従来アプリケーションシステムごとに個別ITインフラ環境を用意してきたが、品質面、コスト面、納期面において下表のようにさまざまな課題が顕在化してきた。これらを解決するためにクラウドによる「共用インフラ」の導入を検討することになった。

パブリック等と比較しプライベートクラウドを選択

ITインフラ環境としてクラウドを考える場合、プライベートとパブリックのどちらが自社要件等に最適かを見極める必要がある。A社様ではこの2つに従来型の個別ITインフラ環境も加えて比較検討を行った結果、プライベートクラウドを選択することになった。

システム構成

プライベートクラウドを活用した「共用インフラ」のシステム構成は下の図の通り。仮想化技術を採用している。

アークシステムの支援内容とスケジュール

アークシステムは仮想化技術を利用したプライベートクラウドによる「共用インフラ」の設計から環境構築、運用まですべてを支援している。

2009年11月から「共用インフラ」の設計・環境構築を開始し、2010年8月に運用を開始した。その後、運用課題の洗い出しおよび運用整備を行い、サービスの安定化を図っている。

「共用インフラ」の利用状況

A社様では「共用インフラ」導入後1年で102OSを仮想環境上に構築した。

メニュー1 ･･･ 標準ハードウェアと標準仮想化ソフトウェアの環境（ミニマムパターン）
メニュー2 ･･･ メニュー1に、標準仮想マシン環境を加えた環境
メニュー3 ･･･ メニュー2に、ISA・SQLServerなど標準ミドルウェアを加えた環境

導入効果

社内向けアプリケーションを新規構築する場合や保守切れ等にともなって新規システムを構築する場合、「共用インフラ」は従来のアプリケーション個別にサーバーを構築する方法に比べて圧倒的にコストパフォーマンスが優れている。そのため保守ベンダーに運用作業を委託する等の特殊要件がない場合は「共用インフラ」が採択されている。

この仮想化技術を利用したプライベートクラウド「共用インフラ」を導入したことにより品質向上、コスト削減、納期短縮という3つ効果が得られた。

品質向上

• ITインフラ環境の共通化に伴い、各アプリケーションへの提供レベルが均一となり、コスト管理等が容易になった
• 仮想OSのひな形を導入したことにより「共用インフラ」提供における環境不具合や作業ミスによるスケジュール遅延等がなくなった

コスト削減

• サービス利用側において、ITインフラ環境構築に要する工数（設計・構築・運用）が不要となった
• 個別にITインフラ環境構築を検討・実施する場合と比較して、構築・運用のコスト面で圧倒的な競争力があり、コスト削減に寄与している

納期短縮

• 利用検討および要件確定後、標準構成なら1仮想OSにつき4時間以内に利用可能となった
• サーバー（仮想OS）増設、サーバーリソース追加、ディスク容量増設あるいはサーバーリソースの低減等ITインフラ環境のリソース変更に迅速に対応できるようになった