移行計画が重要なことを疑う人はいないだろう。移行計画書を作成すること自体は,もはや当たり前と言ってよい。だが筆者らは,問題があると感じる移行計画書の話をよく見聞きする。

 何が問題か―。それは「作るのが遅い」「記述が足りない」「精度が甘い」ということだ。

詳細設計の前には用意する

 ある客先では,こんな失敗談について意見を求められた。そのシステム担当者は,新システムの詳細設計が終わったところで移行計画書を作成した。データベース仕様が決まらないと,移行ツールの仕様が固まらないと考えたからだ。ところが,詳細設計が終わると開発者の大半が新システムのプログラミングに忙殺されるようになり,移行ツールの開発は後回しにされた。本番間際にようやく出来上がったものの,データを正しく移行できるか十分に確認しないまま本番に突入。移行ツールのバグにより,サービス開始時に誤ったデータが出力され,慌てることになったという。

 詳細設計の終了後どころか,結合テストの直前に移行計画書を作ったエンジニアの話も耳にした。このときは,準備不足のために移行作業が失敗し,新システムでのサービス開始が大幅に遅れてしまったという。

 どちらの事例も,移行計画書の作成タイミングが遅すぎたことが,トラブルの原因である。移行計画書は新システムのシステム企画の段階か,遅くとも詳細設計を始める前までには最初のバージョンを作るべきである。

 なぜなら移行には,思いのほか利害関係者(ステークホルダー)が多い。「移行ツールの開発」「リハーサル」「運用担当者への移管」「業務担当者(システム利用者)の教育」など,システム開発者以外の人たちと協力しなければ実施できないタスクがいくつもある。プロジェクトの初期段階から段取りを踏まないと,必要な要員や資材を確保できない。各ステークホルダーとの調整がつかなければ,一歩も先に進めないという事態に陥りやすい。移行作業の本番はプロジェクトの終盤に行うため,ここで手戻りが発生すると遅れを取り戻せる余地はほとんどない。

移行対象など6項目

図1●ある若手エンジニアが作成した「移行計画書」目次
図1●ある若手エンジニアが作成した「移行計画書」目次

 ある若手エンジニアから,右のような移行計画書のレビューを請われたことがある。

 「必要な情報は概ね記されているようだ」と思った読者は認識が甘い。この移行計画書には,「移行対象」「移行中の影響」「移行テスト」という項目が足りない。

 移行計画書に書くべきことは「誰が」「いつ」「何を」するかという三つの要素である。先の若手エンジニアが示した移行計画書には「誰が」に当たる「移行体制」,「いつ」に当たる「移行スケジュール」は書かれていたが,「何を」に当たる項目が抜けている。これでは移行対象や規模がはっきりせず,本番間際になって慌ててしまいかねない。移行スケジュールや移行体制の根拠も分からない。

 この計画書には少なくとも,何を移行するのか(移行対象),影響として何を考えるか(移行中の影響),何をテストするのか(移行テスト)――を追記すべきである。