PL/Iのリバースエンジニアリングとは、汎用機(メインフレーム)上で稼働するPL/I言語製の基幹システムを対象に、ソースコードやジョブ制御言語(JCL)、データベース定義といった現存する資産を解析し、失われた・あるいは実態と乖離した設計書・仕様書をシステムの内部構造から逆算的に復元する調査工程です。総論記事「リバースエンジニアリング」が対象言語を問わない解析手法全般を扱い、「COBOLのリバースエンジニアリング」等の言語別記事群がそれぞれの技術的特性を扱うのに対し、本記事群が扱うPL/Iは、銀行・保険会社の勘定系・契約管理系システムに代表される金融・保険業界の基幹システムで採用例が多く、CICS(トランザクション処理モニタ)やIMS(階層型データベース・トランザクション管理システム)といったIBM系ミドルウェアと密結合しているケースが極めて多いという固有の特徴を持ちます。長年にわたって業務を支えてきたこれらの基幹システムは、改修の積み重ねによって当初の設計思想から大きく変容していることも多く、現時点でのコストを正確に見積もるためには、まず現状を正しく理解するという工程そのものにも相応の投資が必要になります。加えて、PL/Iを扱えるエンジニアはCOBOL技術者よりもさらに希少であり、この人材の希少性は解析の難易度だけでなく、コスト構造そのものにも直接的な影響を及ぼします。予算を握るIT部門・経営層にとって、この人材市場の実情を理解しておくことは、適正な見積もりかどうかを判断するうえでの重要な前提知識になります。
本記事では、PL/Iのリバースエンジニアリングにおける保守・運用費用・ランニングコストに焦点を当てます。開発期間・スケジュールを扱う姉妹記事とは異なり、「解析作業そのものにいくらかかるのか」「解析結果を維持・更新し続けるための費用はどう発生するのか」「PL/I人材の希少性はコストにどう跳ね返るのか」という、予算計画の立案段階で必ず直面する疑問に答えることを目的としています。解析フェーズの費用内訳だけでなく、CICS・IMSを含めた運用コスト構造や、コストを抑えるための実務的な工夫まで踏み込んで整理します。予算担当者やIT部門の責任者が、経営層に対して投資対効果を説明する際に使える判断材料を提供することも、本記事の狙いの一つです。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド
PL/Iリバースエンジニアリングにおける保守・運用費用の全体像
PL/Iリバースエンジニアリングの「保守・運用費用」という言葉は、一般的なシステム開発でイメージされる保守費用とは少し性質が異なります。新規開発したアプリケーションの保守費用が、稼働後のバグ修正や機能改善を指すのに対し、ここで扱うべき費用は、既存システムを「理解し直す」ための調査コストと、その理解を維持し続けるためのコストという、性質の異なる2つの側面に分かれます。この切り分けを最初に理解しておくことが、予算計画を立てるうえでの出発点になります。
「解析作業自体の費用」と「解析結果を活かす保守運用の費用」という2つの側面
1つ目は、リバースエンジニアリングという調査プロジェクトそのものにかかる費用です。技術者の人件費、必要に応じた解析ツールの導入費、成果物としての仕様書・設計書の作成費用などが含まれます。2つ目は、その解析結果を、その後の現行システムの保守・運用にどう活かし、維持し続けるかという費用です。せっかく作成した仕様書も、現行システムの改修が続く限り放置すれば数年で実態と乖離してしまうため、更新し続けるための継続的な費用が発生します。多くの企業がリバースエンジニアリングを「一度きりの調査プロジェクト」と捉えて1つ目の費用だけを予算化しがちですが、本当に費用対効果を得るには、2つ目の「資産として維持し続けるコスト」まで見据えた予算設計が欠かせません。この2つを混同したまま予算化してしまうと、初年度の解析費用は確保できても、翌年度以降の仕様書更新・維持のための予算枠が用意されておらず、結局は数年で最初の状態に逆戻りしてしまうという失敗パターンに陥りがちです。予算化の段階から、単年度の調査費用と、複数年にわたる維持費用を別立てで管理しておくことをお勧めします。
COBOL等の他言語版との違い（ツール自動化の余地が小さく人件費比率が高い）
「COBOLのリバースエンジニアリング」では、市場に流通する解析・自動変換ツールの選択肢が比較的豊富で、ツール導入によって人件費を一定程度抑えられる余地があります。これに対してPL/Iは、市販ツールのPL/I構文対応が部分的・非対応であるケースが多いため、解析作業の多くを人手に頼らざるを得ず、コスト構造全体に占める人件費の比率がCOBOLよりも高くなる傾向があります。さらに、その人手自体がPL/I技術者という希少な人材であるため、同じ工数であってもCOBOL案件より単価が高くなりやすく、結果としてトータルコストが割高になりやすいという構造的な特徴を持ちます。この点を予算計画の段階で織り込んでおかないと、他言語の解析事例をそのまま参考にした見積もりでは大きく実態と乖離してしまうため注意が必要です。社内でCOBOL案件の予算実績があり、それを参考にPL/I案件の予算を策定しようとするケースも見られますが、上記の構造的な違いを考慮せずに単純に流用すると、予算不足に陥る可能性が高い点にも注意が必要です。
解析・仕様書化フェーズの費用内訳
解析プロジェクトそのものの費用は、いくつかの工程に分解して考えると見積もりの精度が高まります。ここでは、費用の中心を占める要素を整理します。
技術者の人件費（解析・仕様書化・レビューの各工程）
解析プロジェクトの費用の大半を占めるのが、技術者の人件費です。静的解析を担うエンジニア、その結果を業務目線の仕様書に落とし込むエンジニア、そして業務有識者(SME)を交えたレビューを担当するメンバーと、フェーズごとに求められるスキルセットが異なるため、単純に「エンジニア何人月」という粗い見積もりではなく、フェーズごとの必要人数と工数を分けて積算することが望ましいでしょう。特にPL/Iの案件では、解析担当者とレビュー担当者を分業できるほど人材の層が厚くないケースも多く、限られた少数の技術者が複数フェーズを掛け持ちすることになりがちです。この場合、見積もり時点で「フェーズを並行して進められるのか、直列にせざるを得ないのか」を確認しておくことが、費用だけでなく期間の見積もり精度にも影響します。また、発注者側の業務担当者がヒアリングやレビューに割く時間も、直接的な支出ではないものの実質的なコストとして無視できません。ベンダー側の見積もりに含まれる工数だけでなく、自社側の関係者がどの程度の時間を拠出することになるのかも、あわせて把握しておくと、プロジェクト全体としての実質的な負担を正確に見積もれます。
解析ツール・環境準備の費用
解析作業を効率化するためのツール導入費用も、内訳の一部として計上する必要があります。汎用の静的解析ツールを利用する場合はそのライセンス費用、PL/I構文への対応が不十分で独自のスクリプト・簡易パーサーを用意する場合はその開発費用が発生します。加えて、メインフレーム環境から解析対象のソースコードやデータ定義を安全に外部へ抽出するための連携環境の準備、セキュリティ要件を満たすための作業環境の構築費用も見落とされがちなコスト要素です。特に金融・保険業界の基幹システムは情報セキュリティ要件が厳しく、社外の解析環境へデータを持ち出せない、あるいは持ち出しに厳格な承認プロセスが必要になるケースも多いため、こうした環境準備にかかる時間的・金銭的コストを、着手前の見積もり段階から織り込んでおくことが重要です。社内のセキュアな環境内で作業を完結させる「オンサイト常駐型」の体制を取る場合は、リモートで作業する場合に比べて技術者の稼働単価や交通費・宿泊費といった実費が上乗せされることもあるため、体制の選び方自体もコストを左右する重要な変数として検討する必要があります。
PL/I人材の希少性がコスト構造に与える影響
PL/I人材の希少性は、単に「見つかりにくい」という採用上の課題にとどまらず、コスト構造そのものを押し上げる要因として作用します。この影響を具体的に見ていきます。
技術者単価の上昇と確保のための追加コスト
PL/I人材の希少性は、単発の解析プロジェクトの見積もりだけでなく、複数年にわたる保守運用の予算計画そのものにも影響を及ぼします。以下では、具体的にどのようなかたちでコストに反映されるのかを見ていきます。需要と供給のバランスから見て、PL/Iを実務レベルで扱える技術者の市場単価は、一般的なWeb系言語やCOBOLの技術者と比べても高水準になりやすい傾向があります。加えて、特定の業界(金融・保険)の業務知識まで併せ持つ人材となると対象者はさらに絞られるため、遠方からの参画や、稼働時間・体制に関する柔軟な調整を前提とした契約になることも珍しくなく、これらが間接的なコスト増要因として積み上がっていきます。自社にPL/I経験者が在籍している場合でも、その人材を解析プロジェクトに専任させることで通常業務への影響が生じるため、代替要員の確保コストや、機会損失というかたちで見えにくいコストが発生している点も見落とせません。さらに、案件によっては候補となる技術者が既に他のプロジェクトで稼働しており、契約締結からアサインまでに数ヶ月単位の待機期間が発生することもあります。こうした「見つかっても、すぐには稼働できない」という制約自体が、間接的にプロジェクト開始の遅延コストとして跳ね返ってくる点も、PL/I案件特有の事情として押さえておく必要があります。
知見の喪失による将来コストの増大リスク
PL/I技術者の高齢化・退職が進むほど、システムの背景知識を持つ人材そのものが失われていきます。今、多少コストをかけてでもリバースエンジニアリングを実施し、仕様を文書化しておかなければ、数年後には「解析すること自体が不可能」という状態に陥るリスクが高まります。仕様書化のタイミングが遅れるほど、有識者へのヒアリングが難しくなり、結果としてより多くの時間と費用をかけても正確な復元ができなくなるという悪循環に陥りかねません。この意味で、PL/Iリバースエンジニアリングの費用は「今かけるコスト」と「先送りした場合に将来かかるであろうコスト」を比較したうえで検討すべきものであり、単純な初期費用の多寡だけで判断するべきではありません。実際、社内で唯一システム全体を把握していた技術者が退職した後になって初めて解析プロジェクトに着手し、有識者不在のまま推測に頼らざるを得なくなった結果、想定を大幅に超える工数と費用がかかってしまうという事態は、レガシー言語の解析案件で繰り返し見られるパターンです。予算の確保が難しいという理由で着手を先送りにする判断そのものが、将来的にはより大きなコスト負担というかたちで返ってくる可能性が高いことを、経営層を含めた予算承認プロセスの中であらかじめ共有しておくことが望ましいでしょう。
CICS/IMS込みの運用コスト構造とコスト最適化の実務
PL/Iプログラム単体の解析費用だけでなく、CICS・IMSといったミドルウェアを含めた運用コスト構造まで視野に入れることで、より実態に即した予算計画が立てられます。ミドルウェアを含めた解析は、PL/Iのソースコードだけを見ていては気づけない追加コストを生む一方、その分だけ精度の高い仕様復元につながるという側面もあります。あわせて、コストを抑えるための実務的なアプローチも確認しておきましょう。
ミドルウェア連携解析を含めた運用コストの全体像
CICS・IMSを含む解析では、PL/Iの解析要員に加えて、これらのミドルウェアに精通した技術者の関与が必要になることが多く、その分の人件費が上乗せされます。また、解析結果として作成した仕様書には、トランザクション定義やデータベース定義の変更履歴を継続的に反映していく必要があり、これを怠ると数年でまた実態と乖離してしまいます。つまり、PL/Iリバースエンジニアリングの運用コストは、解析対象のソースコードだけでなく、その周辺のミドルウェア定義まで含めた「仕様資産全体の維持コスト」として捉える必要があります。この維持コストを継続的な保守契約の一部として組み込んでおくことで、将来再び大規模な解析プロジェクトを一からやり直す事態を防ぎやすくなります。特に、CICSのトランザクション定義とIMSのデータベース定義は、PL/Iのソースコードとは別のリポジトリ・別の管理者のもとで管理されているケースも多く、両者を突き合わせて整合性を確認する作業自体に一定の工数がかかります。この突き合わせ作業を年次・半期ごとの定例タスクとして保守契約に組み込んでおくと、乖離が小さいうちに継続的に是正でき、数年に一度の大規模な再解析を避けやすくなります。
コストを抑える実務ポイント（対象範囲の絞り込みと段階的実施）
コストを最適化する最も効果的な方法の一つが、いきなり全システムを対象にせず、業務上の重要度が高い領域から段階的に解析範囲を広げていくアプローチです。特に、今後の移行・刷新プロジェクトで優先度が高いと分かっている業務領域を先行して解析することで、限られた予算を最も効果の高い部分に集中投下できます。また、機械的に処理できる部分は自動化ツールやスクリプトに任せ、希少なPL/I人材の稼働は業務ロジックの解釈やレビューという「人にしかできない工程」に絞り込むことも、トータルコストを抑えるうえで有効です。あわせて、解析結果を単なる調査報告書としてではなく、検索・参照しやすいナレッジベースとして整備しておくことで、将来同じ範囲を再調査するコストそのものを削減できる点も、長期的なコスト最適化の観点から見逃せません。段階的な解析を進める際は、まず数週間から1〜2ヶ月程度の小規模なPoC(試行調査)で解析ツールの適用範囲や精度を検証し、その結果をもとに本格展開の見積もり精度を高めるという進め方も有効です。PoCの位置づけと具体的な進め方については、姉妹記事「PL/IのリバースエンジニアリングのPoC・プロトタイプ・モックアップ開発について」で詳しく解説しています。加えて、複数年度にわたる解析プロジェクトの場合は、年度をまたぐタイミングでいったん成果物をレビューし、翌年度の解析範囲・予算配分を柔軟に見直す「ステージゲート」方式を採用すると、想定外のコスト超過を早期に検知しやすくなります。
まとめ
本記事では、PL/Iのリバースエンジニアリングにおける保守・運用費用・ランニングコストについて、「解析作業自体の費用」と「解析結果を維持する保守運用の費用」という2つの側面、解析・仕様書化フェーズの費用内訳、PL/I人材の希少性がコスト構造に与える影響、そしてCICS・IMS込みの運用コスト構造とコスト最適化の実務を解説しました。PL/Iの解析コストは、市販ツールによる自動化の余地がCOBOL等より小さいぶん人件費の比率が高く、その人件費自体も希少なPL/I人材の単価に左右されるという構造的な特徴を持ちます。だからこそ、初期の解析費用だけでなく、仕様資産を維持し続ける将来のコストまで見据えた予算計画を立てることが、長期的に見て最も費用対効果の高い選択につながります。段階的な範囲拡大、機械化と人手の役割分担、そしてナレッジベース化による再調査コストの削減という3つの実務ポイントを押さえることで、限られた予算の中でも着実に成果を積み上げていくことが可能です。
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を創業。