レガシーシステムを若手が保守する大変さ｜設計書がない現場でどう生き残るか

設計書はある。でも信用していいとは限らない

レガシーシステムの保守に入ると、まず言われるのが「設計書を確認しておいて」です。フォルダを開き、資料を探し、それらしき設計書を見つけます。開くと古い。画面と違う。処理とも違う。最終更新日を見ると、ちょっとした歴史資料です。

そして先輩から「実際の仕様はソースを見た方が早いよ」と言われます。この瞬間、若手SEは悟ります。設計書は地図ではある。ただし、現在地と道路が少し違う地図です。

私自身も、レガシーシステムやCOBOLの保守についてChatGPTに相談しながら、どう読めばよいか、どこから整理すればよいかを考えたことがあります。レガシー保守で大変なのは、古い技術そのものよりも、「正しい情報がどこにあるか分からないこと」です。

熟練SEの頭の中に仕様がある

レガシーシステムでは、長年の改修、例外対応、顧客別対応、暫定対応が積み重なり、熟練SEに知識が集中しがちです。この条件のときだけ別処理。この項目は昔の名残だが消せない。このフラグは見た目より重要。この処理は触ると何かが起きる。こうした情報が、設計書ではなく人の記憶に残っていることがあります。

つまり、システム仕様がファイルサーバーではなく、熟練SEの頭の中に保存されています。しかもバックアップなしです。

この帳票は別処理にも影響する。この処理は触ると何かが起きる。こうした情報が、設計書ではなく人の記憶に残っていることがあります。これは技術的にも組織的にも、なかなかスリリングです。

若手SEがつらい理由

若手SEがレガシー保守でつらいのは、知識不足だけではありません。何を見ればよいか分からない。どこまで影響するか分からない。どの設計書が正しいか分からない。何を質問すればよいか分からない。この「分からないことが分からない」状態が一番つらいです。

レガシーシステムは影響範囲が広いことがあります。1つの項目が、画面、帳票、バッチ、外部連携、集計処理に使われている。軽い気持ちで直した修正が、別の場所で静かに爆発することもあります。

そしてその爆発は、だいたいリリース直前に見つかります。システムにも演出力があります。

生き残るための読み方

最初に意識したいのは、全部を理解しようとしないことです。まずは、変更対象の周辺だけに絞ります。見るべきポイントは、入力、処理、出力です。何を受け取っているのか。どの条件で分岐しているのか。どのデータを更新しているのか。どの画面や帳票に出ているのか。この流れを押さえるだけでも、かなり理解しやすくなります。

次に、呼び出し元と呼び出し先を確認します。この処理はどこから呼ばれるのか。この処理結果はどこで使われるのか。同じ項目を使っている別処理はないか。grep検索は便利ですが、検索だけでは業務上の意味までは分かりません。

AIを使うなら仮説整理に使う

AIはレガシー保守でも役に立ちます。COBOLの処理を説明させる。条件分岐を日本語で整理させる。影響範囲調査の観点を出させる。テストケースを洗い出させる。特に若手SEにとって、AIは最初の理解を助けてくれます。

ただし、AIの説明をそのまま仕様として信じるのは危険です。AIは現場の過去経緯までは知りません。AIで処理を整理し、ソースで確認し、テストで確かめ、熟練SEに確認し、分かったことをメモに残す流れが安全です。

おすすめは、AIを仮説整理に使うことです。AIで処理を整理する。ソースで確認する。テストで確かめる。熟練SEに確認する。分かったことをメモに残す。この流れが安全です。

まとめ

レガシーシステム保守が大変なのは、古い技術だからだけではありません。設計書が古い。仕様が人に残っている。影響範囲が広い。例外処理が多い。若手にとって判断材料が少ない。だからこそ、読む力、整理する力、質問する力が必要です。設計書がないなら、少しずつ地図を作る。それが若手SEでもできる、レガシー改善の第一歩です。

レガシー保守は、ただ古いシステムを守る仕事ではありません。次の人が少しでも読みやすくなるように、現場の知識を見える化する仕事でもあります。