はじめに
エンジニア1年目の頃、プルダウンに選択肢を1つ追加する改修を担当しました。依頼内容だけを見ると「プルダウンに1項目追加してください」というシンプルなもので、当初はすぐに終わる作業だと思っていました。ところが実際には、想像以上に確認すべき箇所がありました。今回は、その改修を通じて学んだ影響範囲調査について振り返ります。
改修内容
対象システムはPHP（CodeIgniter）で構築されたWebシステムです。ある画面のプルダウンに新しい選択肢を追加する要望がありました。
一見すると、マスタデータにレコードを追加して画面で表示を確認するだけで完了するように見えました。ところが実際に着手してみると、「本当に追加するだけで問題ないのか」を確認する必要が出てきました。
データの流れを追う
最初に手をつけたのは、プルダウンのデータがどこから来ているのかを調べることでした。DBのマスタテーブルなのか、APIなのか、設定ファイルなのか、あるいは定数管理なのか。システムによって管理方法はまちまちなので、まずはこの案件がどのパターンなのかを把握するところから始めました。今回はマスタテーブルから取得している構成でした。
マスタに追加するだけと思っていましたが、いざ手を動かす前にソート順や表示順への影響、論理削除フラグの有無、一意制約に抵触しないかといった点も見ておく必要がありました。単純なINSERTのつもりでも、既存データへの影響はきちんと確認しないといけません。
どこで使われているのかを洗い出す
次にやったのは利用箇所の洗い出しです。マスタを使っているのは対象画面だけとは限りません。同じプルダウンを使う別画面や検索条件、登録画面、編集画面、詳細画面まで、コード検索をかけながら一つずつ潰していきました。
このとき特に気を使ったのが、コード内の条件分岐です。例えば次のように値を直接判定している箇所があると、新しい選択肢を追加しただけで想定外の挙動を引き起こしかねません。
if ($status == 1) {
// 処理A
}
プルダウンに項目を追加するというのは、見た目の話だけでなく業務ロジックにまで波及する可能性があるのだと、このとき実感しました。
画面周りを確認して終わりではなく、マスタ値を使っているバッチ処理やCSV出力、集計処理、帳票出力にも影響が及んでいないか、一通り目を通しました。
学んだこと
今回の改修でわかったのは、改修規模と影響範囲は必ずしも比例しないということです。「1項目追加するだけ」と聞くと簡単な作業に見えますが、実際にはDB、画面、業務ロジック、バッチなど複数の箇所に影響する可能性があります。実装そのものよりも、影響範囲を調べる方に時間を使った記憶があります。
おわりに
小さな改修ほど影響範囲調査が重要だと、この経験を通じて感じました。1年目の当時は「まず実装方法を考える」ことが多かったのですが、経験を積むなかで「どこに影響するのか」を先に考えるようになりました。今後も改修規模に関係なく、影響範囲を丁寧に確認することを意識していきたいと思います。