「動けばいい」 の罠。僕を救ったテストコードの話

かつての僕は「動けばいい」と信じていました。

しかし、その考えが引き起こしたある致命的なバグが、僕を地獄の淵に立たせたのです。

これは、品質を軽んじたフリーランス開発者が後悔の淵から再生し、未来の自分と仲間を救う「テストコード」という名の保険に出会うまでの、試行錯誤の記録です。

あなたのコードに、「保険」 はかかっていますか？

「とりあえず、動けばいいでしょ」

フリーランスになりたての頃の僕は、本気でそう思っていました。画面が仕様書通りに動き、データが保存されればそれで完了。テストコードなんて、納期を遅らせるだけの面倒な作業だとさえ感じていたのです。

——おかしな話ですよね。

というのも、フリーランスになる前の僕は、医療系のシステム開発に携わっていました。人の命に直結しかねないシステムです。そこでのバグは、単なるプログラムのエラーではありません。全国の病院へ出張し、年末年始をサーバー室で過ごしながら僕が学んだのは、一行のコードが持つ、恐ろしいほどの重みでした。

当時は今のように便利な AI もなく、ひとたびバグが発生すれば、原因究明に数時間、ときには数日を要するのが当たり前。一つの不具合が、ドミノ倒しのように他の箇所のバグを誘発する恐怖と、僕たちは常に隣り合わせだったのです。

その経験は、僕にとって開発者としての「ターニングポイント」となるほど、強烈なものでした。

それなのに、フリーランスになった途端、僕は「スピード」という新しい神様に心を奪われ、最も大切なことを見失ってしまいました。それは、書いたコードに対する「未来への責任」です。

多くの開発者が、一度はこの「動けばいい」という甘い罠にハマってしまうのではないでしょうか。目の前のタスクをこなすことに必死で、数ヶ月後、あるいは数年後にそのコードを触る自分や、チームの仲間がどれほどの苦痛を味わうことになるか、想像もせずに——。

この記事は、そんなかつての僕と同じ過ちを、あなたに繰り返してほしくない、という切実な願いから生まれました。

これは、僕が「動けばいい」の呪縛から解き放たれ、テストコードという名の「保険」を手に入れるまでの物語。品質とは何か、そしてプロフェッショナルとしてコードにどう向き合うべきか。僕が地獄の底で学んだ、実践的な哲学のすべてです。

僕はこうして 「動けばいい」 の罠にハマった

命の重みと向き合っていたサラリーマン時代とは打って変わり、僕がフリーランスとして飛び込んだのは、スピードが正義とされるスタートアップの世界でした。そして、まんまとその罠にハマってしまったのです。

あれは、フリーランスとして独立してまだ間もない頃に受けた、ある EC サイトの決済機能改修プロジェクトでした。クライアントは勢いのあるスタートアップで、とにかくスピード感を重視していました。

「おおとろさん、この機能、来週までにリリースできますか？」

無茶な要求だと頭では分かりつつも、「期待に応えたい」「ここで結果を出せば次につながる」という焦りが、僕の正常な判断を狂わせました。

「はい、なんとかします」

その一言が、地獄の始まりでした。

納期だけを神様にした、ある EC サイトプロジェクト

僕は神様になった気分でした。いや、正確には「納期」という神に仕える、哀れな僕（しもべ）でした。

朝から深夜まで、エナジードリンクを相棒にひたすらコードを書く毎日。睡眠時間を削り、食事はデスクの上で 5 分で済ませる。頭の中は、迫り来る納期のことだけ。

正常な状態であれば、決済というクリティカルな機能を扱う以上、細心の注意を払ってテストを書くべきでした。しかし、当時の僕の思考は完全に麻痺していたのです。

「テストコード？そんなものを書いている時間はない」
「まずは動くものを作って、クライアントを安心させることが最優先だ」
「細かいバグは、リリース後に直せばいい」

僕は、最も危険な思考——「品質」を後回しにするという選択を、いとも簡単に下してしまったのです。

「後で書く」 と誓ったテストコードは、永遠に書かれなかった

「時間があったら、後でテストコードを書こう」

そう心の中で言い訳をしながら、僕は目に見える機能の実装だけをひたすらに進めました。

「後でやる」は、エンジニアの世界では「永遠にやらない」と同義語であることを、このときの僕はまだ知りませんでした。

一つ機能を実装しては、次の機能へ。その繰り返し。まるで、借金を雪だるま式に膨らませているような感覚でした。コードを書けば書くほど、見えない「技術的負債」が積み上がっていく。しかし、僕はそれを見ないふりをしたのです。

そして、運命のリリース日。僕はなんとか納期に間に合わせ、ボロボロの体でクライアントに納品しました。「やればできるじゃないか」と、一瞬だけ達成感に浸ったことを、今でも鮮明に覚えています。それが、嵐の前の静けさだとも知らずに。

リリース日の深夜、鳴り響いた一本の電話

リリースから数時間後の、深夜 2 時。けたたましく鳴り響くスマートフォンの着信音で、僕は叩き起こされました。画面には、クライアントの担当者の名前。心臓が嫌な音を立てて跳ね上がりました。

「おおとろさん、大変です！注文が、どんどん重複して処理されています！」

電話の向こうから聞こえてくる、彼の焦燥しきった声。その一言で、僕の眠気は一瞬で吹き飛び、代わりに全身を冷たい汗が駆け巡りました。

決済機能のバグ。それも、最もやってはいけない種類の、金銭が絡む致命的なバグでした。

数百行のコードの海に溺れ、信頼を失いかけた地獄の 72 時間

そこからの 72 時間は、まさに地獄でした。

原因が分からない。どこをどう直せばいいのか、皆目見当もつかないのです。

テストコードがあれば、どの部分に問題があるのか、もっと早く切り分けができたはずでした。しかし、僕の手元にあるのは、何の道標もない、ただただ広大で複雑なコードの海だけ。

僕は、その海にたった一人で放り出され、溺れかけていました。

一行一行、自分の書いたコードを目で追い、仮説を立てては、それが打ち砕かれる。その繰り返し。クライアントからの「まだですか？」という催促のメッセージが、僕の心をさらに深く抉りました。

不眠不休の調査の末、僕はついに原因を突き止めました。特定の条件下で、API へのリクエストが二重に送信されてしまうという、初歩的とも言えるバグでした。テストを書いていれば、5 分で発見できたはずのミスです。

バグは修正できましたが、失ったものはあまりにも大きかった。クライアントの信頼、そして何より、自分自身への信頼です。

「僕はプロとして失格だ」

パソコンの前で朝日を迎えながら、僕は自己嫌悪に苛まれていました。このとき、心の底から誓ったのです。二度と、こんな思いはしない。二度と、品質から逃げるのはやめよう、と。

「動けばいい」という考え方が、僕を殺しかけた瞬間でした。

転機は、一人のエンジニアの言葉だった

EC サイトのプロジェクトで心身ともに燃え尽きた僕は、しばらく仕事への情熱を失いかけていました。自分の書くコードに自信が持てず、キーボードを打つ指が震えることさえありました。

「また、何か見落としているんじゃないか？」
「自分のコードは、本当に信頼できるものなのか？」

そんな疑心暗鬼に苛まれながら、僕はただ時間だけを浪費していました。まるで、濃い霧の中で羅針盤を失った船のように、どこに進めばいいのか分からなくなっていたのです。

心身ともに燃え尽きた僕が出会った、ある技術ブログ

そんなある日、僕は救いを求めるように、漫然とインターネットの海を漂っていました。そこで偶然、あるベテランエンジニアの技術ブログにたどり着いたのです。