今、「システムのマイグレーション」に慎重になるべき理由：デジタル変革前夜のSoRインフラ再定義（2）（2/3 ページ）

[編集部,＠IT]

「メインフレームをマイグレーションする」という考え方が、すでに周回遅れ

　かといって、ほぼ全てのビジネスをITが支えている今、何もせずにいれば、ビジネス展開のスピード、システムの運用効率、コスト効率の面で後れを取るのは目に見えている。これから加速するデジタルビジネスへの対応もできなくなる恐れがある。現実的には、このトレンドにどう対応していけばよいのだろうか？

　亦賀氏は2つの方策を示す。1つはITを「モード1」と「モード2」に分け、それぞれを個別に進めること。

　ガートナーでは、さまざまなITを、特性に応じて「モード1」「モード2」の2つの領域に分け、両者を組み合わせたバイモーダルの考え方を提唱している。モード1は「業務の維持とコスト削減」を重視し、しっかりと作って安定的に運用していくトラディショナルな領域のIT。モード2は「ビジネスの成長と革新」を重視し、新しいテクノロジー、開発スタイルを機敏に取り入れながら、新たな価値を生み出していくイノベーティブな領域のITを指す。

　つまり、メインフレームはモード1の領域、IoT、人工知能、X-Techなどはモード2の領域に分けられる。それぞれ特性は異なるものであり、これらを混ぜることは混乱と破綻を招く可能性があるため、明確に異なるものとして分けておく必要があるという。

図2　「デジタル・ビジネスへの対応：バイモーダルを戦略に組み込む」（出典:ガートナー）

　事実、既存のシステムと、新しいテクノロジ、すなわちモード1とモード2の要素を連携させる取り組みも注目されてはいるが、実践は難しい。「例えば、人工知能とメインフレームを連携させようとした場合、そうした連携の姿について、要件をどう定義するのか、設計、開発、実装、テスト、運用といったことについて、どのようにアプローチしていけばよいかといった問題に直面する」だろう。よって、無理にモード1、モード2を連携させようと考えるのではなく、明確に切り分けて取り組むべきだというわけだ。

　何よりも、亦賀氏が個別の取り組みを勧める最大の理由は、「全てをビジネス起点で考える」ことにある。

　「デジタルトランスフォーメーションが進む中で、ベンダー、ユーザーがモード2領域のビジネスにしのぎを削っており、いかに新たな価値、利便性を生み出せるかが差別化の要件になっています。特に米国ではFinTechをはじめ、デジタルビジネスが急速に進みつつあります。この動きが、モード1である既存システムの本質的な見直し、場合によっては不要論にまで発展しており、結果として、米国はモード1領域のシステムが減少しているのです。つまり『メインフレームにあるものをオープン化する、クラウド化する＝デジタル時代に備える』といった考え方自体が、すでに周回遅れな議論になっています。そもそも、メインフレームには多くの業務アプリケーションが存在しています。それをそのまま、オープン化、クラウド化しても、それでデジタルビジネスに対応できるわけではありません。そうであれば、今すぐにマイグレーションを急ぐ必要はありません。ここはいったん冷静になることが望ましいと言えます」

全システムを「松」「竹」「梅」で切り分ける

　一方、すぐにでも着手すべき施策として、亦賀氏は「既存資産の棚卸しと仕分け」を挙げる。これにより、まずは既存のメインフレーム／システムの段階的かつ現実的な縮小と、全体のコスト削減を狙う。そこで余ったお金を今後の戦略的投資に回す、という作戦だ。

　このために、まずメインフレームにある業務アプリケーションを棚卸しして仕分ける。例えば、稼働率であれば松（99.999％以上）、竹（同99.99％程度）、梅（同99.95％程度）の3レベルに分ける。

　「このうち要求レベルの低い梅レベルの業務アプリケーションからマイグレーションを進めていきます。例えば、AWSやMicrosoft Azureのような（標準化されたサービスである）“本物のパブリッククラウド”のコンピュート部分のSLAは99.95％ですから、梅レベルであれば、クラウド移行も十分に検討することができます。各システムを分類し、最適なインフラに移行するだけでもコストはかなり削減できるはずです」

　ただし、ここで重要となるのが「徹底した割り切り」だ。亦賀氏は、「割り切れない場合は、やはりコストがかかると考えるべきです」と指摘する。

　「この割り切りは、高品質を是としてきた多くの日本人にとって難しいことであるため、ここは明確な意思と実行能力が必要です。こうした割り切りなしに、“絶対止まらないものを安く作ること”といったようなRFPを作ることは厳禁です。これはベンダーやインテグレータと共に悪夢の領域へ突入することを意味し、結果としてユーザー企業も大変なことになります」

図3　「金ない、時間ない」：梅を作り、モード2に備える――アプリケーションやシステムの重要度や求められる要件に応じて、松竹梅の3レベルに分類し、例えば梅レベルのものからオープン化やクラウド化を進める。全てのシステムを（事業部門などから言われるがまま）「松」レベルとして扱いがちだった従来に比べると、これだけでもかなりのコストを削減できる（出典:ガートナー）

　だが現実には、こうした分類ができていないケースは多く、これが間違ったマイグレーションの原因となりやすい。例えば、松レベルのシステムをクラウド移行してしまうといった発想だ。

　というのも、基本的に松レベルの可用性を保証しているパブリッククラウドは存在しない。そもそも、AWSやAzureのような“本物のパブリッククラウド”は基本的に利用者の自己責任が原則であり、セキュリティもバックアップも利用者の責任となる。99.95％といっても冗長構成により99.99％は期待できるが、「絶対に止まらない」ことは期待できない。

　それでも「外部のクラウドのようなものを使いたい」と考え、自社の個別要件を満たしてくれるプロバイダーを探し、ユーザー企業のシステム固有の高度な要件を担保しようとすれば、個別要件に応えるためにカスタマイズされ、その分コストはかさみ、標準化されたサービスである「パブリッククラウド」ではなくなっていく。

　「それは、従来のアウトソーシングやマネージドサービスと変わらなくなります。単に今のオンプレミスのシステムを外部にコピーしたというだけでは、コストメリットもほとんど出せなくなり、クラウドならではの柔軟性・拡張性・俊敏性も期待できません。これでは何のために移行したのか分かりません。管理の手間がかかる持ち家から、管理してもらえる分、管理費や積立金が高い高級マンションに昔のままの状態で引っ越しただけで、生活自体は何も変わらないようなものです」

　本来、パブリッククラウドは標準化されたサービスである以上、自社システムの重要度、SLAを見極めて、割り切って使うことが求められる。だが、システムの分類をしないまま「今あるものをそのままクラウドに」と、ベンダーやSIerに丸投げしてしまえば、彼らはユーザーの要件を満たすために「絶対に止まらない」構成を提案せざるを得なくなり、自ずとコストが高くなるというわけだ。先の「ビジネス起点で考える」こともそうだが、外部に丸投げする従来のスタイルを改め、自社で主体的に考えるスタイルに変革しなければ、真に有効なマイグレーションは難しいのだ。

　しかし、それをどうやって考えてよいか分からないというケースも多い。本来は、こうしたユーザーの悩みにベンダーは正面から向き合う必要があるが、「昨今のベンダーやインテグレータは『ユーザーの言う通りに作る』を基本とすることが多く、結果、ユーザーの悩みは以前よりも増している状況が見られる」という。