グローバルチームで仕様書や設計書を英語で書かなければならないとき、どこから手をつければいいか迷ったことはないだろうか。
「構成がわからない」「要件の強弱を英語で表現できない」「図やテーブルの説明文が書けない」——こうした悩みを抱えるエンジニアは多い。
この記事では、英語仕様書・設計書の基本構成と、すぐに使える表現を30個まとめた。Overview・Requirements・Designの各セクションをカバーしている。
この記事を読めば、次のことがわかる。
- 英語仕様書・設計書を「5つのセクション」で迷わず書く方法
- Must／Should／Mayを使った要件の書き分け方
- そのままコピーして使えるテンプレートと表現30選
結論からいうと、英語仕様書・設計書は「構成」と「型」を覚えれば書ける。 英語力より、何をどの順番で書くかの設計力の方がはるかに重要だ。
英語仕様書・設計書でエンジニアが詰まる3つの場面
何をどの順番で書けばいいかわからない
日本語の仕様書では「背景→課題→要件→設計→まとめ」という流れが多い。 英語でも同様の構成は存在するが、セクション名や書き方のルールが異なる。
「Overview」「Motivation」「Requirements」「Design」——これらの英語セクション名と、それぞれに書くべき内容を知っておくだけで、仕様書作成の迷いが大幅に減る。
要件の強弱（Must/Should/May）を正確に伝えられない
「この機能は必須ですか、任意ですか？」——この判断が英語で伝わらないと、実装の優先順位に混乱が生じる。
英語の技術文書では、RFC 2119という標準規格で定められた表現を使うことが一般的だ。 Must／Should／Mayの使い分けを知っておくことが、正確な要件定義の第一歩だ。
図・テーブル・コードブロックの説明文が書けない
アーキテクチャ図やシーケンス図を貼り付けても、説明文がなければ読み手に意図が伝わらない。 「The following diagram shows…」「As illustrated in Figure 1…」——こうした定番の引用表現を覚えておくことが大切だ。
英語仕様書・設計書の基本構成｜5つのセクションで迷わず書ける
英語の仕様書・設計書は、以下の5つのセクションで構成するのが標準的だ。
①Overview（概要）
文書全体の要約を2〜3文で書く。 「この文書は何のためのものか」「誰が読む文書か」を最初に明示する。
②Background / Motivation（背景・目的）
「なぜこの設計・機能が必要なのか」を説明するセクションだ。 現状の問題点・課題・解決したいことを書く。
③Requirements（要件）
機能要件・非機能要件をMust／Should／Mayで分類して書く。 Acceptance Criteria（受け入れ条件）もここに含める。
④Design / Architecture（設計・アーキテクチャ）
実際の設計内容を書くセクションだ。 アーキテクチャ図・シーケンス図・データモデルなどを含める。 設計の決定理由・トレードオフも明示するのが良い慣習だ。
⑤Open Questions / Future Work（未解決事項・今後の課題）
まだ決まっていないことや、今回のスコープ外の内容をリストアップする。 レビュアーへのフィードバック依頼もここに書く。
Overview・Background で使えるフレーズ10選
技術英語ライティングの基本ルールと共通する表現も多い。 ライティング全般のルールは以下の記事で詳しく解説している。
【例文あり】技術英語ライティングの書き方｜エンジニアが使える文章術5選
目的・背景を説明する表現
① This document describes the design of [機能/システム名]. 「このドキュメントは[機能/システム名]の設計について説明します。」仕様書・設計書の冒頭で使う定番フレーズ。
② The purpose of this document is to [目的]. 「このドキュメントの目的は[目的]です。」文書の意図を明確に示すフレーズ。
③ This proposal addresses the following problem: [問題の概要]. 「この提案は以下の問題に対処します：[問題の概要]。」問題提起から始める書き方。
④ Currently, [現状の課題]. This leads to [問題の影響]. 「現在、[課題]があります。これにより[影響]が生じています。」現状の問題を説明するフレーズ。
⑤ The goal of this change is to [達成したいこと]. 「この変更の目標は[達成したいこと]です。」変更の目標を一文で示すフレーズ。
スコープ・対象読者を示す表現
⑥ This document is intended for [対象読者]. 「このドキュメントは[対象読者]を対象としています。」対象読者を明示するフレーズ。
⑦ This design covers [スコープ内の内容]. The following are out of scope: [スコープ外の内容]. 「この設計は[内容]をカバーします。以下はスコープ外です：[内容]。」スコープを明確にするフレーズ。
⑧ For the purposes of this document, [用語] refers to [定義]. 「このドキュメントでは、[用語]は[定義]を指します。」用語を定義するフレーズ。
用語定義の表現
⑨ See [セクション名 / リンク] for definitions of terms used in this document. 「このドキュメントで使用する用語の定義は[セクション/リンク]を参照してください。」用語集への参照フレーズ。
⑩ Throughout this document, the following conventions are used: [規則の説明]. 「このドキュメント全体を通じて、以下の規則を使用します：[説明]。」表記ルールを明示するフレーズ。
Requirements・Design で使えるフレーズ10選
機能要件・非機能要件を書く表現
英語の要件定義では、RFC 2119の表現を使うのが標準だ。
| 表現 | 意味 | 使い場面 |
|---|---|---|
| MUST / SHALL | 必須 | 絶対に満たさなければならない要件 |
| MUST NOT / SHALL NOT | 禁止 | 絶対にやってはいけないこと |
| SHOULD | 推奨 | 特別な理由がない限り満たすべき要件 |
| SHOULD NOT | 非推奨 | 特別な理由がない限り避けるべきこと |
| MAY | 任意 | あってもなくてもよい要件 |
⑪ The system MUST [必須要件]. 「システムは[要件]を満たさなければなりません。」必須要件を書く定番フレーズ。
⑫ The API MUST NOT expose [禁止事項]. 「APIは[内容]を公開してはなりません。」禁止事項を明示するフレーズ。
⑬ The system SHOULD [推奨要件] to ensure [目的]. 「[目的]を確保するために、システムは[要件]を満たすことが推奨されます。」推奨要件を書くフレーズ。
⑭ Acceptance Criteria: 「受け入れ条件：」受け入れ条件セクションの見出しに使う。番号付きリストで条件を続ける。
設計の決定・トレードオフを説明する表現
⑮ We chose [選択した設計] over [却下した設計] because [理由]. 「[却下した設計]より[選択した設計]を選んだ理由は[理由]です。」設計の決定理由を説明するフレーズ。
⑯ The tradeoff here is [トレードオフの内容]. We prioritize [優先したこと] over [犠牲にしたこと]. 「ここでのトレードオフは[内容]です。[犠牲にしたこと]より[優先したこと]を重視します。」トレードオフを明示するフレーズ。
⑰ This approach has the following advantages: [メリット]. However, it comes with [デメリット]. 「このアプローチには以下の利点があります：[メリット]。ただし、[デメリット]も伴います。」メリット・デメリットを示すフレーズ。
図・テーブル・コードを説明する表現
⑱ The following diagram illustrates [図の説明]. 「次の図は[内容]を示しています。」図の前に使う定番の引用フレーズ。
⑲ As shown in Figure [番号], [説明]. 「図[番号]に示すように、[説明]です。」図を本文中で参照するフレーズ。
⑳ The table below summarizes [テーブルの内容]. 「以下の表は[内容]をまとめたものです。」テーブルの前に使う引用フレーズ。
Open Questions・レビュー依頼で使えるフレーズ10選
未解決事項・前提条件を書く表現
㉑ The following questions are still open and need to be resolved before implementation: 「以下の問題はまだ未解決で、実装前に解決する必要があります：」未解決事項セクションの冒頭フレーズ。
㉒ TBD: [未決定の内容]. Owner: [担当者名]. Due: [期限]. 「未定：[内容]。担当：[名前]。期限：[日付]。」TBD（To Be Determined）を構造的に書くフォーマット。
㉓ This design assumes that [前提条件]. 「この設計は[前提条件]を前提としています。」前提条件を明示するフレーズ。
㉔ If [条件] changes, this design will need to be revisited. 「[条件]が変わった場合、この設計を見直す必要があります。」設計の前提が崩れる条件を示すフレーズ。
フィードバック・承認を求める表現
㉕ Please review this document and provide feedback by [期限]. 「[期限]までにこのドキュメントをレビューしてフィードバックをいただけますか。」レビュー依頼フレーズ。
㉖ I’d especially appreciate feedback on [特に見てほしい箇所]. 「特に[箇所]についてフィードバックをいただけると助かります。」レビューのフォーカスポイントを伝えるフレーズ。
㉗ Does this approach make sense? Are there any concerns I haven’t addressed? 「このアプローチは理にかなっていますか？対応できていない懸念点はありますか？」レビュアーへの問いかけフレーズ。
㉘ This document requires approval from [承認者] before implementation begins. 「このドキュメントは実装開始前に[承認者]の承認が必要です。」承認フローを明示するフレーズ。
変更履歴・改訂を記録する表現
㉙ Revision History: 「改訂履歴：」変更履歴セクションの見出し。日付・バージョン・変更内容・変更者を表形式で管理する。
㉚ Updated [セクション名] based on feedback from [レビュアー名]. 「[レビュアー名]のフィードバックに基づき[セクション名]を更新しました。」改訂内容を記録するフレーズ。
英語仕様書テンプレート（コピーして使えます）
以下のテンプレートをそのままコピーして使ってほしい。
# [Document Title]
**Author:** [名前]
**Status:** [Draft / In Review / Approved]
**Last Updated:** [日付]
---
## Overview
[2〜3文で文書の要約を書く]
---
## Background / Motivation
### Current State
[現状の説明]
### Problem Statement
[解決したい問題の説明]
### Goals
- [目標1]
- [目標2]
### Non-Goals
- [スコープ外の内容]
---
## Requirements
### Functional Requirements
- The system MUST [必須要件1]
- The system MUST [必須要件2]
- The system SHOULD [推奨要件]
- The system MAY [任意要件]
### Non-Functional Requirements
- Performance: [パフォーマンス要件]
- Security: [セキュリティ要件]
- Scalability: [スケーラビリティ要件]
---
## Design
### Architecture Overview
[アーキテクチャの概要説明]
[図をここに挿入]
### Key Design Decisions
**Decision 1:** [決定内容]
- **Rationale:** [理由]
- **Alternatives considered:** [検討した代替案]
- **Tradeoffs:** [トレードオフ]
---
## Open Questions
| Question | Owner | Due Date | Status |
|----------|-------|----------|--------|
| [質問1] | [担当者] | [期限] | Open |
---
## Revision History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [日付] | [名前] | Initial draft |
英語仕様書・設計書を書く力を鍛える3つの習慣
OSSのRFC・設計ドキュメントを読んで構成を真似る
GoogleのDesign Doc・AWSのADR（Architecture Decision Record）・各種OSSのRFCは、英語設計書の最高の教材だ。
特に参考にしやすいのは以下のリソースだ。
- Google Design Doc template：Googleが公開している設計書のテンプレート
- Python Enhancement Proposals (PEPs)：Pythonの機能提案書
- Rust RFCs：Rustの機能設計書
構成を真似るだけでも、英語設計書の型が自然に身につく。
まず日本語で書いてから英語に変換する練習をする
最初から英語で書こうとすると、内容と言語の両方に頭を使って疲弊しやすい。
まず日本語で仕様を整理し、構成が固まってから英語に変換する方法が効率的だ。 DeepLやChatGPTを活用して初稿を作り、その後に表現を磨くという流れがおすすめだ。
コードレビューのような短い英語コメントに慣れてきたら、次は仕様書に挑戦しよう。 コードレビューの英語表現については以下の記事で詳しく解説している。
【例文あり】英語コードレビューの進め方｜エンジニアが使えるフレーズ30選
チームにレビューしてもらいフィードバックを蓄積する
英語設計書の上達に最も効果的なのは、実際にチームメンバーにレビューしてもらうことだ。
「この表現はわかりにくい」「この構成は読みにくい」といった具体的なフィードバックを蓄積することで、次の文書がどんどん良くなっていく。
PRのレビューと同様に、英語設計書もフィードバックのサイクルを回すことが上達の近道だ。 英語PRの書き方については以下の記事も参考にしてほしい。
英語プルリクエストの書き方【エンジニア向け例文テンプレ付き】
まとめ：英語仕様書は「構成」と「型」を覚えれば書ける
この記事では、英語仕様書・設計書の基本構成と使える表現30選を紹介した。
重要なポイントをまとめる。
- Overview・Background・Requirements・Design・Open Questionsの5セクション構成が基本
- Must／Should／Mayで要件の強弱を明確に表現する
- 図・テーブルには必ず引用フレーズで説明文をつける
- テンプレートをコピーして使い回すことで作成効率が大幅に上がる
- OSSのRFC・設計書を読んで構成を真似ることが上達の近道
英語仕様書・設計書は、完璧な英語より「正確な構成と明確な表現」が重要だ。 まず今日、この記事のテンプレートをコピーして次の設計書の雛形を作ってみてほしい。
型があるだけで、英語ドキュメントへのハードルは大きく下がる。
コメント