目次

• リビルド開発の必要性
• リビルド開発手法のプロセス
• 次期システム向けの再設計方針
• まとめ

リビルド開発の必要性

経済産業省のDXレポートにより「2025年の崖」問題が提唱されており、老朽化した既存システムがDX推進の足かせとなっていることが同レポートにより指摘されています。一般的に、老朽化した既存システムは巨大化かつ複雑化、ブラックボックス化する傾向があり、COBOL、メインフレームなどのレガシーな技術が使われているケースがあります。これらのシステムは容易にマイグレーションができないことからつぎはぎで機能追加を行って使い続けるしかなく、結果的に莫大な維持保守コストがかかっている企業が多数存在します。

こうした課題を解決するため、NTT DATAではモダナイズジャーニー（※1）を用いた移行を推奨しています。モダナイズジャーニーに沿って既存システムを段階的に移行することによって、各段階で得られるメリットを早期に享受することができます。
例えば、既存システムがモダナイズジャーニーでいう「レガシー」の状態だった時を考えます。この状態はCOBOLのアプリケーションがメインフレームで動いており、そのアプリケーション自体も密結合でスパゲッティコード化した非モジュール型のシステムです。こういったシステムに対して、リホスト、リライトを行うと「オープンレガシー」もしくは「サーバレガシー」といった状態になります。この状態であればメインフレームからの脱却は達成することができるため、基盤部分のコストメリットを得ることができます。一方で、リホストを選択した場合はCOBOLが残り、リライトを選択したとしてもCOBOLの命令の仕様やメインフレーム基盤との依存性が残るJavaソースが出来上がります。そのため、リホスト、リライトをしただけでは完全にレガシーからは脱却できず、アプリケーション部分の維持保守コストの問題が残り続けることになるのです。

モダナイズジャーニー

そのため、こういった維持保守コストの問題を解決するためには、リビルド（リファクタリング、リインターフェース、リアーキテクチャを含む）開発が必要となります。リビルド開発のプロセスについて、次節で紹介します。

リビルド開発手法のプロセス

リビルド開発を行うための手法として、NTT DATAはN字開発プロセスを整備しています。リビルド開発では、現行設計書の最新化、次期システム向けの再設計、通常のウォーターフォール開発の流れで開発を行います。一度設計に遡り既存のプログラムを破棄してから、設計書を元に再度プログラムを作り直すことによって、既存の保守性の低い作りから脱却することができ、アプリケーションの保守性を高めることができます。

N字開発プロセス

この中の次期システム向けの再設計では、次期システムの開発方針に沿って現行の設計書を元に再設計を行います。詳細について次節で紹介します。

次期システム向けの再設計方針

次期システムの再設計において、アプリケーションとデータベースの再設計有無の組み合わせにより3つの選択肢があります。それぞれの特徴のサマリは下記の表の通りです。それぞれの特徴とメリット／デメリットの詳細について解説していきます。

次期システムの再設計方針の比較表

アプリケーションのみの再設計の場合

1つ目の選択肢はアプリケーションのみの再設計です。アプリケーションのみ再設計とは、データベースのテーブル設計は変えずに、アプリケーションのみを見直す方針のことです。レガシーシステムの場合、1テーブルのカラム数が巨大なメインフレーム時代の構造がそのまま次期システムでも引き継がれてしまうことになります。

アプリケーションのみ再設計する方針の概要

この手法のメリットは、既存の業務仕様を大きく変える必要がないため、言語に依存しない既存システムの設計要素を部分的に流用することができる点です。また、データベースの移行が不要となるため、マイグレーション前後でデータベースを共用することができるため、段階的にアプリケーションを移行することができます。
この手法のデメリットは、データベースの構造を見直さないため、現行システムにおいて1つのテーブルを複数のサブシステムが更新する構造となっていた場合、容易にサブシステムを分割できない点になります。結果、サブシステム間の疎結合化はアプリケーションのリファクタリングでできる範囲にとどまり、効果は限定的となります。

データベースのみを再設計する場合

2つ目の選択肢はデータベースのみの再設計です。データベースのみを再設計する場合、アプリケーションからデータベースアクセス処理を呼ぶ部分までは修正を加えず、データベースアクセス処理にて新しい正規化されたテーブルへのアクセスに変換することによって再設計を実現します。

データベースのみ再設計する方針の概要

この手法のデメリットは、性能劣化のリスクが非常に高い点です。レガシーシステムは1レコードに対し1クエリを投げるつくりが多いのに対し、次期システムで用いるRDB（リレーショナルデータベース）はクエリ発行回数が多くなると性能劣化する傾向にあることから、ループ処理の中でデータベースアクセスを行う処理がある場合に著しく性能劣化する傾向があります。また、現行のテーブルと次期テーブルの差異が大きければ多いほど変換処理の規模も大きくなるため、変換処理によるレスポンス遅延が発生し、開発コストも増大します。
この手法のメリットはテーブルが正規化されるため、データ利活用性が向上する点です。とはいえ、デメリットが大きいため、性能劣化や変換処理の開発コスト増大を回避できる見通しが立ってない場合は選択しないのが無難です。

アプリケーションとデータベース両者を再設計する場合

3つ目の選択肢はアプリケーションとデータベースの両者を再設計する方法です。アプリケーションとデータベース両者の再設計は、データベースの正規化や分割を行った上で、アプリケーションも1機能1テーブル更新となるようサブシステム分割を行い、最終的に疎結合化を目指します。

アプリケーションとデータベース両者を再設計する方針の概要

この手法のメリットは、1テーブルに対して1サブシステムのみが更新する構造に見直すことによって、疎結合化が進むことです。また、機能の凝集度も高まるため、メソッド呼び出しからWeb APIに置き換えることも容易になります。また、データベースの正規化も行うので、データ利活用性が向上します。
この手法のデメリットは、データベースの構造変更に伴い業務仕様が変わるため、設計は1からに作り直す必要がありコストがかかる点です。また、データベース変更に伴ってデータベースの移行が必要となるため、段階的な移行が難しく開発が大規模になる点も注意が必要です。
また、サブシステム分割の実現性にも注意が必要です。特に注意が必要なのはトランザクション境界の観点です。一般的に、サブシステムを跨ったトランザクション境界は設けないため、現行1トランザクションで更新を行っていた処理が複数サブシステムに分割され、トランザクション境界が分かれた場合に、その仕様変更は許容されるのか、許容されない場合にどのような設計変更を行うのか、十分な実現性評価が必要です。

まとめ

リビルド開発において、アプリケーションのみの再設計、データベースのみの再設計、アプリケーションとデータベース両者の再設計の3通りのリビルド手法について、それぞれの特徴とメリット・デメリットについて紹介しました。
NTT DATAは、開発ロードマップ策定や根拠のある費用対効果試算を提供するコンサルティングサービス（※2）を提供しています。ITのあるべき姿を描けない、保守コストが改善しない等、お客さまの課題に応じ最適な開発手法をご提案していくことで、お客さまのDX推進にこれからも貢献します。