2026.05.12

「完璧なコード」を追わなくなった理由

エンジニアになりたてのころ、私は「完璧なコード」というものを本気で信じていた。

変数名は厳密に意味を表していなければならない。関数は15行以内に収めるべきだ。コメントは英語で書いた方がプロっぽい。テストカバレッジは80%以上を維持すること。そういったルールを自分に課して、コードを書くたびにリファクタリングを繰り返していた。

結果、何が起きたか。

何も完成しなかった。

「動くコード」の価値に気づくまで

転機は個人開発のプロジェクトだった。妻に「このサービス、本当に出すの？」と聞かれたとき、私は答えられなかった。コードはきれいになっていたが、サービスはまだ誰にも届いていなかった。

「きれいだけど動いていないコード」と「汚いけど動いているコード」、どちらが価値があるか。ユーザー視点で考えれば答えは明白だ。

在宅ワークで個人開発もしている私の場合、限られた時間の中でアウトプットを出すことが求められる。仕事では「リリース日」という締め切りがある。個人開発では自分に締め切りを設けないと、永遠にリリースできない。

完璧主義はその大敵だった。

少し冷静に考えてみると、「完璧なコード」という概念自体が怪しい。

まず、要件は変わる。今日完璧だと思ったコードも、3ヶ月後には仕様変更でゴミになる。テストを100%書いたとしても、そのテスト自体が間違っていることもある。可読性の高いコードも、チームや文脈が変われば読みにくくなる。

つまり「完璧」は固定した概念ではなく、状況依存のものだ。それを追い求めること自体、意味がない。

あるエンジニアの先輩に言われた言葉が今でも刺さっている。「コードは詩じゃない。動いて、保守できて、変更できればそれで十分だ」。

現在の私がコードを書くとき、チェックしているのは3点だけだ。

1. 今日の自分が理解できるか

1週間後に読んだとき、意図がわかれば合格。過剰なコメントは不要。

2. 変更に耐えられるか

ベタ書きのマジックナンバーがなく、影響範囲が把握できれば十分。

3. 壊れたときに気づけるか

エラーログが出る、テストが1本でもある、という状態なら合格。

カバレッジ100%も、ドキュメント完備も、この3点の前では二次的な話だ。

完璧主義をやめてから、個人開発のリリース頻度が上がった。以前は月1本リリースできれば良い方だったが、今は週1のペースで小さい機能を出せている。

仕事でも変わった。「後でリファクタリングしよう」という ToDo コメントを残すことへの抵抗がなくなった。技術的負債を認識して記録し、優先度をつけて返済していく、という考え方が自然にできるようになった。

講師をしているとき、生徒に「このコードって汚くないですか？」と聞かれることがある。私はこう答えることにしている。「今動いてますか？テストありますか？変更できますか？全部イエスなら、まず十分です」。

完璧を目指す姿勢は悪くない。だが、完璧を待っている間にチャンスを逃すのは最悪だ。

私が今大切にしているのは、「動くコードを出してから磨く」というサイクルだ。

まず動かす。ユーザーに届ける。フィードバックをもらう。それから必要な部分だけリファクタリングする。使われない機能を磨き続けるより、使われる機能を少しずつ良くしていく方が、ずっと実りがある。

完璧なコードを追いかけていた私に言ってあげたい。「その時間で、一回デプロイしてみろ」と。

完璧主義をやめた日から、私のエンジニア人生は少し楽になった。