レガシーを持続可能なシステムに変革
成功のカギを握る3つのポイントとは

老朽化したレガシーシステムは、デジタルトランスフォーメーション（DX）の足かせになる――。これはよく聞く話だが、システムが古いこと自体が問題なのではない。

「元凶はシステムの複雑化・ブラックボックス化。繰り返された業務変化の中で、その経緯や担当者が分からなくなっていることです」とレッドハットの森 和哉氏は訴える。業務側からの変更要求に追従できず、日々のメンテナンスにも多大なコストがかかる。これがビジネス展開を足止めしてしまうというわけだ。

「このため、モダナイゼーションを実践する際は、業務の無駄や属人化を回避するとともに、継続的かつ容易に変更が行える保守性の高いアーキテクチャーを目指す必要があります」と森氏は指摘する。

そのポイントは大きく3つあるという。1つ目は不要な業務・機能の“断捨離”と、やりたい業務のTO-BE（あるべき姿）を描くこと。これはモダナイズに取り組む前の必須作業となる。

「まず問題を潜在化させている不要な業務・機能を洗い出すことが先決です。そのためには現行の業務プロセスと情報の流れを見える化することが欠かせません」と森氏は語る。このとき、既存のソースコードを分析するだけでは不十分だ。業務担当者を巻き込んで、実際の業務プロセス、その際のシステムやデータの流れまで確認する。長年改修を重ねたアプリケーションには、不要な機能が「ゴミ」となって残っているからだ。

このままコンバージョンツールで機械的に移行すると、「よくある失敗パターン」に陥るという。「ゴミを引き継ぎ、ロジックの複雑性もそのまま。テストは煩雑になるし、柔軟性・保守性も低いままです」と森氏は釘を刺す。

踏襲すべきものはアウトプットのデータの整合性であり、既存のプロセスや仕組みではない。見える化することで、現在の業務の流れ、作業タスクとシステムとのやり取り、タスクにかかる時間、無駄なタスクやプロセスそのものの複雑さなどを関係者全員が一目で分かるようになる。これにより、全員が共通の課題認識を持てるようになるわけだ。

「現状を見える化し、共通の課題認識を持てば、その改善に向けてTO-BEを描きやすくなります」と森氏は語る。そしてこの活動そのものが、モダナイズの起案に向けたロードマップの根拠になる。

2つ目は、アプリケーション・アーキテクチャーを再考することだ。「高い保守性を実現するためには、モノリシック（分割されてない巨大なモジュール構造）なアーキテクチャーを脱し、マイクロサービス・アーキテクチャーへの変革が必要です」と森氏は主張する。

モノリシックな造りだと、その後の変更や機能追加が難しく、修正するとプログラムも複雑化する。それに対し、マイクロサービス・アーキテクチャーは、小さな機能単位のソフトウエア（マイクロサービス）を疎結合で組み合わせ、アプリケーションを構築していく手法だ。

「機能が分割されることで、部分的な差し替えが可能になります。システムの一部を部分的にスケールアウトすることもできる。障害などが発生した場合も、影響を局所的に抑えられ、影響範囲も把握しやすい」と森氏は説明する。マイクロサービス化することで、柔軟性・拡張性・保守性が向上し、品質も確保しやすくなるわけだ。

ただし、マイクロサービスには向き・不向きがある。適しているのは、「大規模で複雑なシステムをつくり直す場合」「開発やリリースの柔軟性やスピードを上げたい場合」「障害発生の影響を局所化したい場合」などだ。逆に規模が小さくて単機能、滅多にアップデートや仕様変更が発生しないシステムには向いていない。事前に適用基準を明確化し、判断する必要がある。

マイクロサービスの分割単位にも考慮が必要だ。ただ機能を分割して小さくすればいいというものではない。その指針になるのが「ドメイン駆動設計」だ。ソフトウエア技術者のエリック・エヴァンス氏が提唱した設計技法である。

ここで言うドメインとは、業務機能のこと。複雑なドメインの設計は、モデルベースで行い、業務知識や業務ロジックに焦点を置くべきという考えに基づいている。ドメイン駆動設計によるサービス分割では、タスクとイベントを基にドメインの境界線を見つけていく。タスクとは仕事の最小単位。イベントはタスクの中で発生する作業のこと。ドメイン駆動設計によるサービス分割の進め方はおおよそ図1の通りとなる。

図1　ドメイン駆動設計によるサービス分割の進め方

タスクの中で起こるイベントを洗い出し、必要なインプット／アウトプットや関連データを整理し、ドメインの境界線を見つける。それをさらにUI、ロジック、プロセス管理、データアクセスなどの機能に細分化する。これがマイクロサービスの分割単位になる

3つ目のポイントは、イテレーション開発の実践である。イテレーション開発とは、開発単位を小さく区切り、数週間程度の短い期間で設計・開発・テスト・改善などの工程を繰り返し、品質を高めていく開発手法だ（図2）。

図2　イテレーション開発のサイクル

まず業務担当者と協働し、業務理解を深め、業務の棚卸しを実施。必要な業務要件とルールを導き出し、ロジックを設計する。それに基づき、コンテナ技術を活用して高速開発し、業務担当者と共にテストを行う。テスト結果は開発に反映させ、品質を高めていく

「まず重要となるのが、要件の『幹』をつくること。この幹ができた段階で、業務側に公開し、ブラッシュアップしていくのです」と森氏は主張する。

業務側と密に連携してサイクルを回していくため、齟齬や不明点を早期に解消し、業務側の安心感も高まる。業務側のフィードバックを得ることで、次にフォーカスすべき機能開発が明確になり、無駄な開発や実装も削減できる。

イテレーション開発ではツールを積極的に活用するとも欠かせない。現新比較ツールやCI／CDパイプラインは強力な武器になる。現新比較ツールは、現行システムと新システムとの出力結果の差異を自動抽出する。差分比較や調査確認の人的作業を大幅に軽減し、新システムの正当性や課題を素早く判断できるようになる。CI／CDパイプラインはビルドやテスト、デプロイを自動化する。これらの作業工数を削減し、開発チームは設計・実装に集中することができる。

モダナイゼーションを成功させるためには、紹介した3つのポイントがカギを握るが、実はもう1つ重要なポイントがある。それは、前向きに挑戦するマインドセットを持つこと。これが3つのポイントを推進するエンジンになるという。

しかし、マインドセットは急に変えることは難しい。「最初は小さくてもいいから業務部門、IT部門、協力ベンダーがチーム一丸となって成功体験をつくる。それを繰り返し、成功体験を積み上げていくことで、前向きに挑戦するマインドセットが醸成されていきます」と森氏は述べる。

こうしたことを踏まえ、レッドハットはマインドセットの醸成も含めたモダナイゼーションの取り組みを幅広く支援している。3つのポイントで紹介した方法論の自走化を支援するメニューも豊富にある。「マイクロサービスエッセンシャル」はその1つ。これは、要求分析から実装イメージ、組織論などを学ぶワークショップだ。

マイクロサービスの実装パターンなどを学ぶ、より実践的な「Integration Dojo」というワークショップもある。マイクロサービス・アーキテクチャーで構築した社内システムを題材にして、その実装と活用の可能性を深めていく。

レガシーシステムを新しい器に移し替えるだけではモダナイゼーションは成功しない。レッドハットは、今後も実績のある方法論の自走化からマインドセットの醸成まで伴走支援し、DXの推進基盤となるモダナイゼーションの成功に貢献していく考えだ。