フレームワーク活用ガイドひとことで言うと#
大規模なシステム変更や新規構築の前に、機能要件・非機能要件・運用面・コストを体系的に審査し、手戻りのリスクを事前に潰すプロセス。
押さえておきたい用語#
- Design Doc（デザインドック）
- 設計の背景・方針・代替案・トレードオフを1ドキュメントにまとめた設計書のこと。レビューの入力資料となる。
- Non-Functional Requirements（非機能要件）
- パフォーマンス・可用性・セキュリティなど、機能以外のシステム品質要求を指す。設計レビューで最も見落とされやすい領域である。
- Trade-off Analysis（トレードオフ分析）
- 複数の設計案についてメリット・デメリットを定量比較する手法。レビューで代替案を評価する際に用いる。
- Blast Radius（影響範囲）
- 障害や変更が及ぶシステム・チーム・顧客への波及範囲のこと。設計レビューではこの最小化が重要な観点になる。
システム設計レビューの全体像#
こんな悩みに効く#
- 実装が進んでから「そもそも設計が違う」と手戻りが発生する
- 非機能要件やセキュリティの考慮が抜けたまま本番に出てしまう
- 設計判断の根拠が属人化し、後から「なぜこう作ったのか」がわからない
基本の使い方#
具体例#
エンジニア60名のEC企業。決済基盤が5年前のモノリスに組み込まれており、新決済手段の追加に毎回 3ヶ月 かかっていた。決済マイクロサービスへの分離を設計レビューにかけた。
Design Docには3つの代替案（①決済サービス完全分離、②Strangler Figで段階移行、③外部決済SaaS採用）を記載。レビューで非機能要件の議論が集中し、トランザクション整合性の担保方法（Sagaパターン採用）と、移行中の二重稼働コスト（月額 120万円 増）が事前に可視化された。
レビューなしで進めていた場合に発生していたであろう手戻りコスト（推定 2,400万円 ・4ヶ月遅延）を回避し、計画通り 14週間 で移行を完了した。
エンジニア25名のヘルスケアSaaS。単一テナント構成で運用していたが、顧客数が 200社 を超え、インフラコストが月 850万円 に膨張。マルチテナント化の設計レビューを実施した。
レビューでセキュリティ担当から「医療データのテナント間分離はRLS（Row Level Security）では不十分、スキーマ分離が必須」という指摘があり、設計を修正。また運用性レビューでテナント追加の自動化が未考慮だったことが判明し、Terraformモジュール化を追加した。
指摘事項を設計段階で解消した結果、移行後のインフラコストは月 320万円 に。セキュリティ監査も1回で通過している。
エンジニア12名の物流スタートアップ。手動配車からリアルタイム最適化システムへの移行を計画。CTO含む3名で設計レビューを実施した。
レビューで「ピーク時の同時配車リクエスト 5,000件/分 に対し、提案されたRDBベースの設計ではレイテンシ 800ms 超が予想される」と指摘があり、配車計算をRedis + イベント駆動に変更。コスト観点では、当初のGKEクラスタ構成（月 180万円）をSpot Instancesの活用で月 95万円 に削減する案が採用された。
設計レビューに投じた 3日間 が、実装フェーズでの根本的な作り直しを防いだ。
やりがちな失敗パターン#
- Design Docが代替案を含まない — 「これで作ります」だけではレビューにならない。最低2つの代替案とトレードオフ比較を必ず記載する
- レビュアーが多すぎて収拾がつかない — 10名以上のレビューは形骸化する。コア3〜5名に絞り、残りは非同期コメントで参加してもらう
- レビューが承認儀式になる — 「偉い人が承認する場」ではなく「設計の穴を見つける場」にする。反対意見が出ない会議は機能していない
- レビュー後にDocが更新されない — 決定事項が口頭のまま残ると、半年後に「なぜこう作ったか」がわからなくなる。議事録はDocに直接追記する
まとめ#
システム設計レビューは、大規模変更の前に機能・非機能・運用・コストの4観点で設計を体系的に審査するプロセス。Design Docに背景・方針・代替案・トレードオフを記載し、事前の非同期レビューとレビュー会議を組み合わせて実施する。「手戻りコスト」 は常に 「レビューコスト」 の数倍〜数十倍になるため、設計段階での投資対効果は極めて高い。