はじめに
先日、Jasst'2026 Tokyo に参加させて頂いた際に聞いた「あなたのシステムの壊し方」という講演がとても印象的だったので、感じたことや調べたこと等を、この記事で共有させて頂こうと思う。
講演の概要としては、Unknown-Unknown(考慮していていない、壊してみて初めて気づく領域)、もしくはKnown-Unknown(壊れうることは知っているが、壊れたとき何が起きるかわからない領域)の事象を、様々なツールや手法を用いて、わざとシステムを破壊することで、Known-Knownとしてきちんと対策を講じることで、システムの品質を高めることができる、というような内容だった。
私はこの講演を聞いて、Known-UnknownやUnknown-Unknown領域に対しての考慮が全くなかったことに気づき、「正常系ばかりテストして安心している」自分がいることを認識した（システムを壊す重要性を、知らないことを知らない状態から、知っている、という状態へレベルアップできたとも言える（Unknown-Unknown⇒Known-Knownへの変換））。
では、どうやってシステムを壊せばいいのか、フロントエンドの開発者にとっても最も身近で気軽に実践できる、開発者ツールを用いたシステムの壊し方、を色々調べたので紹介しようと思う。
システムの壊し方
① 通信をオフラインにする
やり方
DevTools → Network → Offline を選択
壊れるポイント
- API通信がすべて失敗する
- ローディングが止まらない場合がある
- エラーメッセージが表示されないことがある
- 再試行処理が実装されていないと操作不能になる
② 通信速度を落とす
やり方
DevTools → Network → Slow 4G
壊れるポイント
- ローディング時間が極端に長くなる
- 非同期処理のタイミングずれで表示崩れが発生する
③ リクエストをブロックする
やり方
DevTools → Network → 該当のリクエストを右クリック → Block requests → Block request URL
壊れるポイント
- 特定APIのみ失敗することで画面の一部だけが壊れる
- 依存している外部リソース（CDN等）が読み込めなくなる
- 一部データが欠損した状態でUIが表示される
- 想定外のnull/undefinedによりエラーが発生する
④ レスポンスを改ざんする
やり方
DevTools → Network → 該当のリクエストを右クリック → Override content → ファイル保存先が開くので編集して改ざん
壊れるポイント
- 想定外のレスポンスでUIが崩れる
- フロント側が正常レスポンスに依存している場合、処理が停止する
⑤ Cookie を壊す
やり方
DevTools → Application → Cookies → 表示されるクッキーの値を修正
壊れるポイント
- セッションが切れた状態になる
- ログイン状態の不整合が発生する
- 認証エラーが適切に処理されない
- ユーザー状態が中途半端な状態で画面が表示される
⑥ css を無効化する
やり方
DevTools → Elements → Styles → 該当のチェックボックスのチェックを外す
壊れるポイント
- レイアウトが崩壊する
- 見た目に依存した設計の弱さが露呈する
おわりに
これまでテストは、「正しく動くこと」を確認するものでした。しかし、実際のユーザーが体験し、そして品質が著しく低下するのは「壊れる瞬間」だと思っています。
だからこそ重要なのは、
壊れないシステムを作ることではなく、壊れても安心できるシステムを作ること、なのかなと思い、その第一歩が、「意図的に壊してみること」だと思いました。
ということで、どんどん壊していきましょう！！