記事

執筆者挨拶

こんにちは！ 株式会社福岡情報ビジネスセンターの高村です。早いもので、前回のブログから3カ月たちました。先日、久しぶりに近くの河畔を散歩したのですが、1カ月ほど在宅ワークをしている間に、外はすっかり春になっていました。プロジェクトも籠っている間にすっかり成功裏に完了してるといいんですけど、そうはいきません。しかたがないので諦めて、しっかりとプロジェクト管理をしていくことにします。
そして今は、あるプロジェクトで人手が足りず、移行計画を私が策定する羽目に．．．
ということで、今回は移行計画についてのお話をしてみたいと思います。

＜前回の記事＞
プロジェクト管理　悲喜こもごも③　～チームビルディング～

 

移行計画はいつ頃たてる？

まず、移行方針として早い段階（要件定義～基本設計）で、移行範囲と移行方法の方針を決めます。移行するデータは全件か直近何年分か、移行タイミングは事前か直前かまたは事後か、及び移行ツールは市販ツールか新たに開発するのか、などです。また業務プロセスの新システムへの移行は一括移行か段階移行か、などの方針も併せて決めます。

次に移行ツールの準備、テストを詳細設計～統合テストの期間で行います。移行用プログラムの設計・開発・テストもこの時期です。そして移行ツールや移行プログラムのテストで移行したテストデータを使って統合テストを実施するようにします。

最後に移行計画です。移行計画は2フェーズに分け、最初のフェーズで移行日程を確定します。全体の流れの整理、作業結果検証も含めた作業項目の洗い出し、作業項目の実施順番決めなどを行います。後は回帰不能点をどのあたりにするか、また切り戻しの手順も確立させておきます。これを統合テスト期間中を目途に策定します。そして最後に移行作業の実施計画として、詳細なタイムチャート、体制、チェックポイント、回帰不能点の設定、最終稼働判定タイミング、稼働後の立ち合いなど、実際の作業をイメージして詳細な計画を立てます。これは移行リハーサルでも使用しますので、移行リハーサル前までに作成します。

そして本番移行がスムーズにいくように、リハーサルを1-2回ほど実施し、実施結果に基づいた修正を各資料に反映させて、移行本番を迎えることになります。また、移行リハーサルで移行したプログラムやデータはそのまま受入テストで使用することで、ほぼ本番移行後の環境と同等のテストを行うことが可能となります。

このように早い段階から方針を決めて、それを意識しながらプロジェクトを進めていくことでスムーズな本番移行ができるのです。小さなプロジェクトでも同様で、プロジェクトの早い段階で移行の方針を立てておくことがスムーズな移行にとても有効です。

 

移行計画時の注意事項は？

移行計画を立てるときに注意することはたくさんありますが、ここでは私なりに注意点だと思うポイントをいくつかあげてみたいと思います。

1. リソース調達の検討

ディスクの空き容量に余裕が無い場合など、外付HDや移行用PCを用意する必要が出てきます。必要であれば調達しないといけませんので、要不要を移行方針を立てるときに併せて検討します。

2. 移行作業手順の明確化

これは言うまでもありませんが、詳細な作業項目の洗出しと作業順を決め、検証作業も含めた移行作業手順を明確にする必要があります。漏れがないよう、また移行時に操作方法等、迷わなくてよいようにできるだけ詳細な手順を作成します。移行をスムーズに行う為には欠かせない重要な作業です。

3. 移行作業所要時間の想定

予想所要時間は、できる限り正確に見積もるために事前のテストで正確な時間を測定しておく必要があります。これを怠ると正確な所要時間が見積もれませんので、移行のタイムスケジュールが引けません。特にデータ移行の事前の時間測定は必須作業ですので、忘れないように必ず実施するようにしましょう。

4. 動作確認について

移行後の動作確認は、限られた時間の中で行ないますので、何をどこまでやるのか明確にしておくことが大事です。例えば照会系だけにするのか、更新系も確認して後で取り消すのかなど、動作確認する機能を具体的に決めておきましょう。また、注意が必要なのは外部連携機能です。本番運用ではありませんので、実際にデータが送信されるとまずいですから、どうやって、どこまで確認するのかを事前に取り決め、場合によっては送信されないような仕掛けを仕込みます。相手先の協力が得られ送信まで可能なケースもありますし、そうではなく送信用のデータを作成するところまでしかできないケースもあります。いずれにせよ、事前に明確にして準備しておくことがスムーズな移行の実現には欠かせません。

5. 現行業務停止期間の明確化（アナウンス）

次にはっきりさせときたいのは、移行に伴う業務停止期間です。いつからいつまでシステムが使えないのかというところは、エンドユーザー様が一番気にされますので、その辺りをはっきりと伝えなくてはなりません。またその時間厳守のためにも余裕のある移行計画をたてましょう。

6. 外部連携の切換え

外部連携の原稿システムから新システムへの切換えのタイミングはとても重要になりますので、誤送信や誤受信が起きないように充分に検討したうえで決めるようにしましょう。

7. 切戻し手順

移行に失敗することも想定して、必ず現行システムへの切戻しの手順を決めておきます。実際に移行が失敗した場合には切戻し手順がとても重要になりますので、移行リハーサル等で必ずその手順が正しいことを確認をしておきましょう。

8. 回帰不能点の設定

切戻し作業には時間がかかります。業務開始時間は厳守しないといけませんので、切戻し作業の時間を考慮して、回帰不能点（ここを過ぎたら、後戻りできないポイント（Point of No Return））を決めておく必要があります。

9. 最終稼働判定

7.の回帰不能点の前までに、必ず最終稼働判定を行ないます。移行作業時の検証結果や動作確認結果を元にこのまま新システムの稼働開始を進めてよいか、または切戻しするかどうかの最終的な判定になります。受入テスト後のサービスイン判定会議は、実装する機能が業務遂行に支障がないことを確認し判定するのに対し、ここでの最終稼働判定は実装そのものやデータの移行が正しく行われたかどうかを確認して判定します。せっかく受入テストで合格しても、移行を失敗するとサービスインできませんので、綿密な移行計画が非常に重要になります。

 

まとめ

『抜け漏れのないスムーズな移行を実現させるために、移行については早い段階で検討を始めること、綿密な移行計画を立てることがとても有効です。』

 

今回も最後まで読んでいただきありがとうございました。いかがでしたでしょうか、移行計画はプロジェクトの後の方という思いがおありだったかもしれませんが、プロジェクトの早い段階で検討を始めることが、有効だということがお判りいただけたかと思います。

弊社は移行をとても重要なイベントととらえており、今後もスムーズな移行ができるよう早めの検討、綿密な計画を心がけて参ります。

株式会社福岡情報ビジネスセンターを今後ともどうぞよろしくお願いいたします！

関連ブログ

プロジェクト管理　悲喜こもごも⑤　～コミュニケーション計画～