レガシーシステムからクラウド基盤への刷新で企業が知っておくべきこと

レガシーシステムをクラウド基盤へ刷新するのは難しい。明確な答えも持たないで推進すれば後になって痛手を負うかもしれない。本稿はそのような状況を避けるために、企業が知るべきことを解説する。

[鈴木恭子，ITmedia]

　デジタルトランスフォーメーション（DX）を推進する企業にとって、レガシーシステムのクラウド化は重要だ。しかし、そこには多くの課題がある。「どのシステムを、どのような点に留意し、どのような方法で」移行するかを見極め、効率的かつ低コストで実施しなければならないからだ。これらに対して企業はどのように取り組むべきなのか。

　アイティメディア主催のオンラインイベント「ITmedia DX Summit Vol.15」にアクセンチュアの青柳雅之氏（テクノロジーコンサルティング本部　金融サービスグループ　アソシエイト・ディレクターAccenture Google Business Group　ソリューションアーキテクト）が登壇し、「レガシーシステムのクラウドへの基盤刷新で考える軸」について語った。

技術視点ではなくビジネス視点でのモダナイズが重要

　講演の冒頭、青柳氏は「レガシーシステムが抱える課題」に言及した。

　同氏によれば、多くの企業はレガシーシステムを運用管理している人材の退職やハードウェアの保守切れに直面している。また、レガシーシステムは新機能の追加開発に時間やコストもかかり、さらには改修を重ねた既存システムの仕様を記したドキュメントが残っておらず、「誰も全体像が把握できない」という自体に陥っている。

　青柳氏は「レガシーシステムはコア業務を支える屋台骨だが、クラウド移行は難しい。一方、情報系システムやCX（Customer eXperience）向上などフロント系はクラウド移行が進んでいる」と指摘する。データウェアハウスやAI（人工知能）など、データドリブンな事業戦略を支えるシステムもクラウドが前提だ。

　レガシーシステムをクラウド移行し、基盤の刷新を図るにはビジネス視点に立脚したアプリのパフォーマンスを実現する「アプリケーションモダナイゼーション」と、それを具現化するためのインフラを最適化する「インフラストラクチャモダナイゼーション」が必須だ。

　アプリケーションモダナイゼーションで最初に実施すべきは、全システムの技術構成要素を俯瞰的に整理する「アーキテクチャマップ」の作成だ。対象システムの特性を鑑みながら「将来のアーキテクチャはどうあるべきか」という視点でその要件を決めていく。

　対象システムの特性には「塩漬けシステム」「現役システム」「強化基幹システム」「パッケージ代理可能基幹システム」などがある。「塩漬けシステム」は、機能拡張や追加開発がほとんど発生しないシステムで、これらは運用コストの低いパブリッククラウドにリホストし“塩漬け”にしてもビジネスに影響はない。

　アプリケーションモダナイゼーションの方針には「リホスト」の他、将来の機能追加や拡張を見越して「COBOL」などのレガシー言語から「Java」に変換する「リライト」、仮想マシン中心のアーキテクチャからクラウドネイティブなアーキテクチャに変更する「リビルト」、代替可能なパッケージを購入してシステムを置き換える「パッケージ」などがある。アプリケーションモダナイゼーションは要件から決めていくが、その際はコストを考慮する必要がある。

　「例えば、リホストは低コストで実現可能だが、リライトは一定のコストがかかる。また、リビルドは全面的刷新が必要でコスト高だ。パッケージも同様にコストが高い。なお、いちばんリスクが高いのはアプリケーションのアーキテクチャを全面的に刷新するリビルドだ」（青柳氏）

オープンテクノロジーを採用するメリットとは

　システム全体のアーキテクチャはベンダーに依存しないオープンテクノロジーを採用することが重要だ。特定ベンダーに依存した技術を利用すると開発者の確保が難しくなるからだ。オープンテクノロジーであれば、ほとんどが基本的な言語であるJavaに対応している。さらに幅広く普及しているオープンテクノロジーであれば、内製化チームを組織するときの学習コストも押さえられる。また、アーキテクチャが統一されておりシステム全体で同等の品質を担保しやすい。

　大量のソースコードの移行にはツールを活用する。変換ツールやテストツールを利用して可能な限り自動化することが望ましい。青柳氏は「自動化ツールを利用しても全てがうまくいくわけではない。重要なところは手作業でワークロードを割き、効率的に作業する必要がある」と指摘する。

　アーキテクチャの定義と最適化が決まったら、次に悩むのがクラウドやサービスの選定だ。選定ポイントについて青柳氏は、「クラウドを利用する目的と定義をしないまま、各クラウドの機能優劣を比較した表を作成してもあまり意味がない。なぜなら現在はどのクラウドも機能的には大きな差がないからだ」と説明する。

　大手クラウドベンダーは機能強化に莫大な投資をしている。そのため、サービス内容に差があっても次のバージョンアップで機能追加されることがほとんどだ。また、"純正"サービスがなくてもサードパーティー製品を利用すれば課題は解決する。

　「特定のクラウドにしか存在しないサービスを選定理由にすることもあるが、（サードパーティー製品で代替できるため）そうしたケースは少ない。差別化要素がない場合は、コストの安いクラウドを選定するのも一考だ」（青柳氏）

　同氏は「むしろ注視すべきは人間関係だ」と指摘する。

　クラウドの選定基準は、パートナーエコシステムの関係や自社組織の状況に大きく依存することを踏まえ、青柳氏は「（クラウドベンダーと）パートナー企業との関係でクラウドベンダーの支援が引き出しやすいこともある。そうした状況を注視する方がクラウドの個別機能よりも重要だ」と話す。

IT基盤刷新のための組織――CCoEの組成が有用な理由――

　大規模なIT基盤刷新で"要"となるのが、それを担当する組織の在り方だ。IT基盤刷新のプロジェクトマネジメントに関するハウツー情報は多い。つまり、それだけ困難なケースが多く、"解"を求めている人がいるのだ。青柳氏は「組織設計の構築時には『コンウェイの法則』を意識すること」が必要だと説く。

　コンウェイの法則とは、「組織がシステム開発を行う際にシステム設計が組織構造と似たものになってしまう」という法則だ。これでは非効率なコミュニケーションになってしまい、システム間で意思疎通ができなかったり、見落としが多発したりする。

　「アプリチーム」「インフラチーム」「移行チーム」「テストチーム」など、構築するチームが技術要素や工程で分割されると、同じシステムを複数のチームで確認することになり、チーム間に誰もケアしない事項が発生してしまう可能性もあるからだ。

　こうした事態を避けるためには、システム別のチームにアプリやインフラなど、それぞれの役割を持った人材を配置しチームを構成することが得策だという。最初にインタフェースを定義していれば、その後はチーム内の仕事だけをすればよく、チーム内には各分野の担当がいるため進捗会議も少なくて済む。結果、作業時間の削減や品質向上の実現につながる。

　なお、チームを組む際の最優先事項は「インタフェース定義と意思疎通確認」だ。多数のシステムが複雑に連携された大規模なIT基盤では、インタフェースを明確に定義しスタブ（Stub）などを利用して相互の疎通を実際に確認することが重要になる。

　青柳氏は「機能ごとのチームに分割すると、『インフラを重視したシステム』『アプリを重視したシステム』などになってしまい、全体で見たときにおかしなものになる。また、相互の疎通を実際に確認せず机上のみでインタフェースを確認すると、必ず見落としが発生する」と警鐘を鳴らす。

　青柳氏は近年注目されている「CCoE」（Cloud Center of Excellence）にも言及した。CCoEはクラウド戦略を進めるうえで必要な人材やリソースを社内組織の壁を越えて横断的に集約した組織を指す。クラウドに限らず「CoE」（Center of Excellence）というアプローチは広がりつつあり、特定のミッションを軸に優秀な人材や設備、資本を集中させ、中核となる組織や研究拠点を構築する。

　CCoEのタスクには設計や利用ガイドラインの整備、人材育成、製品ベンダーなどのパートナーエコシステムとの連携などがある。ただし、CCoEを組成した場合はCCoEメンバーの負担が増加する可能性もある。青柳氏は「CCoEの役割は気軽に聞ける悩み相談室ではないことを組織全体が理解する必要がある」と指摘する。

　CCoEによるクラウド促進で重要なのは、人材育成もかねてCCoEのメンバーを定期的に入れ替えることだ。そのメリットに青柳氏は「CCoEで学んだハウツーが各チームに浸透し、組織全体の技術力の底上げになると同時に、クラウド戦略を強化できる」と話した。