マイグレーションと基幹システム　共通化を実現する方法とは？

2021/08/12

基幹システムのマイグレーションを検討する際に、アタマを悩ませる問題のひとつに「共通化」があります。マイグレーション対象となるシステムは歴史が古く、基幹システムともなると長年の保守の過程で多くの重複コードを生み出しているケースが多々あります。限られた期間の中で、マイグレーションと「共通化」を同時に実現する手段を解説します。

基幹システムのマイグレーションで発生する要件
なぜ、基幹システムでは重複コードが生まれるのか？
なぜ、基幹システムのマイグレーションでは共通化が困難なのか？
基幹システムの共通化を実現する方法

1．基幹システムのマイグレーションで発生する要件

基幹システムのマイグレーションを検討する際に、同時に取り込みたい要件として「共通化」があります。せっかく新システムにするわけですから、「共通化」も同時に進めて、将来の保守性を向上させたいと考えるのは自然です。
この要件、特にシステム資源量が多い「基幹システム」で発生します。実際に私達へのご相談においても、「共通化」の意識や要件が特に強いのは、規模の大きいシステム、業務の根幹データを扱うシステムなど、いわゆるミッションクリティカルな「基幹システム」と呼ばれるシステムのマイグレーションを検討する企業です。
システム規模が大きいほど、保守開発に費やす時間と労力は増加します。そして、類似のプログラム資源である「重複コード」が多ければ多いほど、保守開発の効率は悪くなります。小さなシステムであれば目をつぶることができる「生産性の低下」でも、それが巨大なシステムになれば「見過ごせない問題」になります。そのため「基幹システム」のマイグレーションでは「共通化」の要件が発生しやすいと考えられます。

2．なぜ、基幹システムでは重複コードが生まれるのか？

それではなぜ、「基幹システム」では「重複コード」が生み出されるのでしょうか？技術者の考慮漏れなども無く、もちろん手抜きなどが無くても、基幹システムには「重複コード」が時系列で増えていきます。ここでは、その原因に迫りたいと思います。

架空の損害保険システムを例に考えます。この会社は、これまで販売していた「自動車保険」に加えて、新たに「火災保険」を取り扱うことになりました。そのため、新たに「火災保険システム」を開発する組織を設立しました。「自動車保険システム」は１０年前に開発されたものであり、将来的に「火災保険」を扱う事を想定したものではありませんでした。

販売する保険商品は違いますが、保険契約の内容をデータベースに登録する部分の仕組みは同じです。この場合、以下の２通りの選択肢が考えられます。
A）「自動車保険システム」の一部を、「火災保険システム」でも利用できるように「共通化」し、各システムの固有処理だけを、それぞれ実装する。
B）「自動車保険システム」に影響を与えないように、「自動車保険システム」を複製（コピー）して、「火災保険システム」の固有箇所だけを変更する。
かなり極端な例ですが、皆さまの基幹システムにも、このような背景で作られた「重複コード」があるのではないでしょうか？また、あなたがこの例の開発責任者だった場合、A）を選択したのでしょうか？この選択にあっては、「共通化」に伴う以下の懸案を踏まえて総合的に判断します。

安定稼働している「自動車保険システム」に不具合混入リスクが発生
「火災保険システム」に加えて、「自動車保険システム」に改修コストが発生
「自動車保険システム」の機能を再編成するために分析期間が必要

上記に加えて、「自動車保険システム」と「火災保険システム」の担当組織が異なる場合は、A）を選択する上での懸案事項がさらに多くなります。
基幹システムは規模が大きいからこそ、体制は「縦割り」になりやすく、加えて、上記に挙げた懸案事項が阻害要因となり、A）の選択を困難にします。結局は、「重複コード」を生み出してしまうＢ）を選択したほうが、リスクもコストも抑えられ、期間も短縮できるという結論になりやすい傾向にあります。
このような背景や組織的な構図が、保守開発のフェーズでも続き、同様の大小様々な選択が重なることで、システムは「冗長化」していくと考えられます。このことから、「重複コード」は特に「基幹システム」に生まれやすい背景がある、と言えます。

3．なぜ、基幹システムのマイグレーションでは共通化が困難なのか？

次に、「共通化」と「マイグレーション」の組み合わせを考えてみます。この２つは、少々相性の悪い関係にあります。それぞれの特性をキーワードで列挙しました。

マイグレーション：現行踏襲、コスト・期間短縮、EOL期限の解消
共通化：現行機能の再編成、分析に時間がかかる、将来的な保守効率改善

「マイグレーション」を選択する場合、「スクラッチ」による再構築よりも「期間・コストを圧縮できるから」という判断が背景にあるケースが多いのではないでしょうか。
これに対して、「共通化」というテーマは、現行システムの分析に時間を要します。分析対象のシステム規模が大きいほど、必要な期間は増加します。言い換えると「基幹システム」の分析は、とても大変です。
このように、特に「期間」の観点から「時限性のあるマイグレーション」と「時間のかかる共通化」は、同時に考えることが困難な「組み合わせ」です。

4．基幹システムの共通化を実現する方法

「共通化」の分析にはなぜ時間がかかるのか？それは、膨大なプログラム資源から「似ているコード」を探すのが大変だからです。大変な理由は以下の３点です。

資源量が多ければ、１回あたりのサーチ時間が長くなる
無作為に比較する場合「全プログラム数×全プログラム数（累乗）」の比較回数が必要
「似ている」という判断基準が「あいまい」なため、比較結果の判定に時間を要する

最終的には、「共通化」は「似ているプログラム」を特定して機能を「汎化、もしくは特化する」ことで実現します。これはこれで大変な作業です。その前作業となる、基幹システムを構成する膨大な資源を相手に「似ているプログラム」の候補を抽出する分析作業にも、多くの時間を割かなければいけません。これが「期間」を必要とする主たる原因です。
この問題を解決する方法は、人間の判断が必要な対象を減らすことです。つまり、基幹システムを隅々まで分析する作業が自動化できれば、分析期間の短縮が可能です。
サーチツールやコンペアツールは多くありますが、「共通化」を目的とした分析に特化したものは少なく、思うように　分析期間を短縮出来ませんでした。私たちは、この問題を解決するために独自の分析ツールを作りました。プログラムの「変数定義」と「メソッド定義」を網羅的に比較して、プログラムの類似率を導き出す、わりとユニークな手法です。もちろん、サブシステムや組織的な壁も関係なく、一律比較を行います。これにより、膨大な資源量でも「共通化できる候補」を自動的に短期間で抽出することができるようになりました。
「マイグレーション」に限らず、基幹システムの「再構築」や「保守開発」でも、「共通化」の要望はあります。そして、実現には「期間」の問題がつきまといます。期間を短縮するためには、上記に挙げたような一定の判断基準をもつ「分析ツール」を利用して効率化することが「共通化」を実現する有効な方法の１つになります。

当サイトでは、システム移行について迷われている企業様向けに、マイグレーションをわかりやすく説明している資料をご用意しております。「システム移行変換率と品質向上サービスオープンマイグレーション基本ガイドブック｣は、システム移行時の注意点やポイントが理解できる資料になっています。情報収集中の方や、具体的な解決策を探している方は、ぜひ、当ページより資料をダウンロードください。

その他ブログのご案内

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