英語でデザインレビュードキュメントを書くよう求められたとき、何をどの順序で書けばいいか迷った経験はないだろうか。
デザインレビュー（Design Review）は設計の妥当性をチームで検証するプロセスだ。背景・提案設計・代替案・トレードオフの6つのセクション構成さえ押さえれば、英語でも問題なく進められる。
この記事では、英語デザインレビューに必要な6つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のレビューで活用できる。
デザインレビュードキュメントに必要な6つの構成要素
デザインレビュードキュメントは設計の目的・提案内容・代替案・リスクをレビュアーが短時間で把握できるようにまとめる文書だ。以下の6つが標準的な構成要素になる。
- 概要（Overview）
- 背景・課題（Background & Problem）
- 提案する設計（Proposed Design）
- 代替案（Alternatives Considered）
- トレードオフ・リスク（Tradeoffs & Risks）
- 決定・承認（Decision & Approval）
デザインレビューとADRの違い
ADR（Architecture Decision Record）は「決定済み」の技術選択を記録するアーカイブ文書だ。デザインレビュードキュメントは「これから決める」設計案をレビュアーに提示し、承認を得るためのプロセス文書になる。レビュー完了後にADRとして記録するのが一般的な流れだ。
ADRの書き方は英語ADRの書き方でも確認してほしい。
なぜ英語で書くのか
グローバルチームのデザインレビューでは、レビュアーが複数のタイムゾーンに分散していることが多い。非同期でレビューできる英語ドキュメントがあれば、ミーティング時間を短縮できる。特に代替案とトレードオフを事前に整理しておくと、レビューの質が大幅に上がる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
概要
| 項目 | 内容 |
|---|---|
| ドキュメントタイトル | （例：決済サービス 非同期処理アーキテクチャ設計レビュー） |
| 作成者 | （例：田中） |
| レビュー期限 | （例：2026年8月15日） |
| ステータス | （例：レビュー中 / 承認済み / 却下） |
| 関連ADR | （例：ADR-042 決済非同期化） |
| 関連チケット | （例：PAY-1234） |
背景・課題
| 項目 | 内容 |
|---|---|
| 現状 | （例：決済処理がすべて同期APIで実装されており、タイムアウト障害が月3〜5件発生している） |
| 課題 | （例：外部決済ゲートウェイのレスポンスが遅延した場合、ユーザーに5秒以上の待機が発生する） |
| 解決したいこと | （例：決済処理の非同期化によりタイムアウト障害をゼロにし、ユーザー体験を改善する） |
| 影響範囲 | （例：決済API・注文サービス・通知サービス） |
| 制約 | （例：既存APIの後方互換性を維持すること。データの二重処理を防ぐこと） |
提案する設計
| 項目 | 内容 |
|---|---|
| 設計概要 | （例：決済リクエストをSQSキューに投入し、Lambdaワーカーが非同期に処理する構成に変更する） |
| 主要コンポーネント | （例：決済API・SQSキュー・Lambdaワーカー・DynamoDB（冪等性管理）・SNS（通知）） |
| データフロー | （例：1. APIがリクエストをSQSに投入 → 2. Lambdaが処理 → 3. 結果をDBに保存 → 4. SNSで通知） |
| 冪等性の担保 | （例：DynamoDBにリクエストIDを記録し、重複処理を防ぐ） |
| エラーハンドリング | （例：Lambda処理失敗時はDead Letter Queue（DLQ）に移動し、アラートを発報） |
代替案
| 案 | 概要 | 却下理由 |
|---|---|---|
| 案1（現行維持） | （例：同期API構成を維持しタイムアウト閾値を延長する） | （例：根本原因の解消にならず、ユーザー待機時間の改善も見込めない） |
| 案2（Kafkaキュー） | （例：SQSの代わりにKafkaを使用する） | （例：運用コストとチームの習熟度の観点からSQSが適切。Kafkaは現段階ではオーバースペック） |
| 案3（提案案：SQS+Lambda） | （例：本提案。SQSとLambdaで非同期処理基盤を構築する） | 採用 |
トレードオフ・リスク
| 観点 | 内容 |
|---|---|
| メリット | （例：タイムアウト障害の解消・ユーザー体験の改善・処理スケーラビリティの向上） |
| デメリット | （例：システム複雑度の増加・非同期処理特有のデバッグの難しさ） |
| 主要リスク | （例：DLQ監視漏れによる決済処理の無言失敗） |
| リスク対応 | （例：DLQメッセージ数のアラートをDatadogに設定し、SLA対応フローを整備する） |
| パフォーマンス影響 | （例：同期→非同期への変更でAPIレスポンスは改善。結果確認にポーリングまたはWebhookが必要） |
| コスト影響 | （例：SQS・Lambda・DynamoDB追加コスト：月+$50〜$200程度（トラフィック次第）） |
決定・承認
| 承認者 | 役割 | ステータス | コメント |
|---|---|---|---|
| （例：山田） | エンジニアリングマネージャー | □ 承認待ち | |
| （例：鈴木） | アーキテクト | □ 承認待ち | |
| （例：佐藤） | セキュリティ | □ 承認待ち |
英語版テンプレート（コピペOK）
Overview
| Item | Details |
|---|---|
| Document Title | (e.g., Design Review: Async Payment Processing Architecture) |
| Author | (e.g., Tanaka) |
| Review Deadline | (e.g., August 15, 2026) |
| Status | (e.g., In Review / Approved / Rejected) |
| Related ADR | (e.g., ADR-042 Payment Async Migration) |
| Related Ticket | (e.g., PAY-1234) |
Background & Problem
| Item | Details |
|---|---|
| Current State | (e.g., All payment processing is handled synchronously via REST API, causing 3–5 timeout incidents per month.) |
| Problem | (e.g., When the external payment gateway is slow, users wait over 5 seconds for a response.) |
| Goal | (e.g., Eliminate timeout incidents and improve user experience by making payment processing asynchronous.) |
| Scope | (e.g., Payment API, Order Service, Notification Service) |
| Constraints | (e.g., Must maintain backward compatibility with existing APIs. Must prevent duplicate payment processing.) |
Proposed Design
| Item | Details |
|---|---|
| Design Summary | (e.g., Enqueue payment requests in SQS and process them asynchronously with Lambda workers.) |
| Key Components | (e.g., Payment API, SQS Queue, Lambda Worker, DynamoDB (idempotency), SNS (notifications)) |
| Data Flow | (e.g., 1. API enqueues request to SQS → 2. Lambda processes it → 3. Saves result to DB → 4. Sends notification via SNS) |
| Idempotency | (e.g., Store request IDs in DynamoDB to prevent duplicate processing.) |
| Error Handling | (e.g., On Lambda failure, move message to Dead Letter Queue (DLQ) and trigger an alert.) |
Alternatives Considered
| Option | Summary | Reason for Rejection |
|---|---|---|
| Option 1 (Status Quo) | (e.g., Keep the current synchronous API and extend the timeout threshold.) | (e.g., Does not fix the root cause. Does not improve user-perceived wait time.) |
| Option 2 (Kafka Queue) | (e.g., Use Kafka instead of SQS.) | (e.g., SQS is a better fit given operational costs and team familiarity. Kafka is over-engineered at this stage.) |
| Option 3 (Proposed: SQS + Lambda) | (e.g., This proposal. Build async infrastructure with SQS and Lambda.) | Selected |
Tradeoffs & Risks
| Dimension | Details |
|---|---|
| Benefits | (e.g., Eliminates timeout incidents, improves user experience, increases processing scalability.) |
| Drawbacks | (e.g., Increases system complexity. Async flows are harder to debug.) |
| Key Risk | (e.g., Silent payment failures if DLQ monitoring is missed.) |
| Mitigation | (e.g., Set up a Datadog alert on DLQ message count and define an on-call response playbook.) |
| Performance Impact | (e.g., API response time improves. Clients need to poll or use webhooks to get payment results.) |
| Cost Impact | (e.g., Additional SQS, Lambda, DynamoDB costs: approximately +$50–$200/month depending on traffic.) |
Decision & Approval
| Reviewer | Role | Status | Comments |
|---|---|---|---|
| (e.g., Yamada) | Engineering Manager | □ Pending | |
| (e.g., Suzuki) | Architect | □ Pending | |
| (e.g., Sato) | Security | □ Pending |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
代替案の書き方（却下理由が重要）
代替案は「現状維持」を必ず1つ入れる。「なぜ今変えるのか」の説明になるからだ。却下理由は「コスト・技術的負債・チームの習熟度・制約」の観点で書くと説得力が増す。
| 日本語 | 英語 |
|---|---|
| 〇〇の理由で却下 | Rejected because [reason]. |
| 現状維持では問題が解決しない | The status quo does not resolve the root cause. |
| 技術的負債が増える | This increases technical debt. |
| チームの習熟度が不足している | The team lacks expertise in this area. |
| 運用コストが高すぎる | The operational cost is prohibitive. |
| 現段階ではオーバースペック | Over-engineered for our current scale. |
トレードオフの書き方（リスクと対応をセット）
リスクは「何が起きるか・どれくらいの頻度か・影響は何か」の3点で書く。対応は「誰が・何をする」まで明記する。
| 日本語 | 英語 |
|---|---|
| 〇〇のリスクがある | There is a risk of [X]. |
| 〇〇によって軽減できる | This can be mitigated by [action]. |
| 影響範囲は〇〇に限定される | The blast radius is limited to [scope]. |
| アラートを設定して監視する | Set up an alert to monitor [metric]. |
| SLAへの影響はない | This does not impact the SLA. |
API仕様書との連携は英語API仕様書の書き方でも参考にしてほしい。
デザインレビューでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
レビュープロセスの基本用語
| 日本語 | 英語 |
|---|---|
| 設計レビュー | Design Review |
| 承認者 | Approver / Reviewer |
| トレードオフ | Tradeoff |
| 代替案 | Alternative / Option |
| ブロッカー | Blocker |
| ニット（軽微なコメント） | Nit |
| 提案（任意） | Suggestion (non-blocking) |
| 却下 | Rejected |
| 承認済み | Approved |
| 変更依頼 | Change Request |
レビューコメントのフレーズ
| 日本語 | 英語 |
|---|---|
| この設計に懸念があります | I have a concern about this design. |
| 〇〇を明確にしてもらえますか | Could you clarify [point]? |
| 代替案として〇〇を検討しましたか | Did you consider [alternative] as an option? |
| ニット：〇〇 | Nit: [comment] |
| この箇所はブロッカーです | This is a blocker for me. |
| LGTMです | LGTM (Looks Good To Me). |
| 条件付き承認です | Approved with minor revisions. |
| 変更後に再レビューをお願いします | Please re-share after revisions for a final review. |
技術仕様書との連携は英語技術仕様書の書き方でも確認してほしい。
まとめ：英語デザインレビューは6つのセクションで完成する
英語デザインレビュードキュメントに必要な構成要素を整理した。
- 代替案には「現状維持」を必ず含め、却下理由をコスト・技術的負債・制約で説明する
- トレードオフはリスクと対応（誰が何をする）をセットで書く
- 承認テーブルにレビュアーと期限を明記して非同期レビューを効率化する
- ADRとセットで運用し、決定内容を記録として残す
テンプレートをコピーして、まず「背景・課題」から書き始めてほしい。「なぜ今変えるのか」が明確になると、代替案とトレードオフが自然に整理される。
コメント