古い言語を使ったシステムの改修プロジェクトでSEが意識したいこと 

SEとして経験を積んでいくと、COBOLやPL/I、古いJava、VB系など、現在では新規開発で採用される機会が少なくなった言語を使ったシステムに関わることがあります。

「今まで触ったことのない古い言語だけど大丈夫だろうか」

「既存システムの仕様が分からない状態で、どうやって改修すればいいのか」

「古いシステムなら、いっそのこと新しい言語で作り直したほうがいいのでは？」

こうした疑問を持つ方もいるでしょう。

実際にレガシーシステムの改修プロジェクトに参画すると、最新技術を使った開発とは違った難しさがあります。

一方で、既存システムの調査や改修を通じて、SEとして非常に実践的なスキルを身につけられる機会でもあります。

今回は、「古い言語で構築された既存システムの修正・改善プロジェクトに参画するSE」という状況に焦点を当て、現場で直面しやすい課題や、プロジェクトに入った際に意識したいポイントについて紹介します。

プロジェクト参画後、まずやるべきこと

古い言語のシステム改修プロジェクトに入った場合、いきなりコードを書き始める必要はありません。

むしろ最初に重要なのは、「そのシステムがどのように動いているのかを理解すること」です。

1. 使用している言語・環境を把握する

まずは開発環境や実行環境を確認します。

例えば、

• 使用言語・バージョン
• 開発環境
• コンパイラやランタイム
• データベース
• バッチ処理の仕組み
• ジョブ管理
• 外部システムとの連携方法
• ソースコードの管理方法

などです。

古い言語の場合、現在一般的な開発環境とは異なることがあります。

「コードは読めるけれど、どうやって実行・テストするのか分からない」というケースもあるため、言語そのものだけでなく、その言語が動いている環境まで理解することが重要です。

2. 改修対象の処理を調べる

次に、今回の改修対象となっている処理を確認します。

ここで大切なのは、対象となるプログラムだけを見るのではなく、そのプログラムがどこから呼ばれ、どのデータを受け取り、どこへ渡しているのかまで確認することです。

例えば、

入力

 ↓

バッチ処理

 ↓

対象プログラム

 ↓

データベース更新

 ↓

後続処理

 ↓

外部システム連携

という流れであれば、対象プログラムだけ修正して終わりではありません。

変更によって後続処理に影響が出ないか確認する必要があります。

3. 現行仕様とソースコードを照らし合わせる

レガシーシステムでは、設計書と実際のソースコードが完全に一致していないことがあります。

例えば、

• 「設計書には記載されていない条件分岐がある」
• 「昔の仕様変更がソースコードだけに反映されている」
• 「コメントと実際の処理が一致していない」

といったケースです。

そのため、

「設計書に書いてあるから正しい」

とも、

「ソースコードが動いているから正しい」

とも限りません。

設計書、ソースコード、実際の処理結果、利用者へのヒアリングなど、複数の情報を組み合わせて現行仕様を確認する必要があります。

古い言語を覚えることより「処理の意味」を理解する 

初めて古い言語に触れる場合、当然ながら文法を覚える必要があります。

ただし、改修プロジェクトでは、言語を完全にマスターしてから作業を始める必要はありません。

重要なのは、

「このコードが何をしているのか」

を理解することです。

例えば、ある処理について、

• 何を入力としているのか
• どの条件で分岐するのか
• どのデータを参照するのか
• どのデータを更新するのか
• 処理結果をどこへ渡すのか

を追っていきます。

言語の文法だけに注目するのではなく、処理の流れを追うことを意識すると、初めて触れる言語でも徐々に理解できるようになります。

これは古い言語に限らず、経験者SEが新しいプロジェクトへ参画するときにも役立つ考え方です。

改修では「変更しないこと」も選択肢になる

既存システムを見ていると、

「ここはもっときれいに書き直したい」

「この処理はまとめたほうがいい」

「この設計は今の考え方なら変えたほうがいい」

と思うことがあります。

SEとして技術的な改善点を見つけることは重要です。

ただし、改修プロジェクトでは、今回の目的とは関係のない部分まで変更しないという判断も大切です。

例えば、仕様変更に伴って1つの処理を修正するだけなのに、周辺のコードまで大幅にリファクタリングしてしまうと、変更範囲が広がります。

その結果、

• テスト範囲が増える
• 障害発生時の原因特定が難しくなる
• レビューが複雑になる
• 想定外の影響が発生する

といったリスクがあります。

「コードをきれいにすること」と「安全にシステムを改修すること」は、必ずしも同じではありません。

それでも改善できる部分はある

一方で、古いシステムだからといって、何も改善できないわけではありません。

プロジェクトの目的やルールに合わせて、

• コメントを補足する
• 不要な処理を整理する
• テストケースを追加する
• 手順書を整備する
• 調査した内容をドキュメント化する
• 属人化している知識を共有する

など、将来の保守性を高める取り組みはできます。

特に重要なのがドキュメント化です。

古いシステムでは、「この処理は○○さんしか分からない」という状態になっていることがあります。

自分が調査して理解した内容を残しておけば、次に同じシステムを担当するSEの助けになります。

改修そのものだけでなく、次の改修を少し楽にすることも、レガシーシステムの改善につながります。