PL/Iのリバースエンジニアリングでフルスクラッチ・オーダーメイドを検討するときは、解析ツールを自社専用に作るかと、解析後に新システムを作り直すかを分けて考えます。汎用ツールで足りるかは、独自マクロや拡張記法への対応の要否が目安になります。
- PL/Iリバースエンジニアリングにおけるフルスクラッチの位置づけ
- 汎用解析ツール利用とオーダーメイド解析ツール開発の判断軸
- PL/I特有の言語仕様・独自マクロへの対応が必要なケース
- 解析後の新システム開発をフルスクラッチにする判断基準
PL/Iのリバースエンジニアリングとは、汎用機(メインフレーム)上で稼働するPL/I言語製の基幹システムを対象とする調査工程です。ソースコードやジョブ制御言語(JCL)、データベース定義といった現存する資産を解析し、失われた、あるいは実態と乖離した設計書・仕様書を、システムの内部構造から逆算して復元します。
総論記事「リバースエンジニアリング」は対象言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」などの言語別記事がそれぞれの技術的特性を扱います。
PL/Iは、銀行・保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多い言語です。また、CICS(トランザクション処理モニタ)やIMS(階層型データベース・トランザクション管理システム)といったIBM系ミドルウェアと密結合しているケースが極めて多く、この点も固有の特徴です。
加えて、市販の解析ツールの多くはCOBOL対応が中心で、PL/I構文への対応は部分的か、非対応のケースも少なくありません。そのため、汎用ツールに頼れない場面では、「フルスクラッチ・オーダーメイド」が現実的な検討対象として浮上します。
開発期間・保守運用費用・PoCを扱う姉妹記事とは異なり、ここでは開発方針そのものに関わる論点を取り上げます。具体的には、解析ツールをオーダーメイドで開発すべきケース、汎用の解析ツールと自社専用ツールの使い分け、解析結果をもとに新システムをフルスクラッチで作り直す判断について、順に見ていきます。
ここで扱う「フルスクラッチ」は、解析という工程で使う手段や道具立てに関する意思決定で、システム本体の作り方を指すものではありません。モダナイゼーションや刷新を扱う別の記事で使われる「フルスクラッチ」とは、この点が大きく異なります。
この違いを理解しないまま議論を進めると、解析ツールへの投資判断と新システム開発への投資判断を混同し、それぞれに適した意思決定のタイミングや予算枠を見誤るおそれがあります。
本テーマの全体像は、以下の全体ガイドでご確認ください。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
PL/Iリバースエンジニアリングにおけるフルスクラッチの位置づけ
PL/Iリバースエンジニアリングにおける「フルスクラッチ・オーダーメイド」という言葉は、2つの異なる論点を含んでいます。この2つを区別せずに議論すると、本来必要な意思決定を取り違えてしまうため、まずは論点を整理します。
特にプロジェクトの初期段階でこの整理を怠ると、関係者ごとに「フルスクラッチ」から連想する対象が異なり、会議の議論がかみ合わなくなるおそれがあります。
「解析ツールのオーダーメイド開発」と「新システム本体のフルスクラッチ開発」の切り分け
1つ目の論点は、リバースエンジニアリングの解析作業に使うツール・スクリプトを、既製品に頼らず自社専用にオーダーメイドで開発するかどうかです。2つ目の論点は、解析で明らかになった仕様をもとに、新システムをパッケージ製品や自動変換ツールに頼らずゼロから開発するかどうかです。
モダナイゼーションや刷新を扱う別の記事における「フルスクラッチ」は、もっぱら2つ目の、新システム本体の作り方に関する意思決定を指していました。別の記事が扱う取り組みには、モダナイゼーションや刷新のほか、次のようなものが含まれます。
- 更改
- リニューアル
- リアーキテクチャ
- リプレイス
- 改修
これに対して本記事群のリバースエンジニアリングは分析・調査フェーズに位置するため、まず優先して検討すべきは1つ目の解析ツールの是非です。
2つ目の新システム本体の開発方針は、解析結果を踏まえた「次の意思決定」として切り離して考える必要があります。この2つを混同すると、解析の費用と新システムの費用という、時期も予算枠も異なる2つの意思決定が一つの見積もりに混ざります。その結果、社内の予算承認プロセスが不必要に複雑化するという弊害も生じます。
COBOL等の他言語版との違い（オーダーメイド開発の必要性の高さ）
「COBOLのリバースエンジニアリング」では、市場に流通する解析・自動変換ツールの選択肢が比較的豊富であるため、オーダーメイドでツールを開発する必要性は相対的に低くなります。これに対してPL/Iは、市販ツールの対応状況がCOBOLほど充実していません。
そのため、対象システムの規模や独自マクロの使用状況によっては、オーダーメイドでの解析ツール開発が現実的な、あるいは唯一の選択肢になることも少なくありません。この「ツールの選択肢の少なさ」が、フルスクラッチ・オーダーメイドという論点を他言語より重要にする理由です。
COBOL案件の感覚で「まずは市販ツールを探せばよい」と考えて着手すると、対応ツールが見つからず、計画が停滞することがあります。したがって、PL/I案件では企画の初期段階から、オーダーメイド開発の可能性を選択肢に含めておくことが望ましいでしょう。
汎用解析ツール利用とオーダーメイド解析ツール開発の判断軸
汎用の解析ツールを使うか、自社専用の解析ツールをオーダーメイドで開発するかは、いくつかの観点から総合的に判断します。対象システムの特性によって最適な選択が変わるため、どちらか一方が常に優れているとはいえません。
汎用ツールが適するケース（標準的なPL/I構文が中心の場合）
対象システムが標準的なPL/I構文で書かれ、独自の拡張記法や特殊なプリプロセッサ命令が少ない場合は、汎用の解析ツールでも十分な精度で呼び出し関係やデータ項目を抽出できます。この場合は、ゼロから開発するよりも既存ツールのライセンス費用を負担するほうが、初期投資を抑えて短期間で解析に着手できます。
また、汎用ツールはベンダーによる継続的な機能改善・不具合修正が期待できるため、長期的な保守の観点でも、自社独自ツールより有利な場合があります。
対象システムの構文的な特殊性が低いと判断できるなら、まずは汎用ツールの適用可能性をPoCで確認し、十分な精度が得られるかを見極めるのが合理的です。
オーダーメイドが必要になるケース（独自拡張・特殊マクロが多い場合）
一方、長年の改修で独自のプリプロセッサマクロや、特定のコンパイラ・実行環境に依存した拡張記法を多用するシステムもあります。そうした場合、汎用ツールでは解析結果に大量の抽出漏れや誤変換が発生し、実用に耐えないおそれがあります。そこで、構文パターンに合わせた専用の解析ロジックを開発すれば、汎用ツールで拾いきれない箇所も機械的に処理できます。
ただし、オーダーメイド開発には相応の初期投資が必要です。対象システムの規模が大きく、繰り返し再解析する可能性がある場合は、長期的に汎用ツールのライセンス費用を積み上げるより、投資を回収しやすいケースもあります。
判断にあたっては、対象システムの構文的な特殊性をサンプリング調査し、汎用ツールの解析網羅率を定量的に把握したうえで、オーダーメイド開発の投資対効果を試算することが望ましいでしょう。この調査は、姉妹記事「PL/IのリバースエンジニアリングのPoC・プロトタイプ・モックアップ開発について」で解説したPoCの一環として行うと、要否を客観的に判断できます。
PL/I特有の言語仕様・独自マクロへの対応が必要なケース
PL/Iという言語自体が持つ特殊性と、長年の運用で積み重なった独自拡張が、オーダーメイド開発の必要性をさらに高める要因になります。
こうした特殊性がどの程度潜んでいるかは、汎用ツールを導入する前に見極めておくことが大切です。具体的にどのようなケースが該当するかを、次に見ていきます。
PL/I言語仕様の多機能性がもたらす解析の複雑さ
PL/Iは、FORTRAN・COBOL・ALGOLといった複数言語の特徴を統合した多機能な言語として設計された経緯があり、同じ処理にも複数の書き方が許容されます。この柔軟性は開発時には利点になり得ますが、リバースエンジニアリングの観点では、解析ツールが想定していない書き方に遭遇しやすいという課題にもなります。
特に、条件式の省略記法や、複雑なデータ構造(構造体・配列の組み合わせ)の宣言方法は、PL/I特有の記法です。解析ロジックがこれらを正確に解釈できないと、業務ロジックを読み違えるリスクがあります。加えて、稼働年数の長いシステムでは、開発当時の規約と改修担当者ごとの書き方が混在し、一つのシステムに複数の記法が同居していることも珍しくありません。
汎用ツールがこうした記法を網羅しきれない場合は、実際に使われている記法パターンを洗い出し、それに対応するオーダーメイドの解析ロジックを追加開発することが、精度の高い解析を実現する鍵になります。そのため、解析ロジックは単一の書き方だけを想定せず、記法のばらつきを踏まえて、複数パターンに対応できる設計にしておくことが望まれます。
埋め込みEXEC文（CICS/SQL/DLI）への個別対応
PL/Iのソースコードに埋め込まれるEXEC CICS文・EXEC SQL文・EXEC DLI(IMS)文は、それぞれ異なる構文体系を持つミドルウェア呼び出しです。このため、汎用のPL/I解析ツールがこれらすべてを高精度に解釈できるとは限りません。特にEXEC DLI文は、IMS固有の階層型データアクセスを表す構文で、対応するツールも市場に少ないといえます。
そこで、IMSを多用している場合は、EXEC DLI文の解析ロジックだけをオーダーメイドで開発し、PL/I本体は汎用ツールに任せるという使い分けも現実的です。このように、全体を一つの方法で解析するのではなく、構文の種類ごとに汎用ツールとオーダーメイド開発を組み合わせる発想が、PL/Iのリバースエンジニアリングでは有効です。
同様に、EXEC SQL文も、データベース製品やバージョンによって構文の細部が異なるため、汎用ツールの抽出・解釈精度を事前に確認します。不足があれば該当箇所だけを個別に補うという段階的な進め方により、投資規模を必要最小限に抑えられます。
解析後の新システム開発をフルスクラッチにする判断基準
解析結果が得られた後の新システム開発をどう進めるかという、もう一つの論点も取り上げます。
この判断は、解析プロジェクトの契約とは別枠で検討されることが一般的です。ただし、解析の進め方によってその後の選択肢の幅が変わるため、着手前から視野に入れておく価値があります。
自動変換ツール利用との違い（業務ロジックの再設計の有無）
解析結果をもとに新システムを構築する方法には、PL/Iのソースコードを他言語(JavaやC#等)へ機械的に変換する自動変換ツールを使う方法があります。もう一つは、業務ロジックを新たに設計し直して、フルスクラッチで開発する方法です。自動変換ツールは、既存の業務ロジックをほぼそのまま移植できるため、短期間・低コストで刷新しやすいという利点があります。
一方で、PL/I時代の非効率な処理構造や、現在では不要になった過去の業務ルールまで引き継いでしまうという欠点もあります。フルスクラッチでの開発は、解析で明らかになった業務ロジックを土台に、現在の業務要件に照らして不要な部分を整理し、保守しやすい設計に作り直せる点が強みです。ただし、その分、設計・開発の期間とコストがかかります。
この判断は、今の業務に合わない、歴史的経緯によるロジックがどれだけあるかで左右されます。なお、PL/I向けの自動変換ツールは、ベンダーや言語の組み合わせによって精度や対応範囲に差があり、COBOL向けほど選択肢がありません。自動変換を検討するなら、対象システムの一部を実際に変換して、実用に耐えるかを事前に検証しておくことが不可欠です。
フルスクラッチを選ぶべき判断基準
リバースエンジニアリングの結果、現在では使われていない業務ルール、重複・矛盾した処理ロジック、継ぎ足しで複雑化した分岐構造が多く見つかることがあります。そうした場合は、そのまま自動変換で引き継ぐより、フルスクラッチで整理し直すほうが、長期的な保守性・拡張性の面で有利になる可能性が高いといえます。
逆に、業務ロジック自体は概ね妥当で、実行基盤が古いだけという場合は、自動変換による移行のほうが、リスクとコストを抑えた合理的な選択になり得ます。いずれにしても、どちらの判断も、リバースエンジニアリングという分析・調査フェーズで現状を正確に把握した結果を土台にします。
解析が不十分なまま決めると、「もっと複雑な業務ロジックが残っていた」という手戻りにつながりかねません。判断材料として、業務ロジック一覧やデータフロー図を「現行踏襲すべき処理」「見直すべき処理」「廃止できる処理」に仕分けておくのも有効です。この仕分けは解析フェーズの延長で行え、そのままフルスクラッチか自動変換かを判断する材料になります。
まとめ
ここまで、論点の切り分けや判断軸を中心に、PL/Iのリバースエンジニアリングにおけるフルスクラッチ・オーダーメイド開発を解説してきました。
PL/Iは市販ツールの対応が限られるため、他言語よりオーダーメイド開発の必要性が高くなる傾向があります。そのため、対象システムの構文的な特殊性を事前に見極めたうえで、汎用ツールとオーダーメイド開発を適切に組み合わせることが、精度と費用対効果を両立させる鍵になります。
特に、構文の種類や複雑さに応じて、汎用ツールとオーダーメイド開発を部分的に組み合わせる発想が大切です。限られた予算で解析精度を最大限引き出すには、この発想が欠かせません。
そして、解析結果をもとに新システムをフルスクラッチで作り直すか、自動変換ツールで移行するかという後続の判断も、リバースエンジニアリングの精度に大きく依存します。この2段階の意思決定を計画的に切り分け、それぞれの段階で必要な情報を過不足なく揃えておくことが、プロジェクト全体を無駄なく進めるための要諦です。
自社のPL/I基幹システムで、どの範囲をオーダーメイドで解析すべきか、その先の開発方針をどう定めるべきかに迷う場合があります。そうした場合は、金融・保険業界の基幹システムでPL/I解析やCICS・IMS連携の調査実績が豊富なパートナーに、早めに相談することをお勧めします。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。