PL/Iのリバースエンジニアリングは、いきなり全量を解析せず、一部のモジュールでPoCを行ってから本格展開を判断するのが安全です。PoCでは、解析の見通しと工数感を先に確かめます。
- 全量解析ではなくPoCから始める理由
- PoCの進め方（対象モジュール選定と目的設定）
- PoCで検証すべき技術的ポイント
PL/Iのリバースエンジニアリングは、汎用機（メインフレーム）上で稼働するPL/I製の基幹システムを対象にした調査工程です。ソースコードやジョブ制御言語（JCL）、データベース定義といった現存する資産を解析し、失われた、あるいは実態と乖離した設計書・仕様書を、システムの内部構造から逆算して復元します。
総論記事「リバースエンジニアリング」は、対象言語を問わない解析手法全般を扱います。一方で、「COBOLのリバースエンジニアリング」などの言語別記事は、それぞれの技術的特性を扱っています。
この記事群が扱うPL/Iは、銀行や保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで、採用例が多い言語です。CICS（トランザクション処理モニタ）やIMS（階層型データベース・トランザクション管理システム）といったIBM系ミドルウェアと密結合しているケースが極めて多く、ここに固有の特徴があります。
PL/Iを扱えるエンジニアは、COBOL技術者よりもさらに希少です。そのため、いきなり大規模な全量解析へ踏み切ることには、相応のリスクが伴います。
長年の改修で仕様が複雑化した基幹システムほど、着手前の想定と実際の解析難易度がずれやすくなります。そのずれを早く見つけられるかどうかが、プロジェクト全体の成否を左右します。
この記事は、PoC・プロトタイプ・モックアップ開発に焦点を当てます。開発期間や保守運用費用の見積もりを固める前に、まず何を確認しておくかを整理することが、プロジェクト全体の手戻りを防ぐ第一歩になります。
開発期間・保守運用費用を扱う姉妹記事とは異なり、本格着手の前段階で必ず検討したい論点を取り上げます。具体的には、なぜいきなり全量解析ではなく一部のモジュールで試行すべきか、PoCはどのような目的と進め方で行うべきか、何を確認できればスケールアップの判断を下せるのか、といった点です。
予算もPL/I人材も限られるなかで、最も手戻りの少ない進め方を選ぶための判断材料になります。特に、初めてPL/I基幹システムの解析を検討する情報システム部門にとって、いきなり大規模な予算を確保して全量解析に踏み切ることは、心理的にも組織的にもハードルが高いものです。そのため、まず小さく試すという進め方は、社内の合意形成の観点からも現実的です。
このテーマの全体像は、以下の記事で確認できます。
あわせて、PL/Iのリバースエンジニアリングにおける開発期間・保守運用費用と、フルスクラッチ開発の判断の進め方は、それぞれの姉妹記事で扱っています。プロジェクトの目的や検討フェーズに応じて、必要な観点から読み進めるとよいでしょう。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
全量解析ではなくPoCから始める理由
大規模なPL/I基幹システムを前にすると、まず全体を解析しなければ何も分からないと考えがちです。
しかし、PL/Iの解析には特有の不確実性があり、いきなり全量を対象にすると大きなリスクになります。その理由を順に見ていきます。
ここで扱うPoCは、システム開発で一般的に使われるPoC（新機能・新技術の実現可能性検証）とは目的が違います。あくまで、解析という調査行為そのものを検証するものです。
PL/I特有の不確実性（ツール対応・ミドルウェア連携・人材確保）
ここでいう不確実性とは、着手してみなければ発見できない性質の情報を指します。単なる見積もりの粗さとは区別して考える必要があります。PL/Iの解析プロジェクトには、着手前には正確に見積もりきれない不確実性が複数あります。
市販の解析ツールが対象システムのPL/I構文や独自マクロにどこまで対応できるかは、実際に適用してみないと分かりません。事前の机上検討では、楽観的な見積もりになりがちです。また、CICS・IMSとの連携がどの程度複雑か、想定外のトランザクション連鎖が潜んでいないかも、ソースコードに手を入れて初めて明らかになることが少なくありません。
さらに、確保できたPL/I技術者が対象システムの業務領域にどこまで習熟できるかも、動き出してみないと見えてきません。こうした不確実性を抱えたまま全量解析の契約や予算を確定させると、前提が崩れたときの手戻りが極めて大きくなります。特に、数百万ステップ規模の基幹システム全体を対象に固定金額で契約すると、追加予算の交渉や契約変更に多大な時間がかかり、プロジェクト自体が停滞するリスクもあります。
PoCが果たす役割（前提の検証によるリスクの前倒し発見）
PoC（概念実証）は、こうした不確実性を影響の限られた小規模な範囲で先に検証し、リスクを前倒しで発見するための工程です。ソフトウェア開発一般でいうプロトタイプやモックアップは見た目や操作感の試作品ですが、ここでのPoCは解析の実現可能性そのものを確かめます。この違いを、関係者間で認識を合わせておくとよいでしょう。
全量解析の契約を結ぶ前に、代表的な一部のモジュールで試行します。すると、見積もりの前提となる情報を、実データに基づいて把握できます。たとえば、「このツールはどこまで自動化できるか」「この規模のCICS連携にどの程度の追加工数がかかるか」「確保した技術者はどの程度の生産性を発揮できるか」といった点です。
PoCの費用と期間は全量解析に比べればごくわずかですが、得られる知見は本格展開の見積もり精度を大きく引き上げます。PL/Iのように市場に十分な実績データが蓄積されていない領域では、「小さく試して大きく外さない」進め方が特に効果を発揮します。PoCの成果物であるプロトタイプの仕様書には、主に2つの効果があります。
- サンプルとしての効果：プロトタイプの仕様書そのものが、この品質と粒度で仕様書を作るサンプルになり、発注者が本格展開の成果物イメージを事前に共有できます。
- 仕様書の粒度・記述形式のずれ：着手後に発覚する認識のずれは、PoCの段階でサンプルを確認しておくことで多くを未然に防げます。
PoCの進め方（対象モジュール選定と目的設定）
PoCを効果的にするには、進め方そのものを丁寧に設計することが欠かせません。場当たり的に一部のモジュールへ手をつけると、結果を本格展開の判断材料として十分に活用できなくなります。
対象モジュールの選び方と目的の定め方を解説します。
対象モジュールの選び方（代表性のあるサンプルの選定）
PoCの対象モジュールは、解析しやすそうな単純なものではなく、対象システム全体を代表する複雑さや特徴を持つものを選ぶことが重要です。極端に単純なモジュールだけでPoCを行うと、得られた知見が本番の全量解析に当てはまらず、PoCの意味が薄れてしまいます。
具体的には、CICSのトランザクション呼び出しを含むオンライン処理系、IMSのデータベースアクセスを含むバッチ処理系、比較的シンプルなマスタ管理系のように、性質の異なるモジュールをバランスよく選びます。そうすると、実態に近いリスク評価が可能になります。さらに、業務上の重要度が高く今後の移行・刷新で優先的に扱われる領域を選べば、PoCの成果をそのまま後続プロジェクトに活用できます。
選定の際は、社内の現行システム担当者とベンダーの双方が「ここなら代表性がある」と合意できる、客観的な根拠を用意します。たとえば、ステップ数、呼び出し関係の複雑さ、過去の改修頻度などです。そうしておけば、後から「対象の選定が偏っていたのではないか」という疑義が生じるのを防げます。
PoCの目的設定と期間の目安
PoCを始める前に、「何を確認できれば成功といえるのか」という目的を、関係者間で明文化しておくべきです。目的が曖昧なままでは結果の評価軸が定まらず、次のステップへの判断材料になりにくくなります。
目的の例は、後工程の見積もりに直結する具体的な問いです。たとえば、「特定の解析ツールがPL/I構文・埋め込みSQLをどこまで正確に解析できるか」を確かめるといった形です。ほかにも、CICSトランザクション1件あたりの解析に平均してどの程度の工数がかかるか、業務有識者へのヒアリングを何回程度行えば仕様書のレビューが完了するか、といった問いが考えられます。
期間の目安は数週間から1〜2ヶ月程度で区切り、得られた知見をすぐ本格展開の計画に反映できるサイクルにしておくと望ましいでしょう。PoCの実施体制についても、誰が解析作業を担当し、誰が発注者側の窓口としてヒアリングに応じ、誰が成果物をレビューするかを、開始前に文書で取り決めておく必要があります。そうすれば、限られた期間で無駄なコミュニケーションコストが生じるのを防げます。
PoCで検証すべき技術的ポイント
PoCで確認すべき技術的な論点は多岐にわたりますが、PL/I案件では、ツールの精度とCICS/IMS連携の2点を重点的に検証すると効果的です。
この2点は、いずれも本格展開時の工数見積もりの精度に直結します。そのため、限られたPoCの期間の中でも優先的に時間を割くべき領域といえます。
自動解析ツールの精度・網羅性の検証
候補となる自動解析ツールが、対象システムのPL/Iソースコードをどこまで正確に解析できるかは、カタログの性能だけでは判断しきれません。PoCでは実際のソースコードを投入し、呼び出し関係の抽出漏れや、独自マクロ・プリプロセッサ命令の解釈、解析結果が仕様書のベースとして使える品質かを具体的に検証します。
ツールによっては、標準的なPL/I構文には対応していても、独自に拡張された記法や古いバージョンのコンパイラ特有の記法には対応しきれないことがあります。そのため、複数のツールを比較する、あるいはツールで扱えない部分を補う簡易スクリプトの開発余地を見極める、といった判断もPoCの段階で行っておくと望ましいでしょう。
検証では、PL/Iを読める技術者がツールの出力をソースコードと突き合わせる「答え合わせ」の工程も、必ず組み込んでおきます。ツールの出力を無条件に信頼すると、検出漏れや誤変換に本格展開の段階まで気づけないおそれがあります。
CICS/IMS連携解析の可否と工数感の把握
CICSトランザクション定義やIMSのデータベース定義（PSB・DBD）を、PL/Iのソースコードとあわせてどこまで解析できるかも、PoCで重点的に確かめておきます。ミドルウェア側の定義情報が解析チームへ提供できる状態にあるか、提供された場合にツールや手作業でどの程度の工数を要するかは、一部のトランザクションやデータベースで実際に試行して把握します。
この工程で得られる工数感は、本格展開時の人月見積もりに直接反映される重要な情報です。PoCの段階でここを曖昧にしたまま本格着手すると、「ミドルウェア連携の解析だけで想定の数倍の工数がかかることが判明した」という事態に陥りかねません。
加えて、IMSの階層型データモデルは、リレーショナルデータベースに慣れた技術者には直感的に理解しにくい構造です。そのため、どの程度の学習期間があれば実務レベルで読み解けるようになるかという育成コストの観点も、PoCの段階で確認しておくと、本格展開時の体制設計に役立ちます。
PoCの成功判断基準とスケールアップ判断
PoCを実施した後は、その結果をもとに本格展開へ進むべきかどうかを、客観的に判断する必要があります。
せっかく丁寧にPoCを設計・実施しても、評価の基準が曖昧なままでは次のアクションを決めきれず、プロジェクトが宙に浮いてしまいます。判断基準の立て方と、スケールアップ時の留意点を整理します。
定量・定性の両面から見る成功判断基準
スケールアップの判断は、あらかじめ定めた基準に照らして機械的に判定できる状態にしておくのが理想です。感覚的な評価に頼ると、判断が人によってぶれやすくなります。PoCの成功可否は、定量面と定性面の両方から評価するのが望ましいでしょう。
定量面では、事前に設定した目的（ツールの解析網羅率、1トランザクションあたりの解析工数、レビューに要したヒアリング回数など）が、許容できる範囲に収まっているかを確認します。定性面では、実際に作業した技術者が業務ロジックをどの程度スムーズに理解できたか、業務有識者との意思疎通が円滑だったかなど、数値化しにくいが本格展開の成否を左右する要素を評価します。
この両面を突き合わせて、「このアプローチ・この体制であれば全量解析を進められる」と判断できるかどうかが、スケールアップの分岐点になります。また、PoCを実施したベンダー自身による自己評価だけに頼らず、発注者側の情報システム部門や業務部門を交えて第三者的な視点でレビューすると、判断の客観性を保ちやすくなります。
本格展開時の計画修正とアプローチの見直し
PoCの結果、当初のアプローチでは本格展開が難しいと分かった場合は、当初計画を無理に押し通すよりも、アプローチを見直すべきです。たとえば、想定したツールで解析網羅率が不十分なら、別のツールとの併用や、対象範囲に応じたオーダーメイドのスクリプト開発を検討します。この点は、姉妹記事「PL/Iのリバースエンジニアリングのフルスクラッチ・オーダーメイド開発について」で詳しく扱っています。
逆に、PoCの結果が良好だった場合も、PoC規模から全量規模へ広げると、単純な比例計算では見積もれない工数増（拠点間・システム間の連携解析など）が生じることがあります。そのため、PoCの結果を直線的に延ばすだけでなく、規模拡大に伴う追加要因を織り込んで計画を練り直すことが求められます。
特に、PoCで対象とした一部のモジュールでは問題にならなかった業務ロジックの重複や相互依存が、対象範囲を広げるにつれて次々と表面化することは珍しくありません。そこで、本格展開のスケジュールには、規模拡大に伴う想定外の発見に対応するためのバッファをあらかじめ組み込んでおくことをお勧めします。
まとめ
ここまで、全量解析ではなくPoCから始める理由、PoCの進め方、検証すべき技術的ポイント、成功判断基準とスケールアップの判断を解説しました。
PL/Iの解析には、ツール対応やミドルウェア連携、人材確保といった着手前には見積もりきれない不確実性が多くあります。そのため、小規模なPoCで前提を検証し、リスクを前倒しで発見しておくことが、結果として最も確実で費用対効果の高い進め方になります。
代表性のあるモジュールを選び、定量と定性の両面から明確な目的を設定し、その結果を客観的に評価するという一連の流れを丁寧に踏めば、限られた予算でも着実に本格展開への道筋を描けます。
PoCで得られる知見は、金額にすると小さく見えても、その後の本格展開での手戻りを防ぐという意味で、プロジェクト全体の成否を左右する重要な投資です。
特に、PoCを外部パートナーに依頼する場合は、その実施経験が後の本格展開の提案にも生きます。単なるお試し発注ではなく、長期的なパートナー選定の一環としてPoCの依頼先を検討することをお勧めします。
自社のPL/I基幹システムでどのようなPoCが適切か判断に迷う場合は、金融・保険業界の基幹システムにおけるPL/I解析、CICS・IMS連携の調査実績が豊富なパートナーに、PoCの設計段階から相談するとよいでしょう。
▼全体ガイドの記事
・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を創業。