「図は、とある企業のITコストの内訳。この図の緑の部分だけを見ていてはクラウド移行の高い効果を得られない。実際には、全ての要素でそれぞれに見直すべきポイントがある」（戸賀氏）

　この図の例では、例えばクラウドに移行したシステム全体を標準化できれば、開発基盤や実行基盤を共通化できる。基盤そのものやツール類を集約できればボリュームディスカウントを適用できるケースも出てくるため、個別の契約よりもコストを抑制できる。また、共通化や標準化ができれば、自動化できる作業も増える。さらに、運用ではクラウドプラットフォーム側がサービスとして提供しているものもあるため、この部分を見直すことで運用費を削減できる可能性もある。

　このように、移行先のクラウドが持つ性質を最大限に生かすことを前提に全体を見直すことで、既存ITコストよりも負担を軽減していけば、移行期のコスト増を回避できる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

ハードウェアリソースのコスト削減だけでは不十分。運用や開発の領域でも効率化が必要に

　とはいえ、組織全体のシステムを移行するとなると、さまざまな障壁も考えられる。戸賀氏は、代表的なものとして「メインフレームなどのミッションクリティカル系をどうしたらよいかが分からない」「エンジニアが技術についていけない」「移行やクラウド運用コストが心配」といったものを挙げた。

　このセッションでは中でも特に、技術的な障壁、コスト面での障壁とその具体的な乗り越え方に関する同社のノウハウや事例を聞くきくことができた。

減少するCOBOLエンジニアを抱え続けるか、18カ月でAWSに移行するか

　基幹系システムを含む全てをパブリッククラウドに移行するとなると、どうしてもレガシーなシステム、複雑に組まれたプログラムを持つメインフレームの移行もスコープに入ってくる。しかし、複雑であり規模も大きいメインフレームは移行工数や費用はかさみやすく、ステークホルダーも多く、意思決定が難しいことから、「虫食いクラウド」の要因となっている。

　高難度のメインフレームはパブリッククラウドに移行できるのか――戸賀氏は実際に基幹系を含む全システムのクラウド化を進める企業の実例を元に、虫食いクラウドから脱却し、包括的なクラウド化を実現する道筋を示した。

　1つ目の事例は、COBOLプログラムの一部をJavaに書き換えて移行したケース。工数やコストを考慮し、載せ替えと書き換え（リホストとリライト）を併用して移植したものだ。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

メインフレームを18カ月でAWSに移行

　こちらは、オンライン処理30万ステップをJavaに書き換え、その他のCOBOLプログラムの実行環境を他の環境に切り替える手法を採用、メインフレームの全てを作り替える場合の見積もりと比べて3分の1の費用で、約18カ月でAWSに移行している。

　より詳細な手続きを見ていくと、メインフレームの複雑に絡み合ったプログラムを1つずつ分解して「連携基盤」に移植。連携基盤上に移植した個別のプログラムを動作させながらAPIを介して、徐々にクラウド環境にデータをシフトしていく手法を取っている。

　「これは基幹業務系システムのクラウド移行では基本的なセオリーだが、根気のいる作業。しかし、COBOLエンジニアの数はもはやJavaエンジニアの10分の1以下。今後もメインフレームに残り続けるという選択肢は考えにくい」（戸賀氏）