マイグレーションと保守　よくある疑問にお答えします

2022/01/11

マイグレーションと保守の関係については、様々な疑問が浮かびます。移行後の保守性は？ドキュメントは？構造は？からはじまり、システム刷新と同時に保守性を改善できるのか？など。ひとことで「保守」といっても、様々な観点や目的があるため、全てのケースでマイグレーションを選択することが適切とは言いきれません。
このような、マイグレーションと保守にまつわる様々な疑問を解消するとともに、移行後の保守を見据えた場合に「できること」「できないこと」を解説します。

マイグレーションと保守　よくある疑問
一般的なマイグレーションの手法
マイグレーションによる、保守性劣化の懸念
マイグレーションによる、保守性改善の期待
まとめ

1．マイグレーションと保守　よくある疑問

まず、「マイグレーションと保守」に関する、よくある疑問を挙げていきます。マイグレーションを検討する場合、移行後の保守性は気になる観点です。プログラミング言語やフレームワークの変更で、移行後の保守性に対する疑問が生じます。よくある疑問の内容は「保守性が劣化しないのか？」と「保守性を改善できないか？」の２つに大きく分類されます。

<保守性の劣化を懸念する疑問>

ソースの可読性は劣化しないのか？
既存の設計書は流用できるのか？
既存の体制（人員）で保守できるのか？

<保守性の改善を期待する疑問>

資源を共通化（スリム化）できるのか？
設計書が存在しないが、作成できるか？
テストを自動化できるか？

これらの疑問について、１つ１つ解消していきたいと思います。

2．一般的なマイグレーションの手法

それぞれの疑問の解説に先立ち、一般的なマイグレーションの手法を説明します。言語やフレームワークにより種類は様々ですが、一般的には概ね以下のような手法が採用されています。

自動変換ツールによるコンバージョン
自動変換率を上げるための共通部品群（ラッパー等と呼ばれる）
自動変換できない部分の手修正

このように、移行前のソースコードから自動的に新しいソースコードを生成する方式が一般的です。
共通部品群（ラッパー）は、変換に伴うギャップを吸収する目的で作成されており、古い言語の命令文を新しい言語で再現するための部品群です。これにより、自動変換率の向上が実現できます。また、手修正は自動変換で対応できない（もしくは、手修正したほうが低コスト）ケースをカバーする目的で行います。
このように、マイグレーションの中心には「ツールによる自動変換」があると言えます。

＼システム資産の棚卸／
資産棚卸サービスの活用を検討されている方はこちら！

3．マイグレーションによる、保守性劣化の懸念

ソースコードが自動変換されるということは、システムのコンテンツであるビジネスロジックの内容や順序は移行前と同じになります。また、機能や部品の単位も、移行前の状態が維持されます。例えば、移行前の「社員情報取得部品」は、移行後も「社員情報取得部品」のままです。
アプリケーション基盤やプログラミング言語が変わっても「入れ物」が変わるだけで、保守で扱いなれた構成や内容は維持されたまま、新システムに移行されます。このような特性から、<保守性の劣化を懸念する疑問>については、ほとんどのケースで「問題がない」と言えます。

<保守性の劣化を懸念する疑問の答え>

ソース可読性は劣化しない
- 自動変換されるので、構成・部品の単位は維持される。
- 現行システムのコメント行は、そのまま移行される。
- 新システムで対応できない命令は、旧言語と同等の命令文で再現（ラッパー）される。

既存の設計書は流用できる
- 機能の構成・部品の単位に変更が無いため、機能設計レベルでは流用可能。
- 詳細設計レベルでは、物理名称等が変更になる場合があるが、読み替え表で識別可能。

既存の体制（人員）で保守できる
- 既存の設計書を流用でき、可読性も同等のため既存体制（人員）の知見を活用できる。
- COBOL→Javaなど将来的な技術者不足の解消への対策として移行を行う場合でも、旧言語の技術者が読解できるレベルに変換される。

マイグレーションを選択することは「現行資産を最大限活用」しながら、保守性を維持したまま新システムへ移行できるというメリットがあります。

4．マイグレーションによる、保守性改善の期待

一方、マイグレーションの手法が自動変換であるという同じ理由から、機能的な再編成の要素はないため、<保守性の改善を期待する疑問>については、「実現が困難」となります。そのため、システム移行に合わせて大幅な保守性の改善を目指すのであれば、以下のような方法を検討する必要があります。

マイグレーションではなく、スクラッチによる再構築を選択する。
マイグレーション完了後に、保守性改善の対策を行う。

マイグレーションでは新システムに「そのまま移行」するという手法から、テストの主眼が「現行と同じであること」の確認になります。マイグレーションに加えて保守性改善のために機能を再編成してしまうと、問題が発生した場合の原因特定が複雑化してしまいます。そのため、選択肢としては、費用と期間が許せばスクラッチを選択する。もしくは、マイグレーション完了後に保守性改善策を実施するのが有効な手段となります。

<保守性の改善を期待する疑問の答え>

資源を共通化（スリム化）は困難。別手段で対応する。
- マイグレーションと機能の再構成を同時進行するのが非効率。
- テストの品質保証が複雑化し、コスト・期間メリットを損なう。
- ただし、マイグレーション完了後（もしくは開始前）に、分析ツールを活用して、共通化を行うことは可能。

設計書が存在しない場合、作成できるが別手段での対応になる。
- ソースから自動変換するため、基本的には設計書が介在しない。
- マイグレーション単独では設計書のリバース作成は実施しない。
- ただし、ソース資源から設計書を生成するツールを活用すれば作成自体は可能。

テストは自動化できない。ただしテスト資源は活用可能。
- マイグレーションをしただけでテストを自動化されることはない。
- しかし、自動化ツールが豊富な開発環境（プログラミング言語）へ移行すれば、保守性を改善するための選択肢を広げることにつながる。
- また、マイグレーションでは新旧の比較テストを行うため、テストデータの再利用は可能。

5．まとめ

マイグレーションと保守にまつわる疑問を紐解きながら「できること」「できないこと」を解説してきました。マイグレーションは良くも悪くも「現状の保守性を維持したまま新環境」に移行するという特性があります。新環境に移行することで、副次的に保守性の向上にはつながりますが、それ以外は別の手段（分析ツールなど）での対応が必要になります。
マイグレーションは、スクラッチに比べて費用・期間を抑えることができる選択肢ですが、保守性の維持や改善と合わせて考えた場合に、それぞれの特性を理解した上で、どちらを優先するのかを判断する必要があります。

当サイトでは、システム移行について迷われている企業様向けに、マイグレーションをわかりやすく説明している資料をご用意しております。「うまくいくマイグレーションとうまくいかないマイグレーション、その違いとは？」というダウンロード資料には、マイグレーションの品質向上のポイントや、マイグレーション変換率に依存しない考え方を記載しております。ぜひ、ダウンロードページより資料をご覧ください。

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