PL/Iのリバースエンジニアリングとは、汎用機(メインフレーム)上で稼働するPL/I言語製の基幹システムを対象に、ソースコードやジョブ制御言語(JCL)、データベース定義といった現存する資産を解析し、設計書・仕様書が失われた、あるいは実態と乖離してしまった状態から、システムの内部構造・業務ロジック・データフローを逆算的に復元する調査工程です。総論記事「リバースエンジニアリング」が対象言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」「C言語のリバースエンジニアリング」といった言語別記事群がそれぞれの技術的特性を扱うのに対し、本記事群が扱うPL/Iは、銀行・保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多く、CICS(トランザクション処理モニタ)やIMS(階層型データベース・トランザクション管理システム)といったIBM系ミドルウェアと密結合しているケースが極めて多いという固有の技術的特徴を持ちます。加えて、PL/Iを扱えるエンジニアはCOBOL技術者よりもさらに希少であり、解析の難易度そのものよりも「解析できる人材をどう確保するか」がプロジェクトの成否を左右する、という他言語には見られない事情も抱えています。本記事群は、こうしたPL/I解析を、老朽化システムの移行・刷新プロジェクトにおける「意思決定より前段の分析・調査フェーズ」として位置づけ、モダナイゼーションや刷新、移行を扱う既存記事群とは異なる専門記事として解説します。
本記事では、PL/Iのリバースエンジニアリングにおける開発期間・スケジュール・納期に焦点を当てます。保守・運用費用やPoC、フルスクラッチ開発を扱う姉妹記事とは異なり、「調査・解析にどれくらいの時間がかかるのか」「何がスケジュールを左右するのか」「どう進めれば納期どおりに終えられるのか」という、プロジェクト計画立案の初期段階で必ず直面する疑問に答えることを目的としています。ソースコードの規模やドキュメントの有無だけでなく、CICS・IMSとの連携解析やPL/I技術者の希少性といった、この言語ならではの期間変動要因まで踏み込んで整理し、現実的なスケジュールを組むための判断材料を提供します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
PL/Iリバースエンジニアリングの位置づけと開発期間を左右する全体構造
PL/Iのリバースエンジニアリングにかかる期間を正しく見積もるには、まずこの作業が「プロジェクト全体のどこに位置する、何を目的とした工程なのか」を明確にしておく必要があります。位置づけを誤ると、本来は移行・刷新の意思決定に必要な調査工程であるにもかかわらず、移行プロジェクトそのものの一部として期間を見積もってしまい、後工程との切り分けが曖昧なままスケジュールが破綻するというケースが少なくありません。
「分析・調査」フェーズとしての位置づけ（モダナイゼーション・移行クラスタとの違い）
老朽化した基幹システムを刷新する際、「モダナイゼーション」「刷新」「更改」「リニューアル」「リアーキテクチャ」「リプレイス」「改修」といった記事群は、いずれも「何を・なぜ・いつ・どう変えるか」という意思決定と設計の論点を扱い、「移行」を扱う記事群は、その意思決定が済んだ後の「変える瞬間・移す作業そのものをどう安全に遂行するか」という実行フェーズを扱います。これに対して本記事群が扱うリバースエンジニアリングは、これらすべての前提となる、さらに上流の工程です。PL/Iで書かれた基幹システムは、長年の改修の積み重ねでドキュメントが実態と乖離し、あるいは紛失していることが多く、「どのアプローチで刷新すべきか」「どう移行すべきか」を判断する材料そのものが手元にない状態でプロジェクトが始まることが珍しくありません。リバースエンジニアリングは、この「判断材料そのものを作る」工程であり、期間を見積もる際は、後続の刷新・移行プロジェクトの工数とは独立した、調査・解析に特化したスケジュールとして扱う必要があります。
COBOL・C言語等の他言語版との違い（CICS/IMS連携と人材希少性という期間変動要因）
同じメインフレーム系のレガシー言語である「COBOLのリバースエンジニアリング」と比較すると、PL/Iは解析にかかる期間の変動要因が大きく異なります。COBOLは国内外で採用実績が圧倒的に多く、専用の解析ツールや変換ツールも比較的充実しているため、ツール導入によって期間を圧縮しやすい傾向があります。一方でPL/Iは採用企業自体が限られており、市販の解析ツールもPL/I構文への対応が部分的、あるいは非対応であることが多いため、解析作業の多くを人手による読み解きに頼らざるを得ない場面が増えます。さらに、PL/IのソースコードにはEXEC CICS・EXEC SQL・EXEC DLI(IMS)といったミドルウェア呼び出しがプリプロセッサ命令として埋め込まれているケースが多く、これらを正しく解釈するには、PL/I言語そのものの知識に加えてCICS・IMSの内部動作への理解が必須になります。「C言語のリバースエンジニアリング」のように業務ロジックがアプリケーション層に閉じているケースとは異なり、PL/Iの解析では業務ロジックとミドルウェア呼び出しが密接に絡み合っているため、解析範囲の切り分け自体に時間がかかりやすいという特徴があります。
規模別の期間の目安とフェーズ別スケジュール
PL/Iリバースエンジニアリングの期間は、対象システムのステップ数(コード行数)や機能範囲によって大きく異なりますが、大まかな目安を持っておくことは、プロジェクト計画の初期段階で欠かせません。ここでは、規模別の相場観と、一般的なフェーズ構成を確認します。
規模別（ステップ数）の期間相場
単一の機能・サブシステム単位で数万ステップ規模のPL/Iプログラム群を対象とする小規模な解析であれば、数週間から3ヶ月程度で現状分析と仕様書化の初版を完成させられるケースが多く見られます。これに対し、勘定系や契約管理系のように数百万ステップ規模に及ぶ基幹システム全体を対象とする大規模な解析では、半年から1年、対象範囲やミドルウェア連携の複雑さによってはそれ以上の期間を要することもあります。重要なのは、こうした期間はあくまで目安であり、後述するドキュメントの残存状況やCICS・IMS連携の複雑さ、そしてPL/I技術者の確保状況によって大きく前後するという点です。特に、解析対象を「全量」とするか「重要な業務ロジックに絞った部分解析」とするかによって、必要期間は数倍単位で変わり得るため、プロジェクトの目的(移行判断材料の作成なのか、詳細設計書の完全復元なのか)に応じてスコープを事前に定義しておくことが、現実的な納期設定の第一歩になります。また、同じ基幹システムであっても、勘定系のように取引ロジックが複雑に分岐する領域と、マスタ管理のように比較的定型的な処理が中心の領域とでは、同じステップ数でも解析にかかる時間が大きく異なります。見積もりの精度を高めるには、単純なステップ数だけでなく、条件分岐の密度やサブルーチンの呼び出し階層の深さといった、複雑度を示す指標もあわせて確認しておくことが望ましいでしょう。
フェーズ分け（現状調査→静的解析→仕様書化→レビュー→移行設計へのインプット）
フェーズを最初から一つの連続した工程として一体で見積もると、途中で発生した想定外の事象がそのまま最終納期の遅延に直結してしまいます。フェーズごとにマイルストーンと成果物を明確に定義し、フェーズの区切りごとに進捗と残課題を発注者側と確認する運用にしておくことで、遅延の兆候を早期に把握し、後続フェーズの計画を柔軟に調整できるようになります。PL/Iリバースエンジニアリングの標準的なスケジュールは、大きく5つのフェーズに分けて計画すると見通しが立てやすくなります。(1)現状調査フェーズでは、対象となるソースコード・JCL・データベース定義・既存ドキュメントの棚卸しと、システム関係者へのヒアリングを行い、解析範囲を確定します。(2)静的解析フェーズでは、専用ツールやスクリプトを用いてプログラム間の呼び出し関係、データの入出力、CICS・IMSの呼び出し箇所を機械的に抽出します。(3)仕様書化フェーズでは、静的解析の結果を業務目線で読み解き、処理フロー図やデータ定義書、業務ルール一覧といった成果物に落とし込みます。(4)レビューフェーズでは、業務有識者(SME)を交えて仕様書の正確性を検証し、機械解析だけでは拾いきれない「なぜその処理になっているか」という背景知識を補完します。(5)最後に、これらの成果物を移行・刷新プロジェクトの設計インプットとして引き渡します。この5フェーズのうち、PL/Iの案件で特に時間を要しやすいのが(3)仕様書化と(4)レビューであり、機械的な解析だけで完結させず、有識者を交えた検証工程にどれだけ余裕を持たせられるかが、納期全体の精度を左右します。
PL/I特有の期間長期化リスク要因
PL/Iのリバースエンジニアリングでは、他言語の解析ではあまり問題にならない、この言語・この業界特有の要因によってスケジュールが後ろ倒しになるリスクが存在します。事前にリスクの所在を把握しておくことが、現実的な納期設定とバッファ確保の鍵になります。
CICS/IMSとのミドルウェア連携解析の複雑さ
金融・保険業界の基幹システムでは、オンライン取引の処理をCICSが担い、階層型のマスタデータや取引データの管理をIMSが担うという構成が数多く採用されています。PL/Iプログラムの内部では、これらのミドルウェアの機能をEXEC CICS文やEXEC DLI文として直接呼び出しており、業務ロジックの流れを正確に追うには、PL/Iのソースコードだけでなく、CICSのトランザクション定義、IMSのデータベース定義(PSB・DBD)まで横断的に参照する必要があります。特にIMSは階層型データモデルという独特のデータ構造を持つため、リレーショナルデータベースの解析に慣れたエンジニアであっても、データ構造そのものの読み解きに追加の学習時間が必要になることが少なくありません。ミドルウェア側のドキュメントもソースコード同様に散逸・陳腐化しているケースが多く、この領域の解析が想定より深く食い込んでしまい、結果としてスケジュール全体が後ろ倒しになるという事態は、PL/I案件で繰り返し見られるパターンです。加えて、CICSのトランザクション同士が内部的に連鎖して呼び出し合う構成になっている場合、1つの業務処理の全体像を把握するために複数のトランザクション定義を横断的に追跡する必要があり、想定していた解析範囲が芋づる式に広がってしまうことも珍しくありません。着手前の段階で、対象トランザクションの呼び出し関係をある程度俯瞰しておき、想定外の範囲拡大が起きた場合のスケジュール調整ルールをあらかじめ関係者間で合意しておくことが、後工程での混乱を防ぐポイントです。
PL/I技術者の希少性による人繰り・レビュー遅延
PL/Iを実務レベルで読み書きできる技術者は、COBOL技術者と比較してもさらに数が限られており、市場で新たに確保しようとしても短期間で人員を積み増すことが難しいのが実情です。機械的な静的解析までは比較的短期間で終えられても、その結果を業務目線で検証し、正しい仕様として文書化する工程では、PL/Iと対象業務の両方に精通した技術者の関与が欠かせません。こうした人材が社内に限られている、あるいは既に高齢化・退任間近であるケースでは、レビューのスケジュールがその人材の稼働状況に強く依存することになり、他の工程がどれだけ順調に進んでも、最終的な仕様書の確定がボトルネックになりがちです。プロジェクト計画の段階で、こうしたキーパーソンの稼働可能時間をあらかじめ確保し、レビュー工程に十分なリードタイムを設定しておくことが、人材の希少性に起因する遅延リスクを抑える現実的な対策になります。さらに、社内に精通した人材が誰もいない、あるいは既に退職してしまっているというケースも珍しくありません。その場合は、外部の解析パートナーが持つPL/I技術者の稼働枠そのものがボトルネックになり得るため、契約前の段階で、実際に手を動かす技術者の人数とスキルレベル、他案件との掛け持ち状況まで確認しておくことが、開始後の期間遅延を防ぐうえで有効です。
スケジュール遅延を防ぐ進め方と体制づくり
PL/I特有のリスク要因を踏まえたうえで、それでも納期を守り切るための進め方・体制づくりのポイントを整理します。リスクの存在を認識するだけでなく、具体的な対策に落とし込むことが、計画倒れを防ぐために欠かせません。
自動解析ツール・静的解析の活用による工数圧縮
市販の解析ツールがPL/I構文に部分的にしか対応していない場合でも、呼び出し関係の抽出やコード行数の集計、データ項目の参照箇所リスト化といった機械的に処理できる部分は、汎用の静的解析エンジンやスクリプトを活用することで工数を大きく圧縮できます。すべてを人手で読み解こうとすると、規模が大きくなるほど期間が線形以上に膨らんでしまうため、機械化できる範囲を最初に見極め、人手による読み解きは業務ロジックの解釈やレビューといった「機械では代替できない工程」に集中させる、という役割分担が期間短縮の基本方針になります。特に、CICS・IMSの呼び出し箇所を自動抽出できるだけでも、ミドルウェア連携部分の調査範囲を早期に可視化でき、後工程での手戻りを防ぐ効果が見込めます。既製のツールで十分にカバーできない場合は、対象システムの構文パターンに合わせた簡易的な解析スクリプトを内製・オーダーメイドで用意するという選択肢もあり、この判断軸については姉妹記事「PL/Iのリバースエンジニアリングのフルスクラッチ・オーダーメイド開発について」で詳しく扱っています。
発注者側の協力体制とドキュメント収集の前倒し
ベンダー側の解析体制をどれだけ整えても、発注者側の協力なしにはスケジュールを守り切れません。着手前の段階で、社内に残る古い設計書や運用手順書、過去の改修履歴、退職者が残したメモといった資料をできる限り洗い出し、解析チームに提供する準備を前倒しで進めておくことが重要です。また、業務有識者へのヒアリングやレビューの日程を、プロジェクト開始時点であらかじめ確保しておくことも欠かせません。多忙な有識者ほど直前の日程調整が難しく、レビュー工程で数週間単位の遅延が発生する原因になりがちです。発注者・受注者双方が、リバースエンジニアリングを「ベンダー任せの調査」ではなく「自社の資産を可視化するための共同プロジェクト」として位置づけ、必要な社内リソースを計画的に確保しておくことが、結果として最も確実な納期遵守の手段になります。加えて、進捗を週次・隔週といった短いサイクルで発注者側と共有し、解析が進むにつれて明らかになる新たな論点(想定外のミドルウェア連携や、廃止済みと思われていた業務ロジックの現存など)を早期に拾い上げる体制を整えておくと、スケジュールの後半で大きな手戻りが発覚するという最悪のパターンを避けやすくなります。
まとめ
本記事では、PL/Iのリバースエンジニアリングにおける開発期間・スケジュール・納期について、モダナイゼーション・移行クラスタとは異なる「分析・調査フェーズ」としての位置づけ、規模別の期間相場とフェーズ別スケジュール、CICS・IMS連携解析やPL/I技術者の希少性といった期間長期化リスク要因、そしてスケジュール遅延を防ぐための進め方・体制づくりを解説しました。PL/Iの解析は、他のメインフレーム言語と比べてもツールによる自動化の余地が限られ、業務有識者を交えた人手のレビュー工程がボトルネックになりやすいという特徴があります。だからこそ、着手前の段階でリスクの所在を正しく把握し、機械化できる範囲と人手が必要な範囲を切り分けたうえで、余裕を持ったスケジュールとレビュー体制を組んでおくことが、納期を守りながら精度の高い調査結果を得るための最も確実な道筋です。
PL/Iのリバースエンジニアリングは、後続の移行・刷新プロジェクト全体の土台となる工程であるため、ここで組んだスケジュールの精度が、その後のプロジェクト全体の成否にも影響します。自社だけで期間の見積もりや体制づくりに不安がある場合は、金融・保険業界の基幹システムにおけるPL/I解析、CICS・IMS連携の調査実績が豊富なパートナーに、早い段階から相談することをお勧めします。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。