仕事の関係上、システムetcを大規模移行する事があります。そんな際、求められるのが移行計画書です。作成するにあたっては、様々な項目etcがあり、はっきりとその内容を把握していないとトラブルが発生してしまう事になります。長い年月をかけてテストを繰り返してやっとシステムの本番稼働する為の移行となりますので、綿密な計画を立てなければなりません。移行計画書とは何か、書き方や必要項目や留意点、雛形について考えていきます。
移行計画書とは？
どんな際に活用される文書なのかを検証しましょう。
「移行」とは？
その名の通りある場所からある場所に何かを移す作業の事であり、その手順や道筋を細かく書き込むものが移行計画書となります。
システムの「テスト環境→本番環境」移行時に使われる！
システム開発をしている中で色々なテストを繰り返し、ある程度誤作動や不具合も検証し、本番稼働させる環境への移行計画書になります。基本的にシステム移行が行なわれる際に発行される書類です。
基本的に移行計画書が作成される時、実際の引越etcではなく、IT系におけるシステムの移動etcがメインです。
システム開発は事前に「テスト環境」で行われている！
その為、数多くのパターンでは運用システムetcが完了しているシステムを実際の本番に稼働する環境に移す計画書になるのです。
多くがシステムを開発していて仮のURL上だったりオフネットの環境でプログラムを組んでいきます。
テスト環境と同等の再現を本番環境でも実施する必要がある！
本番稼働となると本番に使うURLにシステムを移して稼働させます。このシステムを一気に本番のサーバーに移して不具合になる可能性もあります。
バックアップetcをとっていますので、消える事はないですが、どこがどう機能して正常に稼働していくか検証しながら本番稼働させていくので、今回、紹介している移行計画書なる書類が必要になります。
移行計画書の留意点は？
移行計画書は、新旧のシステムを切り返す際に作る事の多い文書です。要するに、新しいシステムに今までのシステムを全て移してしまう事ですので、失敗するとシステム大障害が起こる事になります。
移行手順や移行内容を誤るとシステム障害に…
PCetc、さまざまなデータetcが蓄積されている時、計画書を曖昧にしたり、違った内容で作ってしまうと会社自体が機能しなくなる恐れがあるのです。
誰が見ても分かる誤解の生じない詳細な書き方で！
その為、移行計画書を作る際は曖昧な作り方をするのではなく、専門家etcも交えてはっきりと作る事が求められるのです。
移行の準備は数か月や数年前から実施する！
通常は何カ月前もから準備に入りますが、大規模なシステムの移行となると何年もかけて移していくケースがあります。例えばメガバンクのシステムを変えるといったような大規模のシステムの移行は、綿密な計画を作って何年もかけてシステムの移行を進めていきます。
移行計画書の書き方
移行計画書を作る際、どんな書き方が求められるのでしょうか。一言で言ってもプロジェクトによって大きく内容は変わってきます。
大きな計画であるか、小さな計画であるかによっても項目が変わってくる事から、一概に「絶対にこう書く！」という決まりはありません。しかし、最低限これはいれておいた方がよいだろうという項目は存在しています。
移行計画書を作る際に入れておきたい項目について解説していきたいと思います。
また、余談ですが、雛形はインターネット上に存在していますので、書き方がわからない方etcは、無料でダウンロード出来るサイトもありますので、ダウンロードして参考にしてみるのも良いでしょう。
移行計画書の項目
移行計画書を作る際、基本的に入れておきたい項目がいくつかあるので見ていきましょう。
タイトル
移行計画書という事がわかるように大きな文字でタイトルを書き込んで下さい。誰が見てもわかるようになっている事が重要です。
移行目的
目的を書き込みます。移行要件を書き込んで、特徴etcも書き込んでいきましょう。システムアーキテクチャの変更やデータベースや書類形式etcを書き込みます。
移行方法
「対象業務の移行方法」です。これは、一斉に実施するのか、並行運用は実施するのかというような項目です。
移行計画をどう実施するのかの軸になるので忘れずに項目に書き込みましょう。
移行スケジュール
いつからいつまでの間に実施するのか。これをはっきりと書き込む事で、仕事の調節を行なってもらえます。
移行テスト
テストの計画書も同時に作る事を伝えておきます。
移行リハーサルが行なわれたのち、本移行が行なわれる旨をはっきりと書き込みます。ケースによってはその後に計画の報告書も作る事があります。
データ移行
データを移す際に伴うデータの保存方法です。これがはっきりとしていないと、今までのデータが無くなるという最悪の事態になりますので留意して下さい。
コンティンジェンシープラン
また、案外重要なのがが失敗してしまった時の措置をどう実施するか、というところです。責任の所在をどこまでおうのか。こんな部分も項目のひとつとして入れておくとよいでしょう。
【その他】移行に必要な人材や資材や環境etc
そのほか、必要なスタッフはどのくらいいるのか、どこの業者に手伝ってもらうのか、必要機材、検証及び妥当性検証方法etcです。
移行計画書の大枠
上記で説明した通り、移行計画書には必要な項目が多いですが、ベーシックなシステム移行計画には主に以下の内容を書き込みます。
基本方針
基本的な方針を書き込みます。これを書き込む事で何か問題があった時etcに優先順位がすぐわかります。
全体スケジュール
計画段階～移行後までの予定を書き込みます。根幹部分なので、はっきり把握する必要があります。
タイムチャート
移行当日の詳細なスケジュールを表します。当日は緊張しますので、手順を間違えないようスケジュールを検証する必要があります。
システム構成図
システムのどの部分を移すのかを明示的に示します。対象システムがわからないと意味がないので、はっきりと示さなければチームが慌てます。
体制図
誰がどこで対応するかという役割分担を明らかにします。これも重要な事で、得意分野ごとに振り分けられたら良いでしょう。
検証計画
システムを移した後にどんな検証を実施するのかを書き込みます。移したら終わりではないので、みんなで把握しておく必要があります。
コンティンジェンシープラン
事前に想定されるシステム障害を洗い出して、もしもその障害が発生した時に、被害を最小限に抑える為の対応内容を書き込みします。前もって不具合を想定するのは、危機管理が出来ている事につながるので、重要な事です。しかも対応策を書き込む事で、誰でも対応出来るようにする事が大事です。
その他…
その他、必要に応じてデータ移行方法や本番リリース後における重点監視期間についても書き込みます。これを書き込む事でチーム全体で気を付けるようになります。不具合の検証etcで発見が早くなり、対応も早くなるので顧客にも喜ばれます。
移行計画書の雛形
計画書を作る際、会社に雛形etcがあればいいですが、無い時はゼロから作る事になります。
移行計画書は、とても重要な道しるべとなるものですので失敗は許されません。
そこで、おすすめなのがすでに作られている雛形を活用するという手段です。インターネット上にはエクセル雛形etcがあり、無料でダウンロードをする事が出来ます。
自分なりにアレンジし、分かりやすくまとめれば時短にもなりますし、ミスを防ぐ事も出来ます。作る方法がわからず迷っている方は雛形をぜひ活用してみましょう。
前述でも述べていますが、雛形を活用する事で、こんな手順でシステムを移した方が良いetc、新たなアイデアが生まれたりもしますので、人が作った雛形を見る事も勉強になります。
移行計画書は方針を分かりやすく書き込む＆何度もや複数人で検証を！
移行計画書を作る際、何度も検証するようにして下さい。間違えると、データ移行が失敗してシステム障害が発生します。
システム障害が発生してしまうと、顧客やユーザーに迷惑がかかる事はもちろん、限られた時間内でシステム復旧対応をしなければならないですし、自社内でシステム障害報告会に出席したり再発防止策を考案したりと通常業務とは別の作業が発生して大変です。こんな惨事を防ぐためにも、システムを確実に把握しながら計画を作って何度も検証する必要があります。関係者複数人での検証は必須です。
まずは、移行計画の日程を把握し、逆算して考えていく必要があります。時系列で何をすれば良いのか考え、さらに細かい計画を考えていくという作業が必要なので、全体像を作ったら計画の細かい部分に担当を決めてその担当に詳細な計画書を作ってもらうという事も良いかもしれません。
こんな風に人に仕事を振るという事で、部下の士気も上がり、自分以外にも移行計画書を作れる人材を育てる事が出来るメリットもあります。また、一人で全ての項目を書き込むとなると膨大量の作業になるケースもありますので、適材適所で分担した方が効率が良いでしょう。
ぜひ、雛形etcを上手に活用しながら方針を明確にした移行計画書を作れるようにしましょう。
