機能仕様書とは？書き方・項目・設計書との違いをわかりやすく解説！

システム開発をしていると、「機能仕様書を書いてください」と言われることがあります。

しかし、いざ機能仕様書を書こうとすると、

• そもそも機能仕様書って何？
• 要件定義書や基本設計書・詳細設計書とは何が違うのか？
• 何を書けばいいの？
• どこまで細かく書けばいいの？
• プログラムの内部処理まで書く必要があるの？

と疑問に思うこともあるでしょう。

この記事では、機能仕様書とは何なのか、基本的な役割や書く項目、具体的な書き方についてわかりやすく解説します。

機能仕様書とは？

機能仕様書とは、簡単にいうと、システムが「何をするのか」をまとめた文書です。

ユーザーの視点から製品が備えるべき機能・振る舞い・制約を記述します。

例えば、Webサービスに「ユーザー登録機能」があるとします。

機能仕様書には、

• ユーザーが新規登録できる
• 氏名・メールアドレス・パスワードを入力する
• メールアドレスは必須である
• すでに登録されているメールアドレスは利用できない
• 登録に成功すると完了画面を表示する
• 入力内容に問題がある場合はエラーを表示する

といった、ユーザーの視点から製品が備えるべき機能・振る舞い・制約を記載します。

一方、

• どのクラスを作るか
• どのメソッドを呼び出すか
• どのデータベースを使うか
• テーブルをどのように設計するか

といった実装方法は、基本的には機能仕様書ではなく詳細設計書に記載します。

つまり、機能仕様書では「How（どう作るか）」ではなく「What（何をするか）」を書くと考えると分かりやすいでしょう。

もう一つの判断基準が、ユーザーや外部から確認できる振る舞いかどうかです。

例えば、ユーザー登録機能では、「登録に成功すると、登録完了画面を表示する」といった、ユーザーから確認できる振る舞いを記載します。その一方で、内部でusersテーブルにユーザー情報を登録するといった実装方法まで書く必要はありません。

機能仕様書は何のために作る？

機能仕様書は、システムの各機能が「どのような条件で、どのように動くのか」を明確にし、関係者の共通認識を作るために必要です。

機能仕様書は、開発者だけが読む文書ではありません。

例えば、次のような人も利用します。

• テスト担当者
• マニュアル担当者
• サポート担当者

機能仕様書があることで、それぞれの担当者が「このシステムの機能はどのように動くのか」という共通認識を持つことができます。

具体的には、次のような目的で利用されます。

• 発注者や開発者など、関係者間の認識を合わせる
• 開発者が機能を実装するときに仕様や振る舞いを確認する
• テスト担当者がテストケースを作成する
• マニュアル担当者が操作方法を整理する
• サポート担当者がシステムの動作を確認する
• 機能追加や改修を行うときの参考資料にする

そのため、機能仕様書はプロジェクト全体を支える「共通の地図」のような文書と考えることができます。

要件定義書・機能仕様書・基本設計書・詳細設計書の違い

機能仕様書について理解するときは、要件定義書・基本設計書・詳細設計書との違いを知っておくと分かりやすくなります。

それぞれの役割を大まかに分けると、次のようになります。

要件定義書

要件定義書では、システムを作る目的や、システムで実現したいことを整理します。

例えば、会員制のWebサービスであれば、「ユーザーがWebサービスのアカウントを作成できること」といった内容です。

この段階では、「どのような画面にするのか」「内部でどのような処理をするのか」といった細かな内容までは決めません。

機能仕様書

機能仕様書では、要件定義で決めた内容をもとに、システムが具体的に何をするのかを定義します。

基本設計書

基本設計書では、機能仕様を実現するために、システムをどのような構成やインターフェースにするのかを設計します。

基本設計は「外部設計」と呼ばれることもあり、ユーザーから見える部分や、システム同士の接点などを具体化します。

例えば、ユーザー登録機能であれば、

• ユーザー登録画面を用意する
• 氏名・メールアドレス・パスワードの入力欄を配置する
• 登録ボタンを配置する
• 登録成功後は登録完了画面へ遷移する
• 入力エラーは各入力欄の下に表示する

といった内容です。

プロジェクトによっては、次のようなものも基本設計書に含まれます。

• 画面一覧
• 画面レイアウト
• 画面遷移
• 入出力項目
• APIのインターフェース
• 外部システムとの連携方法
• データベースの論理設計

機能仕様書が「その機能が何をするのか」を定義するのに対して、基本設計書では「その機能をユーザーや外部システムから見て、どのような形で実現するのか」を具体化していきます。

詳細設計書

詳細設計書では、基本設計をもとに、プログラム内部でどのように実装するのかを具体化します。

例えば、以下のような内容を記載します。

• どのクラスを作成するか
• どのメソッドで処理するか
• 各処理をどのような順序で実行するか
• データをどのように読み書きするか
• SQLをどのように実行するか
• API内部でどのような処理を行うか
• エラー処理をどのようなロジックで実装するか

例えば、ユーザー登録機能なら、

• UserServiceクラスでユーザー登録処理を行う
• usersテーブルにユーザー情報を登録する
• メールアドレスにはUNIQUE制約を設定する

といった、開発者向けの実装内容を記載します。

機能仕様書はいつ作る？

一般的には、要件定義が終わったあと、基本設計や実装を進める前に作成します。

例えば、次のような流れです。

企画
↓
要件定義
↓
機能仕様書
↓
基本設計
↓
詳細設計
↓
実装
↓
テスト

ただし、実際の開発では、必ずしもこの流れどおりに一方向で進むわけではありません。

例えば、基本設計やプロトタイプの作成を進めている途中で、

• 入力内容に誤りがあった場合はどうするのか
• 同じメールアドレスがすでに登録されていた場合はどうするのか

など、追加で決める必要がある仕様に気づくことがあります。

その場合は、必要に応じて機能仕様書に戻り、内容を追加・修正します。

ただし、設計で決まった内容をすべて機能仕様書へ書き戻すわけではありません。設計を進める中で、製品としてユーザーに保証すべき新しい振る舞いや条件が判明した場合に、機能仕様書へ反映します。

例えば、画面を試作した結果、「この状態では登録ボタンを押せないようにする必要がある」と分かった場合、その振る舞いが製品仕様であれば機能仕様書にも反映します。

このように、要件定義・機能仕様・設計は必ずしも一方向に進むものではなく、必要に応じて内容を見直しながら開発を進めます。

機能仕様書に書く主な項目

機能仕様書には「必ずこの項目を書かなければならない」という決まりがあるわけではありません。ただし、一般的には次のような内容を記載します。

1. 基本情報・改訂履歴

まず、文書自体の情報を記載します。例えば、文書名・バージョン・作成日・作成者・承認者・改訂履歴などを記載し、誰が・いつ・どのバージョンを作ったかが一目でわかるようにします。仕様変更のたびに更新履歴を残すことで、「古い仕様書を見ていた」といったトラブルを防ぎやすくなります。

2. システム概要

そのシステムが何のために存在するのかを簡単に説明します。

例えば、以下のような内容です。

本機能は、ユーザーがWebサービスを利用するためのアカウントを作成する機能です。氏名・メールアドレス・パスワードを入力して、ユーザー登録を行うことができます。

このように、専門知識のない人でも理解できる言葉で書くとよいでしょう。

3. 用語定義

プロジェクト独自の用語や、意味があいまいになりやすい言葉がある場合は、あらかじめ定義します。

例えば、次のようにまとめます。

例えば、「ユーザー」という言葉でも、管理者を含むのか、一般ユーザーだけを指すのかによって、仕様の意味が変わることがあります。そのため、用語の意味をあらかじめ決めておくことで、関係者による解釈の違いを防ぐことができます。

4. 利用者と利用環境

システムを誰が、どのような環境で利用するのかを定義します。

例えば、利用者には次のような種類があります。

• 管理者
• 未登録ユーザー
• 一般ユーザー

役割によって利用できる機能が異なる場合は、その違いも記載します。

• 管理者：ユーザーの追加や削除、システムの設定変更ができる
• 未登録ユーザー：氏名・メールアドレス・パスワードを入力して、自分のアカウントを登録できる
• 一般ユーザー：登録したアカウントでログインし、通常の機能を利用できる

といった内容です。

また、システムを利用する環境についても定義します。

• Windows
• macOS
• Chrome
• Edge
• スマートフォン

このように、「誰が利用するのか」「それぞれ何ができるのか」「どのような環境で利用するのか」を明確にしておくことで、システムの利用条件について関係者の認識をそろえることができます。

5. 機能一覧

システムにどのような機能があるのかを一覧にします。

例えば、ユーザー登録を含むWebサービスであれば、次のようにまとめます。

このように、機能ごとに機能IDを付けて整理しておくと、他のドキュメントから参照しやすくなります。

例えば、「テストケース F-001-01」のように、ユーザー登録機能に関するテストケースと紐付けることもできます。

6. 各機能の詳細仕様

機能仕様書の中心となる部分です。

機能一覧に挙げた各機能について、具体的にどのように動作するのかを定義します。

例えば、ユーザー登録機能なら次のように書けます。

#### 機能名

ユーザー登録機能

#### 機能概要

新しいユーザーのアカウントを登録する。

#### 入力項目

- 氏名
- メールアドレス
- パスワード

#### 処理

1. ユーザーが必要事項を入力する
2. 登録ボタンを押す
3. システムが入力内容を確認する
4. 問題がなければユーザーを登録する
5. 登録完了画面を表示する

#### 正常時

ユーザー登録を行い、登録完了画面を表示する。

#### 異常時

入力内容に問題がある場合は、エラーメッセージを表示する。

この部分を書くときに重要なのは、プログラム内部でどのように実装するかではなく、ユーザーや外部から見てシステムがどのように振る舞うのかを書くことです。

迷った場合は、実装方法を知らないテスト担当者が、その仕様を読んで動作を確認できるかを考えると分かりやすいでしょう。

例えば、

• 「usersテーブルにユーザー情報を登録する」→ 内部の実装方法なので設計情報
• 「ユーザー登録に成功すると、登録完了画面を表示する」→ 実際に操作して確認できるため機能仕様
• 「登録済みのメールアドレスでは登録できない」→ 実際に操作して確認できるため機能仕様

と判断できます。

7. データ仕様

入力項目や出力項目について、詳細な条件を記載します。

例えば、ユーザー登録機能では次のようにします。

このように入力条件を明確にしておくことで、以下のような疑問が起きにくくなります。

• パスワードは何文字以上必要なのか？
• メールアドレスは必須なのか？

8. エラー処理

正常時だけでなく、エラーが発生した場合の振る舞いも重要です。

例えば、次のようにまとめます。

エラー時の動作は抜けやすいため、正常に処理できる場合だけでなく、異常系や例外系についても意識して記載する必要があります。また、文字数の上限・下限など、境界となる条件についても明確にしておくと、実装やテスト時の認識違いを防ぎやすくなります。

9. 非機能要件

機能そのものの動作だけでなく、性能やセキュリティなど、システムの品質に関する要件を記載する場合もあります。

例えば、ユーザー登録機能であれば、

• 登録処理は3秒以内に完了する
• 通信はHTTPSで暗号化する
• パスワードは平文で保存しない
• 同時に100件のユーザー登録処理が行われても、登録処理を継続できる

規模の大きなシステムでは、非機能要件だけを別の文書にまとめることもあります。

「各機能の詳細仕様」の書き方

では、実際に「各機能の詳細仕様」をどのように書けばよいのでしょうか。代表的な書き方をいくつか紹介します。

項目ごとに整理する方法

機能ごとに、あらかじめ決めた項目に沿って仕様を整理する方法です。

例えば、ユーザー登録機能であれば、次のようにまとめます。

機能名：
ユーザー登録機能

機能概要：
新しいユーザーのアカウントを登録する。

前提条件：
登録されていないメールアドレスであること。

入力項目：
・氏名
・メールアドレス
・パスワード

処理：
1. 入力内容を確認する
2. 問題がなければユーザーを登録する
3. 確認メールを送信する

正常時：
ユーザー登録を行い、登録完了画面を表示する。

異常時：
入力内容に問題がある場合は、エラーメッセージを表示する。

この書き方は、機能ごとに同じ項目を確認しながら記載できるため、仕様の抜け漏れを防ぎやすいというメリットがあります。ただし、単純な機能では項目が細かすぎて、かえって文書が長くなることもあります。そのため、機能の複雑さに応じて、必要な項目だけを使うとよいでしょう。

処理の流れを書く方法

ユーザーの操作に沿って、システムがどのように動くのかを順番に説明する方法です。日本のシステム開発でもよく使われる書き方です。

例えば、ユーザー登録機能であれば、次のように書きます。

【動作の流れ】

- ユーザーが登録画面を開く
- 氏名・メールアドレス・パスワードを入力する
- 登録ボタンを押す
- システムが入力内容を確認する
- 入力内容に問題がなければユーザーを登録する
- 登録完了画面を表示する
- 登録したメールアドレスへ確認メールを送信する

【制限事項】

- メールアドレスは必須とする
- 登録済みのメールアドレスは使用できない
- パスワードは8文字以上とする

この書き方では、「ユーザーが何をすると、システムがどう動くのか」を上から順番に確認できるため、処理の流れを理解しやすいという特徴があります。また、メールアドレスの必須条件やパスワードの文字数など、処理の流れとは別に決めておく条件は「制限事項」として分けて記載すると、仕様を確認しやすくなります。

基本フローと例外フローに分ける方法

正常に処理が進む場合の流れを「基本フロー」、エラーなどで通常とは異なる処理になる場合を「例外フロー」として分けて書く方法です。正常系と異常系を対比させたいときに向いています。

例えば、ユーザー登録機能であれば次のように書きます。

【基本フロー】

1. ユーザーが登録画面を表示する
2. 氏名・メールアドレス・パスワードを入力する
3. 登録ボタンを押す
4. システムが入力内容を確認する
5. 問題がなければユーザーを登録する
6. 登録完了画面を表示する

【例外フロー】

4a. 必須項目が入力されていない場合
    エラーメッセージを表示する

4b. メールアドレスがすでに登録されている場合
    登録済みであることを示すエラーメッセージを表示する

この書き方では、正常時の流れとエラー時の流れを分けて確認できるため、複数のエラー条件がある機能でも仕様を整理しやすくなります。特に、「4a」「4b」のように、基本フローのどの時点から分岐するのかが分かるのがメリットです。

本記事のまとめ

この記事では、機能仕様書とは何なのか、要件定義書・基本設計書・詳細設計書との違いや、主な記載項目、具体的な書き方について解説しました。

機能仕様書を書くときは、以下の点を意識すると分かりやすくなります。

• 機能仕様書には、システムが「何をするのか」を記載する
• 実装方法ではなく、ユーザーや外部から確認できる振る舞いを書く
• 正常時だけでなく、異常時や例外時の動作も記載する
• 入力条件や制限事項は、できるだけ具体的にする
• 機能仕様か設計情報か迷った場合は、実装を知らないテスト担当者が確認できる内容かどうかを考える
• 設計を進める中で新しい製品仕様が判明した場合は、必要に応じて機能仕様書も更新する

機能仕様書は、開発者だけでなく、テスト担当者やマニュアル担当者、サポート担当者など、さまざまな関係者がシステムの振る舞いを理解するための重要な文書です。

「どのように実装するか」ではなく、「製品としてどのように振る舞うのか」を意識して書くと、分かりやすい機能仕様書を作りやすくなります。

お読みいただきありがとうございました。