ある日の終電後。オフィスには私しかいなかった。
蛍光灯は半分消えている。デスクのモニターだけが、青白い光を放っている。IRCの通知は止まっている。誰も見ていない。誰も知らない。今、私がここで何をしても、誰にも分からない。
三時間前、本番環境で障害が発生した。
顧客からの問い合わせが殺到した。Nagiosのアラートチャンネルが真っ赤に染まった。私はオンコール担当だった。原因を調査した。特定した。十五年前に書かれたコードの中に、バグがあった。
なぜ今頃発火したのか。おそらく、長らく使っていたNFSの性能が落ちていたからだ。十五年間、たまたま踏まなかった地雷を、今夜ついに踏んだ。バグは十五年前からそこにあった。ただ、表に出てこなかっただけだ。
障害は収束した。暫定対応でサービスは復旧した。しかし、根本原因を修正しなければ、また同じ障害が起きる。明日の朝までに、修正をリリースしなければならない。
画面には、十五年前に書かれたコードが映っていた。
変数名は tmp と data と result の三種類しかない。コメントは一行もない。テストは存在しない。一つの関数が八百行ある。その関数の中に、さらに三重のネストしたif文がある。読んでいると、頭が痛くなる。
しかし、このコードは動いてきた。十五年間、今夜まで、一度も止まることなく、毎日数万件のトランザクションを処理してきた。
私は、二つの選択肢の前で立ち尽くしていた。
正しいやり方——リファクタリングする。テストを書く。変数名を直す。関数を分割する。その上で、バグを修正する。それには、最低でも三週間かかる。明日の朝には間に合わない。その間、同じ障害が再発するリスクを抱え続ける。
間違ったやり方——このコードの該当箇所に、場当たり的なパッチを当てる。動けばいい。テストは書かない。後で直す。いつか直す。たぶん、直さない。
私は知っていた。後者を選べば、このコードはさらに腐る。次にこのコードを触る人は、私を呪うだろう。しかし、その「次の人」は、私ではない。
——と書いて、立ち止まる。本当にそうか。「次の人」は、来年の私かもしれない。
それでも、私は迷っていた。
「正しいコードを書け」。
私は、何度もこの言葉を聞いてきた。本で読んだ。カンファレンスで聞いた。先輩に言われた。自分でも言ってきた。
SOLID原則。DRY原則。クリーンアーキテクチャ。テスト駆動開発。私は、これらの「正しさ」を信じてきた。信じていた、と思っていた。
しかし、終電後のオフィスで、十五年物のレガシーコードを前にして、障害の再発リスクを抱えながら、私は気づいた。
「正しさ」は、昼間の言葉だ。
昼間は、みんながいる。コードレビューがある。品質基準がある。「正しさ」を語ることで、評価される。「リファクタリングしましょう」と言えば、「意識が高い」と思われる。
しかし、夜になると、誰もいない。誰も見ていない。「正しさ」を語る相手がいない。
残っているのは、障害の再発リスクと、明日の朝というデッドラインだけだ。
私は思い出した。以前、ある先輩が言っていた言葉を。
「コードの美しさなんて、障害対応の現場には関係ない。止血が先だ」
当時の私は、反発した。「技術的負債がたまる」「保守性が下がる」「長期的に見れば損だ」。正論を並べた。先輩は笑って聞いていた。今になって分かる。あの笑いの意味が。
先輩は、私の「正しさ」が、まだ試されていないことを知っていた。
本番障害の修羅場を経験したことがない。顧客からのクレームの電話を受けたことがない。自分の判断で、会社の信用が左右される経験をしたことがない。そういう人間が語る「正しさ」は、空論だ。
——と書いて、自分の中にある別の声が聞こえる。それは、本当にそうか。「試されていない」ことが、「正しくない」ことの証明になるのか。試されていなくても、正しいものは正しいのではないか。
しかし、その夜の私には、その声は届かなかった。
私は、キーボードに手を置いた。
そのとき、ふと考えた。十五年前、このコードを書いた人は、何を考えていたのだろうか。
きっと、同じような状況だったのではないか。締め切りに追われていた。リソースが足りなかった。「後で直す」と自分に言い聞かせて、このコードを書いた。
その人も、テストを書かなかった。変数名を直さなかった。コメントを書かなかった。なぜか。時間がなかったからだ。
その人の後に来た人も、同じだったのではないか。このコードを見て、顔をしかめた。しかし、直さなかった。なぜか。時間がなかったからだ。
そして今、私がここにいる。同じ選択を迫られている。
「時間がなかった」。
この言葉が、十五年間、このコードを腐らせ続けてきた。そして今、私も同じ言葉を使おうとしている。
これは、正当化の連鎖だ。「前の人も時間がなかった。だから、自分も許される」。前例が、免罪符になる。
私は、その連鎖の中に自分を位置づけようとしていた。連鎖の一部になれば、責任は薄まる。「自分だけが悪いわけではない」と言える。責任を、過去に分散させることができる。
——と書いて、その論理の欺瞞に気づく。責任を分散させても、コードは腐ったままだ。連鎖に加わることで、私が得るのは心理的な安心だけだ。コードは何も改善しない。
しかし、その夜の私には、心理的な安心が必要だった。
私は、自分を正当化する論理を組み立て始めた。
この会社は、このプロダクトで売上を立てている。プロダクトが止まれば、顧客は離れる。顧客が離れれば、売上は下がる。売上が下がれば、会社は傾く。会社が傾けば、私は職を失う。
正しいコードを書いている間に、サービスが止まり続けたら、何の意味がある？
障害を早く直すことは、顧客のためだ。会社のためだ。同僚のためだ。そして、自分のためだ。
みんなのためにやっている。だから、許される。
この論理は、強力だ。「自分のため」だけなら、罪悪感がある。しかし、「みんなのため」なら、むしろ正義になる。利他的な動機があれば、手段は正当化される。
私は、この論理に身を委ねようとしていた。
しかし、ふと気づいた。十五年前の人も、同じ論理を使ったのではないか。「顧客のために、早くリリースしなければ」「会社のために、間に合わせなければ」。そう言い聞かせて、このコードを書いた。
その結果が、今夜の障害だ。
「みんなのため」という論理で書かれたコードが、十五年後に「みんな」を苦しめている。
私は、同じことをしようとしている。今夜、「みんなのため」にパッチを当てる。そのパッチが、十五年後に誰かを苦しめる。
正当化の論理は、短期的には機能する。しかし、長期的には破綻する。「みんなのため」は、「将来のみんな」を含んでいない。
——と書いて、また立ち止まる。では、どうすればいいのか。障害を放置して、明日も明後日も顧客を苦しめることが、「将来のみんな」のためになるのか。
どちらを選んでも、誰かを苦しめる。それが、この状況の本質だ。
コードを書いている途中で、手が止まった。
私は、自分が何をしているのか、急に分からなくなった。
画面には、私が追加したパッチがある。八行。たった八行の条件分岐だ。バグの原因となっていたエッジケースを、特別扱いする。根本的な解決ではない。しかし、これで障害は再発しなくなる。たぶん。
私は、自分のコードを見つめた。そして、気づいた。
私は、このコードを十五年後に見る誰かを、呪っている。
私は、十五年前にこのコードを書いた誰かを呪った。「なぜこんなコードを書いたのか」「なぜテストを書かなかったのか」「なぜリファクタリングしなかったのか」。呪いながら、同じことをしている。
十五年後の誰かは、私を呪うだろう。同じ言葉で。同じ怒りで。そして、同じように、さらに八行のパッチを追加するだろう。
呪いの連鎖だ。
私は、その連鎖の一部になろうとしている。連鎖を断ち切ることもできる。リファクタリングすればいい。テストを書けばいい。しかし、それには三週間かかる。明日の朝には間に合わない。
連鎖を断ち切るコストを、私は払えない。いや、払う気がない。
コストを払う気がないのは、なぜか。それは、連鎖を断ち切る恩恵を受けるのが、私ではないからだ。
リファクタリングの恩恵を受けるのは、十五年後の誰かだ。その誰かは、私ではないかもしれない。私は、十五年後にはこの会社にいないかもしれない。別のプロジェクトにいるかもしれない。そもそも、このプロダクト自体が、十五年後には存在しないかもしれない。
コストは今の私が払い、恩恵は未来の誰かが受ける。それなら、コストを払わない方が、合理的だ。
私は、その論理に抗えなかった。
気がつくと、窓の外が明るくなっていた。
目が痛い。徹夜明けの頭が、鈍く重い。始発の電車が走る音が聞こえる。オフィスのエアコンが、タイマーで動き始めた。
私の目の前には、完成したパッチがあった。テストはない。コメントは一行だけ。「障害対応: エッジケースの特別処理を追加」。それだけだ。なぜそう書いたのか。どんな判断をしたのか。何も書かない。書けない。
いや、違う。書かないのだ。書くと、自分がやったことを認めることになる。認めたくない。だから、曖昧にする。
ステージング環境でテストした。動いた。本番環境にデプロイした。障害は再発しなかった。アラートは鳴らなかった。IRCに報告を書いた。「根本原因を修正しました。再発防止策は別途検討します」。
「別途検討します」。
この言葉が、どれほどの問題を先送りしてきたか。私は知っている。知っていて、使っている。
私は、椅子にもたれかかった。疲れていた。しかし、安堵もあった。終わった。障害は収束した。顧客は救われた。私の仕事は終わった。
そして、私は立ち上がって、オフィスを出た。
朝の光が、眩しかった。夜の間に考えていたことが、すべて嘘のように思えた。「正しさ」も「正当化の連鎖」も「呪いの連鎖」も、夜の闘いの産物だ。朝になれば、消える。
いや、消えるのではない。見えなくなるだけだ。
朝の光の中で、私は「普通のエンジニア」に戻る。「正しいコードを書くべきだ」と語る。「技術的負債は早めに返すべきだ」と主張する。昼間の私は、そう言う。
しかし、また夜が来る。また障害が来る。誰もいないオフィスで、同じ選択を迫られる。そのとき、私は何を選ぶか。
私は、自分が何を選ぶか、もう知っている。
この文章を読んでいるあなたは、どうだろうか。
「私は違う」と思っているかもしれない。「私は正しいコードを書いている」「私はリファクタリングをしている」「私は技術的負債を返している」。そう思っているかもしれない。
本当にそうだろうか。
あなたは、一度も「後で直す」と言ったことがないか。一度も、テストを書かずにコミットしたことがないか。一度も、分かりにくいコードをそのまま追加したことがないか。一度も、「別途検討します」と書いたことがないか。
ないはずがない。
私たちは、みな同じ箱の中にいる。状況が許せば、正しいことをする。しかし、状況が許さなければ、正しさを捨てる。そして、「仕方なかった」と自分を正当化する。
これは、個人の問題ではない。箱の問題だ。
締め切りがある。障害対応の緊急性がある。リソースが足りない。時間が足りない。この箱の中で、「正しさ」を貫くことは、英雄的な行為だ。普通の人間には、できない。
——と書いて、自分でも分かっている。「箱を変える」と言うのは簡単だ。実際に変えるのは、難しい。私自身、何度も挫折してきた。
しかし、箱を変えようとしなければ、私たちは永遠に同じ場所にいる。夜ごとに「正しさ」を捨て、朝になると何事もなかったかのように振る舞う。その繰り返しだ。
私は、その繰り返しから抜け出したい。しかし、抜け出せることを、確信できない。
この矛盾を抱えたまま、私は今日もコードを書いている。
あの夜から、三ヶ月が経った。
私が当てたパッチは、まだ動いている。障害は再発していない。顧客からのクレームもない。障害対応は成功した。誰も、あのコードの中身を知らない。
しかし、私は知っている。あのコードの中に、たった八行のパッチがあることを。テストがないことを。コメントが一行しかないことを。「別途検討します」と書いた根本対応が、まだ検討されていないことを。
そして、いつか誰かが、あのコードを触ることになる。そのとき、その人は私を呪うだろう。「なぜこんなパッチを当てたのか」「なぜ根本対応をしなかったのか」と。
私は、その呪いを受け入れる準備ができている。いや、できていない。受け入れなければならないと分かっているだけだ。
次の障害が来たとき、私は何を選ぶか。「正しさ」を選ぶか。また同じ論理に堕ちるか。
私自身にも、分からない。
分からないまま、今日も私はオフィスに向かう。昼間は「正しさ」を語り、夜になれば「正しさ」を捨てる。その繰り返しの中で、私は何者になっていくのか。
十五年前の人は、一度だけ選択した。その選択の結果が、今夜の障害だった。
しかし、エンジニアは、毎日選択を迫られる。毎日、小さな「正しさ」を捨てるか、守るかを選ぶ。
その積み重ねが、私たちを作る。そして、十五年後のコードを作る。
私は、どんなエンジニアになりたいのか。どんなコードを残したいのか。
その問いに、まだ答えられない。答えられないまま、今日も私は、コードを書く。
十五年前の人の行方は、誰も知らない。
私の行方も、私自身が知らない。
