Slide 1
Slide 1 text
2026/2/6
【障害報告】
新生活の「要件」を盛りすぎて
リリース1ヶ月でシステムダウンした件
u-Hoshi(ゆーほし)
Slide 2
Slide 2 text
障害内容：リソース枯渇によるシステムダウン
症状：39度の発熱
影響範囲：業務・生活パフォーマンス低下
原因：要件定義の盛り込みすぎ
概要
Slide 3
Slide 3 text
・
「まだいける」と言い続けている人
・最初から全部入り設計をする人
・疲れているのに仕様を下げない人
共有対象者
Slide 4
Slide 4 text
1.システム紹介
2.タイムライン
3.3つの原因分析
4.教訓
5.再発防止策
6.まとめ
アジェンダ
Slide 5
Slide 5 text
システム紹介
Slide 6
Slide 6 text
タイムライン
8月 9月 10月前半 11月
10月後半
大型リリース 高負荷状態 障害発生 暫定復旧 完全復旧
新環境(同棲)
へ移行完了
外部リクエスト急増
（合宿・イベント・
飲み会）
警告ログ（ダルい）
を無視して運用継続
昼12時ダウン
レイテンシ増大
（微熱・咳）
デグレ解消
Slide 7
Slide 7 text
1.システム紹介
2.タイムライン
3.3つの原因分析
4.教訓
5.再発防止策
6.まとめ
アジェンダ
Slide 8
Slide 8 text
工数見積もりの甘さ
原因①
計画
実家と変わらない生活レベルを維持
非同期処理で終わる見込み
Slide 9
Slide 9 text
工数見積もりの甘さ
原因①
計画 実績
実家と変わらない生活レベルを維持
非同期処理で終わる想定
同期処理の連続
献立を考える→
材料調達→
料理→
皿洗い
待ち時間の発生
皿を洗わないと料理が作れない
洗濯が終わるまで外出不可
Slide 10
Slide 10 text
■ 高すぎる目標を「勝手」に設定
オーバースペックな要件定義
原因②
「丁寧な暮らし」という謎の仕様書を作成
非機能要件が異常に高い
根拠はプライド
Slide 11
Slide 11 text
■ 要件
オーバースペックな要件定義
原因②
「毎日自炊」
→ 誰にも依頼されていない必須要件
「完璧な家事」
→ 非機能要件を過剰に設定
「業務外のタスク量を維持」
→ 既存ワークロードを削減しない
Slide 12
Slide 12 text
アラート無視と誤ったスケーリング
原因③
アラートのミュート
「楽しいから大丈夫」と疲労のアラートを無視
誤ったスケーリング戦略
回復ではなく稼働時間でスケール
技術的負債の放置
回復コストを未払いのまま稼働継続
Slide 13
Slide 13 text
その結果...
甘い見積もり
盛りすぎな要件
アラート無視
→エラーバジェットが0に
Slide 14
Slide 14 text
1.システム紹介
2.タイムライン
3.3つの原因分析
4.教訓
5.再発防止策
6.まとめ
アジェンダ
Slide 15
Slide 15 text
「運用体制に見合わない要件は破綻する」
MVPフェーズの運用に エンタープライズ級の品質（＝
実家レベル）を求めてはいけない
「バッファはコストではなく可用性」
予備リソースゼロ運用は突発イベントで即障害化する
教訓
Slide 16
Slide 16 text
要件定義の見直し
運用可能なSLOへ再設定
非コア機能の外部化
内製範囲を限定し負荷を削減
可観測性の導入
主観ではなくメトリクスを評価
再発防止策
Slide 17
Slide 17 text
高すぎる目標より
落ちない運用が正義
まとめ
Slide 18
Slide 18 text
2026/2/6
【障害報告】
新生活の「要件」を盛りすぎて
リリース1ヶ月でシステムダウンした件
u-Hoshi(ゆーほし)