PL/I のリバースエンジニアリングは、発注前の準備から RFP による依頼、契約、プロジェクト中の役割分担まで、順を追って進めます。
PL/I は IBM メインフレーム上で動くため、準備が足りないと依頼が曖昧になり、見積もりのブレや追加費用を招きます。
- 現行資産と発注目的の整理：解析対象の範囲と、何を成果物として受け取るかを決める
- RFP・提案比較・ベンダー選定：PL/I 固有の項目を入れた RFP で提案を比べる
- NDA・契約・クリーンルーム条項：ソースコードの秘密保持と、解析と開発の人員分離を定める
- 業務部門とIT部門の役割分担：業務ロジックの確認と、ベンダーとの技術的な窓口を分ける
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
外注前に発注側が準備すべき項目
外注前の準備が足りないと、見積もりの精度が下がります。その結果、プロジェクトの途中でスコープが変わったり、追加費用が生じたりします。
事前に準備を整えておけば、ベンダーに渡せる情報が充実し、正確な見積もりと円滑な進行につながります。
対象システム・ソース資産の棚卸
解析に入る前に、解析対象となる PL/I プログラム資産の全体量を把握します。次の項目を集めて、「システム資産台帳」としてまとめておきます。
- ソースプログラム：ファイル数と総行数（LOC）
- JCL：ジョブ定義の一覧
- VSAM ファイル：カタログ情報
- ミドルウェアの定義：IMS/DB の DBD・PSB、CICS のトランザクション定義
IMS/DB の DBD（データベース定義）と PSB（プログラム仕様ブロック）の有無、CICS のトランザクション定義（DFHCSDUP 出力）も確認します。
台帳にまとめておくと、ベンダーは見積もりの根拠となる規模感を正確につかめます。
ソースについては、次の2点を発注前に確認しておきます。
- 版の管理：最新版の保存場所、複数版の混在の有無
- ソースと本番の一致：本番のロードモジュールとソースが食い違っていないか
一致の確認は、解析の信頼性に直結します。
パッチが反映されていないソースが資産として管理されていた例もあります。そのため、発注前に必ず確認してください。
目的と成果物要件の明確化
「なぜ PL/I のリバースエンジニアリングを行うのか」という目的と、「何を成果物として受け取るのか」を具体的に決めておくことが欠かせません。
成果物要件が曖昧なまま発注すると、「ベンダーは言われたとおりに作ったつもりでも、発注側が期待していたものとは違った」というトラブルが高い確率で起きます。
受け取るべき成果物の中身は、最初に決めた目的によって変わります。目的ごとの必要な水準は、次の2通りです。
- モダナイゼーション計画の策定：システム全体の処理概要と主要モジュール間のデータフローを把握する、フローチャートレベルが適切
- 新システムへの要件定義・設計：業務仕様書（各業務処理の目的・入出力・判断条件・業務ルールの根拠）が必要
成果物要件は、具体的な項目で書き出します。たとえば、変数名の意味と役割の説明や、業務ロジックへの日本語の業務コメントを含めます。加えて、JCL と PL/I プログラムの対応関係図、IMS/DB のセグメント定義と使用箇所のマッピングも必要です。
業務部門の巻き込み体制
PL/I のリバースエンジニアリングでは、業務部門の協力が欠かせません。
コードから「How（何をしているか）」は解析できても、「Why（なぜその仕様か）」は業務知識を持つ担当者がいないと正確に把握できないためです。
特に PL/I システムは保険・金融・官公庁の業務に密接に関わっています。そのため、コードだけでは判断できない背景が多く含まれており、主に次のようなものがあります。
- 法規制：法令に合わせて組まれたロジック
- 特定顧客：特定の顧客向けに設けられた特例処理
- 過去の障害対応：障害対応で追加された暫定ロジック
業務部門を巻き込むうえで最低限確保したいのは、「業務照会に応答できる担当者の週次対応枠（2 時間以上）」と「中間成果物のレビュー参加（月 1〜2 回）」です。業務繁忙を理由にこれが確保できないと、成果物の精度が大幅に下がります。
プロジェクト開始前に内部調整を行い、IT 部門長と業務部門長の間で「業務部門の協力体制」を正式に合意しておくことを強くお勧めします。
発注の進め方（RFP作成〜契約）
準備が整ったら、RFP を作成してベンダーを選び、提案を評価したうえで、NDA を結んでから契約に進みます。
PL/I のリバースエンジニアリングには、一般的な IT 発注と異なる注意点が複数あります。そのため、各ステップで確認したい事項を順に解説します。
RFPに含めるべきPL/I固有の項目
RFP には、通常の IT 調達 RFP に加えて PL/I 固有の項目を入れることが不可欠です。次の5項目を盛り込み、ベンダーの回答を求めます。
- 対象ソースコードの概要：IBM PL/I for z/OS のバージョン、ソースファイル数、推定総 LOC
- 実行環境の概要：メインフレームの機種（IBM Z シリーズ等）、JCL の複雑度、使用ミドルウェア
- PL/I 固有技術への対応要件：BASED 変数とポインタ操作の解析実績、AREA 属性の使用箇所への対応、アセンブラ混在コードへの対処方針
- 成果物要件の詳細：前述の成果物定義（業務コメント付記・データフロー図・ミドルウェア連携マッピング等）を示し、対応可否と対応コストを確認
- 情報管理・セキュリティ要件：解析環境のネットワーク分離、担当者の身元確認、成果物の持ち出し制限
併せて、コンパイルオプションの傾向（EBCDIC 文字コード、最適化レベルなど）も記載します。使用ミドルウェアは、IMS/DB のバージョン、VSAM の使用形態、CICS のバージョンです。
保険・金融・官公庁のデータを扱う法的責任は発注側にあるため、RFP 段階から明確にしておく必要があります。
NDA・クリーンルーム手法の契約条項
PL/I のリバースエンジニアリングでは、ベンダーが依頼企業の基幹システムのソースコードにアクセスするため、NDA（秘密保持契約）は必須です。
NDA では、次の3点を盛り込みます。
- 著作権の帰属：解析対象プログラムの著作権が依頼企業または元の開発会社に帰属することを確認
- 開示の禁止：取得したソースコード・成果物を第三者へ開示しないことを定める
- データ消去と損害賠償：プロジェクト終了後のデータ消去義務と、違反時の損害賠償条項を標準として含める
クリーンルーム手法を採用する場合は、契約書に、解析チーム（Dirty Room）と開発チーム（Clean Room）の人員分離を明記します。仲介担当者による仕様書フィルタリングや、解析で得た情報の伝達方法の制限も明文化します。これにより、著作権侵害のリスクを契約上も排除できます。
ベンダーによっては「クリーンルーム対応可能」と言いながら、実際の運用が不明確なケースがあります。そのため、「クリーンルーム手法の運用規程または社内マニュアルの提出」を契約前に求めることを推奨します。
プロジェクト推進時の役割分担（業務部門×IT部門×ベンダー）
PL/I のリバースエンジニアリングプロジェクトを成功させるには、業務部門・IT 部門・ベンダーの役割を明確に定め、相互の連携の進め方を事前に決めておくことが重要です。
役割が曖昧なまま進むと、「その質問はどちらが答えるのか」という混乱が生じ、意思決定が遅れてプロジェクトが停滞します。
業務部門の役割と責務
業務部門は、業務ロジックの真の意味を知る唯一の存在として、中心的な役割を担います。解析の結果が業務の実態からずれないよう、場面ごとに関わります。
- 業務照会への回答：ベンダーから提出された業務質問リストへの週次の回答
- 中間成果物のレビューと承認：フローチャートや業務仕様書の業務上の正確性の確認
- 不要・廃止可能な機能の特定：解析対象を絞り込むためのスコープ判断
業務部門が担うべきでないのは、「技術的な解析方法の指示」と「ベンダーとの技術的なコミュニケーション窓口」です。これらは IT 部門が一元的に担うべきものです。業務部門が直接ベンダーと技術的なやり取りをすると、業務部門の工数が過大になったり、技術的に誤った前提に基づく業務説明が行われたりするおそれがあります。
IT部門の役割と責務
IT 部門は、プロジェクト全体のコントロールタワーとして機能します。ベンダーと業務部門の両方と接する立場から、全体を見て進め方を整えます。
- ベンダーとの技術的な窓口：技術面のやり取りを一本化する
- 資産情報の安全な提供：ソースコードや設定ファイルを、セキュリティ管理を含めて渡す
- 進捗管理と品質確認：プロジェクトの進み具合と成果物の品質を見る
- 業務部門との調整・連携：業務部門の協力を取り付け、段取りを整える
- 予算・スケジュール管理：費用と期間を計画どおりに保つ
特に「ベンダーからの技術的な質問を業務部門が理解できる言葉に翻訳して伝え、業務部門の回答を技術的な文脈で解釈してベンダーに伝える」というトランスレーター機能は、IT 部門にしか担えない役割です。
IT 部門の担当者にも、一定レベルの PL/I とメインフレーム環境の知識が求められます。最低限、「JCL の基本的な読み方」「IMS/DB のセグメント構造の理解」「CICS トランザクションの概念理解」程度の知識がないと、ベンダーの技術的な説明を正確に理解できず、適切な意思決定も難しくなります。
スキルが不足している場合は、社内の OJT や外部研修を利用した事前学習か、PL/I に詳しい技術顧問のアサインを検討してください。
よくあるトラブルと回避策
PL/I のリバースエンジニアリングでは、実際に起きるトラブルにいくつかのパターンがあります。事前に把握しておくと、プロジェクトの開始前から予防策を講じられます。
LOC見積もりの齟齬と保守性の問題
最も多いトラブルの一つが「LOC 見積もりの齟齬」です。事前に提示した LOC 数より実際の解析量が多く、プロジェクト中盤で追加費用を請求されるケースがあります。原因は、コメントを除いた有効コードの定義が違っていたことや、アセンブラ混在コードを LOC に数えるかが未定義だったことなどです。
回避策は、契約書の定めと事前の実測に分けて考えられます。
- LOC のカウント方法：契約書で有効コード行の定義を取り決める
- 超過時の対応：契約書で、LOC が見積もり時の数値を 10% 以上超過する場合は事前協議を行うと定める
- プレ解析による実測：サンプル解析で有効 LOC を測っておく
保守性の問題は、業務仕様書の品質が発注側の期待に届かないケースです。「業務ルールの背景が書かれていない」「変数名の説明がなく、新システム開発チームが理解できない」といった問題が起きます。
これを防ぐには、業務処理ごとの業務コメント、BASED 変数の役割の日本語説明、JCL と PL/I の対応関係図を品質基準として RFP と契約書に明文化し、中間成果物のレビューで確認します。
業務ルール欠損と「Why」不明問題
PL/I リバースエンジニアリングで特に深刻なトラブルは、業務ルールの欠損です。コードから「How（どう動くか）」は解析できても、「Why（なぜその計算をするのか、なぜこの条件分岐があるのか）」が分からないまま仕様書が作られ、新システム移行後に障害が多発するケースがあります。
これは業務部門の協力が不十分な場合に起きやすく、前述のとおり、業務部門の関与を契約・体制面から確保することが根本的な対策です。それでも「Why」が解明できない部分が残る場合は、「業務ロジック不明箇所リスト」を成果物の一つとして納品させ、発注側の内部で追加調査を行う方針を明確にしておきます。
不明箇所を曖昧なまま放置した成果物を「完成品」として受け取ると、新システム開発での手戻りコストとなって後から返ってきます。そのため、最終成果物の受け入れ基準に「不明箇所のリストアップが完了しており、各項目に対する業務部門のコメントが付記されている」ことを設定しておくことを推奨します。
「PL/I対応可」を謳うが実態が伴わないベンダー
PL/I 対応を謳いながら、実際には COBOL 中心の実績しかなく、BASED 変数・AREA 属性・ON 条件への対応経験がないベンダーに発注してしまうトラブルも報告されています。
特に「メインフレームモダナイゼーション対応」という表現は、広い意味を持ちます。JCL の書き換えや COBOL から Java への変換を指す場合が多く、「PL/I ソースコードの業務仕様復元」は全く別の専門性です。
発注前に、「担当予定技術者の PL/I 実務年数」と「BASED 変数を含む PL/I プログラムの解析実績の具体例」を必ず確認してください。回答が具体性を欠く場合は、別のベンダーを選ぶ方がよいでしょう。
まとめ
PL/I のリバースエンジニアリングを成功させる発注のポイントは、「準備」「RFP」「体制」「契約」の 4 つの段階を丁寧に積み重ねることです。
発注前の 3 つの準備（ソース資産の棚卸、目的と成果物要件の明確化、業務部門の巻き込み体制の確保）が整って初めて、ベンダーから精度の高い見積もりと提案を引き出せます。
RFP には PL/I 固有の技術要件（BASED 変数・ポインタ対応・ミドルウェア連携解析）とセキュリティ要件を明記します。さらに NDA とクリーンルーム手法の契約条項を徹底して、法的リスクを排除します。
プロジェクト推進時は、業務部門・IT 部門・ベンダーの役割を明確に分け、「業務ロジックの Why を業務部門が補完する」というプロセスを標準として設計してください。
LOC 見積もりの定義と成果物の品質基準を契約書に明文化し、不明箇所の扱いや業務部門の協力体制も決めておくことが、後のトラブルを防ぐ最善の手段です。
PL/I 対応のベンダーが少ない市場だからこそ、発注側の準備と知識が成否を分ける最大の要因になります。
全体ガイドの記事として、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を創業。