💡 このページでわかること
- システム改修と新規開発の違い
- 初めてシステム改修を行うときの6つの手順
- 既存システムを壊さないための影響調査の考え方
- 改修後に確認しておきたいテストの範囲
- 初心者がシステム改修で注意したいポイント
ITの現場で仕事をしていると、「この画面のボタンの動きを変更してほしい」「このエラーが出ないように修正してほしい」と、既存システムの改修を任されることがあります。
初めてシステム改修を担当すると、
「どこから確認すればいいんだろう？」
「既存のプログラムを壊してしまったらどうしよう……」
と不安になりますよね。
システム改修では、いきなりプログラムを書き換えるのではなく、改修内容の確認 → 影響調査 → 方針決定 → 実装 → テスト → リリースと順番に進めることが大切です。
この記事では、IT初心者や初めて改修を担当する方向けに、システム改修の基本的な進め方と注意点を6つのSTEPで解説します。
現場によって細かな進め方は異なりますが、まずは基本の流れを押さえておきましょう。
作業前に知っておくこと
具体的な手順を見る前に、システム改修とはどのような作業なのかを押さえておきましょう。
「新規開発」と「システム改修」の違い
「新規開発」が新しいシステムや機能をゼロから作るのに対し、「システム改修」は、すでに動いているシステムに機能追加・仕様変更・不具合修正などを行う作業です。
すでに動いているものを変更するからこそ、システム改修では変更箇所以外への影響にも注意する必要があります。
改修作業で大切なのは「他への影響を防ぐこと」
システム改修では、変更した機能が正しく動くだけでは十分ではありません。
変更したことで、これまで正常に動いていた別の機能に問題が発生していないかも確認する必要があります。
たとえば、複数の画面で共通して使われている処理を変更すると、自分が担当している画面だけでなく、別の画面にも影響する可能性があります。
そのため、
「どこを直すか」だけでなく「その変更がどこに影響するか」まで考えること
が、システム改修ではとても重要です。
初めてのシステム改修｜全体の流れ
システム改修では、いきなりプログラムを書き始めるのではなく、「確認する → 調べる → 計画する → 実装する → テストする → リリースする」という順番で進めます。
まずは、全体の流れを確認してみましょう。
ここからは、それぞれのSTEPで何をするのか詳しく見ていきます。
STEP1｜改修する内容と目的を確認する
最初に行うのは、今回何をどう変更するのかを正確に把握することです。
改修の依頼内容（要件）を確認する
まずは、チケットや依頼書、要件書などを確認します。
ここでは、
- どの画面・機能を変更するのか
- 現在はどのような動作なのか
- 改修後はどのような動作にするのか
- どのような条件で処理が変わるのか
などを整理します。
たとえば、「会員登録画面で、電話番号をハイフンなしでも入力できるようにする」という改修であれば、電話番号入力欄だけを見るのではなく、現在どのような入力チェックが行われているのかも確認します。
「なぜ改修するのか」背景も確認する
改修内容だけでなく、なぜその変更が必要なのかも確認しておきましょう。
背景を理解していると、影響調査やテストで「何を確認すべきか」が考えやすくなります。
依頼内容を読んでも、
「この場合はどうなるんだろう？」
「この条件について書かれていないな」
といった疑問が残る場合は、自己判断で進めず、実装に入る前に依頼者や先輩、リーダーへ確認しましょう。
STEP2｜既存システムを調べて影響範囲を洗い出す
改修内容を理解したら、次は既存システムが現在どのように動いているのかを調べます。
この作業を「影響調査」「影響範囲の洗い出し」などと呼びます。
システム改修の中でも、特に重要な工程です。
改修対象となる処理を特定する
まずは、今回変更する機能がどのように作られているのかを確認します。
設計書や仕様書がある場合は、最初にそれらを確認しましょう。
そのうえで必要に応じて、開発環境で実際に画面を操作したり、ソースコードを検索したりしながら処理の流れを追っていきます。
「変更箇所以外」への影響も確認する
調査するのは、変更するソースコードだけとは限りません。
関連する画面やデータベース、API、バッチ処理など、変更によって影響する可能性がある範囲も確認します。
たとえば、複数の画面から利用されている共通処理を変更した場合、その処理を利用している別の画面にも影響する可能性があります。
「このファイルを直せば終わり」と考えるのではなく、
「この処理は他から使われていないか？」
という視点を持つことが大切です。
全ファイル検索や参照検索なども活用しながら、関連する処理を確認しましょう。
STEP3｜改修方針とテスト内容を決める
影響範囲が分かったら、実際にどのように改修するのか方針を決めます。
どの処理をどう変更するか整理する
STEP2で調べた内容をもとに、
- どのファイルを変更するのか
- どの処理を変更するのか
- 新しい処理を追加するのか
- DBや設定ファイルなどの変更が必要か
- どの機能に影響する可能性があるか
などを整理します。
複雑な改修の場合は、改修方針を簡単なメモや設計書にまとめ、実装前に先輩エンジニアやリーダーへ確認してもらうと安心です。
テスト内容も実装前に考えておく
「実装が終わってから、どう確認するか考えよう」ではなく、実装前にテスト内容も考えておくことが大切です。
テストでは主に、
- 変更した機能が想定どおり動くか
- 影響する可能性のある既存機能がこれまでどおり動くか
を確認します。
STEP2で見つけた影響範囲が、そのままSTEP5で確認するテスト範囲につながると考えると分かりやすいでしょう。
STEP4｜開発環境で実装し、レビューを受ける
改修方針とテスト内容が決まったら、実際にプログラムを変更します。
基本的には、ユーザーが利用している本番環境を直接変更するのではなく、チームで用意された開発環境などで作業します。
チームのバージョン管理ルールを確認する
Gitなどのバージョン管理ツールを利用している現場では、作業前に最新のソースコードを取得し、チームのルールに従って改修用のブランチを作成します。
バージョン管理の方法は現場によって異なるため、自己流でファイルをコピーしてバックアップを作るのではなく、チームで決められた方法に従って変更を管理することが大切です。
既存コードのルールに合わせて実装する
STEP3で決めた方針に沿ってコードを変更します。
このとき、自分なりの書き方に変えるのではなく、既存コードやチームの命名規則・コーディングルールに合わせましょう。
実装後はレビューを受ける
実装が終わったら、チームの進め方に従って他のエンジニアにコードを確認してもらいます。
これを「コードレビュー」と呼びます。
レビューでは、自分では気づかなかったミスや影響範囲の見落とし、チームのルールと異なる実装などが見つかることがあります。
指摘された内容を修正し、必要に応じて再度確認してもらいましょう。
STEP5｜変更箇所と影響範囲をテストする
実装とレビューが終わったら、変更したシステムが正しく動くかテストします。
変更した機能が正しく動くか確認する
STEP3で用意したテスト項目に沿って、変更した機能が想定どおり動くか確認します。
正常な操作だけでなく、必要に応じて、
- 未入力の場合
- 上限・下限となる値
- 不正な値を入力した場合
- エラーが発生する条件
なども確認します。
どこまでテストするかは、改修内容やプロジェクトのルールによって異なります。
影響範囲に問題がないか回帰テストを行う
改修では、変更した機能だけ確認して終わりではありません。
STEP2で洗い出した関連機能についても、変更前と同じように正常に動くか確認します。
このように、変更によって既存機能に問題が発生していないことを確認するテストを「回帰テスト（リグレッションテスト）」と呼びます。
たとえば、共通処理を変更したのであれば、その処理を利用している別の画面についても確認が必要になる可能性があります。
テスト中に不具合が見つかった場合は、原因を調査して修正し、再度テストを行います。
STEP6｜リリース準備・本番反映・リリース後確認を行う
テストで問題がないことを確認できたら、本番環境へのリリース準備を進めます。
リリースはシステムへの影響が大きいため、必ず現場で決められた手順に従って進めましょう。
リリース前に手順と切り戻し方法を確認する
本番環境へ反映する前に、
- 何をリリースするのか
- どの順番で作業するのか
- 誰が作業するのか
- リリース後に何を確認するのか
- 問題が起きた場合にどう元へ戻すのか
などを確認します。
特に、問題が発生した場合に変更前の状態へ戻すことを「切り戻し」と呼びます。
「問題が起きてから戻し方を考える」のではなく、事前に切り戻し方法を確認しておくことが大切です。
決められた手順で本番環境へ反映する
リリース手順書などに従って、本番環境へ変更を反映します。
システムによって、プログラムの配置、設定変更、DBへの変更など作業内容はさまざまです。
本番環境では、小さな操作ミスでも大きな影響につながる可能性があります。
自己判断で手順を変更せず、決められた内容を確認しながら進めましょう。
リリース後に動作確認を行う
リリースしたら、本番環境で変更した機能が正しく動いているか確認します。
必要に応じて、関連機能やエラーログ、データベースの状態、他システムとの連携なども確認します。
リリース後の確認まで問題なく終われば、システム改修作業はひと区切りです。
初心者がシステム改修で注意する3つのポイント
最後に、初めてシステム改修を担当するときに特に意識したいポイントを3つ紹介します。
1. 勝手な判断でコードを書き換えない
既存のコードを読んでいると、
「ここはもっときれいに書けそう」
「この処理はいらないのでは？」
と気づくことがあります。
しかし、一見不要に見えるコードでも、過去に発生したトラブルへの対応など、何らかの理由で残されている可能性があります。
今回の改修と関係のない部分まで、自分の判断だけで変更するのは避けましょう。
気になるコードを見つけた場合は、先輩やリーダーに確認してから対応します。
2. 影響調査を思い込みで終わらせない
システム改修では、
「たぶんこの画面だけだろう」
「この処理は他では使っていないだろう」
という思い込みがトラブルにつながることがあります。
「たぶんここだけ」で終わらせず、STEP2で確認した影響範囲をもとに判断しましょう。
ただし、影響範囲をどこまでも調べ続ければよいわけではありません。
「どこまで調べれば十分なのかわからない」場合も、重要な相談ポイントです。
自分だけで判断せず、先輩やリーダーに確認しましょう。
3. わからないことは「調べた内容」と一緒に相談する
既存システムの改修では、初めて見るコードや知らない処理に出会うことも珍しくありません。
わからないことを抱えたまま進めるより、早めに相談する方が安全です。
そのとき、
「わかりません」
だけではなく、
「ここまでは確認しましたが、この処理がどこから呼ばれているのかわかりません」
「AとBまでは調べましたが、Cにも影響するか判断できません」
のように、自分が確認した内容と、わからない部分を分けて伝えると、相手も状況を把握しやすくなります。
よくある疑問
Q. 仕様書や設計書がない既存システムはどうすればいいですか？
A. 現在動いているシステムとソースコードを確認しながら、実際の動きを把握します。
古いシステムでは、設計書が最新化されていなかったり、一部の資料が残っていなかったりすることがあります。
その場合は、開発環境で実際に画面を操作しながら、ソースコードを検索したり、デバッグ機能を使って処理の流れを追ったりして現在の動作を確認します。
ただし、わからない仕様をコードだけから推測して決めてしまうのは危険です。
判断できない部分がある場合は、過去の資料やチケットを確認したり、システムに詳しいメンバーへ確認したりしましょう。
Q. 既存のコードが読みにくいときは、きれいに直してもいいですか？
A. 原則として、今回の改修範囲以外は勝手に変更しない方が安全です。
コードを整理して読みやすくする「リファクタリング」自体は、悪いことではありません。
しかし、改修範囲を広げるほど変更箇所が増え、その分テストが必要な範囲や不具合が発生するリスクも増えます。
どうしても修正した方がよい部分がある場合は、個人で判断せず、先輩やリーダーに相談しましょう。
まとめ
システム改修では、「変更した機能を正しく動かすこと」と同じくらい、「既存の機能を壊さないこと」も重要です。
そのため、いきなりコードを書き換えるのではなく、要件確認・影響調査・改修方針の整理をしてから実装へ進みましょう。
初めての改修では、影響範囲をどこまで調べればよいか判断できないこともあります。
そんなときは自己判断せず、「ここまで調べたけれど、ここから判断できない」と早めに相談することも大切です。
まずはSTEP1の「今回何を変えるのか」の確認から始めてみましょう。