Scale Game について
Scale Gameは、極端な規模で手法を試し、限界と維持される性質を明らかにする開発スキルです。量、速度、ユーザー数、期間、障害率などの観点から、小さい条件と大きい条件の両方を検証します。
主な機能
- 01検証する規模の軸の選択
- 02最小・最大条件での検証
- 03手法が破綻する地点の特定
- 04維持される性質の記録
活用シーン
- 01デプロイ前の本番環境の限界確認
- 02極端な条件でのアーキテクチャ評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/scale-gameを入力して読み込まれたか確認します。
詳細
スケールゲーム
概要
極端な規模でアプローチを試し、何が壊れ、何が意外にも持ちこたえるかを確認します。
中核となる原則： 極端な条件では、通常の規模では見えない根本的な真実が明らかになります。
クイックリファレンス
| スケールの側面 | 極端な条件でのテスト | 明らかになること |
|---|---|---|
| 量 | 1 件 vs 10 億件 | アルゴリズムの計算量の限界 |
| 速度 | 瞬時 vs 1 年 | 非同期処理の要件、キャッシュの必要性 |
| ユーザー数 | 1 人 vs 10 億人 | 並行処理の問題、リソースの限界 |
| 期間 | ミリ秒 vs 年単位 | メモリーリーク、状態の増大 |
| 失敗率 | 失敗しない vs 常に失敗する | エラー処理が十分かどうか |
プロセス
- 側面を選ぶ - 極端に変化する可能性があるものは何ですか？
- 最小を試す - これが 1000 分の 1 の小ささ／速さ／少なさだったらどうなりますか？
- 最大を試す - これが 1000 倍の大きさ／遅さ／多さだったらどうなりますか？
- 壊れる箇所を記録する - どこで限界が現れますか？
- 持ちこたえる箇所を記録する - 根本的に健全なのは何ですか？
例
例 1：エラー処理
通常の規模： 「エラーが発生したら処理する」で問題なく機能します 10 億件の場合： エラーの量がロギングを圧倒し、システムがクラッシュします 明らかになること： エラーを発生し得ないようにする（型システム）か、発生するものとして備える（カオスエンジニアリング）必要があります
例 2：同期 API
通常の規模： 関数を直接呼び出せます グローバル規模： ネットワーク遅延により、同期呼び出しは使いものになりません 明らかになること： 非同期処理／メッセージングは最適化ではなく、生き残るための必須要件になります
例 3：メモリー内の状態
通常の期間： 数時間／数日なら機能します 数年の場合： メモリーが際限なく増加し、最終的にクラッシュします 明らかになること： 永続化または定期的なクリーンアップが必要であり、メモリーに頼ることはできません
これが必要な兆候
- 「開発環境では動きます」（でも本番環境でも動くでしょうか？）
- 限界がどこにあるのかわからない
- 「問題なくスケールするはずです」（テストしていないのに）
- 本番環境の挙動に驚く
覚えておくこと
- 極端な条件では根本的な性質が明らかになります
- ある規模で機能するものが、別の規模では失敗します
- どちらの方向もテストします（大きく、そして小さく）
- 早い段階でアーキテクチャを検証するために、得られた知見を活用します
コメント
Markdown 対応