こんにちは。エンタープライズクラウド部 磯谷です。
日々、お客様のクラウド支援に関わる中でレガシーシステムの課題と向き合う機会が数多くあります。それ以外にも過去キャリアを通じて見てきた数々のレガシーシステムを、どのようにアプローチすればモダンアーキテクチャに移行できるのか？という点を常に考えてきました。
今回、モダンアーキテクチャ移行を単なる技術的な刷新だけでなく、組織の変革、ベンダーとの関係性の見直し、そして「基幹システムの民主化」という視点で考えました。
本記事では、レガシーシステムを抱えるエンタープライズの (1)IT部門の情報システム担当者および (2)事業部門の要件を担うシステム担当者を読者として想定しています。
また、本記事でレガシーシステムと呼称する対象システムを基幹系システム、とりわけエンドユーザーの目に触れることが少ないため塩漬けされてきたバックエンドシステム（事務処理システム等）として想定しています。
ちなみに筆者が買った最初の車はスバルのレガシィです。
レガシーシステムの限界
デジタルトランスフォーメーション（DX）が叫ばれる今日でもなお、多くのエンタープライズが直面している課題の一つが、レガシーシステムの存在です。
レガシーシステムとはモノリシックなアーキテクチャで構成され、現在のビジネスニーズに適合しにくくなったシステムを指します。そのシステムの多くは、今日もビジネスの根幹を支える基幹システムとして重要な役割を担っています。その一方で、急速に変化する市場環境への適応を妨げる要因ともなっています。
多くの基幹システムでは以下のような問題に直面しているのではないでしょうか。
システムの複雑化と知識の分散
長年の改修と機能追加により、システムが肥大化し全体像を把握している人材が不在。当然、改革を推進できる人材もまた不在。
変更管理の困難さ
要件変更時のテスト範囲が膨大になり、コストとリリース期間に大きな影響を及ぼしている。小さな変更でも大規模なテストが必要となり、変更の実装や新機能の導入に時間がかかり、市場ニーズへの迅速な対応が困難。
人材面の課題
キャリア形成の観点から技術的な魅力が低下しているため、若手技術者の離職率が増加。また、レガシー技術に精通した人材の不足により、システムの長期的な維持が困難。
ベンダー依存
ITベンダーへの過度な依存により、新たな技術や手法の導入が難しい。 日本企業に特に顕著な問題で、「基幹システムの民主化」を妨げる大きな要因となっています。
特にエンドユーザーの目には直接触れる機会の少ない基幹システムは、「安定稼働優先」の名のもとに延命措置を繰り返し、常に問題を先送りされてきました。
これらの課題を克服するシステム構成をモダンアーキテクチャとして定義して、移行を考えていきます。
モダンアーキテクチャへの移行の道のり
レガシーシステムからモダンアーキテクチャへの移行は技術面だけではなく、組織やプロセス、さらにはベンダーとの関係性まで含めたアプローチが必要です。 特に組織の変革が伴って初めて達成できる大規模なプロジェクトです。
ここでは、移行に必要なポイントを紹介します。
特に考慮すべきアーキテクチャ
モダンアーキテクチャへの移行は簡単には行えません。
まずは基幹システムをマイクロサービスに分割することが重要です。その際、いわゆるビジネスドメインの知識をベースにアーキテクチャの再設計が必要になるので、ここは必ず内製しておく必要があります。
大規模なレガシーシステムを、段階的に疎結合でIT担当者が内製してコントロールできる範囲に切り出していくことがまずは重要と考えています。
筆者の主観で特に考慮すべきアーキテクチャを下記の表に挙げます。
| 考え方 | メリット | 実現のために |
|---|---|---|
| マイクロサービス | ・機能ごとに独立したサービスとして実装することで、スケーラビリティと保守性が向上する | ・誰も全体像を把握できなかったサービス範囲をIT担当者がコントロールできる範囲に再設計する ・基幹システムのビジネスロジックからの切出しにIT担当者が正しく責任をもてるか？ |
| API駆動型アーキテクチャ | ・サービス間の疎結合な連携を実現し、柔軟な機能拡張と共通部品化による再利用性の向上をはかる ・疎結合となることで運用保守フェーズでの改修コストの削減ができる |
・基幹システム全体のボトルネックAPIのレスポンス改善や障害発生時の切り分けの考え方がレガシーシステムと変わる |
筆者の考えでは、大規模なレガシーシステムにおいては「どのような技術を採用するか？」は重要ではありません。技術は常に刷新されていくものであり、レガシーシステムがリリースされてきた後も当時のトレンドとなる技術は次々と発表されてきました。 それにも関わらず、システムが先の4点の課題を依然抱えているという現状は別の問題の割合が大きいと考えるべきです。
AWSの具体的な技術で考えますと、コンテナ（ECS/EKS）、サーバレス（Lambda）で置き換えてましょう、というアプローチが重要な目的ではないということです。仮にEC2上で動くアプリケーションであっても、先の4点の課題を何らかクリアできていれば、それはモダンアーキテクチャの第一歩を踏み出していると言って良いと考えます。
参考情報：
組織とプロセスの変革
モダンアーキテクチャへの移行は、技術面の変革だけでは不十分です。組織構造・企業文化の変革、開発プロセスが不可欠です。
これまでレガシーシステムから脱却できていない場合の多くは、組織とプロセスの問題にあまりフォーカスできていなかったのではないでしょうか。この組織とプロセスの変革があって、はじめてマイクロサービス化ができます。
レガシーシステムから脱却のためにここで本気を出しましょう。
アジャイルの導入
アジャイルは、変化に強い開発プロセスを実現します。
- 短いイテレーションでの開発と頻繁なフィードバック
- 変化への迅速な対応
アジャイルの導入により、市場の変化や顧客ニーズの変化に迅速に対応できることを目指します。
レガシーシステムからの脱却のためにアジャイルが必要なのではなく、再びレガシーシステム化しないようマイクロサービスであり続けるためにアジャイル組織が必要と考えています。マイクロサービスをビジネスドメインと技術面の両面から管理し続ける組織です。
組織文化を変革できなければウォーターフォール時代と何も変わりません。そのために、ITベンダー主導ではなく内製主導で進めることで、予算ドリブンからユーザー機能ドリブンへの変革を目指します。
参考情報：
JUAS 基幹系システムへのアジャイル適用研究プロジェクト活動報告
DevOps文化の醸成
DevOps文化は、開発と運用の連携を強化し、効率的なシステム開発・運用を可能にします。
- 開発と運用の連携強化
- 継続的インテグレーション/継続的デリバリー（CI/CD）の実践
- 自動化の推進
DevOps文化の醸成により、開発から運用までのサイクルが短縮され、運用コストの削減が期待できます。 レガシーシステムからの脱却に必ずしもDevOpsの考え方が必要なわけではありませんが、脱却の先にある変化への迅速な対応を考えれば中長期的には必要な要素です。
外部ITベンダーとの協業におけるポイント
日本企業においては、ベンダー依存体質もマイクロサービス化を妨げる大きな要因となっています。
ベンダーの提案に合理性がないわけではありませんが、システム刷新の主権者が誰であるかを常に意識しておくべきです。
内製化とアウトソーシングのバランス
すべてをいきなり内製化することは現実的ではありません。
レガシーシステム脱却の初期段階では、過去にビジネスドメインの知識流出を含めて外注してしまった外部ITベンダーの協力は欠かせません。かといってそこで再び丸投げしてしまっては問題を先送りしてしまうだけです。
顧客ニーズに敏感でなくてはいけないのは、外部ITベンダーではなくエンタープライズ側です。 そのことを念頭において、マイクロサービス化の主導権を外部ITベンダーに委ねず「基幹システムの民主化」を勝ち取ることを最重要視しなければ何も変わりません。
内製化に向けたスキル開発
並行して実施すべき内製化の過程では、継続的なスキル開発と人材育成が重要です。単なるスキルアップだけでなく、変革を推進するマインドセットの醸成が重要です。「基幹システムの民主化」を実現するために、技術だけでなくビジネスドメインの体系的な理解・育成の計画も必要です。
ここはベンダー依存体質では実現できない領域です。
参考情報：
→189Pに内製化の状況に関する言及があります
まとめ／持続可能な基幹システムに向けて
モダンアーキテクチャへの移行は、技術だけでなく組織全体の変革を必要とします。クラウドの普及によって「インフラの民主化」が一気に進みました。その延長線上にマイクロサービス化、アジャイル組織への移行を経て、単なる技術的な革新ではない「基幹システムの民主化」があると考えています。
何より重要なのは膨大な基幹システムからサービスを少しずつコントロール可能な範囲に再設計することです。方法論は数多くあれど、本質はいかにビジネスドメインと本気で向き合うかです。
本記事が、レガシーシステムからモダンアーキテクチャへの移行を検討されている皆様にとって、その第一歩となれば幸いです。
