🏠

【失敗と学びシリーズ】本番環境のサービス画面上に localhost のリンクが埋め込まれた話

BABY JOB 開発部

2025/02/13に公開

失敗

失敗と学び

idea

!本記事は BABY JOB開発部の失敗と学びシリーズ の記事です。

 はじめにBABY JOB 開発部のミヤギです。

本記事では、最近起きたチームの失敗の事例と、そこから得た学びを共有します。

この事例が、読んだ方の頭の片隅に残り、何かしらお役に立てると幸いです。

 ことの発端あるタスクの一環で、プロダクト全体のデザインを見直していた時のことでした。

ステージング環境を使って、よく使われる画面からニッチな画面まで、様々な機能を触っていると、最近追加されたリンクを発見。

「こんな仕様になったんだ〜」と思いそのリンクを押してみました。
すると、以下の画面が。。

実際の画面
画面をよく見ると「localhost」の文字。

前述の通り、ここはステージング環境です。
「まさか、そんなはずは。。！」
私は震える手で本番環境に確認しに行きました。
※ 当時の状況をイメージしやすいよう、多少脚色しています。

 何が起きたのかご想像の通り、本番の画面上にも http://localhost:8000/~ を含むリンクが出てしまいました。

幸い、かなりニッチな操作をしたときにのみ表示されるリンクだったため、影響は小さくすみました。

 なぜ起きたのか
 原因<a> タグのパス指定をすべき箇所にローカル環境でのフルパスを指定していました。

以下にソースのイメージを記載します。
## 誤った修正
<a href="http://localhost:8000/test"><strong>テスト記事</strong></a><br>

## 正しい修正
<a href="/test"><strong>テスト記事</strong></a><br>

 経緯このコードは、ある機能開発の仕様検討フェーズで混入しました。

画面仕様を検討するための仮実装をしたときに、ローカル環境で取得した URL をコピペ、という感じです。

その後、実装で URL を正すことを失念し、ローカル環境で動作確認しても問題なく動くためすり抜けました。

また、軽微な修正内容であり、環境による挙動の差はないと考えた（パスを指定しているつもりだった）ため、ステージング環境で動作確認せずリリースされました。

実際のプロセス

 どうしたのか発覚後、当日中に修正してリリースしました。

また、再発防止のためにふりかえりを実施しました。

 ふりかえり手法本事象に対するふりかえりは、「事実確認」と「考察」の 2 部構成で実施しました。

これは論点を絞ることがねらいで、事実確認は淡々と行い、改善ポイントの議論を厚めにしたかったためです。

ふりかえりでは以下の独自フレームワークを利用しました。

利用したフレームワーク
前半戦
参加者：実装者・レビューア・ファシリテータの 3 名
ふりかえり範囲：「事象」「原因となった要素」の洗い出し

後半戦
参加者：チームメンバー全員
振り返り範囲：「対策の案」の検討

ふりかえりでは活発な議論が行われ、さまざまな案が出ました。

中には「ローカル環境でも localhost の利用を禁止する」という案も出ましたが、個別具体的な対策は制約が増え過ぎてしまう副作用があるので選択しませんでした。

実際の様子

 どう防ぐのかふりかえりの結果、以下 3 つの観点で対策を講じることにしました。

 教育の観点本事象をチーム内に周知しました（本記事もその一環です）。
今回、コードレビューもちゃんと行なっていましたが、レビューアも人間なので見逃すこともあります。

「こういうこともあったよ」という事例を頭の片隅に残し、今後の気づきとなればと思います。

 混入防止の観点チームの Working Agreement に以下の内容を追加しました。
リリースする予定のないコードを仮実装する場合は TODO コメントを記載する
仕様検討などのスピードを優先すべきタイミングでは、なりふり構わずに実装することもあります。

この事実を許容し、実装者は TODO コメントをもって「絶対コミットしないぞ」という意思表示してもらいます。

TODO コメントがあれば、静的解析ツールやコードレビューで検知できるだろうという魂胆です。

 検知の観点環境ごとの動作確認実施基準を整備することにしました（実施中）。
今回の事象は、軽微な修正・ローカルで動作確認済みということで、ステージング環境での動作確認が省略されました。

この判断自体には再現性があり、全員の記憶を消して同じ改修をすると、おそらく再発します。

そのため、現時点での判断基準を見直してみようと思います。

場合によっては、動作確認の省略を許容する基準になるかもしれません。

 終わりに今回、初めて "チームの失敗" としての記事を書いてみました。

失敗した個人が失敗事例をふりかえると、反省文になりがちで、客観的に整理できないことがあります。

そこで、チームごととして記事を書くことで、失敗事例を単なる事象として捉え、整理することができました。

やってみて良かったので今後も続けたいと思います。