はじめに
実務をしていると、大きな機能追加よりも「ちょっとした表示修正」や「軽微な改修」のほうが、修正後に意外と見落としがあったなと感じることがあります。
例えば、1つの画面内に複数のポップアップがあり、そのうち1つだけを改修して安心していたところ、テストで他のポップアップの修正漏れに気づきました。
さらに、見た目は似ていて同じデータを扱っているように見えたのに、実際にはポップアップごとに呼び出している関数が異なっていて、同じ引数・同じ取得処理で値を取れると思っていたデータが取れていない、ということもありました。
振り返ると、今回の問題は単なる修正漏れというより、「似ているから同じ実装だろう」と思い込んでしまったこと が大きかったと感じています。
この記事では、この経験を通して感じた 「小さな変更ほど影響範囲を見極めることが大事」 という観点で書いていきます。
小さな変更ほど見落としがちな理由
「表示だけの修正」「ポップアップ1個の改修」と聞くと、影響範囲も小さそうに見えます。
でも実務では、見た目の修正対象が小さいからといって、本当に確認範囲が小さいとは限りません。
特に見落としがちなのは、次のようなケースです。
- 同じ画面の中に似た部品が複数ある
- 見た目は似ているが、実装の中身は少しずつ違う
- 同じデータを扱っているように見えて、取得経路や呼び出し関数が異なる
- 過去の実装を参考にして対応した結果、差分確認が甘くなる
今回の自分のケースも、まさにこれでした。
「このポップアップを直せば終わり」と思っていたのですが、実際には同じような役割のポップアップが他にも存在していて、しかも中の実装は完全には揃っていませんでした。
実際に起きたこと
今回対応したのは、ある画面で複数の異なるポップアップを呼び出している箇所でした。
最初は、対象となるポップアップ1つだけを見て改修を進めていました。
見た目としては似たようなポップアップが並んでいて、扱っているデータも近かったため、どこかで 「他も同じような実装になっているはず」 という前提で見てしまっていたのだと思います。
しかし、テストを進める中で2つの問題が見つかりました。
1. 他のポップアップ側の修正漏れ
1つだけ直して安心していたものの、同じ画面内で似たような振る舞いをする別のポップアップには変更が反映されていませんでした。
2. データ取得の前提が揃っていなかったこと
見た目も扱うデータも似ていたので、同じ名前で呼び出せば値が取れると思っていました。
ところが実際には、ポップアップごとに呼び出している関数が違っていて、同じように実装したつもりでも一部では期待どおりにデータが取得できていませんでした。
その場では「コピペして直したから気づけなかった」とも言えるのですが、今振り返ると、もっと本質的な原因は別にあったと思っています。
本当の原因は「コピペ」より「思い込み」だった
今回の件を振り返ってみると、表面的には「類似箇所を参考にして対応した際の見落とし」でした。
でも、もう少し踏み込むと、根本にあったのは 思い込み だったと感じます。
- 見た目が似ているから中身も同じだろう
- 同じデータを表示しているから取得方法も同じだろう
- 前に似た実装をしたから今回も同じで大丈夫だろう
こうした前提で進めてしまうと、差分をきちんと確認しないまま実装してしまいます。
その結果、1つのポップアップだけ直して終わった気になったり、関数の違いに気づかずデータが取れなかったりします。
コピペ自体が必ず悪いわけではないと思っています。
ただ、コピペ元と修正対象の差分を確認しないまま進めること はかなり危ないです。
今回の経験で改めて感じたのは、実務で見落としていた原因は 「似ているものを同じだと扱ってしまうこと」 だということでした。
小さな修正でも見ておきたい影響範囲
今回のようなことがあると、修正対象そのものだけを見るのでは足りないと分かります。
小さな変更でも、少なくとも次の観点は見ておきたいと感じました。
1. 同じ役割の部品が他にないか
まず確認したいのは、「似たポップアップ」「似たボタン」「似た表示領域」など、同じ役割を持つ部品が他に存在しないかです。
今回で言えば、対象ポップアップだけを見ていたのがよくなかったです。
画面内に似たようなポップアップが複数ある時点で、「他にも修正対象があるかもしれない」 と考えるべきでした。
2. 呼び出し元が本当に同じか
見た目が同じでも、呼び出し元の処理やイベントが違うことがあります。
1つの画面の中でも、ボタンによって別の関数を呼んでいたり、異なる条件分岐を通っていたりします。
今回も、ポップアップごとに呼び出し方が揃っていなかったことが、修正漏れやデータ取得漏れにつながりました。
3. データの取得経路が同じか
「同じデータを使っているように見える」ことと、「同じ方法で取得している」ことは別です。
変数名や表示項目が似ていても、裏側では別の関数を通っていたり、返却形式が異なっていたりすることがあります。
ここを確認せずに「たぶん同じ」と進めると、値が取れない、表示だけ崩れる、といった問題が起きやすいです。
4. どこまでテストすれば十分か
小さな修正ほど、「修正した箇所だけ見て終わり」にしがちです。
でも実際には、類似UIや関連する導線まで確認しないと安心できません。
今回も、テストで別ポップアップの修正漏れに気づけたからよかったものの、見ていなければそのまま残っていた可能性がありました。
今回の経験から自分が意識したいこと
今回の件を通して、今後は次のことを意識したいと思いました。
見た目ではなく、実装の差分を確認する
似ているUIを見つけたら、「同じ実装だ」と判断する前に、まず差分を確認する。
呼び出し元、取得関数、使っているデータ、条件分岐の有無などを見て、どこまで共通でどこから違うのかを把握してから触るようにしたいです。
修正対象を1つに決め打ちしない
最初に「ここだけ直せばいい」と決めつけるのではなく、同じ役割の部品が他にないかを洗い出す。
特にポップアップやモーダル、一覧の表示部品のように、似た実装が増えやすい箇所では重要だと感じました。
コピペするなら、コピペ前後で確認ポイントを持つ
過去の実装を参考にすること自体はよくあることですが、その場合でも 「何が同じで何が違うか」 を確認する前提で使う。
丸ごと流用するのではなく、呼び出し先やデータ取得部分が合っているかを見るだけでも事故は減らせそうです。
テスト観点を「周辺」に広げる
修正した箇所だけでなく、似た部品や関連導線もあわせて確認する。
今回のように、テストで初めて見つかる修正漏れは意外と多いので、「周辺にも同じ影響が出ていないか」 を見る癖をつけたいです。
おわりに
実務では、大きな変更よりも小さな変更のほうが気を抜きやすいです。
でも実際には、見た目が小さい修正ほど 「たぶん大丈夫だろう」 という思い込みが入りやすく、影響範囲を見誤りやすいのかもしれません。
今回の経験で学んだのは、見た目が同じでも、実装が同じとは限らない ということでした。
特に、複数の類似UIが存在する画面では、修正対象だけを見るのではなく、呼び出し元やデータの流れまで含めて確認することが大切だと感じています。
これからは、小さな修正ほど「ここだけで終わる」と思わずに、次の点を一度立ち止まって見るようにしたいです。
- 同じような部品は他にないか
- 取得方法は本当に同じか
- 周辺に影響は出ていないか
同じように、表示修正や軽微な改修で 「思ったより影響範囲が広かった」 という経験がある方の参考になればうれしいです。
採用拡大中！
アシストエンジニアリングでは一緒に働くフロントエンド、バックエンドのエンジニア仲間を大募集しています！
少しでも興味ある方は、カジュアル面談からでもぜひお気軽にお話ししましょう！
お問い合わせはこちらから↓