PL/IのリバースエンジニアリングのPoC・プロトタイプ・モックアップ開発について

PL/Iのリバースエンジニアリングとは、汎用機(メインフレーム)上で稼働するPL/I言語製の基幹システムを対象に、ソースコードやジョブ制御言語(JCL)、データベース定義といった現存する資産を解析し、失われた・あるいは実態と乖離した設計書・仕様書をシステムの内部構造から逆算的に復元する調査工程です。総論記事「リバースエンジニアリング」が対象言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」等の言語別記事群がそれぞれの技術的特性を扱うのに対し、本記事群が扱うPL/Iは、銀行・保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多く、CICS(トランザクション処理モニタ)やIMS(階層型データベース・トランザクション管理システム)といったIBM系ミドルウェアと密結合しているケースが極めて多いという固有の特徴を持ちます。加えて、PL/Iを扱えるエンジニアはCOBOL技術者よりもさらに希少であり、この希少性ゆえに、いきなり大規模な全量解析へ踏み切ることには相応のリスクが伴います。長年の改修によって仕様が複雑化した基幹システムほど、着手前の想定と実際の解析難易度が乖離しやすく、その乖離を早期に発見できるかどうかが、プロジェクト全体の成否を左右します。

本記事では、PL/Iのリバースエンジニアリングにおいて、PoC・プロトタイプ・モックアップ開発に焦点を当てます。開発期間や保守運用費用の見積もりを固める前段階で、まず何を確認しておくべきかを整理しておくことが、プロジェクト全体の手戻りを防ぐ第一歩になります。開発期間・保守運用費用を扱う姉妹記事とは異なり、「なぜいきなり全量解析ではなく、まず一部モジュールで試行すべきなのか」「PoCはどのような目的・進め方で行うべきなのか」「何を確認できればスケールアップの判断を下せるのか」という、本格着手の前段階で必ず検討すべき論点を扱います。限られた予算とPL/I人材というリソースの制約の中で、最も手戻りの少ない進め方を選ぶための判断材料を提供します。特に、初めてPL/I基幹システムの解析を検討する情報システム部門にとって、いきなり大規模な予算を確保して全量解析に踏み切ることは心理的にも組織的にもハードルが高いため、まず小さく試すというアプローチ自体が、社内合意形成の観点からも現実的な進め方だと言えます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。あわせて、PL/Iリバースエンジニアリング全体の開発期間・保守運用費用・フルスクラッチ開発の判断軸については、それぞれの姉妹記事も参照してください。プロジェクトの目的や検討フェーズに応じて、必要な観点から読み進めていただくことをお勧めします。

▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド

なぜ全量解析ではなくPoCから始めるべきか

大規模なPL/I基幹システムを前にすると、多くの企業は「まず全体を解析しなければ何も分からない」と考えがちです。しかし、PL/Iの解析には特有の不確実性があり、いきなり全量を対象にすることには大きなリスクが伴います。まずはその理由を整理します。ここで扱う「PoC」は、システム開発における一般的なPoC(新機能・新技術の実現可能性検証)とは目的が異なり、あくまで「解析という調査行為そのものの実現可能性と工数感を検証する」という位置づけである点にも注意が必要です。

ここで言う不確実性とは、単なる「見積もりの粗さ」ではなく、着手してみなければ発見しようがない性質の情報を指します。PL/Iの解析プロジェクトには、着手前の時点では正確に見積もりきれない不確実性が複数存在します。市販の解析ツールが対象システムのPL/I構文・独自マクロにどこまで対応できるかは、実際に適用してみないと分からない部分が大きく、事前の机上検討だけでは楽観的な見積もりになりがちです。また、CICS・IMSとの連携がどの程度複雑か、想定外のトランザクション連鎖が潜んでいないかも、実際にソースコードへ手を入れてみて初めて明らかになることが少なくありません。さらに、確保できたPL/I技術者が対象システムの業務領域にどこまで習熟できるかも、プロジェクトが動き出してみないと見えてこない要素です。これらの不確実性を抱えたまま、いきなり全量解析の契約・予算を確定させてしまうと、着手後に前提が崩れた場合の手戻りが極めて大きくなります。特に、数百万ステップ規模の基幹システム全体を対象とした契約をあらかじめ固定金額で結んでしまうと、途中で不確実性が顕在化した際に、追加予算の交渉や契約変更に多大な時間を要し、プロジェクト自体が停滞してしまうリスクもあります。

PoC(概念実証)は、こうした不確実性を、影響範囲が限定された小規模な範囲で先に検証し、リスクを前倒しで発見するための工程です。ソフトウェア開発一般で言うプロトタイプ・モックアップという言葉が持つ「見た目や操作感を確認する試作品」というニュアンスとは異なり、ここでのPoCは「解析という調査行為の実現可能性そのもの」を確かめる工程である点を、関係者間で認識合わせしておくとよいでしょう。全量解析の契約を結ぶ前に、代表的な一部モジュールを対象として試行することで、「このツールはどこまで自動化できるか」「この規模のCICS連携ならどの程度の追加工数がかかるか」「確保した技術者は実際にどの程度の生産性を発揮できるか」といった、見積もりの前提となる情報を実データに基づいて把握できます。PoCにかかる費用と期間は、全量解析に比べればごくわずかですが、そこで得られる知見は、その後の本格展開の見積もり精度を大きく引き上げてくれます。PL/Iのように市場に十分な実績データが蓄積されていない領域では、このPoCという「小さく試して大きく外さない」進め方が、特に大きな効果を発揮します。また、PoCの成果物であるプロトタイプの仕様書は、それ自体が「この品質・この粒度で仕様書を作成する」というサンプルとして機能するため、発注者側が本格展開の成果物イメージを事前に共有できるという副次的な効果も持ちます。仕様書の粒度・記述形式について、着手後に認識のズレが発覚するという事態は、PoCの段階でサンプルを確認しておくことで多くを未然に防げます。

PoCの進め方（対象モジュール選定と目的設定）

PoCを効果的なものにするには、進め方そのものを丁寧に設計する必要があります。行き当たりばったりで一部モジュールに手をつけてしまうと、得られた結果を本格展開の判断材料として十分に活用できません。ここでは、対象モジュールの選び方と、目的の定め方について解説します。

PoCの対象モジュールは、「解析しやすそうな単純なもの」ではなく、対象システム全体を代表する複雑さ・特徴を持ったモジュールを選ぶことが重要です。極端に単純なモジュールだけを対象にPoCを行うと、そこで得られた知見が本番の全量解析には当てはまらず、PoCの意味が薄れてしまいます。具体的には、CICSのトランザクション呼び出しを含むオンライン処理系のプログラム、IMSのデータベースアクセスを含むバッチ処理系のプログラム、そして比較的シンプルなマスタ管理系のプログラムというように、性質の異なる複数のモジュールをバランスよく選定すると、より実態に近いリスク評価が可能になります。また、業務上の重要度が高く、今後の移行・刷新プロジェクトで優先的に扱われる見込みのある領域を選ぶことで、PoCの成果そのものを後続プロジェクトに直接活用できるという副次的なメリットも得られます。選定にあたっては、社内の現行システム担当者やベンダー双方が「ここなら代表性がある」と合意できる客観的な根拠(ステップ数、呼び出し関係の複雑さ、過去の改修頻度など)を用意しておくと、後になって「PoCの対象選定自体が偏っていたのではないか」という疑義が生じるのを防げます。

PoCを開始する前に、「何を確認できれば成功と言えるのか」という目的を、関係者間で明文化しておくことが欠かせません。目的が曖昧なまま進めてしまうと、PoCの結果をどう評価すればよいのかが分からず、次のステップへの判断材料にならないという事態を招きかねません。目的の例としては、「特定の解析ツールがPL/I構文・埋め込みSQLをどこまで正確に解析できるか」「CICSトランザクション1件あたりの解析に平均してどの程度の工数がかかるか」「業務有識者へのヒアリングを何回程度行えば仕様書のレビューが完了するか」といった、後工程の見積もりに直結する具体的な問いを設定することが有効です。期間の目安としては、数週間から1〜2ヶ月程度で区切り、得られた知見を速やかに本格展開の計画へ反映できるサイクルにしておくことが望ましいでしょう。あわせて、PoCの実施体制についても事前に取り決めておく必要があります。誰が解析作業を担当し、誰が発注者側の窓口としてヒアリングに応じ、誰が最終的な成果物のレビューを行うのかという役割分担を、PoC開始前の段階でドキュメント化しておくことで、限られた期間の中で無駄なコミュニケーションコストが発生するのを防げます。

PoCで検証すべき技術的ポイント

PoCで確認すべき技術的な論点は多岐にわたりますが、PL/I案件では特に次の2点への重点的な検証が有効です。この2点は、いずれも本格展開時の工数見積もりの精度に直結するため、限られたPoCの期間の中でも優先的に時間を割くべき領域と言えます。

候補となる自動解析ツールが、対象システムのPL/Iソースコードをどこまで正確に解析できるかは、ツールのカタログスペックだけでは判断しきれません。PoCの段階で実際のソースコードを投入し、呼び出し関係の抽出漏れがないか、対象システム特有の独自マクロやプリプロセッサ命令を正しく解釈できるか、出力される解析結果がそのまま仕様書のベースとして使えるレベルの品質かを、具体的に検証する必要があります。ツールによっては、標準的なPL/I構文には対応していても、対象システムが独自に拡張した記法や、古いバージョンのコンパイラ特有の記法には対応しきれないケースもあるため、複数のツールを比較検証する、あるいはツールでカバーできない部分を補う簡易スクリプトの開発余地を見極める、といった判断もPoCの段階で行っておくことが望ましいでしょう。検証の際は、ツールが出力した解析結果を、実際にPL/Iを読み解ける技術者がソースコードと突き合わせて確認する「答え合わせ」の工程を必ず組み込むことも重要です。ツールの出力を無条件に信頼してしまうと、検出漏れや誤変換に本格展開の段階まで気づけないという事態になりかねません。

CICSトランザクション定義やIMSのデータベース定義(PSB・DBD)を、PL/Iのソースコードとあわせてどこまで解析できるかも、PoCで重点的に確認すべきポイントです。ミドルウェア側の定義情報が、ソースコードと同じように解析チームへ提供可能な状態にあるか、提供された場合にツールや手作業でどの程度の工数を要するかを、実際に一部のトランザクション・データベースを対象に試行して把握しておきます。この工程で得られる工数感は、本格展開時の人月見積もりに直接反映される重要な情報であり、PoCの段階でここを曖昧にしたまま本格着手してしまうと、後になって「ミドルウェア連携の解析だけで想定の数倍の工数がかかることが判明した」という事態に陥りかねません。加えて、IMSの階層型データモデルは、リレーショナルデータベースに慣れた技術者にとって直感的に理解しづらい構造であるため、PoCの段階で「どの程度の学習期間があれば実務レベルで読み解けるようになるか」という育成コストの観点まで確認しておくと、本格展開時の体制設計にも役立ちます。

PoCの成功判断基準とスケールアップ判断

PoCを実施した後は、その結果をもとに本格展開に進むべきかどうかを客観的に判断する必要があります。せっかく丁寧にPoCを設計・実施しても、その結果を評価する基準が曖昧なままでは、次のアクションを決めきれずにプロジェクトが宙に浮いてしまいます。ここでは、判断基準の立て方とスケールアップ時の留意点を解説します。

スケールアップの判断は、単に「うまくいったかどうか」という感覚的な評価ではなく、あらかじめ定めた基準に照らして機械的に判定できる状態にしておくことが理想です。PoCの成功可否は、定量面と定性面の両方から評価することが望ましいでしょう。定量面では、事前に設定した目的(ツールの解析網羅率、1トランザクションあたりの解析工数、レビューに要したヒアリング回数など)が、許容できる範囲に収まっているかを確認します。定性面では、実際に稼働してもらった技術者が対象システムの業務ロジックをどの程度スムーズに理解できたか、業務有識者とのコミュニケーションが円滑に進んだかといった、数値化しにくいが本格展開の成否を左右する要素を評価します。この両面を突き合わせたうえで、「このアプローチ・この体制であれば全量解析を進められる」と判断できるかどうかが、スケールアップの分岐点になります。評価の際は、PoCを実施したベンダー自身による自己評価だけに頼らず、発注者側の情報システム部門や業務部門を交えた第三者的な視点でのレビューを行うことも、判断の客観性を担保するうえで有効です。

PoCの結果、当初想定していたアプローチのままでは本格展開が難しいと判断された場合は、無理に当初計画を押し通すのではなく、アプローチそのものを見直すべきです。例えば、想定していたツールでは解析網羅率が不十分だと分かった場合は、別のツールとの併用や、対象範囲に応じたオーダーメイドのスクリプト開発を検討する必要があります。この判断軸については、姉妹記事「PL/Iのリバースエンジニアリングのフルスクラッチ・オーダーメイド開発について」で詳しく扱っています。逆に、PoCの結果が良好であった場合も、PoC規模から全量規模への拡大に伴い、単純な比例計算では見積もれない工数増(例えば拠点間・システム間の連携解析など)が発生する可能性があるため、PoCの結果をそのまま線形に引き延ばすのではなく、規模拡大に伴う追加要因を織り込んだうえで、本格展開の計画を練り直すことが求められます。特に、PoCで対象とした一部モジュールでは問題にならなかった業務ロジックの重複や相互依存が、対象範囲を広げるにつれて次々と表面化してくることは珍しくありません。本格展開のスケジュールには、こうした「規模拡大にともなう想定外の発見」に対応するためのバッファをあらかじめ組み込んでおくことをお勧めします。

まとめ

本記事では、PL/Iのリバースエンジニアリングにおいて、なぜ全量解析ではなくPoCから始めるべきか、PoCの進め方(対象モジュール選定と目的設定)、PoCで検証すべき技術的ポイント(自動解析ツールの精度・CICS/IMS連携解析の工数感)、そしてPoCの成功判断基準とスケールアップ判断について解説しました。PL/Iの解析には、ツール対応やミドルウェア連携、人材確保といった着手前には見積もりきれない不確実性が多く存在するため、小規模なPoCで前提を検証し、リスクを前倒しで発見しておくことが、結果的に最も確実で費用対効果の高い進め方になります。代表性のあるモジュールを選び、定量・定性の両面から明確な目的を設定し、その結果を客観的に評価するという一連のプロセスを丁寧に踏むことで、限られた予算であっても着実に本格展開への道筋を描くことができます。

PoCで得られる知見は、金額換算すると小さく見えても、その後の本格展開における手戻りを防ぐという意味で、プロジェクト全体の成否を左右する重要な投資です。特に、PoCを外部パートナーに依頼する場合は、その実施経験がその後の本格展開の提案にも活かされるため、単なる「お試し発注」ではなく、長期的なパートナー選定の一環としてPoCの依頼先を検討することをお勧めします。自社のPL/I基幹システムでどのようなPoCが適切か判断に迷う場合は、金融・保険業界の基幹システムにおけるPL/I解析、CICS・IMS連携の調査実績が豊富なパートナーに、PoCの設計段階から相談することをお勧めします。

▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。