PL/Iのリバースエンジニアリングの期間は、対象の規模と機能範囲で大きく変わります。数週間から3ヶ月程度の小規模な解析もあれば、半年から1年、場合によってはそれ以上かかる基幹システム全体の解析もあります。解析の対象になるのは、システムを支える既存の資産です。
- ソースコード
- ジョブ制御言語（JCL）
- データベース定義
PL/Iのリバースエンジニアリングは、汎用機（メインフレーム）で動くPL/I言語製の基幹システムを対象にした調査工程です。現存する資産を解析し、設計書や仕様書が失われたり実態と合わなくなったりした状態から、内部構造、業務ロジック、データフローを逆算して復元します。
総論記事「リバースエンジニアリング」は言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」「C言語のリバースエンジニアリング」といった言語別記事群は、それぞれの技術的特性を扱います。本記事群のPL/Iは、銀行や保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多いという特徴があります。
また、CICS（トランザクション処理モニタ）やIMS（階層型データベース・トランザクション管理システム）といったIBM系ミドルウェアと、密結合しているケースが極めて多くあります。
さらに、PL/Iを扱えるエンジニアはCOBOL技術者よりも希少で、これは他言語には見られない事情です。そのため、解析の難しさそのものよりも、解析できる人材をどう確保するかが、プロジェクトの成否を左右します。
本記事群は、こうしたPL/I解析を、老朽化システムの移行・刷新プロジェクトにおける「意思決定より前段の分析・調査フェーズ」として位置づけます。モダナイゼーションや刷新、移行を扱う既存記事群とは異なる専門記事として解説します。
PL/Iのリバースエンジニアリングの開発期間・スケジュール・納期を取り上げます。保守・運用費用やPoC、フルスクラッチ開発を扱う姉妹記事とは扱う範囲が異なり、プロジェクト計画の初期段階で必ず直面する疑問に答えることを目的としています。
その問いは、「調査・解析にどれくらいの時間がかかるのか」「何がスケジュールを左右するのか」「どう進めれば納期どおりに終えられるのか」の3つです。ソースコードの規模やドキュメントの有無に加え、CICS・IMSとの連携解析やPL/I技術者の希少性といった、この言語ならではの期間の変動要因まで整理し、現実的なスケジュールを組むための判断材料を示します。
このテーマの全体像は、次の完全ガイドで確認できます。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
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プログラム群を対象にし、数週間から3ヶ月程度で現状分析と仕様書化の初版を完成させられるケースが多く見られます。一方、勘定系や契約管理系のように数百万ステップ規模の基幹システム全体を対象にすると、半年から1年かかります。
対象範囲やミドルウェア連携の複雑さによっては、それ以上の期間を要することもあります。ただし、これらは目安にすぎず、後述するドキュメントの残存状況、CICS・IMS連携の複雑さ、PL/I技術者の確保状況によって大きく前後します。特に、全量を解析するか、重要な業務ロジックに絞った部分解析にするかで、必要な期間は数倍単位で変わり得ます。
そのため、全量を解析するか、重要な業務ロジックに絞った部分解析にするかは、移行判断の材料作りか、詳細設計書の完全な復元かによって、事前に定めておくことが納期設定の第一歩です。同じステップ数でも、取引ロジックが複雑な勘定系と定型的なマスタ管理とでは、解析時間が大きく異なります。精度を高めるには、ステップ数に加えて、条件分岐の密度やサブルーチンの呼び出し階層も確認しておくとよいでしょう。
フェーズ分け（現状調査→静的解析→仕様書化→レビュー→移行設計へのインプット）
フェーズを一体で見積もると、途中の想定外の事象が納期の遅延に直結します。そこで、フェーズごとにマイルストーンと成果物を定め、区切りごとに進捗と残課題を発注者と確認すると、遅延の兆候を早く把握でき、後続の計画も柔軟に調整できます。標準的なスケジュールは、5つのフェーズに分けて計画すると見通しを立てやすくなります。
（1）現状調査では、ソースコード、JCL、データベース定義、既存ドキュメントを洗い出し、関係者にヒアリングして解析範囲を確定します。（2）静的解析では、専用ツールやスクリプトで呼び出し関係やデータの入出力、CICS・IMSの呼び出し箇所を機械的に抽出します。（3）仕様書化では、静的解析の結果を業務の目線で読み解き、処理フロー図、データ定義書、業務ルール一覧にまとめます。
（4）レビューでは、業務有識者（SME）を交えて仕様書の正確性を検証し、機械解析では拾いきれない「なぜその処理になっているか」を補います。（5）最後に、これらの成果物を移行・刷新プロジェクトの設計インプットとして引き渡します。特に時間を要しやすいのは（3）と（4）で、機械解析だけで済ませず有識者の検証に余裕を持てるかが、納期全体の精度を左右します。
PL/I特有の期間長期化リスク要因
PL/Iのリバースエンジニアリングには、他言語の解析ではあまり問題にならない、この言語と業界に特有の要因があります。これらによってスケジュールが後ろ倒しになるおそれがあるため、事前にリスクの所在を把握しておくことが、現実的な納期設定とバッファ確保の鍵になります。
CICS/IMSとのミドルウェア連携解析の複雑さ
金融・保険業界の基幹システムでは、オンライン取引をCICSが、階層型のマスタや取引データをIMSが担う構成が数多く採用されています。PL/Iプログラムは、EXEC CICS文やEXEC DLI文でこれらを直接呼び出しています。そのため、業務ロジックを追うには、ソースコードに加え、CICSのトランザクション定義やIMSのデータベース定義（PSB・DBD）まで参照する必要があります。
特にIMSは階層型のデータモデルを持つため、リレーショナルデータベースに慣れた人でも、データ構造の読み解きに追加の学習時間が必要になることが少なくありません。ミドルウェアのドキュメントも、ソースコードと同じく散逸・陳腐化していることが多くあります。その結果、解析が想定より深く食い込み、スケジュール全体が後ろ倒しになる事態は、PL/I案件で繰り返し見られるパターンです。
加えて、CICSのトランザクション同士が内部で連鎖して呼び合う構成では、業務処理の全体像をつかむために複数の定義を横断して追う必要があり、解析範囲が芋づる式に広がることも珍しくありません。そのため、着手前に呼び出し関係をある程度俯瞰し、想定外の範囲拡大時の調整ルールを関係者間で合意しておくことが、後工程の混乱を防ぐポイントです。
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のリバースエンジニアリングの完全ガイド
▼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を創業。