メインフレームを始めとして、レガシープラットフォームのストレートコンバージョンを成功裡に移行するには、最適な方法というものがあります。これを活用して進めるのとそうでないのとでは、コスト、時間、工数に大きな差が生じます。なかでも、最も重要なのはシステムインテグレーションです。どの道を歩んでもいずれゴールにはたどりつきますが、経験と知恵のあるガイドが案内すれば、それほど苦労せずに登頂できる登山と同じです。ＪＢＣＣはシステム開発の世界でガイドの役割を果たすことができます。
今回は、他社とはひと味もふた味も違う、メインフレーム基盤移行におけるＪＢＣＣのマイグレーション力についてお話しします。
 |
目次 |
1. 着実かつ迅速なメインフレーム基盤移行を実現するＪＢＣＣ SLTCプロセス
ＪＢＣＣでは、メインフレーム基盤移行プロジェクトを遂行する際、SLTCプロセスと呼んでいるＪＢＣＣならではのプロセス手法を用います。前回のコラムでも触れたように、これは図１のような流れに沿って進めていきます。
図１ ＪＢＣＣレガシーマイグレーション・プロセス（SLTCプロセス）
ここで大前提としているのは、ＪＢＣＣ製の高品質な自動変換ツールを用いてプログラムやデータを変換していくということです。これらのプロセスは、そのために行う準備・実行・テストの流れを示しているともいえます。簡単に、各プロセスの概要をご紹介します。
1-1. プロジェクトの全体戦略を練る「移行計画セッション」
まず「移行計画セッション」ですが、これはプロジェクト開始前の無償プロセスです。ここでメインフレーム基盤移行について、スコープと、それぞれのシステムについて機能要件、非機能要件を明確化し、現行機能を維持するためのソリューションの選定と概略設計を行います。これが定まれば、あとは粛々と進めていくのみ、という体制を整えることができます。
1-2. 移行の核心 命令コードを抽出する「調査分析」
ＪＢＣＣのレガシーマイグレーションでは、命令コードが1対1対応で完全に移行できれば、プログラム全体も移行できるというのが根本的な考え方です。そのため「調査分析」では、プログラムからツールによって命令コードを抽出し、そのパターンと出現する数を把握します。命令コードを、パラメータを含めプログラムから切り離しバラバラにするというイメージです。
1-3. 命令コードの自動変換方法を設計する「機能設計」
「調査分析」によって、たとえば命令コードが500パターン存在することがわかったとします。そうすると、その500パターンに対して、1対１対応でツールを使った自動変換方法を設計します。これが「機能設計」です。500パターン存在したとしても、COBOL to COBOL移行の場合、互換性のある命令コードもあります。自動変換方法を設計するのは非互換部分です。そして、これはお客様プログラムごとに設計します。基本的に流用することは考えません。流用ありきにすると、そのツールを使いたいがために無理やり当てはめようとし、結果として自動変換率を低下させることになるからです。 "豊富な実績があって自動変換ツールのカバー率が高い"といわれると、つい安心感を抱いてしまいますが、決していいことばかりではないのです。もちろん、1対1対応での自動変換を設計したら、その精度についてはこの時点で徹底的に検証します。
ただし、プログラム全体で1～2回しか現れない命令コードにまでツールを作成するのは非効率であるため、そうした部分はハンドコーディングで修正を行います。
ちなみに、命令パターン分析を採用する利点は、テストプロセスでも享受できます。
プログラムに修正を施すと、テストデータを作成した上でホワイトボックステストを行わなくてはいけません。しかし、この方法だと、１対１で変換精度が保証された命令コード移行しか行っておらず、ロジックは変更していないため、ホワイトボックステストを実施する必要がないのです。すなわち命令の1対1移行に撤するSLTCプロセスでは、ホワイトボックステストではなく、生の業務データを使った現新比較テスト、ブラックボックステストで検証を行うことができます。
1-4. 全体の流れを確認する「パイロット１（設計試作）」
命令コードの変換方法に目途を立てたら、全対象プログラムの中から2～3本を抜き出して、ＪＢＣＣの用意する移行フレームワークがフィットして機能するかどうかを確かめます。ここでは、オンライン処理はどうか、バッチ処理はどうかといった具合に、大枠の流れがうまくいくか、合っているかどうかを見ていきます。合っていなければ、先に進んでも手戻りが発生するだけだからです。ＪＢＣＣではこれを「パイロット１（設計試作）」と呼んでいます。
1-5. 改善すべき点を発見し修正をかける「生産設計」
実際にパイロットにかけてみると、改善すべき点が出てくることもあります。これは、移行元、移行先のアーキテクチャの違いから、また、命令コードの組み合わせによって発生してしまう差分、つぶしきれなかった設計ミス、ツールにひそんでしまったバグなどによって生じます。「生産設計」では、これらの点を修正し、スムーズに自動変換できる割合を高めるよう注力します。これは、できるかぎりハンドコーディングを減らし、お客様の大切な既存プログラムを守るというためにも重要なプロセスです。
1-6. 設定したツール自動変換率で品質を検証する「パイロット2」
「パイロット2」では、全対象プログラムのうち3～5％のプログラムで試してみます。ここで計画当初に設定したツール自動化率目標が90%なら、その達成をめざします。品質を評価するには実際に目で確認できる指標が必要で、私たちはこれにツール自動変換率を設定し、最低限の品質基準としています。もし90％に届いていないのであれば、原因を探って対策を図ります。図２は、プロジェクトでの「パイロット2」報告書事例です。
図２ 「パイロット2」報告書事例
青とピンク以外のセルは、「パイロット2」段階で何らかの対策を行い、それが完了したことを示しています。一方、青のセルが示しているのは、「パイロット2」段階、変換実施段階では残ってしまうけれども、単体テスト、総合テストを行う前には事前対応できるものです。ピンクのセルは、移行元と移行先の基盤の違いからどうしても発生してしまうため、単体テストで発見、都度修正していくものになります。このように、一つひとつ事象に対してきめこまかく分析と対策を行いながら、精度の高い移行を実現します。
1-7. さらに高い精度をめざす「量産計画」
変換実施前のプロセスとしては最後になる「量産計画」では、自動化率目標以上の精度を実現できるよう、継続的に改善を繰り返していきます。
見てきたように、「パイロット1」「パイロット2」と検証局面を設けているのがＪＢＣＣプロセスの大きな特長で、これにより品質を確認しながら一歩一歩前に進めていけます。これはメインフレーム基盤移行プロジェクトのアジャイル開発ともいえ、致命的な手戻りを防ぐ非常に有効な方法です。しかも、ツールを使ってカバー率高く自動変換が可能ですから、プロジェクト期間の短縮が可能です。
2. 確定期間、確定料金の請負契約だから最後まで安心
またＪＢＣＣでは、このプロセスを準委任契約ではなく請負契約で、つまり期間も確定なら、料金も確定した上でお引き受けしています。これも他社ではほとんど見られない大きな特長です。これによってお客様は、コスト増やプロジェクト遅延などといった懸念を抱えることなく、安心してメインフレーム基盤移行プロジェクトに臨んでいただけます。
私たちは見積りを提出した時点で、必ず成功させる勝算があります。なぜそこまで自信を持てるのかというと、無償の移行計画セッションによってお客様の既存環境をしっかり精査しつくした上で、これなら確実に移行可能という案を提示するからです。ＪＢＣＣの伴走で、お客様には確実なゴールと、そのゴールの先の未来に目を向けていただくことができます。
プロセスのすべてをＪＢＣＣが先頭に立ってガイドするのでなければならない、ということもありません。「パイロット２」が終了し、ツール自動化率90％が達成できたあと、「変換とテストは自社主導で行いたい」「テストは自社主導で行いたい」などといったご要望も出ることがあるでしょう。そのときは、ＪＢＣＣは側面からの技術支援に回ってプロジェクト成功への道を見守り続けます。
3. 新規開発が必要なときも、手戻りリスクなしの「ＪＢアジャイル」で
メインフレーム基盤移行プロジェクトでは、ただプラットフォームを移すのみならず、新規にシステム開発が必要になる場合があります。あるいは、ひとまずは移行するだけにとどめるが、ひと段落したらDX推進観点で移行したプログラムを改善する、追加開発するといったケースも考えられます。こうしたときにぜひとも行っておきたいのは、新規システム開発に適用する手法を見極めることです。ＪＢＣＣは、この分野でも超高速開発手法「ＪＢアジャイル」という強力なソリューションを提供可能です。
図３ 「ＪＢアジャイル」の流れ
一般的なアジャイル開発では、現状分析・要件定義を行わないことが多いですが、「ＪＢアジャイル」では行います。これにより、機能数を確定し、スコープを明確にするためです。その上で、確定した機能数をベースラインにアジャイル開発を行っていきます。
「ＪＢアジャイル」は、開発局面をプロトタイプ局面、プロダクト局面、パイロット局面と分けて表現します。そしてこれに対して、計5回のイテレーションを行います。具体的には、プロトタイプ局面では、基本テストケースを基に２回、プロダクト局面では、深堀された最終テストケースを基に２回、最後にパイロット局面で１回です。
計5回のイテレーションでは、情報システム部門のみならず、エンドユーザーの皆さんも一緒に確認会を実施します。最初から実際に作成したプログラム・データを使って確認するため、新要件の深堀がしやすく、新旧システムの対比テストも可能で、見落としがちなバッチ処理の奥深い機能要件なども顕在化させることができます。この5回のイテレーションを実施するのに、ＪＢＣＣでは超高速開発ツール「GeneXus」を用いています。
「GeneXus」は、データ構造の定義、入力チェックなどのルール定義、帳票や集計などのプロシージャ定義といった設計情報からプログラムを100%自動生成します。画面であれば、20～50%、バッチ処理では70%程度手入力すれば、後は「GeneXus」が引き受けて、アプリケーションとデータベースを自動生成します。
「GeneXus」をベースにした「ＪＢアジャイル」によって、お客様は大きなメリットを享受できます。早い段階から実際に使用する画面を確認しながら構築を見守れるため、要望はそのつど出すことができます。ということはつまり、利用部門の責任者にプロジェクトリーダーの役割を務めていただけるということです。情報システム部門にフロントに立っていただく必要はありません。マイグレーションは情報システム部門が担当し、新規開発は利用部門が担当するといった役割分担も可能です。何にせよエンドユーザーである利用部門と密にコミュニケーションが図れるため、開発終盤に入ってからの認識相違が起こりません。それによる手戻りリスクも回避できるため、開発期間が短縮できます。当社での検証では、平均で40%も期間短縮できることが確認ずみです。さらに、プログラム生成ツールを利用して構築するため、物理バグによるトラブルも起こりません。
当社では、サービスイン後の自社保守を見据えたお客様への「GeneXus」教育も行っています。「ＪＢアジャイル」は、基盤移行したシステムのみならず、IAサーバーで稼働するシステムなどにも幅広く適用可能であるため、標準開発手法として採用いただければ、システムインテグレータへのキャッシュアウト抑制策としてご活用いただけます。
今後の検討に役立つ、ITレガシーマイグレーション移行事例をご紹介
▼「IBM i World 2022」レガシー・マイグレーションとアジャイル開発を同時進行！DX化構築事例
https://www.jbcc.co.jp/event/2023/01/01/6493.html
▼「IBM i World 2020」 IT モダナイゼーション・日本貨物鉄道（JR貨物）様事例セミナー
https://www.jbcc.co.jp/event/2023/01/01/6281.html
レガシーマイグレーション「ITモダナイゼーション」支援メニューのご紹介
ＪＢＣＣでは、レガシーシステムの「信頼性･安定性」と最新テクノロジーの「先進性･将来性」を両立した、新たなビジネスニーズへの対応を可能にする"いいとこ取り"のレガシーマイグレーション「ITモダナイゼーション」サービスを提供しています。
| メニュー名 | 内容 |
| 事例見学 ※ |
ＪＢＣＣのサービスを利用し、実際にレガシーマイグレーションされたお客様へ訪問し見学いただけます。 |
| 個別セミナー | ダウンサイジングセミナーを個別に実施します。これまでのＪＢＣＣの導入事例や具体的なサービスをご紹介します。 |
| びっくりデモ |
汎用機とIBM i を比較しながら、アーキテクチャーを説明します。ＪＢＣＣが選ばれる理由をご理解いただけます。 |
| 移行計画セッション | お客様の移行に関する不安を解消するために、ご契約前に移行計画セッションを実施します。 |
| パイロットコンバージョン |
お客様より1～2本のPGM/JCL/DATAをお預かりして、IBM i にコンバージョンを実施します。その結果を元に移行計画やデモなどで、ご説明します。 |
※ お客様へ確認の上、対応いたします。お客様の都合により、ご要望に添えない場合がございます。
「ITモダナイゼーション」サービスに関するお問い合わせ
 |
ＪBＣＣ株式会社 メインフレームからIBM Power System（IBM i）へ移行する |
 |
ＪＢＣＣ株式会社ＪＢＣＣ株式会社は、企業のデジタル・トランスフォーメーション（DX）を支援するITサービス企業です。クラウドサービスを中心にシステムの設計から構築、運用までを一貫して手掛けており、クラウド 2,150社、超高速開発による基幹システム構築 460社、セキュリティ 1,100社の実績があります。 |