How Lab. 第7回開催レポート – 後悔開発王決定戦2025

企業テック

howtv.hatenablog.com

前回の開催レポートに引き続き今月も社内勉強会 How Lab.の開催レポートをまとめていこうと思います。まず、はじめにHow Lab.とは？から説明します。

ハウテレビジョンでは社内技術共有イベント How Lab. を定期的に開催しています。参加者は開発メンバー中心に、最新技術の理解と実践に取り組んでいます。

毎月異なるチームが主催をするのですが、今月はこのブログの筆者が主催を担当して企画させていただきました。企画名は「後悔開発王決定戦2025」です。読んで字の如く、これまでの後悔している開発をLTしようぜという会です。

「後悔開発王決定戦2025」では、各エンジニアが過去経験した失敗・やらかしエピソードを共有し、その教訓を全員で学びます。笑いあり、涙あり、学びありの会です。参加者の投票により「最も価値ある後悔」を披露した人が後悔開発王に輝きます。

では発表について一部をピックアップして、簡単に内容をまとめていきたいと思います。

確認を怠ってはいけない

一つ目の登壇ではここ1年で発生した障害の振り返りとなりました。特に登壇者が関わった障害3つをピックアップしそれぞれの障害の重さとその原因について言及していきました。その原因のところがまさに後悔ポイントで「確認ちゃんとやってればこんなことには…」というものばかり、いや100%そうでした。じゃあなんで確認をできてなかったのかというと、小さな修正で影響は少ないという思い込みであったり、網羅的な確認はしなくても大丈夫だろうという認識だったりと聴講者みんな心当たりがありそうな理由となってました。
仕組みで解決するのはもちろんのこと、それでもみんな確認はちゃんとしていこうねという良い戒めとなりました。

Claudeに全部おまかせ☆

続いての登壇はClaude Codeでの開発中の事故に関しての発表でした。結論から言うと rm -rf ~/をYESしちゃってホームディレクトリが破壊された話ですね。エンジニアだらけの会場からは悲鳴が上がる内容です。

登壇者はプライベートの開発中に動画を見ながらClaude Codeからの許諾にYESを返していたそうです。その際にClaude Codeが謎のディレクトリを作成したらしく、「それいらないから消しといて」で発動したのがホームディレクトリの削除コマンドだったようです。

幸いなことに途中で気づいて実行を止めたそうなのですが当然被害はあり、

  • VS Code拡張機能が次々消失
  • エイリアスコマンドがNot Found
  • ホームディレクトリ全体が削除されてどんどんスリムボディに…
  • Udemy、O’Reillyの学習コンテンツ（思い出）も全消失…

という事態に。

プライベート開発のマシンでは怠っていたようですが、改めてClaude Codeの設定ファイルはみんな確認した方が良さそうですね。事故が起きてからでは遅いので…

~/.claude/settings.json に以下を記述:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "Bash(sudo *)",
      "Read(.env*)",
      "Read(./secrets/**)"
    ],
    "allowedTools": [
      "Read",
      "Write(src/**)",
      "Bash(git *)",
      "Bash(npm run *)"
    ]
  }
}

公式ドキュメントによると、denyルールはallowedToolsより優先されます。

教訓

  1. ✅ AIの提案コマンドは必ず内容確認
  2. ✅ rm -rf は特に危険
  3. ✅ ~/ = ホームディレクトリ全体 👈
  4. ✅ 事前にpermissions設定でブロック
  5. ✅ バックアップ大事

高額請求は突然に

続いての登壇では自身のやらかしというよりはインフラ、特にAWSでのやらかし事例まとめの発表となりました。改めてやらかしたら怖いんだぞというのを叩き込んでくれる発表でした。

  • インスタンスなどの消し忘れでの高額請求
  • Auto Scalingが残っていて消しても復活するEC2で高額請求
  • Lambdaの設定ミスで無限ループで高額請求
  • AWS Shield Advanceポチって高額請求

などなどいろんな高額請求の事例を教わりました。ハンズオンの消し忘れとか過去に筆者もやったのでとても懐かしく思います。

そんな高額請求のやらかしを防ぐ対策としてはAWSコンソール / Cost Explorer / AWS Pricing Calculatorなどでの確認であったり、コストの定期通知をSlackなどに送信し毎日確認できる習慣をつけておくことが大事なようです。自動停止の方法もあるのでそちらも頭に入れておきましょう。

最後のまとめの一節ですが、「サンドボックス使って慣れよう」これが一番大事ですね。弊社では各エンジニアが業務以外でも利用できるサンドボックス環境が存在するので、ここで学んでいくのが良さそうです。やらかしても連帯責任。

データ変更なんて1日でできるもん！

続いての登壇では前職の新卒時代（入社1ヶ月）でやらかした方の発表となりました。

入社まもなくの頃に依頼されたのがマスターデータの更新作業。タスク内容は、Course テーブル description カラムをMaster CSVを元に影響。

元気よく見積もりは1日で提出したそうです。元気な新卒とても良いですね。

そして何が起きたかというと「descriptionではなく、name を変更してしまった」という事件でした。

csv_rows.each do |csv_row|
  id = csv_row[0]
  description = csv_row|[3] // [3] は、name だった。[4]が,description
  Course.where(id: ).update(description: )
end

上司に助けてもらいなんとか復旧はできたそうなのですが、流石に肝が冷えそうなやらかし。

なんでそんなミスをしてしまったのかを振り返ると、テスト環境では、description, name が同じコンテンツとなっており、確認時に気づいてなかった、勘違いしてしまっていたということです。

というわけで彼がそのやらかしから学び心掛けるようになった対策はこちら

  1. 意味のあるテストデータを作ろう！
  2. 失敗すること考えよう
  3. 実装前に検証方法（テスト）を記載しておく
  4. データ移行系の見積もりは多めに出す

登壇者がちょうど現在取り組んでいるタスクとして決済テーブルのリファクタリングがあり、同じようなデータ移行のミスが起きないように細心の注意を払い安全なテーブル設計に取り組んでいるとのことです。筆者も昔データ移行で同じようにやらかしたことがあるので心に沁みる教訓でした。

今回のLTでは、最後に参加者みんなで投票を実施しました。見事に優勝した方には賞品としてRaspberry Pi 5 Starter Kitが授与され会の幕を閉じました。

普段のLTでは失敗談を聞くことは滅多にないので新鮮な会となりました。しっかり教訓から学ぶこともでき我々の成長につながったのではないかと思います。1年に一回くらいこういう回やっていきたいですね。

最後に、今回ご紹介した勉強会の取り組みに共感いただけるエンジニアの方がいらっしゃいましたら、ぜひ私たちのチームにジョインしませんか？弊社では、一緒に笑って学べるエンジニアを募集中です！

現在募集中の採用情報の詳細は下記をご覧ください。

https://herp.careers/v1/howtv/requisition-groups/dfc2cc4a-edcc-49c0-9d83-b5870b734c04




元の記事を確認する

Yahoo!ニュース、“釣り見出し”などに対応強化　メディアに対し「掲出減」のペナルティーも……背景を聞いた 前の記事 Chrome DevTools MCP vs Playwright MCP 次の記事

関連記事