久波 健二
日本アイ・ビー・エム株式会社
IBMコンサルティング事業本部
技術理事
ハイブリットクラウド・サービス担当CTO
モダナイゼーションはウェーブ２へ
企業のDXが迫られる中、変化への対応力を強化するために既存のシステム資産を新しい技術や設計で刷新する、システムのモダナイゼーションにチャレンジする企業が増えています。しかし「動かない」「完了しない」などのトラブルに直面することや、本番稼働したものの「対応のための開発生産性が上がらない」など期待した成果が得られないケースも少なくありません。
これは主にフロント領域と呼ばれる顧客接点のシステムが対象であったウェーブ１が一巡し、企業における一丁目一番地の業務機能が稼働する基幹システムを対象とするウェーブ２が始まったためです。既存業務や現行システムの制約を前提に、高い品質が求められる基幹システムのモダナイゼーションは、これまでにない罠が潜んでいます。ウェーブ２で陥りがちな10の罠について、IBMの経験に基づきポイントをご紹介します。
ウェーブ２で待ち受ける10の罠
1.設計書の罠
対象範囲の特定、システム移行による影響の見極め、既存システムからの移行ロードマップの作成のために、システム全体像からプログラムの処理内容に至るまで既存システムの設計情報が必要となります。しかしながら、システム構築時の設計書やプログラム仕様書が存在しない、もしくは最新情報に保守されていないケースは非常に多くあります。特に長期にわたり保守されたシステムでは、関係者が異動や退職している場合が多く、一部の改修工事は可能ですが、システム全体を見据えたモダナイゼーションの検討は簡単ではありません。
2.レガシー技術の罠
モダナイゼーション方法の選定やシステム移行による影響の見極めには、既存システムの仕組みや処理内容を理解する必要があり、採用技術の知識はその前提となります。しかしながら、技術の進化は非常に早く、当時は最適な選択肢であった技術仕様やデザインも現在では陳腐化し、理解できる人が少ないのが現状です。例えばアセンブラに代表される低水準言語のプログラム言語の仕様理解はよく話題になります。既存システムで採用された技術と最新技術の双方を理解しなければ、各技術の得意・不得意を踏まえた適切な判断を行うことは困難となります。
3.サポート切れの罠
モダナイゼーションを検討する契機として既存システムの採用製品の保守サポート切れ対応があります。一部のお客様では「戦略的塩漬け」として開発保守がほとんど見込まれないシステムを、保守サポート切れの品質リスクを承知の上で継続稼働されていることもあります。しかしながら、保守サポート切れにより製品提供ベンダーから情報提供を受けることができない状況は、不備発生時の原因の特定や製品障害の解消に向けた支援が受けられず、基幹システムでは致命傷になりかねません。同様にモダナイゼーションにおいても、保守サポート切れの製品を含むシステムの検討や移行作業は簡単ではありません。
4.パフォーマンスの罠
基幹システムのモダナイゼーションでは「３つの安（安全・安心・安定）」の維持が求められるため、既存システムで実現しているパフォーマンス要件の達成は最低限必要となります。しかしながら、多くの既存システムが単一システム内で業務処理が完了することに対し、移行後は複数のシステムで処理が分散された場合、システム間連携が増加、または複雑になりオンライン性能が低下するケースがあります。またI/O処理中心のバッチ処理に関しても、稼働環境を変更した結果、夜間のバッチ処理が遅延して翌朝のオンライン処理開始に間に合わないケースがあり、単純にCPUやメモリーを増強しても改善できないこともあります。
5.データ整合性の罠
基幹システムでは、業務処理された結果データがシステム全体でリアルタイム同期されている完全一貫性が重視されてきました。しかしながら、既存システムが単一システム内で処理が完了することに対して、モダナイゼーション後に複数のシステムに業務処理が分散される場合、各システムに格納されたデータに一時的にズレ（不整合）が発生する可能性があります。この場合、一時点で各システムのデータ項目が一致しない、最新データが得られない可能性を前提とした結果整合性の観点でシステム設計が必要となります。
6.可用性/信頼性の罠
基幹システムでは、「3つの安」の観点で既存システムの可用性や信頼性の実現が求められます。既存システムがオンプレ環境からクラウド環境へモダナイゼーションする際には、稼働環境のサービス品質保証（SLA）の考慮が重要となります。クラウド環境では誤操作・誤動作による障害が発生することを前提としたフェイルセーフの設計思想に重点が置かれており、障害発生後にいち早く復旧することを目指しています。これまでの停止しないことが前提としてあったオンプレ環境で稼働する既存基幹システムと同等の高可用性を実現することは困難となります。
7.セキュリティーの罠
基幹システムでは、モダナイゼーション後も既存システム同等のセキュリティー機能の実現が求められます。さらにDXを加速し、インターネットを利用した利便性の向上、並びに外部システムとの連携や外部サービスの活用を実現するためには、より高度なセキュリティー機能の実装が必要となります。しかしながら、多くの既存システムが社内利用者や社内システム連携を前提としたシステムであり、最新のセキュリティー対策が実施されていないことが殆どです。加えてセキュリティー機能がプログラム・ロジックに組み込まれており、機能の追加や改修が容易に実施できないことが対応を困難としています。
8.文字コード/属性の罠
業務要件の実現において忘れがちなのが、既存システムで利用されている文字コード/属性の継続サポートです。基幹システムでは、住所や氏名を含めたお客様情報管理や金銭勘定を含めた会計処理が実施されるため、適切な文字コード/属性、それを扱う関数の提供が必要となります。しかしながら、既存システムが採用したプログラム言語や稼働環境（OS）によっては、サポートされていない文字コード/属性や関数があります。モダナイゼーション移行先のシステムで文字コードがサポートされていない場合は、個々に外字登録による対応が必要となります。同様にデータ属性がサポートされていない場合は、データの処理結果、例えば利率計算の最後の1桁が異なることが起こり得ます。
9.現行保証の罠
モダナイゼーション作業では、求められる機能要件、並びに非機能要件のテスト実施は品質保証の観点で重要です。特に既存システムの機能踏襲となるコンバージョン作業では、現新比較テストにより処理結果に差異がないことを検証することが確実な方法となります。しかしながら、近道である既存システム構築時のテスト・ケース再利用を検討したものの、設計書と同様に当時のテスト仕様書が残っていないケースが多くあります。さらに機能拡張やAPI化などにより外部接続インターフェース変更をともなう場合には、現新比較による現行保証は困難となります。
10.運用保守性の罠
モダナイゼーション完了後は、既存システムと同等、またはより効率化された本番運用保守作業が求められます。しかしながら、複数システムに跨るオブザーバビリティー（可観測性）やトレーサビリティー（追跡可能性）の確保が考慮されておらず、本番稼働したものの、システム状態が把握できない、障害時に原因究明に時間がかかる、問題解析・根本原因究明に必要な情報が得られない例が増えてきました。外部クラウド・サービスでの障害は詳細情報が得られないことも多く、再発防止に向けた対策立案に必要な情報の迅速な入手が困難となります。
10の罠を乗り越えるには
モダナイゼーションのウェーブ２を成功裡に実現するには、製品やツールの有効活用に加えて開発保守手法やプロセスの変革が必要です。
本ブログでは、ご紹介したモダナイゼーションを進めるうえで陥りがちな 10の罠について、IBM の経験に基づき、傾向と乗り越え方を具体的にシリーズでお伝えしております。今後の解説もぜひご期待ください。
次の記事『モダナイゼーション10の罠｜1.設計書の罠』を読む
