PL/I のリバースエンジニアリングを外注しようとする際、多くの担当者が最初につまずくのは「どんな情報を準備すればいいのか分からない」という問題です。一般的な Web システム開発とは異なり、IBM メインフレーム上で動く PL/I プログラムの特性を理解していないと、RFP（提案依頼書）に何を書けばいいかすら分からず、ベンダーに曖昧な依頼をしてしまうことになります。その結果、見積もりに大きなブレが生じ、プロジェクト開始後に追加費用が発生するトラブルが頻発します。

本記事では、PL/I のリバースエンジニアリングを発注・外注・委託する際に発注側が準備すべき 5 項目から、RFP 作成・NDA 締結・契約の流れ、プロジェクト推進時の役割分担、そしてよくあるトラブルと回避策まで、実務的なノウハウを網羅的にお伝えします。初めての PL/I リバースエンジニアリング発注を成功させるための実践ガイドとしてお使いください。

▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド

外注前に発注側が準備すべき5項目

PL/I リバースエンジニアリングを外注する前に、発注側が準備を怠ると、見積もりの精度が低下し、プロジェクト途中でのスコープ変更や追加費用の温床になります。以下の 5 項目を事前に整備することで、ベンダーへの情報提供が充実し、より正確な見積もりと円滑なプロジェクト推進が実現します。

最初に行うべきは、解析対象となる PL/I プログラム資産の全量把握です。具体的には、PL/I ソースプログラムのファイル数・総行数（LOC）のカウント、JCL ジョブ定義の一覧、IMS/DB の DBD（データベース定義）と PSB（プログラム仕様ブロック）の存在確認、VSAM ファイルのカタログ情報、CICS のトランザクション定義（DFHCSDUP 出力）の収集が含まれます。これらを「システム資産台帳」としてリスト化することで、ベンダーが見積もりの根拠となる規模感を正確に把握できるようになります。

さらに、ソースコードのバージョン管理状況（最新版がどこに保存されているか、複数バージョンが混在していないか）も確認が必要です。長年稼働してきた PL/I システムでは、本番環境のロードモジュールとソースコードが乖離していたり、「本番に当たっているパッチが反映されていないソースが資産として管理されていた」という事態が起きていることがあります。ソースと本番バイナリの一致確認は、解析の信頼性に直結するため、発注前に必ず確認してください。

「なぜ PL/I のリバースエンジニアリングを実施するか」という目的と、「何を成果物として受け取るか」を具体的に定義することが不可欠です。目的が「モダナイゼーション計画の策定」であれば、システム全体の処理概要と主要モジュール間のデータフロー把握を目標とするフローチャートレベルが適切です。目的が「新システムへの要件定義・設計」であれば、業務仕様書（各業務処理の目的・入出力・判断条件・業務ルールの根拠）が必要になります。

成果物要件には「変数名の意味と役割の説明を含む」「業務ロジックに対する業務コメントを日本語で付記する」「JCL と PL/I プログラムの対応関係図を含む」「IMS/DB のセグメント定義と PL/I での使用箇所のマッピングを含む」など、具体的な項目を列挙してください。この成果物要件が曖昧なまま発注されると、「ベンダーは正直に言うと言われた通りのものを作ったつもりだが、発注側が期待していたものとは違った」というトラブルが高確率で発生します。

PL/I のリバースエンジニアリングにおいて、業務部門の協力は必須です。コードから「How（何をしているか）」は解析できますが、「Why（なぜその仕様か）」は業務知識を持つ担当者なしには正確に把握できません。特に PL/I システムは保険・金融・官公庁の業務に密接に関わっており、法規制への対応、特定顧客への特例処理、過去の障害対応で追加された暫定ロジックなど、コードだけでは判断不能な背景が多く含まれています。

業務部門の巻き込みで最低限確保すべきは「業務照会に応答できる担当者の週次対応枠（2 時間以上）」と「中間成果物のレビュー参加（月 1〜2 回）」です。担当者の業務繁忙を理由にこれが確保できない場合、リバースエンジニアリングの成果物の精度が大幅に低下します。プロジェクト開始前に、IT 部門長と業務部門長の間で「業務部門の協力体制」を正式に合意するための内部調整を先行して行っておくことを強くお勧めします。

発注の進め方（RFP作成〜契約）

準備が整ったら、実際の発注プロセス（RFP 作成→ベンダー選定→提案評価→NDA→契約）を順を追って進めます。PL/I リバースエンジニアリングでは一般的な IT 発注と異なる注意点が複数あるため、各ステップでの確認事項を解説します。

PL/I リバースエンジニアリングの RFP には、通常の IT 調達 RFP に加えて以下の PL/I 固有項目を含めることが不可欠です。第一に「対象ソースコードの概要」として、PL/I のバージョン（IBM PL/I for z/OS のバージョン）・ソースファイル数・推定総 LOC・コンパイルオプションの傾向（EBCDIC 文字コード、最適化レベルなど）を記載します。第二に「実行環境の概要」として、使用しているメインフレーム機種（IBM Z シリーズ等）・JCL の複雑度・使用ミドルウェア（IMS/DB のバージョン・VSAM の使用形態・CICS のバージョン）を明記します。

第三に「PL/I 固有技術への対応要件」として、BASED 変数とポインタ操作の解析実績・AREA 属性の使用箇所対応・アセンブラ混在コードへの対処方針を回答させます。第四に「成果物要件の詳細」として、上述の成果物定義（業務コメント付記・データフロー図・ミドルウェア連携マッピング等）を提示し、ベンダーの対応可否と対応コストを確認します。第五に「情報管理・セキュリティ要件」として、解析環境のネットワーク分離要件・担当者の身元確認・成果物のデータ持ち出し制限を明記してください。PL/I システムが扱う保険・金融・官公庁データのセキュリティ保護は、発注側の法的責任として RFP 段階から明確にしておく必要があります。

PL/I のリバースエンジニアリングでは、ベンダーが依頼企業の基幹システムのソースコードにアクセスすることになるため、NDA（秘密保持契約）は必須です。NDA には「解析対象プログラムの著作権が依頼企業または元の開発会社に帰属することの確認」「取得したソースコード・成果物の第三者への開示禁止」「プロジェクト終了後のデータ消去義務」「違反時の損害賠償条項」を含めることを標準としてください。

クリーンルーム手法を採用する場合は、契約書に「解析チーム（Dirty Room）と開発チーム（Clean Room）の人員分離」「仲介担当者による仕様書フィルタリングプロセス」「解析で得た情報の開発チームへの伝達方法の制限」を明文化することで、著作権侵害リスクを契約上も排除できます。ベンダーによっては「クリーンルーム対応可能」と言いながら実際の運用が不明確なケースがあるため、「クリーンルーム手法の運用規程または社内マニュアルの提出」を契約前に求めることを推奨します。

プロジェクト推進時の役割分担（業務部門×IT部門×ベンダー）

PL/I のリバースエンジニアリングプロジェクトを成功させるためには、業務部門・IT 部門・ベンダーの 3 者の役割を明確に定義し、相互の連携プロセスを事前に設計することが重要です。役割が曖昧なまま進むと、「その質問はどちらが答えるのか」という混乱が生じ、意思決定が遅れてプロジェクトが停滞します。

業務部門は、PL/I リバースエンジニアリングプロジェクトにおいて「業務ロジックの真の意味を知る唯一の存在」として中心的な役割を担います。具体的な責務は「業務照会への回答（ベンダーから提出された業務質問リストに対し週次で回答する）」「中間成果物のレビューと承認（フローチャートや業務仕様書の業務上の正確性を確認する）」「業務的に不要・廃止可能な機能の特定（解析対象を絞り込むためのスコープ判断を行う）」の 3 点です。

業務部門が担うべきでないのは、「技術的な解析方法の指示」や「ベンダーとの技術的なコミュニケーション窓口」です。これらは IT 部門が一元的に担うべきものであり、業務部門が直接ベンダーと技術的なやり取りをすることで、業務部門の工数が過大になったり、技術的に誤った前提に基づいた業務説明が行われたりするリスクがあります。

IT 部門はプロジェクト全体の「コントロールタワー」として機能します。ベンダーとの技術的なコミュニケーション窓口、ソースコードや設定ファイルなど資産情報のベンダーへの安全な提供（セキュリティ管理含む）、プロジェクトの進捗管理と品質確認、業務部門との調整・連携、そして予算・スケジュール管理が IT 部門の主要な責務です。特に「ベンダーからの技術的な質問を業務部門が理解できる言葉に翻訳して伝え、業務部門の回答を技術的な文脈で解釈してベンダーに伝える」というトランスレーター機能は、IT 部門にしか担えない役割です。

PL/I のリバースエンジニアリングでは、IT 部門の担当者にも一定レベルの PL/I とメインフレーム環境の知識が求められます。「JCL の基本的な読み方」「IMS/DB のセグメント構造の理解」「CICS トランザクションの概念理解」程度の知識がないと、ベンダーの技術的な説明を正確に理解し、適切な意思決定を行うことが困難です。IT 部門担当者のスキルが不足している場合は、社内の OJT や外部研修を利用した事前学習か、PL/I に詳しい技術顧問のアサインを検討してください。

よくあるトラブルと回避策

PL/I のリバースエンジニアリングプロジェクトで実際に発生するトラブルには一定のパターンがあります。これらを事前に把握しておくことで、プロジェクト開始前から予防策を講じることができます。

最も多いトラブルの一つが「LOC 見積もりの齟齬」です。事前に提示した LOC 数よりも実際の解析量が多かった（コメントを除いた有効コードの定義が違った、アセンブラ混在コードを LOC にカウントするかが未定義だった等）ことを理由に、プロジェクト中盤で追加費用が請求されるケースがあります。回避策として、契約書に「LOC のカウント方法（有効コード行の定義）」と「LOC が見積もり時の数値を 10% 以上超過する場合は事前協議を行う」という条項を明記してください。また、プレ解析（サンプル解析）を活用して、有効 LOC のカウントをプロジェクト開始前に実測することも有効です。

保守性の問題は、成果物として納品された業務仕様書の品質が発注側の期待に達していないケースです。「技術的なフローは書いてあるが、業務ルールの背景が全く書かれていない」「変数名の説明がなく、新システム開発チームが理解できない」という問題が起きることがあります。これを防ぐには、成果物の品質基準（「各業務処理に業務コメントを必ず付記する」「BASED 変数の役割を日本語で説明する」「JCL と PL/I の対応関係図を含む」）を RFP と契約書に明文化し、中間成果物のレビューポイントで品質確認を実施することが重要です。

PL/I リバースエンジニアリングで特に深刻なトラブルは「業務ルールの欠損」です。コードから「How（どう動くか）」は解析できても、「Why（なぜその計算をするのか、なぜこの条件分岐があるのか）」が分からないまま仕様書が作成され、新システム移行後に障害が多発するケースがあります。これは業務部門の協力が不十分な場合に起きることが多く、前述の通り業務部門の関与を契約・体制面から確保することが根本的な対策です。