「遅いですよね、あなたのせいですよ」
冗談で言われたんだとわかってる。みんなで笑ってた。自分も愛想笑いをした。
でも何もできなかった。検索が遅い理由はわかってきた。でも直す方法も、直す余裕も、まだなかった。そのとき一番歯痒かったのは、笑われていることより、何もできない自分のことだった。
引き継いだとき、自分はまだ何も知らなかった
30歳を超えてからエンジニアになった。未経験のまま医療系スタートアップに入って、治験CRMというシステムを引き継ぐことになった。
「ベンダーが作ったものだから」という言葉で、それまで誰もコードの中身を見ていなかった。
自分は違う向き合い方をするしかなかった。必死さが違った。同い年のエンジニアはとっくに数年のキャリアがある。自分にはなかった。だから勤務時間のほぼ全部をコードに費やした。舐め回すようにコードを読んだ。何をしているのかわからなくても読み続けた。
意味が分かった日の達成感は今でも覚えている。
最初に気づいた「遅さ」の正体
システムを使い始めた社内から、検索が遅いという声が上がり始めた。治験の被験者データは50万レコード近い。複雑な条件の検索になると、画面がフリーズするような感覚になる。
コードを追っていくと、原因はわかった。複数テーブルの複雑なJOINが、毎回フルスキャンに近い動作をしていた。ベンダーが設計した当時は件数が少なかったのかもしれない。データが積み上がったことで、ほころびが表面化した。
わかったが、すぐには直せなかった。自分はまだそのシステムの全体像を把握できていなかった。下手に触って壊すことへの恐怖があった。
その間も「遅い」という声は続いた。
マテリアライズドビューで、ようやく息ができた
時間をかけてシステムを理解した末に、マテリアライズドビューという仕組みに行き着いた。事前に集計結果をテーブルとして保存しておき、検索時には高速で参照できるようにする。
導入後、検索の体感速度が劇的に変わった。
「あなたのせいですよ」という冗談が聞こえなくなった。それだけのことなのに、それがすごく大事なことだった。
ただ正直に言うと、あのときもっと早く動けたかもしれないという気持ちは残っている。コードを理解することに時間をかけすぎた。焦って壊すよりはよかったと思うようにしているが、使っている人たちの不満の時間は変えられない。
今も直したいものはある
マテリアライズドビューの問題が落ち着いてからも、「直したい箇所のリスト」は消えない。むしろ理解が深まるほど、見えてくるものが増えていく。
でも「直したい」がそのまま「直せる」にはならない。
本部長は経営の視点で「この機能の優先度が高い」と言う。現場は現場で「この部分が使いにくいから直してほしい」という。そしてテックリードの自分は「このモジュールを先に整理しないと、どっちも安全に進められない」と思っている。
全員が正しい。全員の優先事項が違う。
結果として、コードの改善は後回しになり続ける。「今のうちに直しておけば後が楽になる」という主張は技術者には自明でも、ビジネスの文脈では「今は機能を進めてほしい」になりやすい。
「管理し続ける」という感覚に変わった
技術的負債は「いつか全部返済できる問題」ではないと、今は思っている。
完璧に綺麗なコードベースより、動くシステムの方が価値がある——これはビジネスの論理として正しい。でも「触るたびに壊れそうで怖い」コードが積み上がり続けると、開発スピードは落ちるし、メンバーのモチベーションも下がる。
自分が今やっていることは、「全部直す」でも「全部諦める」でもない。触るたびに少しだけ状態をよくする。次に触る人間が少しだけ理解しやすい状態にしておく。それの繰り返しだ。
地味だし、目に見えにくい。でも3年前と今のコードを見比べると、確かに変わっている。
直したいものはまだある。今日も後回しになっている。それが現実だ。
関連記事: