「既存のコードを参考にして実装してね、と言われたけど……正直、既存実装がイケてない、、、」
システム開発の現場にいると、こんな場面に本当によく出くわしますよね。
既存の作りにとらわれず「あるべき姿（ベストプラクティス）」で綺麗に書くべきか、それともモヤモヤを抱えつつ無難に「既存踏襲」で合わせるべきか。
真面目に開発と向き合っているエンジニアほど、この板挟みで深く悩んでしまいます。
僕自身、JavaやSpring Bootのバックエンド開発の現場で、この「既存踏襲 vs あるべき姿」の選択には何度も頭を抱えてきました。
現役フリーランスエンジニア（4年目）の僕が、この悩みにぶつかったときにどうやって判断し、どう立ち回っているのかを実体験をもとに解説します。
「既存踏襲」か「あるべき姿」かで迷ったときの3つの判断基準
結論から言うと、僕が現場で「既存に合わせるか、ベストプラクティスで書くか」を迷ったときは、以下の3つの基準で判断しています。
- バグ・セキュリティ・深刻な性能問題に直結するなら「あるべき姿」を提案する
- 設計思想や書き方の好みの問題なら、モヤモヤを飲み込んで「既存踏襲」を選ぶ
- 改善したいときは勝手に直さず、「既存踏襲案」と「改善案」を並べてリーダーに相談する
順番に説明します。
①バグ・セキュリティ・深刻な性能問題に直結するなら「あるべき姿」を提案する
1つ目は、「そのまま既存を真似すると、明確な実害が出るケース」です。
どれだけ「既存踏襲が基本」の現場であっても、以下のようなケースでは既存の書き方をそのままコピーしてはいけません。
- ループの中でSQLを大量発行しており、本番データ量だと画面が固まる（N+1問題）
- トランザクション制御や排他制御が抜けていて、データの不整合が起きるリスクがある
- SQLインジェクションや認証漏れなど、セキュリティ上の脆弱性につながる
過去のコードがたまたま少量のデータで動いていただけ、というケースは現場でよくあります。
それをそのまま別の機能に横展開して本番障害が起きた場合、「既存がそうなっていたので合わせました」という言い訳は通用しにくいです。
そのため、「システムが壊れる・遅くなる・危険になる」という明確な根拠があるときは、既存の作りにとらわれずベストプラクティス側を主張するようにしています。
②設計思想や書き方の好みの問題なら、モヤモヤを飲み込んで「既存踏襲」を選ぶ
2つ目は、実害までは出ないものの、エンジニアとして「この書き方は微妙だな……」とモヤモヤするケースです。
ほとんどがこのケースだと思います。
例えば、現場では以下のようなコードによく遭遇します。
- 本来はServiceクラスに書くべきビジネスロジックが、Controllerにずらっと書かれている
- DTOクラスを作らず、Map型のままデータをバケツリレーしている
- 共通化できそうなチェック処理が、各クラスにコピペされている
- 命名が良くない（boolean型にflagを付けていたり、否定形になっていたり）
真面目でより良いコードを追求する人ほど「あー、リファクタしたい」とウズウズすると思います。
僕も昔、良かれと思って自分の担当画面だけ「教科書通りの綺麗な設計」で実装し、コードレビューに出したことがありました。
するとレビュアーから、「他の画面と作りが違うと、後から見る人が混乱するから既存に合わせてほしい」と指摘され困りました。
（参画したてだったのと、バグや性能に関わる内容ではなかったので、このときは波風立てず既存に合わせるように変更しました）
ここで大事なのは、「1つのシステムの中に、2種類の設計ルールが混在すること自体が新たな技術的負債になる」という視点です。
99個の画面が「Aという微妙な書き方」で作られている中に、1個だけ「Bという望ましい書き方」が混ざると、保守するメンバーは「なぜこの画面だけ作りが違うの？特別な仕様があるの？」と余計な調査コストを払うことになります。
だからこそ、プロジェクト全体のリファクタリング方針がない限りは、グッとこらえて「既存のルール（統一感）」を優先するのも必要な選択だと割り切っています。
③改善したいときは勝手に直さず、「既存踏襲案」と「改善案」を並べてリーダーに相談する
3つ目は、「どうしてもここは改善した方が良さそうだけど、既存踏襲から外れていいか迷う」ときの具体的な解決方法です。
一番やってはいけないのは、相談なしに自分の判断だけで「あるべき姿」で実装を進めてしまうことです。
僕は迷ったとき、実装を始める前にチャットや口頭で以下のように相談するようにしています。
- 「既存の〇〇画面を見るとAの方式で実装されていますが、今回同じように作ると△△の懸念があります」
- 「①既存の統一感を優先してAで進めるか、②今後を見据えてBの方式（ベストプラクティス）にするか、どちらの方針がよろしいでしょうか？」
- 「個人的には〇〇の理由で②が良いと考えています」
この聞き方のポイントは、既存のコードを批判するのではなく、「統一感（既存踏襲）」と「品質（あるべき姿）」のトレードオフとして判断を仰ぐことです。
こうやって事前に合意を取っておけば、もし「今回は納期優先で既存踏襲でいこう」と言われても納得して作業できますし、「確かにその通りだから改善案でお願い！」と背中を押してもらえることも多いです。
モヤモヤを一人で抱え込まず、「提案はするけれど、最終決定権は現場のリーダーに委ねる」というスタンスをとると、精神的にもすごく楽になります。
そもそも、なぜ現場には「ベストプラクティスと違う既存コード」があふれているのか
いろんな現場を経験して分かったのですが、「最初から汚いコードを書こうと思って書いている人」はほとんどいません。
それでも既存実装がベストプラクティスから外れてしまうのには、現場ならではの理由があります。
当時の厳しい納期・急な仕様変更・メンバーのスキル差の中で、「まずは動くものを作る」ことを最優先した結果だから
SES社員時代からフリーランスになっていくつかの現場を見てきましたが、どのプロジェクトにも必ず「歴史的な経緯」があります。
「リリース直前に仕様がひっくり返り、設計を直す時間がなかった」「当時はフレームワークに詳しい人がおらず、手探りで作られた」など、過去のメンバーが必死に戦った跡が今の既存コードです。
そう考えると、「なんだこのダメなコードは！」とイライラする気持ちが少し和らぎます。
また、僕たちフリーランスエンジニアに求められているのは、自分の理想のコードを書いて満足することではなく、チームの状況に合わせてプロジェクトを前に進めることです。
「ベストプラクティスを知っていること」と「現場の事情を汲んであえて既存に合わせられること」の両方を持っているエンジニアこそが、結果的にどの現場でも長く信頼されると感じています。
さいごに
今回は、システム開発でよくぶつかる「既存踏襲 vs あるべき姿」の悩みと、僕なりの判断基準について紹介しました。
「せっかくなら綺麗なコードを書きたい」と思えるのは、エンジニアとして向上心がある証拠です。
ただ、現場のコードにはこれまでの経緯や事情があるため、すべてを理想通りに直そうとすると自分が疲弊してしまいます。
「実害がある箇所は提案して直す」「全体の統一感が大事な箇所は割り切って既存に合わせる」という線引きを持っておくだけで、日々の開発のストレスはかなり減らせます。
同じように現場で「既存に合わせるべきか、直すべきか」とモヤモヤしている方の気持ちが、少しでも軽くなれば嬉しいです。
それでは！