この記事は Wano Group Advent Calendar 2025 の13日目の記事となります。
昨日の Copilot エージェント導入で、開発者の生産性は本当に上がったのか？ は読みごたえがありましたね。ただ現場の定量的な評価のみならず 物量が増える → コンテクストスイッチが増える → 心理的な負荷がかかる という分析は舌を巻きました。
それでは本日も張り切っていきましょう！
ネタバレ
- 過去（前職）編でつくったアプリのカメラを立ち上げたときにストリームが開けっぱなしだったせいで落ちまくったよ
- いま見返すと、対策できるレイヤーは多岐に渡るよ
- コーディング規約
- レビューの粒度
- テストの強さ
はじめに
こんにちは！@shibe_ です。TuneCore Japanでバックエンドエンジニアをしています。
2022年の3月にTuneCore Japanに入りました（採用に至るまでの経緯などはこちら）。
それよりもずっと昔、ヒヨッコだったころ、起こしたやらかしをここに供養したいと思います。
コンプライアンスに抵触しないよう、ある程度内容をぼかしてぼかして書いてます。すべて見逃してください
エピソードトーク
当時、自分はとあるアプリケーションを開発していました。スマートフォンで撮影した写真を、メニュー画面を介さずサーバーにぶっこむ機能です（よくありますよね）。コードレビューも通り、撮影テストも終え、意気揚々と本番に反映。翌日にはアプリケーションが落ちるという問い合わせが積み上がっていました。
原因特定：しらみ潰しの地獄
🐕なんで？？？？
と、件のアプリケーションを立ち上げてカメラ撮影をしますが特に異常はありません。
開発者のおてもとで再現できないのに本番環境で起きまくるエラー。
あせる気持ちを抑えつつ、原因を特定するために問題の切り分けに入ります。
サーバ側との通信がうまくいかない時に落ちるのかな？と試したり、
特定の操作を行ったときに問題が発生するのかとさまざまな動かし方をしてみたり、
ずーっとただソースコードをながめてみたり なめてみたり 音を立てたり 嗅いでみたり。
そうするうちに、一度に写真を何枚も撮影しているとアプリケーションが落ちることがわかりました。
（ログ取って収集せんかい。ワタシもそう思います。それはまた別のおはなし）
そうしてカメラ周りのソースコードを舐めるように眺め、
読解力に乏しいため何度も見直し、五周目に差し掛かったころ、
🐕 アッッッッッ！！！！！Stream開いたまんまや！！！！！
なぜテストやレビューで気づけなかったのか
原因はいくつか考えられますが、
- テスト量と実運用量の差が大きかったこと
- クソデカPRでレビュアーの認知負荷が大きかったこと
- 「動いてる」ことへの安心感でそのままエイヤとぶっ込んでしまったこと
あたりが大きな原因かなと考えます。
特に
「動いてる」ことへの安心感でそのままエイヤとぶっ込んでしまったこと
この現象は残り時間に追われるエンジニアの脳裏にチラつく考え方なのではないでしょうか。
今ならこう防ぐ：設計・レビュー・テスト
設計/コーディングで防ぐ
たとえばC# ではOpen / Closeを使わずにusing 節を使うことで開けっ放しを防ぐことができます。
using (FileStream fs = new FileStream("test.bin", FileMode.Open))
{
// すべてを実行
}
// file streamは closeされている
また、Goでは即座に defer f.Close を書く慣習があるためこれを防ぎやすいですね。
f, _ := os.Open(path)
defer f.Close() // ループ内で defer を積みすぎると、Close が遅れて別の事故になるので注意
ですが、慣習や心構えのみならずそれをlinterやstaticcheck などで回避するのがより安全です。
レビューで防ぐ
これらの対応漏れは、データ構造や変数の命名、各層の責務といった内容と比較して見えづらいミスだと思います。
そのため該当箇所がある開発の場合はまず明示するのが安全そうです。
また、ブランチ戦略も重要と考えます。過去の自分が行ったようなビッグバンプルリクでは
こういった細かい箇所を拾い切ることはとても難しいです。
現代では GitHub Copilot や Claude Code などにレビューさせたり、書いてもらうことができます。
が、それでもデカいプルリクは出すほうも見るほうも疲弊しやすく、どんなにAIの手によってわかりやすくされた指摘も
「動いてるならエエか＾＾」と見逃しやすくなり、事故に繋がる危険があることを頭に置きましょう。
テストで防ぐ
耐久テストを実施しましょう。
機能を満たしているかは、想定する数のアクセスや実行回数を耐えられてはじめて成立すると考えて差し支えないです。
アクセス数や実行回数の指標を立て、その回数実行して問題がないか確認するのが安全でしょう。
最近はこのようなテストも自動化するツールが台頭してきたので、耐久性を試すには追い風といえます。
おわりに
ン年前の自分へ
張り倒すぞ。
この記事を読む人々へ
ご安心ください。
幸いにして、現代では
・gitでのより直感的なブランチ管理
・莫大な集合知を用いたブランチ戦略
・LLMを用いたコーティングやレビュー
・自動化されたテスト
とガードレールが非常に充実した環境になりました。
しかしながらガードレールがあっても事故は起こるもの。ン年前の事故と笑い話にできるか……というとやや不安が残ります。
それを防いだり、被害を最小限に抑えるのも我々の役目となります。
気張っていきましょう。
この記事で、より多くの魂が救われることをここで祈り続けています。
TuneCore Japan では 一緒に働くメンバーを募集しています。
エンジニアだけでなく、Director等の各種ポジションをオープンしているので興味がわいた方はぜひご覧ください！