仕様書の書き方完全ガイド｜PdMが使えるテンプレートと実例

仕様書は、プロダクト開発において「何をどう作るか」をチーム全体で共有するための中心的なドキュメントです。書き方を誤ると手戻りや認識齟齬が頻発しますが、基本構成と書き方のコツを押さえれば、誰でも品質の高い仕様書を作成できます。この記事では、仕様書の定義から構成・ステップ・テンプレートまでを体系的に解説します。

仕様書とは何か｜要件定義書・設計書との違いを整理する

仕様書とは、プロダクトや機能を「どのように作るか（How）」を記述したドキュメントです。似た名称のドキュメントが複数存在するため、まず役割の違いを整理しておくことが重要です。

仕様書・要件定義書・設計書の役割の違い

要件定義書は「何を作るか（What）」を定義するドキュメントで、ビジネス目標・ユーザーニーズ・解決すべき課題を記述します。仕様書はその一段下に位置し、「どう作るか（How）」すなわち機能の振る舞いや条件を具体的に記述します。設計書はさらに実装レベルの詳細——データベース設計・API設計・クラス設計など——を扱い、エンジニアが直接参照する技術文書です。

この3つを混同すると、要件定義の段階で実装詳細を議論したり、仕様書に「なぜ作るか」が書かれていなかったりと、ドキュメントの目的が曖昧になります。それぞれの役割を明確に分けることで、各ドキュメントの読者と更新タイミングも自然と定まります。

仕様書が必要になる場面

仕様書が最も活躍するのは、開発チームへの機能説明と認識合わせの場面です。口頭説明だけでは伝わりにくいエッジケースや条件分岐を文書化することで、エンジニアとデザイナーが同じ理解のもとで作業を進められます。また、QAチームがテストケースを設計する際の基準としても機能し、「仕様通りに動いているか」を客観的に判断できます。

リリース後の仕様変更管理においても仕様書は重要です。変更前後の仕様が記録されていれば、影響範囲の特定や回帰テストの設計が格段に効率化されます。仕様書を「一度書いたら終わり」ではなく、プロダクトの生きた記録として維持することが、長期的な開発品質の向上につながります。

仕様書に必ず含める基本構成と必須項目

仕様書の品質は、何を書くかよりも「何を必ず書くか」の設計で決まります。標準的な構成を持つテンプレートを用意しておくことで、書き漏れを防ぎ、チーム全体で一貫したフォーマットを維持できます。

仕様書の基本構成テンプレート

仕様書に含めるべき基本セクションは以下の6つです。①概要・背景（なぜこの機能を作るか）、②対象ユーザー・スコープ（誰のための機能か、何を含み何を含まないか）、③機能仕様（正常系・異常系・エッジケース）、④非機能要件（パフォーマンス・セキュリティ・可用性）、⑤制約・前提条件（技術的制約・ビジネス上の前提）、⑥用語定義（ドキュメント内で使う専門用語の統一）です。

省略可能な項目と省略不可な項目の判断基準は「読者が判断に迷うかどうか」です。小規模な機能追加であれば④非機能要件を省略することもありますが、①概要・背景と③機能仕様は規模に関わらず必須です。背景がなければエンジニアは「なぜこの仕様なのか」を理解できず、機能仕様がなければ実装の根拠がなくなります。

機能仕様の書き方：正常系・異常系・エッジケース

機能仕様を記述する際に有効なのが、ユーザーストーリー形式です。「As a（誰が）/ I want（何をしたい）/ So that（なぜ）」の3要素で機能を記述することで、機能の目的と対象ユーザーが明確になります。例えば「ログイン済みユーザーとして、パスワードをリセットしたい。なぜなら、パスワードを忘れた際に自力で解決できるようにするため」のように書きます。

異常系・エッジケースを網羅するためのチェックリスト観点としては、「入力値が空の場合」「最大文字数を超えた場合」「ネットワーク切断時」「同一操作の二重実行時」「権限のないユーザーがアクセスした場合」などが挙げられます。正常系だけを書いた仕様書は、QAフェーズで大量の質問が発生する原因になります。異常系を先に洗い出す習慣をつけることで、仕様の穴を早期に発見できます。

仕様書の構成に迷ったときは、Granty の PdM 特化転職エージェントに相談することで、現場で実際に使われているドキュメント設計の知見を得られます。Granty の PdM 特化転職エージェントでは、仕様書スキルを含むPdMとしての市場価値向上を無料でサポートしています。

仕様書の書き方ステップ｜ゼロから完成まで

仕様書を書き始める際に最も多い失敗は「いきなり機能の詳細から書き始めること」です。目的・背景・スコープを先に固め、全体像を図示してから文章化するという順序を守ることで、後から大幅に書き直す手戻りを防げます。

Step1：目的・背景・スコープを先に固める

仕様書の冒頭には「なぜこの機能を作るか」を1〜2文で明記します。例えば「ユーザーのパスワード忘れによるサポート問い合わせを月間200件削減するため、セルフサービスのパスワードリセット機能を実装する」のように、ビジネス上の目的と機能の関係を簡潔に書きます。この一文があるだけで、仕様の判断に迷った際の拠り所になります。

スコープ外（Out of Scope）の明示も同様に重要です。「今回はSNSアカウントによるパスワードリセットは対象外」のように除外事項を書くことで、開発中に「これも対応するの？」という質問を事前に防げます。スコープ外の明示は手戻りを減らすだけでなく、ステークホルダーとの期待値調整にも機能します。

Step2：ユーザーフローを図示してから文章化する

機能仕様を文章だけで書こうとすると、分岐条件の記述が複雑になりがちです。まずフローチャートやシーケンス図で全体像を描き、文章はその補足として書くアプローチが効果的です。Miro・FigJam・draw.ioなどのツールを使えば、エンジニアやデザイナーと同期しながら図を作成できます。

図と文章の整合性チェックは、仕様書完成前に必ず行います。図では「エラー時はトップページに戻る」と書いてあるのに、文章では「エラーページを表示する」と書かれているような矛盾は、実装フェーズで混乱を招きます。図を先に確定させてから文章を書くと、このような不整合を防ぎやすくなります。

Step3：レビュー・承認フローを設計する

仕様書のレビューは、ステークホルダーごとに観点を分けて依頼することが重要です。エンジニアには「実装可能か・技術的な抜け漏れはないか」、デザイナーには「UXフローに矛盾はないか」、ビジネス担当者には「ビジネス要件を満たしているか」という観点でレビューを依頼します。全員に同じレビューを依頼すると、観点がバラバラになり有効なフィードバックが得られにくくなります。

承認済みバージョンの管理には、Notion・Confluence・Googleドキュメントなどのツールが広く使われています。重要なのは「どのバージョンが承認済みか」を明確にすることです。ステータスフィールド（Draft / In Review / Approved）を設けるか、承認日と承認者を変更履歴セクションに記録する運用が一般的です。

仕様書の書き方：現場で使えるコツと表現パターン

仕様書の品質を左右する最大の要因は「曖昧さの排除」です。書いた本人には意味が通じても、読み手によって解釈が変わる表現が一つあるだけで、実装の方向性がずれることがあります。

曖昧な表現を排除する書き方

「適切に処理する」「なるべく早く表示する」「高速に動作する」といった副詞や形容詞は、仕様書から排除すべき代表的な曖昧表現です。これらは必ず数値・条件に置き換えます。「3秒以内に初期表示を完了する」「エラー発生時は500msec以内にエラーメッセージを表示する」のように、測定可能な基準で記述することで、QAチームがテスト基準を設計できるようになります。

主語の明確化も重要なポイントです。「〜が表示される」という受動態は、誰が・何が表示するのかが不明確です。「システムが〜を表示する」「ユーザーが〜を入力できる」のように、主語を明示することで実装担当者の解釈ブレを防げます。特に「システム」と「ユーザー」の動作を明確に使い分けることが、機能仕様の読みやすさを大きく向上させます。

非機能要件（パフォーマンス・セキュリティ・可用性）の書き方

パフォーマンス要件は「同時接続数・レスポンスタイム・エラー率」の3軸で記述するのが基本です。例えば「同時接続1,000ユーザー時に、APIレスポンスタイムの95パーセンタイルが500ms以内であること」「月間エラー率0.1%以下を維持すること」のように、具体的な数値と測定条件をセットで書きます。

セキュリティ要件は、認証・認可・データ保護の3観点で最低限の項目を列挙します。「パスワードはbcryptでハッシュ化して保存する」「APIエンドポイントはJWTによる認証を必須とする」「個人情報はAES-256で暗号化して保存する」のように、実装方針レベルまで踏み込んで書くことで、エンジニアが設計判断を迷わずに進められます。可用性要件については「月間稼働率99.9%以上」のようなSLA（サービスレベル合意）の形式で記述するのが一般的です。

仕様書でよくある失敗パターンと対策

仕様書作成の経験を積んでも、特定のパターンで同じ失敗を繰り返すことがあります。よくある失敗を事前に知っておくことで、品質の高いドキュメントを効率よく作成できます。

失敗パターン①：書きすぎ・読まれない仕様書

仕様書が読まれない最大の原因は「長すぎること」です。1ページに全情報を詰め込むのではなく、概要（1〜2ページ）と詳細（別ページまたは折りたたみセクション）の2層構造にすることで、読者が必要な情報にすぐアクセスできます。エンジニアが実装時に参照する詳細仕様と、ステークホルダーが承認時に確認する概要は、同じドキュメントに混在させないほうが読みやすくなります。

仕様書の冒頭に「この仕様書を誰が・いつ・何のために読むか」を明記することも有効です。「対象読者：開発チーム・QAチーム、参照タイミング：実装開始前・テスト設計時」のように書くだけで、読者が自分に関係する情報を素早く見つけられます。

失敗パターン②：更新されず陳腐化する仕様書

仕様書が陳腐化する根本原因は「更新ルールが決まっていないこと」です。仕様変更が発生した際に「誰が・いつ・どこの仕様書を更新するか」をチームで合意しておくことが不可欠です。更新担当者が不明確だと、実装は変わっているのに仕様書は古いままという状態が常態化します。

変更履歴セクションを設けることで、差分が追えるようになります。「2026年5月15日：パスワードリセットのメール送信先をプライマリメールのみに変更（変更者：山田）」のように、日付・変更内容・変更者を記録します。変更履歴があれば、後から「なぜこの仕様になったのか」を追跡でき、新しいメンバーのオンボーディングにも役立ちます。

失敗パターン③：エンジニアに伝わらない仕様書

実装判断が必要な箇所を曖昧なまま放置することは、エンジニアに不必要な意思決定を押し付けることになります。決まっていない箇所は「TBD（To Be Determined）」と明示し、決定者と期限を必ず記載します。「TBD：エラーメッセージの文言（決定者：PdM 田中、期限：2026年6月10日）」のように書くことで、未決事項の管理が可視化されます。

仕様書レビューにエンジニアを早期から巻き込むことも重要な対策です。仕様書が完成してからレビューを依頼するのではなく、ドラフト段階でエンジニアに確認してもらうことで、技術的に実現困難な仕様を早期に発見できます。エンジニアの視点を取り入れることで、仕様書の実装可能性と精度が大幅に向上します。

仕様書テンプレート｜すぐ使えるMarkdown・Notion形式

仕様書の品質を安定させる最も効果的な方法は、チームで統一されたテンプレートを持つことです。ゼロから書き始めるよりも、構成が決まったテンプレートに情報を埋めていく方が、書き漏れを防ぎ作成時間も短縮できます。

Markdown形式の仕様書テンプレート（基本版）

以下は、すぐにコピーして使えるMarkdown形式の仕様書テンプレートです。7つのセクションで構成されており、各セクションに記入例（プレースホルダー）を含んでいます。

# 仕様書：[機能名]

## 1. 概要・背景
- 目的：[この機能を作る理由を1〜2文で記述]
- 背景：[解決したい課題・ビジネス上の文脈]

## 2. 対象ユーザー・スコープ
- 対象ユーザー：[例：ログイン済みの一般ユーザー]
- スコープ内：[この仕様書でカバーする範囲]
- スコープ外（Out of Scope）：[対象外の機能・ケース]

## 3. 機能仕様
### 3.1 正常系
- [ユーザーが〜した場合、システムは〜する]

### 3.2 異常系・エッジケース
- [入力値が空の場合：〜]
- [タイムアウト時：〜]

## 4. 非機能要件
- パフォーマンス：[例：レスポンスタイム500ms以内（95パーセンタイル）]
- セキュリティ：[例：認証はJWT、データはAES-256で暗号化]
- 可用性：[例：月間稼働率99.9%以上]

## 5. 制約・前提条件
- [例：既存の認証基盤（Auth0）を使用する]

## 6. 用語定義
| 用語 | 定義 |
|------|------|
| [用語] | [定義] |

## 7. 変更履歴
| 日付 | 変更内容 | 変更者 |
|------|----------|--------|
| YYYY-MM-DD | 初版作成 | [名前] |

Notion・Confluenceでの仕様書管理のコツ

NotionやConfluenceでは、データベース機能を活用してステータス管理を運用するのが効果的です。各仕様書ページにステータスプロパティ（Draft / In Review / Approved）を設定することで、チーム全体でどの仕様書がどの段階にあるかを一覧で把握できます。Notionの場合はボードビューを使うと、カンバン形式でステータスを視覚的に管理できます。

テンプレートページを作成してチーム全体で統一フォーマットを使うことも重要です。Notionでは「テンプレートとして保存」機能を使い、新しい仕様書を作成する際に必ずテンプレートから始めるルールを設けます。Confluenceでは「ページテンプレート」機能が同様の役割を果たします。フォーマットが統一されることで、レビュー時に「どこに何が書いてあるか」を探す手間がなくなり、レビュー品質も向上します。

仕様書を書けるPdMのキャリア価値｜スキルアップと転職への活かし方

仕様書作成スキルは、PdMとしての市場価値を高める重要な要素の一つです。「仕様書が書ける」という事実よりも、「仕様書を通じてどんな課題を解決したか」を語れることが、採用面接での差別化につながります。

採用面接で仕様書スキルをアピールする方法

面接で仕様書スキルをアピールする際は、「どんな仕様書を書いたか」という成果物の説明ではなく、「どんな課題を解決したか」という問題解決の文脈で語ることが重要です。「仕様書の構成を改善したことで、エンジニアからの仕様確認質問が週10件から2件に減少した」「異常系の網羅的な記述により、QAフェーズのバグ検出率が30%向上した」のように、仕様書の品質改善がチームの生産性や手戻りにどう影響したかを定量化して伝えます。

仕様書スキルは、PdMとしてのコミュニケーション能力・論理的思考力・ステークホルダーマネジメント力を示す証拠にもなります。「複数のステークホルダーの要求を整理し、エンジニアが実装判断できるレベルまで仕様を具体化した」という経験は、PdMとしての総合的な能力を示す強力なエピソードです。仕様書作成の経験を振り返り、チームへの貢献を言語化しておくことが、転職活動での武器になります。

仕様書スキルを含むPdMとしてのキャリア相談は、Granty の PdM 特化転職エージェントに無料でご相談いただけます。現場で評価されるドキュメントスキルの磨き方から、転職活動での効果的なアピール方法まで、PdM専門のエージェントがサポートします。