マイグレーション計画書の作り方　移行方針やテスト・品質計画も説明

2021/05/25

マイグレーション開発は、通常の開発とは「前提」や「プロセス」が大きく異なるため、これまでスクラッチ開発や保守開発を長年経験されたベテランのマネージャであっても、計画書の作成に迷われるケースが多いのではないでしょうか。マイグレーション開発のポイントを十分に理解しないと、必要なテストが十分実施されず、結合テストで不具合が多発する事例や、必要以上にテストを行ってしまい、想定していた生産性が出ない事例に陥ってしまいます。
弊社の豊富な成功事例をベースとして、マイグレーション計画書の作り方をご紹介します。移行方針やテスト計画・品質計画など計画書別に、マイグレーション開発で押さえるべきポイントを解説いたします。

プロジェクト計画書で最初に明確にすべきポイント
マイグレーション計画書の移行方針の立て方
テスト計画書での品質の積み上げ方
マイグレーション計画書の作り方　まとめ

1．プロジェクト計画書で最初に明確にすべきポイント

マイグレーション開発において、プロジェクト計画書にはどのような内容を記載すべきでしょうか。ソースをツールで変換するだけなのにプロジェクト計画書など必要なのか？と疑問を持たれる方も、いらっしゃるかも知れません。
よく勘違いされますが「自動変換できれば正しく稼動する」という認識は誤りです。変換は正常に行われても＜現行では許容されるレベルであったプロパティ設定誤りが、新の言語では許容されずに誤った挙動をするケース＞や＜言語の特性により差異が生じるケース＞等がよく発生します。そのような不具合に対して適切に対応し、安全に移行するための開発プロセスや品質計画を、しっかりとプロジェクト計画で定義します。

他にも様々な観点がありますが、私は以下の３点が重要であると考えます。

プロジェクトの基本方針
業務要件
システム要件

１．プロジェクトの基本方針
マイグレーション開発では、通常開発と同様に色々な問題が発生し、難しい選択を迫られます。その際の判断基準となるのがこの基本方針になります。
現状のままでは何が課題だったのでしょうか。マイグレーションを行うに至った理由は、ハード・ソフトのサポート切れやマシンスペックの限界、古い技術を使用することによる技術者確保などが課題になることが多いです。
各課題についてお客様に丁寧にヒアリングを行い、その重要度とリミットを明確にしておくことで、開発中に発生する問題を円滑に対処できるようにします。
またOSの相違などで生じる細かい差異については、基本的に許容して進める方針であることもここで合意しましょう。

２．業務要件
マイグレーション開発において業務観点の改修や追加機能は行わないことが基本です。お客様は日頃から保守開発などに併せて他の改修を行っているケースも多いです。ここで、機能については一切変更しない」という点について改めて認識を合わせましょう。
また移行範囲を明確にするため、対象となるサブシステムなどを記載することも、後々の揉め事を回避するために重要です。

３．システム要件
マイグレーション開発では、現行システムを構成するハード、OSやアプリケーションソフトなどのうち、一部または全てを入れ替えます。何を何に入れ替えるのか、どのバージョンからどのバージョンに入れ替えるのかを明確にします。
マイグレーション開発におけるテストは現行と新の比較によるテストが基本となります。その際に再現する現行と新のシステム構成が誤っていると、正しく比較が行えず品質を担保できません。
通常の開発と異なり、現行のシステム構成が新と同レベルに重要である点がマイグレーション開発の特殊であり肝要な点です。古いハードやアプリケーションソフトについては現時点で調達が困難なケースもあります。早めに調達方法の目処を立てること、困難な場合はどのように代替するかを明確にしておく必要があります。

2．マイグレーション計画書の移行方針の立て方

マイグレーションは通常開発より規模が大きくなることが多く、行き当たりばったりで開発をしていると高い品質で平準化することはできません。
弊社では、要件定義工程で観点を抑えた機能に対してプロトタイプ開発を行い、その結果を踏まえた移行方針をマイグレーション計画書として定めます。
この中で、資源の種類別にマイグレーション方針を具体的に定義します。オンラインプログラム・バッチプログラム、帳票や、ツールの利用箇所について、イメージや具体的なソースの例を挙げて変換方式を定義します。
大部分は変換ツールによる自動変換を行いますが、変換ツールでは対処できない人手による変換が必要なパターンが出てきます。この手修正部分について、別紙として手修正手順書を作成することで、人に依存しない形で品質を確保します。
内容はかなり細かくなりますが、ここで誤ると全体に影響が出てしまうのでしっかりと検討を行う必要があります。
それでも開発を進める中で新たなロジックのパターンや、環境の変化に伴い、内容の訂正が必要となる場合もあります。その際には、速やかに訂正して関係者に周知するような柔軟な動きも必要となります。
現行を踏襲するマイグレーション開発では、通常開発で作成する外部設計書（システムの振る舞いの定義）や内部設計（機能の実装方法）は必要ありませんが、このマイグレーション計画書で、しっかりと移行の方針を定めることが非常に重要です。

＼うまくいくマイグレーション／
基幹システムのマイグレーションを検討されている方はこちら！

＼オープンマイグレーションとは？／
マイグレーションについて詳しく知りたい方はこちら！

3．テスト計画書での品質の積み上げ方

テストは基本的に現／新におけるシステム操作の比較検証で実施します。
テスト計画では、以下の２点が重要です。

テスト粒度
現新差異判定

１．テスト粒度
現新比較による検証を行うことが、効率的かつ正確に検証を行えることは容易に想像ができるかと思います。では、どのような粒度でテストを行えば必要十分となるでしょうか？

単体テストでは、テスト対象の変換方法別に粒度を決定します。

変換ツールにより自動で変換を行った部分
予め変換ツール自体の単体テストを十分に行うことで、変換後のプログラムについてはテスト粒度を下げることが可能です。ブラックボックステストとして、イベント毎やジョブネット毎に、レイアウト、データ、操作性が全て一致することを検証することで品質を担保します。
人手により修正している部分
人手により修正した部分は、スペルミスや文法誤りなど人的ミスが残存している可能性は通常開発と同様にあります。
ホワイトボックステストとしてカバレッジ１００％となるテストで品質を担保します。

結合テストは基本的に通常開発と同レベルでの検証を行います。マイグレーションだからと結合テストを省略すると、プログラム単位では問題無く稼動していても、結合した機能としての挙動が正しくないケースは往々にあります。
結合テストで必要な検証まで省略しないよう注意しましょう。

２．現新差異判定
OSの違いなどにより、微妙なレイアウト差異やフォカース位置の相違などはどうしても発生します。この差異まで完全に一致させるのは非常に労力が必要ですし、その必要も無いことが多いです。
テスト計画書では「差異が発生すること」、また「発生した場合にお客様に報告して共有し、<許容できる差異>か<業務上支障が出るので対応が必要な差異>なのかを協議する会議を開催すること」を合意します。

４．マイグレーション計画書の作り方　まとめ

今回、マイグレーションにおける計画書の作り方の概要を解説しました。
同じマイグレーションといっても、言語の変換バリエーションはもとより、既存システムの状態などにより、常に状況は異なります。その都度どこにリスクがあるのかを見極め、その手当てを各計画書に盛り込むことが必要となります。
各項では、詳細な部分まで触れられていないので、別の機会に詳細な解説ができればと思います。

当サイトでは、システム移行をお考えの方に向けて、参考になるダウンロード資料をご用意しております。『システム移行　変換率と品質向上サービス「オープンマイグレーション」基本ガイドブック』は、御社のシステム移行の意思決定のヒントになるはずです。
ぜひ、ダウンロードページより資料をご覧ください。

＼うまくいくマイグレーション／
基幹システムのマイグレーションを検討されている方はこちら！

＼オープンマイグレーションとは？／
マイグレーションについて詳しく知りたい方はこちら！

その他ブログのご案内

オープンマイグレーションサービスでは、その他下記のようなブログをご用意しております。

マイグレーション計画書の作り方 移行方針やテスト・品質計画も説明