はじめに

「レガシーコードばかり触ってて、スキルつかないんじゃない？」

何度か言われたことがある。

確かに、僕はキャリアの中で5年ほど、いわゆる「レガシー」な環境で戦ってきた。 10年以上前に書かれたコード。誰も触りたがらないシステム。テストがない。ドキュメントもない。 フレームワークは古く、設計思想も今とは違う。

でも、そこで気づいたことがある。

レガシーもモダンも、やっていることは同じだった。

コードを整理する。 責務を分ける。 変更しやすくする。 読みやすくする。

使う道具が違うだけで、本質は変わらない。

この記事では、レガシー環境で戦い続けた末にたどり着いた境地を書いてみたい。

デザインパターンを学んだ日

エンジニアになって数年経った頃、デザインパターンを学んだ。

Gang of Fourの本を読んだ。 Factory、Strategy、Observer、Singleton…

「これがプロの設計か」と思った。 パターンを知っているだけで、強くなった気がした。

現場で使ってみた。 Strategyパターンを導入した。 Facadeで複雑さを隠蔽した。

レビューで褒められた。 「ちゃんとパターン使ってるね」と。

でも、しばらくして気づいた。

パターンを使うこと自体が目的になっていた。

「ここはStrategyパターンで」と言いたいがために、Strategyを使う。 シンプルなif文で済むのに、わざわざクラスを分ける。 読む人が「なんでこんな構造？」と困惑する。

パターンは道具だ。 道具に使われていた。

クリーンコードを読んだ日

次に、クリーンコードを読んだ。 Robert C. Martin（Uncle Bob）の名著だ。

  • 関数は小さくしろ
  • 名前に意図を込めろ
  • コメントは失敗の証拠
  • 1つの関数は1つのことだけ

「これだ」と思った。 自分のコードが汚く見えた。 リファクタリングしたくなった。

現場で実践した。 関数を分割した。 変数名を長くした。 コメントを消した。

そして、レビューで言われた。

「分けすぎて追いにくい」 「名前が長すぎて読みづらい」 「コメントないと意図がわからない」

正しいはずのことをやったのに、怒られた。

正しさは、文脈によって変わる。

この当たり前のことに、なかなか気づけなかった。

「正しさ」で消耗した時期

しばらく、僕は「正しさ」に執着していた。

  • SOLID原則に違反してないか
  • DRY原則を守っているか
  • 凝集度は高いか、結合度は低いか
  • このパターンは適切か

コードを書くたびに、自分を検閲した。 他人のコードを見るたびに、「これは違う」と思った。

レビューで指摘しすぎて、嫌われた時期もある。 「正しいこと言ってるのに、なんで伝わらないんだ」と苛立った。

正しさを追い求めるほど、消耗した。

チームの空気が悪くなった。 自分も楽しくなかった。 コードは確かにきれいになったが、何かを失っていた。

レガシーコードが教えてくれたこと

転機は、あるレガシーシステムの改修だった。

10年以上前に書かれたコード。 フレームワークは独自。 テストはない。 設計思想は、今の常識とは違う。

最初は絶望した。 「こんなコード、どうしろと」

でも、動いている。 10年間、ビジネスを支えてきた。 売上を生み、顧客を満足させてきた。

その事実を、無視することはできなかった。

少しずつ、コードを読んだ。 書いた人の意図を想像した。 なぜこの構造にしたのか、考えた。

すると、見えてきた。

当時の制約の中で、最善を尽くした跡があった。

メモリが少なかった時代の工夫。 フレームワークがなかった時代の自作ライブラリ。 チームが小さかった時代の、シンプルな設計。

「レガシー」と呼ばれるコードの中に、先人の知恵があった。

結局、やっていることは同じだった

レガシーコードを改修しながら、気づいたことがある。

僕がやっていることは、結局これだった。

  1. 読みやすくする — 次に読む人が理解できるように
  2. 変更しやすくする — 次に変更する人が壊さないように
  3. 責務を分ける — 1つの場所が肥大化しないように
  4. 依存を整理する — 影響範囲を予測できるように

これは、モダンな環境でも同じだ。 ReactでもRailsでも、GoでもRustでも。

使う道具が違うだけ。 言語が違うだけ。 フレームワークが違うだけ。

本質は「コードを整理する技術」だった。

デザインパターンも、その手段の1つ。 クリーンコードも、その視点の1つ。 SOLID原則も、その指針の1つ。

どれも正解ではなく、道具だった。

正しさより、目的

今の僕は、こう考えている。

「正しいか」より「目的を達成できるか」

コードは、目的を達成するために書く。 ビジネスを動かすために書く。 誰かの問題を解決するために書く。

その目的に対して、今の構造は適切か。 今のチームで、保守できるか。 今の期限で、リリースできるか。

正しさは、文脈によって変わる。 チームによって変わる。 時代によって変わる。

10年後には、今の「モダン」が「レガシー」になる。 ReactもTypeScriptも、いつか古くなる。

永遠に正しいコードはない。

だから、正しさで消耗するのはやめた。

消耗しないための3つの考え方

今の僕が意識していることを、3つ書いておく。

1. 原則は「参考」であって「法律」ではない

SOLID原則を破っていいとは言わない。 でも、SOLID原則を守ることが目的ではない。

原則は、先人が見つけた「うまくいくパターン」だ。 多くの場合、従った方がいい。 でも、文脈によっては従わない方がいいこともある。

原則を知った上で、判断する。

知らずに破るのと、知った上で破るのは、まったく違う。

2. 完璧を目指さない

完璧なコードは、存在しない。

どんなに設計しても、後から「こうすればよかった」は出てくる。 要件が変われば、設計も変わる。 未来は予測できない。

今の時点での最善を出す。それでいい。

完璧を目指して1週間悩むより、80点で出して改善した方がいい。

3. 人を責めない

「なんでこんなコード書いたの」と言いたくなることがある。

でも、書いた人には、書いた人の文脈があった。 時間がなかったのかもしれない。 知識がなかったのかもしれない。 要件が急に変わったのかもしれない。

コードを批判しても、人を批判しない。

「このコードをこう変えたい」と言えばいい。 「なんでこう書いたの」と詰める必要はない。

モダンな現場でも、同じことをしている

最近は、比較的モダンな環境で仕事をすることもある。 TypeScript、React、Next.js、Docker、Kubernetes…

でも、やっていることは変わらない。

  • 読みやすくする
  • 変更しやすくする
  • 責務を分ける
  • 依存を整理する

道具がモダンになっただけで、技術の本質は同じだ。

むしろ、レガシー環境で鍛えられた「コードを整理する技術」が、そのまま活きている。

最新のフレームワークを追いかける必要はない。 本質を理解していれば、どんな道具でも使える。

「○○の経験年数」という茶番

転職サイトを見ると、こういう募集要項をよく見かける。

  • React経験3年以上
  • TypeScript経験2年以上
  • AWS経験5年以上

正直に言う。この業界の採用基準には、ずっと違和感がある。

言語やフレームワークの経験年数で、何がわかるというのか。

Reactを3年触っていても、コンポーネント設計がめちゃくちゃな人はいる。 TypeScriptを2年使っていても、型の恩恵を活かせていない人はいる。 AWSを5年使っていても、コスト最適化ができない人はいる。

逆に、Reactを半年しか触っていなくても、設計センスがある人はいる。 新しい言語でも、1ヶ月で本質を掴む人はいる。

経験年数は、スキルの証明にならない。

表層しか見ていない

「Rustが熱い」 「Next.jsが来てる」 「Goが求人多い」

こういう話題で盛り上がる人たちがいる。 言語の人気ランキング、フレームワークの市場価値、トレンドの予測。

否定はしない。情報として知っておくのは悪くない。

でも、それは表層の話だ。

言語が変わっても、やることは同じ。 フレームワークが変わっても、設計の本質は同じ。

    ソースコード
    ↓ コンパイル / インタプリタ
機械語
    ↓ CPU実行
結果（出力・状態変化）

最終的に、CPUは命令を実行して結果を返すだけだ。 CPUは「このコードはReactで書かれているか」なんて判断しない。 「この言語は人気があるか」なんて気にしない。

ハードウェアの領域で、結果が同じになればいい。

それが本質だ。

本当に見るべきもの

採用で見るべきは、経験年数ではない。

  • この人は、問題をどう分解するか
  • この人は、コードをどう整理するか
  • この人は、変更にどう備えるか
  • この人は、結果を出すためにどう動くか

これらは、言語に依存しない。 フレームワークに依存しない。 レガシーでもモダンでも、同じように発揮される。

「React 3年」より「設計で悩んだ経験」の方が価値がある。 「AWS 5年」より「障害対応で学んだこと」の方が価値がある。

経験年数を並べるだけの採用基準は、本質を見ていない。 そして、その基準に振り回されるエンジニアも、本質を見失う。

レガシーは、悪ではない

「レガシーコードは悪」という風潮がある。

確かに、保守しにくいコードは大変だ。 テストがないシステムは、触るのが怖い。 ドキュメントがないと、理解に時間がかかる。

でも、レガシーコードは「生き残ったコード」でもある。

何年もビジネスを支えてきた。 何人もの開発者が手を入れてきた。 その歴史が、コードに刻まれている。

レガシーと呼ばれる環境で戦うことは、スキルがつかないことではない。

むしろ、制約の中で工夫する力が身につく。 ドキュメントがない中で読み解く力が身につく。 テストがない中で慎重に変更する力が身につく。

これらは、モダンな環境でも必ず活きる。

結論：正しさより、持続可能性

僕がレガシー環境でたどり着いた境地は、これだ。

正しさを追い求めて消耗するより、持続可能な形で貢献し続けることの方が大事。

完璧なコードを書くことより、チームが保守できるコードを書くこと。 最新の技術を使うことより、目的を達成できる技術を選ぶこと。 正しさで議論することより、動くものを出して改善すること。

デザインパターンは知っておいた方がいい。 クリーンコードは読んでおいた方がいい。 SOLID原則は理解しておいた方がいい。

でも、それに縛られて消耗する必要はない。

道具は道具。使いこなすのは自分。

レガシーでもモダンでも、本質は変わらない。 コードを整理する技術。 それが、エンジニアの武器だ。

最後に

「レガシーばかり触ってて、大丈夫？」

今なら、こう答える。

「大丈夫。むしろ、いい修行になった」

最新技術を追いかけることだけがスキルアップではない。 目の前のコードを、少しずつ良くしていくこと。 それも立派なスキルだ。

正しさで消耗しなくなったとき、仕事は少し楽になった。 チームとの関係も、良くなった。 コードを書くことが、また楽しくなった。

完璧を目指さない。 正しさに執着しない。 目の前のコードを、少しだけ良くする。

それを続けていれば、自然とスキルはついてくる。

レガシーもモダンも、関係ない。 コードを整理する技術は、一生使える。