Decision Quality と設計判断失敗パターン
概要¶
kawasima の Scrapbox ページ「Decision Quality と設計判断失敗パターン」を紹介した nwiizo のポスト。「要はバランス」という曖昧な結論に逃げる前に、言葉を尽くして判断の質を高めることの重要性。
詳細¶
Decision Quality（意思決定の質）とは¶
高い Decision Quality = 「良い判断プロセスを経た意思決定」。結果が良くても悪くても、プロセスが良ければ Decision Quality は高い。
設計判断失敗パターン¶
パターン1: 「バランス」という言葉への逃げ¶
✗ 「パフォーマンスと保守性のバランスをとりました」
→ どちらをどの程度重視したのか不明
→ 何と比較してバランスが取れていると判断したのか不明
◯ 「レスポンスタイムの要件（P99: 200ms）を満たすため、
正規化を犠牲にしてキャッシュを導入。
結果、書き込み時の整合性管理が複雑になるが、
読み取り頻度が書き込みの100倍のため許容できると判断」
→ 具体的な数字と根拠がある
パターン2: 前提条件を記録しない¶
✗ 「マイクロサービスにしました」（理由なし）
◯ 「当時のチーム構成（3チーム・15人）とデプロイ頻度（週2回）
を前提として、チームごとの独立デプロイを優先しマイクロサービスを選択。
現在チームが1つに統合された場合は再検討が必要」
→ 判断の前提が記録されているので将来の再検討ができる
パターン3: 代替案を検討しない¶
判断の質を上げるには必ず「他の選択肢」を明示する
フォーマット例（ADR: Architecture Decision Record）:
## 状況
[何が問題/課題なのか]
## 決定
[何を選んだか]
## 根拠
[なぜこれを選んだか]
## 検討した代替案
[他の選択肢と、なぜ選ばなかったか]
## 結果
[この決定がもたらす影響・トレードオフ]
パターン4: 可逆性を考慮しない¶
設計判断は可逆性によってリスクが変わる
可逆的な判断（気軽に決める）:
- ライブラリの選定（後で変えられる）
- API の内部実装（インターフェースが変わらなければ）
不可逆的な判断（慎重に検討する）:
- データベースの選択（移行コストが高い）
- 認証・セキュリティアーキテクチャ
- 外部公開 API の設計
実践：判断の言語化を習慣にする¶
コードレビューや設計レビューで使える質問:
「他の選択肢も検討しましたか？」
「この判断の前提条件は何ですか？」
「5年後にこの判断を変えることになった場合、何がトリガーになりそうですか？」
「パフォーマンス vs 保守性のトレードオフを具体的に教えてください」
なぜ重要か / いつ使うか¶
- 設計レビューでなんとなくOKを出してしまいがちなとき
- チームの設計判断の質を上げたいとき
- 「バランスをとる」が口グセになってきたとき
- ADR（Architecture Decision Record）を導入するとき