PL/Iのリバースエンジニアリングのフルスクラッチ・オーダーメイド開発について

PL/Iのリバースエンジニアリングとは、汎用機(メインフレーム)上で稼働するPL/I言語製の基幹システムを対象に、ソースコードやジョブ制御言語(JCL)、データベース定義といった現存する資産を解析し、失われた・あるいは実態と乖離した設計書・仕様書をシステムの内部構造から逆算的に復元する調査工程です。総論記事「リバースエンジニアリング」が対象言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」等の言語別記事群がそれぞれの技術的特性を扱うのに対し、本記事群が扱うPL/Iは、銀行・保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多く、CICS(トランザクション処理モニタ)やIMS(階層型データベース・トランザクション管理システム)といったIBM系ミドルウェアと密結合しているケースが極めて多いという固有の特徴を持ちます。加えて、市販の解析ツールの多くはCOBOL対応を中心としており、PL/I構文への対応が部分的・非対応であるケースが少なくないため、汎用ツールに頼れない場面で「フルスクラッチ・オーダーメイド」という選択肢が現実的な検討対象として浮上します。

本記事では、PL/Iのリバースエンジニアリングにおけるフルスクラッチ・オーダーメイド開発に焦点を当てます。開発期間・保守運用費用・PoCを扱う姉妹記事とは異なり、「解析ツールをオーダーメイドで開発すべきなのはどのようなケースか」「汎用の解析ツールと自社専用ツールをどう使い分けるべきか」「解析結果をもとに新システムをフルスクラッチで作り直す判断はどう下すべきか」という、開発方針そのものに関わる論点を扱います。ここで扱う「フルスクラッチ」は、システム本体の作り方ではなく、解析という工程で使う手段・道具立てに関する意思決定であるという点が、他の7波(モダナイゼーション・刷新等)の記事群における「フルスクラッチ」とは大きく異なります。この違いを理解しないまま議論を進めると、解析ツールの投資判断と新システム開発の投資判断を混同してしまい、それぞれに適した意思決定のタイミング・予算枠を見誤るおそれがあります。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

PL/Iリバースエンジニアリングにおけるフルスクラッチの位置づけ

PL/Iリバースエンジニアリングにおける「フルスクラッチ・オーダーメイド」という言葉は、実は2つの異なる論点を含んでいます。この2つを区別せずに議論を進めると、本来必要な意思決定を取り違えてしまうため、まずは論点の整理から始めます。プロジェクトの初期段階でこの整理を怠ると、関係者ごとに「フルスクラッチ」という言葉から連想する対象が異なり、会議での議論がかみ合わなくなるという事態にもつながりかねません。

1つ目の論点は、リバースエンジニアリングという解析作業そのものを行うためのツール・スクリプトを、既製品に頼らず自社専用にオーダーメイドで開発するかどうかという判断です。2つ目の論点は、リバースエンジニアリングによって明らかになった仕様をもとに、その後の新システムをパッケージ製品や自動変換ツールに頼らず、フルスクラッチでゼロから開発するかどうかという判断です。7波(モダナイゼーション・刷新・更改・リニューアル・リアーキテクチャ・リプレイス・改修)の記事群における「フルスクラッチ」は、もっぱら2つ目の、新システム本体の作り方に関する意思決定を指していました。これに対して本記事群であるリバースエンジニアリングは分析・調査フェーズに位置するため、まず優先的に検討すべきは1つ目の「解析ツールのオーダーメイド開発」の是非であり、2つ目の新システム本体の開発方針は、あくまで解析結果を踏まえた「次の意思決定」として、切り離して考える必要があります。この2つを混同したまま議論を進めてしまうと、「解析にどのくらいの費用がかかるか」という話と「新システム開発にどのくらいの費用がかかるか」という、本来は時期も予算枠も異なる2つの意思決定が一つの見積もりに混ざり込み、結果として社内での予算承認プロセスが不必要に複雑化するという実務上の弊害も生じやすくなります。

「COBOLのリバースエンジニアリング」では、市場に流通する解析・自動変換ツールの選択肢が比較的豊富であるため、オーダーメイドでツールを開発する必要性は相対的に低くなります。これに対してPL/Iは、市販ツールの対応状況がCOBOLほど充実していないため、対象システムの規模や独自マクロの使用状況によっては、オーダーメイドでの解析ツール開発が現実的な、あるいは唯一の選択肢になるケースが少なくありません。この「ツールの選択肢の少なさ」こそが、PL/Iのリバースエンジニアリングにおいてフルスクラッチ・オーダーメイドという論点が他言語よりも重要度高く浮上する理由です。COBOL案件の感覚のまま「まずは市販ツールを探せばよい」と考えて着手すると、対応ツールが見つからずに計画が停滞してしまうことがあるため、PL/I案件では企画の初期段階からオーダーメイド開発の可能性を選択肢に含めておくことが望ましいでしょう。

汎用解析ツール利用とオーダーメイド解析ツール開発の判断軸

汎用の解析ツールを利用するか、自社専用の解析ツールをオーダーメイドで開発するかは、いくつかの観点から総合的に判断する必要があります。どちらか一方が常に優れているというものではなく、対象システムの特性に応じて最適な選択が変わる点を踏まえて検討することが重要です。

対象システムのソースコードが標準的なPL/I構文で書かれており、独自の拡張記法や特殊なプリプロセッサ命令が少ない場合は、汎用の解析ツールでも十分な精度で呼び出し関係やデータ項目の抽出が行えます。この場合、オーダーメイドでゼロからツールを開発するよりも、既存ツールのライセンス費用を負担するほうが、初期投資を抑えつつ短期間で解析に着手できるという利点があります。また、汎用ツールはベンダーによる継続的な機能改善・不具合修正が期待できるため、長期的な保守の観点でも自社独自ツールより有利な場合があります。対象システムの構文的な特殊性が低いと判断できるのであれば、まずは汎用ツールの適用可能性をPoCで確認し、それで十分な精度が得られるかを見極めることから始めるのが合理的です。

一方、対象システムが長年の改修の中で独自のプリプロセッサマクロや、特定のコンパイラ・実行環境に依存した拡張記法を多用している場合、汎用ツールでは解析結果に大量の抽出漏れ・誤変換が発生し、実用に耐えない可能性があります。このような場合は、対象システムの構文パターンに合わせた専用の構文解析ロジックをオーダーメイドで開発することで、汎用ツールでは拾いきれない箇所まで機械的に処理できるようになります。オーダーメイド開発には相応の初期投資が必要になりますが、対象システムの規模が大きく、繰り返し解析・再解析を行う可能性がある場合には、長期的に見て汎用ツールのライセンス費用を積み上げるよりも投資回収しやすいケースもあります。判断にあたっては、対象システムの構文的な特殊性を事前にサンプリング調査し、汎用ツールでの解析網羅率がどの程度に留まるかを定量的に把握したうえで、オーダーメイド開発の投資対効果を試算することが望ましいでしょう。このサンプリング調査自体を、姉妹記事「PL/IのリバースエンジニアリングのPoC・プロトタイプ・モックアップ開発について」で解説したPoCの一環として実施すると、オーダーメイド開発の要否をより客観的な根拠に基づいて判断できます。

PL/I特有の言語仕様・独自マクロへの対応が必要なケース

PL/Iという言語自体が持つ特殊性、そして長年の運用の中で積み重なった独自拡張が、オーダーメイド開発の必要性をさらに高める要因になります。汎用ツールの導入だけで安心せず、こうした特殊性がどの程度潜んでいるかを見極めることが重要です。具体的にどのようなケースが該当するかを見ていきます。

PL/Iは、FORTRAN・COBOL・ALGOLといった複数言語の特徴を統合した多機能な言語として設計された経緯があり、同じ処理を実現するにも複数の書き方が許容されているという特徴を持ちます。この柔軟性は開発時には利点になり得ますが、リバースエンジニアリングの観点では、解析ツールが想定していない書き方のパターンに遭遇しやすいという課題にもなります。特に、条件式の省略記法や、複雑なデータ構造(構造体・配列の組み合わせ)の宣言方法など、PL/I特有の記法を正確に解釈できる解析ロジックを備えていないと、業務ロジックの読み違いにつながるリスクがあります。汎用ツールがこうした多様な記法パターンを網羅しきれていない場合は、対象システムで実際に使われている記法パターンを洗い出したうえで、それらに対応するオーダーメイドの解析ロジックを追加開発することが、精度の高い解析を実現する鍵になります。加えて、対象システムが稼働してきた年数が長いほど、開発当時のコーディング規約と、その後の改修担当者ごとの書き方の癖が混在し、一つのシステムの中に複数の記法スタイルが同居しているケースも珍しくありません。オーダーメイドの解析ロジックを設計する際は、単一の書き方だけを想定するのではなく、こうした記法のばらつきをあらかじめ洗い出したうえで、複数パターンに対応できる柔軟な設計にしておくことが望まれます。

PL/Iのソースコードに埋め込まれるEXEC CICS文・EXEC SQL文・EXEC DLI(IMS)文は、それぞれ異なる構文体系を持つミドルウェア呼び出しであり、汎用のPL/I解析ツールがこれらすべてを高精度に解釈できるとは限りません。特にEXEC DLI文はIMS固有の階層型データアクセスを表現するための構文であり、対応するツール自体が市場に少ないため、対象システムでIMSを多用している場合は、EXEC DLI文の解析ロジックだけをオーダーメイドで開発し、PL/I本体の解析は汎用ツールに任せるという、部分的な使い分けが現実的な選択肢になることもあります。このように、システム全体を一つのアプローチで解析しようとするのではなく、構文の種類ごとに汎用ツールとオーダーメイド開発を組み合わせるという発想が、PL/Iのリバースエンジニアリングでは特に有効です。同様に、EXEC SQL文についても、対象システムが利用しているデータベース製品・バージョンによって構文の細部が異なるため、汎用ツールがどこまで正確にSQL文を抽出・解釈できるかを事前に確認し、不足があれば該当箇所のみオーダーメイドで補うという段階的なアプローチを取ることで、オーダーメイド開発の投資規模を必要最小限に抑えられます。

解析後の新システム開発をフルスクラッチにする判断基準

ここからは、リバースエンジニアリングによって解析結果が得られた後、その先の新システム開発をどう進めるかという、もう一つの論点について整理します。この判断は解析プロジェクトそのものの契約とは別枠で検討されることが一般的ですが、解析の進め方次第でその後の選択肢の幅が変わってくるため、着手前から視野に入れておく価値があります。

解析結果をもとに新システムを構築する方法として、PL/Iのソースコードを他言語(JavaやC#等)へ機械的に変換する自動変換ツールを利用する方法と、業務ロジックを新たに設計し直してフルスクラッチで開発する方法があります。自動変換ツールは、既存の業務ロジックをほぼそのまま新しい言語・環境に移植できるため、短期間・低コストで刷新を実現しやすい一方、PL/I時代の非効率な処理構造や、現在では不要になった過去の業務ルールまでそのまま引き継いでしまうという欠点があります。これに対してフルスクラッチでの開発は、リバースエンジニアリングで明らかになった業務ロジックを土台にしつつ、現在の業務要件に照らして不要な部分を整理し、より保守しやすい設計に作り直せるという利点がありますが、その分の設計・開発期間とコストを要します。この判断は、対象システムがどれだけ「今の業務に最適化されていない、歴史的経緯によるロジック」を抱えているかによって左右されます。なお、PL/I向けの自動変換ツール自体も、対応言語の組み合わせやツールベンダーによって変換精度・対応範囲に差があり、COBOL向けの変換ツールほど選択肢が豊富ではありません。自動変換を検討する場合は、対象システムの一部を実際に変換してみて、変換後のコードがどの程度そのまま実用に耐えるかを事前に検証しておくことが不可欠です。

リバースエンジニアリングの結果、対象システムに「現在ではもう使われていない業務ルール」「重複・矛盾した処理ロジック」「継ぎ足しにより複雑化した分岐構造」が多く見つかった場合は、それらをそのまま自動変換で引き継ぐよりも、フルスクラッチで整理し直すほうが、その後の保守性・拡張性の面で長期的に有利になる可能性が高いといえます。逆に、業務ロジック自体は現在も概ね妥当であり、単に実行基盤が古いだけという場合は、自動変換ツールによる移行のほうが、リスクとコストを抑えられる合理的な選択になり得ます。いずれの場合も、この判断はリバースエンジニアリングによって現状を正確に把握して初めて下せるものであり、解析結果が不十分な状態でフルスクラッチか自動変換かを決めてしまうと、後になって「実はもっと複雑な業務ロジックが残っていた」という手戻りにつながりかねません。だからこそ、本記事群が扱うリバースエンジニアリングという分析・調査フェーズの精度が、その後のフルスクラッチかどうかという大きな意思決定の土台になるのです。判断材料をより具体的にするには、リバースエンジニアリングの成果物として作成した業務ロジック一覧やデータフロー図をもとに、「現行踏襲すべき処理」「見直すべき処理」「廃止できる処理」の3区分にあらかじめ仕分けしておくという進め方も有効です。この仕分け作業自体は解析フェーズの延長として実施でき、その結果がそのままフルスクラッチか自動変換かを判断する材料になります。

まとめ

本記事では、PL/Iのリバースエンジニアリングにおけるフルスクラッチ・オーダーメイド開発について、「解析ツールのオーダーメイド開発」と「新システム本体のフルスクラッチ開発」という2つの論点の切り分け、汎用解析ツール利用とオーダーメイド解析ツール開発の判断軸、PL/I特有の言語仕様・独自マクロへの対応が必要なケース、そして解析後の新システム開発をフルスクラッチにする判断基準を解説しました。PL/Iは市販ツールの対応状況が限られているため、他言語よりもオーダーメイド開発の必要性が高まりやすく、対象システムの構文的な特殊性を事前に見極めたうえで、汎用ツールとオーダーメイド開発を適切に組み合わせることが、精度と費用対効果を両立させる鍵になります。特に、システム全体を一律の方針で解析しようとせず、構文の種類や複雑さに応じて汎用ツールとオーダーメイド開発を部分的に組み合わせるという発想は、限られた予算の中で最大限の解析精度を引き出すうえで欠かせない視点です。

そして、解析結果をもとに新システムをフルスクラッチで作り直すか、自動変換ツールで移行するかという後続の判断も、リバースエンジニアリングの精度に大きく依存します。この2段階の意思決定を計画的に切り分け、それぞれの段階で必要な情報を過不足なく揃えておくことが、プロジェクト全体を無駄なく進めるための要諦です。自社のPL/I基幹システムについて、どの範囲をオーダーメイドで解析すべきか、その先の開発方針をどう定めるべきか判断に迷う場合は、金融・保険業界の基幹システムにおけるPL/I解析、CICS・IMS連携の調査実績が豊富なパートナーに、早めに相談することをお勧めします。

▼全体ガイドの記事
・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を創業。