当社エンジニアによる書き下ろし技術レポート Close-Up IT

技術レポート 新着RSS(Atom)

この記事に関連するサービス
システム・インフラ基盤の設計・構築
この記事に関連するお問い合わせ
お問い合わせ

第3章 :移転推進の勘どころ

1システム移転推進の勘どころ [1] 計画

移転作業は、作業項目によっていくつかのフェーズに分けて推進していく。それぞれのフェーズの役割や目的によって、何を重視するかも変化していくことになる。ここでは「計画」、「環境構築」、「テスト」、「リハーサル」、「移転」の5つのフェーズを想定した。またこれらフェーズとは独立した存在 (機能) として「移転推進」を配置した。各フェーズ / 機能についてアークシステムが考える勘どころを紹介するのでぜひ参考にしていただきたい。

計画

移転作業の最初のフェーズは、計画フェーズである。関係各社や関連部門の責任者を中心に 移転対象、方法、期間、体制などを基本計画として策定していく。後続のフェーズはすべてこの計画を拠りどころとして推進していくため、漏れのないように、明確に策定することが肝要である。

主な作業 ドキュメント
  • 基本計画作成
  • 担当割り振り決定
  • スケジュール作成

勘どころ

  • 移転計画書 (基本計画書) には、移転にかかわる計画項目のすべてを記載すること。全体感を明示することで、認識のずれや、曖昧さをなくす。その際、業務担当者を明確にし、また担当者がわかる具体的な記述レベルで記載することが重要である。担当が明確になることで、プロジェクトに必要となるワークロードの見積りや、人的リソースの不足などを事前に把握することが可能となる。
     
  • 移転計画書では概要、移転対象、移転中の影響、テスト、スケジュール、体制などの基本項目のほかに、テストやリハーサルが不可能な "一発勝負" の項目を洗い出し、明確にする必要がある。"一発勝負" の項目のすべてにおいて、万が一の事態を想定したコンティンジェンシープランをたてる (例えば、搬送時事故により本番機器が破壊された場合の本番業務回復方法など) 。また、移転元環境と移転先環境の差異 (設備面、ハードウェア、ソフトウェアバージョンなど) を列挙し、それぞれのケースに関して、移転前後の影響や必要なアクションについて明示する。
     
  • マスタースケジュールは当フェーズで策定した後は変更しない。マスタースケジュールの変更は、その影響が大きすぎるからである。ある1項目を変更すると、他に変更すべき項目が芋づる式に現れ、それぞれの調整のために多大な負荷が必要となったり、調整しきれない項目が出てきてさらなるスケジュール調整が必要になったりする恐れがある。一方、システム移転にかかわる人員の意識に関する問題として、それまでに努力して遵守してきたマスタースケジュールが変わることで、士気やモラルが低下してしまったり、ひとつにまとまっていた "心" がバラバラになってしまう恐れがある。マスタースケジュールは死守するという気概を持って推進していくことが肝要である。
     
  • テストおよびリハーサルのスケジュールと実施方針については、早い段階で実作業者に提示する必要がある。後続の工程にて「テスト計画」や「リハーサル計画」を策定していくうえで、時間的余裕やテスト環境の特性によって、テストやリハーサルの実施方法やシビアさが大きく異なってくるからだ。
     
  • データ移行方法は、容量、更新タイミングの特性によっては分割実施を検討すべきである。すべてのデータを一括して移行する静止点移行の方法をとると、データ移行の所要時間は必然的に長くなってしまう。事前の移行や、差分移行、事後の移行などの方法を併用し、データ移行時のリスクを最小限に減らす計画を立てておく必要がある。
     
  • 移転当日のリスクを極力減らすため、運用変更は事前に実施、リリースするように計画する。ただし、移転に直接的にかかわらない運用変更 (例えば、運用改善目的の変更など) は移転後に実施すべきであり、「移転リスクを減らす」という共有の目標に対して、全体として整合性のとれた計画になっているか、運用部署と確認、調整することが必要となる。

このページの先頭へ