保守案件に入ったら最初に確認すること！現役SEが実務で見ているポイント│システムエンジニアで生きていく

新規開発ではなく、既存システムの保守案件に入ることはSEの実務でよくあります。

保守案件では、すでに動いているシステムを扱うため、いきなりコードを読んだり修正したりするよりも、まず全体像を把握することが重要です。

初心者のうちは、担当になった機能のソースコードから見始めてしまいがちです。しかし実務では、コードだけを見ても、そのシステムが業務でどう使われているのか、どこを変更すると影響が出るのかは分かりません。

私自身、保守や改修に関わる中で、最初に確認する情報の質によって、その後の調査や対応のしやすさが大きく変わると感じています。

この記事では、保守案件に入ったら最初に確認することを、現役SEの実務目線で整理します。

この記事でわかること

保守案件では「コードを読む前の確認」が重要

保守案件に入ると、まずソースコードを確認したくなります。

もちろんコードを読むことは必要です。しかし、最初から細かい実装だけを見ると、全体像を見失うことがあります。

保守案件で最初に知りたいのは、次のような情報です。

このあたりを把握してからコードを見ると、なぜその実装になっているのかを理解しやすくなります。

保守案件でよくある失敗が、担当機能だけを見て修正してしまうことです。

既存システムでは、同じデータを複数の画面、バッチ、帳票、外部連携で使っていることがあります。

たとえば、注文ステータスの扱いを少し変えるだけでも、次のような箇所に影響するかもしれません。

対象画面だけで動作確認しても、他の処理で不具合が出る可能性があります。

リリース前の影響確認については「リリース前チェックで見落としやすいポイント」でも解説しています。

保守案件では、過去の障害履歴や問い合わせ履歴が重要な情報になります。

過去に何度も問題が起きている箇所は、仕様が複雑だったり、運用で例外対応が多かったりすることがあります。

障害履歴を見ると、次のような情報が分かります。

この情報を知らずに改修すると、過去と同じ問題を繰り返す可能性があります。

障害報告の見方については「障害報告書で伝わらない原因と対策」も参考になります。

既存システムには、設計書に書かれていない運用ルールが残っていることがあります。

たとえば、月末だけ手動でデータを補正している、特定の取引先だけ例外対応している、障害時だけ別手順で処理している、というケースです。

これらを知らずにシステムを変更すると、現場の運用が回らなくなることがあります。