結論から言うと、技術負債は「見えないコスト」じゃなくて「見えていないコスト」だ。
OpenAIのエンジニアブログを読んだ。大規模なコアダンプ解析を使って、インフラの稀なクラッシュ原因を追いかけたら、ハードウェアの障害と、18年間誰にも気づかれなかったソフトウェアのバグを同時に発見したという話だ。18年前と言えば2006年。自分はまだ大学生だった。そのバグはずっとそこにあったのに、誰も見つけられなかった。
読んでいてすぐ思ったのは、うちの話じゃないかということだ。従業員8人のスタートアップで、インフラ担当は実質1人。Claudeを業務全面導入してから開発速度は上がったが、それと同時に「古いコードに新しい機能を継ぎ足している」状態がじわじわ進行している感覚がある。
スタートアップが技術負債を無視するコストはROIで語れる
OpenAIほどの規模でも18年越しのバグが潜んでいた。うちみたいなフェーズのスタートアップなら、負債の密度はもっと高いはずだ。PMFを急ぎながらコードを書いてきたから、当然だ。問題は、それが「いつ爆発するか」ではなく「すでに静かにROIを削っているかどうか」という視点で見ていなかったことだと気づいた。
OpenAIのケースで面白いのは、発見の手法だ。個別の障害対応ではなく、大量のコアダンプを統計的に分析した。いわば障害の「疫学調査」をやった。単発で見ていたら絶対に気づけなかった異常を、データの集積から見つけた。
これ、自分たちに置き換えると何に当たるか。バグレポートの傾向分析、サポートチケットのパターン、デプロイ後のエラーログ集積、そのあたりだ。うちはまだそこを「感覚」でやっている部分が多い。Claudeにログ解析を任せている箇所はあるが、体系化はできていない。
投資家への説明でも技術負債は避けて通れない
シリーズAの調達を準備している中で、デューデリで技術スタックを聞かれることが増えてきた。先月、あるVCから「スケール時のボトルネックはどこですか」と直球で聞かれた。正直に言えば、今の構成で10倍のユーザーを捌けるかどうか、自分たちでも確信が持てない部分がある。
投資家はGTMだけ見ているわけじゃない。プロダクトの内部品質、技術的なスケーラビリティ、それを支えるエンジニアの実力、全部セットで判断される。「18年前のバグが残っていました」なんてことが、うちの規模で起きたら致命的だ。リカバリするリソースがない。
OpenAIの話が刺さったのはそこだ。大きな組織でも体系的な調査をやらないと見えないバグが残る。うちみたいに小さな組織なら、もっと積極的に「定期的な内部スキャン」の仕組みを作らないといけない。感覚頼りで進めてきたツケが、スケールフェーズで一気に来るのがいちばん怖い。
競合の何社かがすでにAIを使ったコードレビュー自動化を導入しているという話も聞いた。エラーパターンをAIに学習させて、異常検知の精度を上げているらしい。費用対効果で言えば、エンジニア1人が週に数時間を手動レビューに使うより確実にROIが出る。
うちでやるとしたら、まずClaudeにエラーログの定期サマリーを出させる仕組みから始める。週次で傾向を見て、スパイクしているエラー種別があればその週に対処する、そういうサイクルを作ることだ。OpenAIがやったような大規模コアダンプ解析は無理でも、小規模版の「障害の疫学」ならできるはずだ。
18年間誰も気づかなかったバグという話は、怖い話であると同時に、発見できる手法があるという話でもある。自分たちが今見えていないものを、どうやって可視化するか。そこに時間とコストを使うタイミングは、調達前の今だという気がしている。