マイグレーションとカスタマイズ　変換率のワナに迫ってみました

2021/10/26

マイグレーションを成功に導くための重要な要素に「カスタマイズ」があります。マイグレーションの検討対象になるシステムの多くは、過去にスクラッチで開発されていることが大半で、いわばオーダーメイドです。そのため、システムには必ず固有の「くせ」があり、標準化やモジュール分割の方針等も様々です。これはシステムやサブシステムのレベルでも、開発者個々人のレベルでも差が出てきます。これらの特性を正確に把握し、安全に新システムに移行する方法を把握する必要があります。陥りやすい失敗事例とともに解説しますので、‘変換率のワナ’に一緒に迫ってみましょう！

マイグレーションにおける変換率のワナとは？
マイグレーションにおけるカスタマイズの役割とは
カスタマイズがもたらす効果
まとめ

1．マイグレーションにおける変換率のワナとは？

まず、「マイグレーションにおける変換率のワナ」について説明します。各ベンダーから提案が以下のような内容だったらどうでしょうか？

A社：自動変換率100%、2千万円
B社：自動変換率95%、3千万円

これだけで考えれば、A社のほうが自動変換率も高く、価格も安いため、A社を採用するのが妥当です。しかし、以下のように保証範囲が追加されたらどうでしょうか？

A社：自動変換率100%、2千万円、疎通確認後に納品
B社：自動変換率95%、3千万円、出力の新旧一致を確認後に納品

これは、どちらが「お得」かが分からなくなってきます。製造・単体テストまでを請負契約とした場合に、上記の例では、納品後の不具合で「無償」で修正できる範囲が異なります。提案を受ける場合には、金額や自動変換率など、分かりやすい指標に注目しがちですが、実は「保証範囲」も重要な観点の１つです。しかし、この観点に気が付かないと、自動変換率が高ければ、テストは最小限で問題ないだろうと考えてしまいがちです。これが「変換率のワナ」です。
具体的には、自動変換したプログラムは、個々の命令が動いても、画面やバッチ処理など「機能単位」で見た際に正しく動かないケースがあります。A社に委託した場合、納品後の結合テストで検知した疎通確認範囲外の不具合は「追加料金で委託」するか「発注元で修正」する必要があります。実際に、このような理由でプロジェクトの期間・コストを大幅に超過した事例も存在します。

2．マイグレーションにおけるカスタマイズの役割

それでは、プロジェクトを予算・期間内に収めて完遂するために「気を付けるべき観点」とは何でしょうか？私達は「自動変換率という言葉を正しく把握すること」だと考えています。
プロジェクトにより優先事項は異なるので、A社とB社のどちらが正しいか？は、一概には言えません。しかし、発注者側は少なくても「違い」を正しく認識する必要があると考えます。
まず、「自動変換率」という言葉の使い方が、会社によって違っています。これは、注意しないと気がつかない観点だと思います。
先に挙げた2社でいうと、各社の「自動変換率」の定義は以下が想定されます。

A社：自動変換率＝論理的に正しく（コンパイルエラーなく）、自動で変換できる割合
B社：自動変換率＝機能が正しく動く状態に、自動で変換できる割合

これらの考え方が背景にあるため、納品時の保証範囲に差が出ていると考えると「なるほど」と思うのではないでしょうか？

そして、B社のように、自動変換率が100%にはならないという考え方の際に重要なのが、変換ツールの「カスタマイズ」です。システムが「機能」として正しく動くためには、手修正が必要な前提で考えているため、前工程で可能な限り自動変換率を上げる活動を行います。
なお、手修正が必要となる例として、VBのVariant型、JavaのObject型、COBOLのGO-TO文など、プログラムの前後の文脈を捉えて別言語に変換する必要があるケースがあります。これらの扱いを、コンパイルエラーがないので「是」とするか否かで、A社とB社の考え方に違いが生じます。

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

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

3．カスタマイズがもたらす効果

前述の通り、変換ツールの「カスタマイズ」は、自動変換率の向上を目指す活動です。その背景には保証範囲を「どこまで」考えるか？という違いがあります。これは一長一短で、既存の変換ツールをカスタマイズせずに「そのまま利用」したほうが、コストは安くなります。
それでは、カスタマイズがもたらす効果とは何でしょうか？同じくA社とB社の事例で比較します。

A社：システムが変換ツールの特性に合っていれば短納期・低コストを実現できる
B社：システムに合わせてカスタマイズを行うので、調査完了段階で計画精度が高い

つまり、A社ではプロジェクト納品時の品質はブラックBOXです。運が良ければ問題なく完了し、運が悪ければ納品後に「もぐらたたき」のように不具合の解消に工数・期間を投入することになります。ただし、A社の例が必ずしも「悪い」とは言えず、それを理解した上で、委託するケースは十分にあり得ます。しかし、その違いを誤解したまま委託すると期間やコストのコントロールが難しくなります。

逆に言えば、B社のようにカスタマイズを事前に実施する場合は、固有のシステムに対して自動変換率と手修正の作業量を正確に導き出すことができます。つまりカスタマイズがもたらす効果は「プロジェクトの計画精度の向上」であると言えます。

4．まとめ

本ブログではマイグレーションとカスタマイズの観点から変換率のワナに迫ってみました。もっとわかりやすくご説明するために、A社とB社の考え方の比較から、発注者側が注意すべきポイントについて記載しました。あらためて、どちらの手法が正しいか？という観点ではなく「違いを正しく把握すること」の重要性と、判断を誤りやすいポイントを中心に解説しました。マイグレーションを検討する際の一助になれば幸いです。

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

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