MENU

Part1 :DX推進に向けた基幹システムの対処法 ~クラウドネイティブな手法でモダナイズする

2025年の崖とDX実現手法

 経産省が2018年に公開した「DX レポート~IT システム『2025 年の崖』克服とDX の本格的な展開~」が話題である。2025年に日本全体で12兆円、企業平均で年314万円相当の経済損失が発生。その主因は複雑化・老朽化・ブラックボックス化した基幹業務システムであり、システムトラブル、データ消失リスクが懸念される。老朽化した基幹業務システムは保守・運用に78.8%の予算を割り当てねばならず、その結果、デジタルトランスフォーメーション(以下、DX)が進まず、日本企業の競争力が低下し続けている、というストーリーである。 
 
 被害額推計の規模感や問題意識のレベルはユーザーごとに温度差があるだろうが、総論に異論なしではないだろうか。
 2025年の崖に向けた対処法は、次の4案に集約される。
 
① 塩漬け
② レガシー技術でシステム連携
③ クラウドネイティブな技術でモダナイズ
④ 全面再構築
 
 ①は基幹システムを改変しないという選択である。②はFTPやSQLアクセスなどのレガシーな技術でシステム間を連携し、(基幹システムは大きく改変せずに)崖を克服する、③はREST APIやマイクロサービス化などクラウドネイティブなテクノロジーで、基幹システムを段階的にモダナイズする、④は既存システムから全面脱却して、新しいシステムに乗り換えるとなる。
 
 基幹システム再構築の目的がDXであるなら、おのずと③④が中心(必須)となるであろう。ただし一般的にすべての基幹システムをDX推進するのは、非現実的かつ不必要であり、適材適所でのDX対応推進になると推測される。
 
 その理由は費用、要員計画、そしてそもそも論としてDX推進とは関係性の薄い(投資対効果の認められない)システム群が存在するからである。その結果、多くの企業では①②を選択肢とする領域が残るものと思われる。
 
 

サンプルケースの設定

 
 本稿では①~④の対応方針のうち、③を中心的に取り扱う。Before/Afterで示すと、図表1のようなシステム環境刷新を想定する。
 
 
 
 ここでは便宜上、Webアプリケーションの例で記載しているが、それ以外のアプリケーション(5250、バッチ、クライアント/サーバーなど)でも基本的な考え方は同じである。
 
 また簡略化するため、すべてのシステムをマイクロサービス化するかのように書かれているが、前述したとおり、全システムをクラウドネイティブ対応するのは非現実的であり、投資対効果的にも見合わないと考える。実際には、従来のまま存続するシステムが存在するはずである。
 
 なおDXはさまざまに解説されているが、本稿では以下のように定義する。
 
DXの目的

1. 新しい企業価値の創造
  ビジネストランスフォーメーション
2. 企業競争力
3. 変わり続ける企業文化

 
DXの手法
1. クラウドネイティブ技術
2. ハイブリッドクラウド
3. CI/CD(継続的なインテグレーションとデリバリ)
 
 現在のITインフラ環境は、クラウドとオンプレミスに分類される。それぞれのメリット/デメリットについては多様な解釈が可能なので、本稿では図表2の定義を前提に議論する。
 
 
 
 プライベートクラウドはハードウェア視点ではオンプレミス、システム運用・アプリケーション面ではクラウドと定義できるが、オンプレミスとクラウドという2軸での議論から演繹できるため、本稿では割愛する。
 
 

ある現行システムの課題

 
 以上のような条件下で基幹システムアプリケーションをマイクロサービス化して、クラウドネイティブ対応する事例を考えてみたい。「ある現行システム」と名付けた仮定のシステムが図表3である。ある現行システムの課題点について、以下のように補足する。
 
 
 
・ Webの3層構造アプリケーションだが、個別サービス化を想定していないモノリシックな設計のため、近年発生するアプリケーションの細かな仕様変更ごとに多くのアプリケーションモジュールを改修する必要がある。
 
・ 保守生産性が悪いという評価がある。
 
・ 簡単なアプリケーション改修でも1か月以上のサイクルになり、課題となっている。DXを想定し、今後は細かなアプリケーション改修が定常的に発生すると予想される。
 
・ さらに新しい販路(たとえば新しいショッピングサイト)がダイナミックに増減するなどのビジネス変化も想定される。図表3はある1つのショッピングシステム向けで、この機能セットが2つ、3つと増えるようなイメージでビジネスが変化すると予想される。
 
 このような課題点を解決し、DXを実現するのに適したアプリケーション領域をマイクロサービス化、ハイブリッドクラウド化することが今回のシステム更改の目標となる。
 
 実際の方法や範囲は多様だが、実事例を参考に本稿での改善方針案を図表4に示す。骨子となる改善策は、アプリケーションのマイクロサービス化、コンテナ化と、その結果として実現されるハイブリッドクラウド化である(図表4に例示した改善案での主要な実施内容はPart 3以降で解説)。
 
 
 
 図表5に、図表4の改善方針を適用して刷新されたインフラ・アプリケーションのモデル例を示す。
 
 
 
 このTO BEモデルが実現すれば、アジャイルでのCI/CDの実現、オンプレミスかクラウドかを意識しないインフラ基盤の柔軟性の獲得、ハイブリッドクラウド環境の運用管理の統一・標準化による管理コストの最小化が可能になる。現行システムでは、対応困難なDXを容易に実現可能なシステム基盤を獲得できる。
 
 

 

著者|

佐々木 幹雄

 
日本アイ・ビー・エム株式会社
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
 
AS/400誕生とほぼ同時期からIT業界に関わる。IBM i やPC、ネットワーク機器など一般企業のIT基盤の提案・構築、アーキテクトなどを幅広く経験。IBM i エバンジェリストとしての活動もある。
 

 

・・・・・・・・

特集|IBM iのマイクロサービス化

 
 
 
 
 
 
 
・・・・・・・・
 

Column 1 OpenShiftかKubernetesか
Column 2 どこでもKubernetes
Column 3 ミドルウェアのコンテナ化対応
Column 4 SCNは戦略策定のためのフレームワーク
Column 5 ハイブリッドクラウド移行(中期)計画を作る
Column 6 アジャイルはSoEだけのものか?
Column 7 IBM iサービスとDb2 for iサービス
Column 8 IBM iのクラウドサービス
Column 9  コンテナテクノロジーを導入しても、イノベーションは起きない
 
 

[i Magazine 2020 Spring掲載]

新着