当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
『機能仕様書を書いて』と頼まれたものの、何をどこまで書けばいいのか分からない。要件定義書や設計書とも似ていて、違いがあいまいですよね。
結論から言うと、機能仕様書は「この機能は、何を受け取って、何をして、何を返すか」を決める書類です。1つの機能を「入力」「処理」「出力」「例外」の4枠で書けば、初めてでも形になります。
この記事を読めば、機能仕様書とは何か、書く項目と書き方、テンプレートやサンプルとの付き合い方が分かります。
機能仕様書とは？何を決める書類か
機能仕様書とは、システムの1つ1つの機能が「何をするか」を決めて書いた書類です。作る人、テストする人、使う人が同じ動きを思い浮かべられるようにするのが目的です。
国際的な用語の規格 ISO/IEC/IEEE 24765:2010 では、functional specification を「システムや部品が果たすべき機能を定める文書」という意味で定義しています。同じ規格の注記では、要求仕様の一部であることが多い、とも書かれています。
つまり機能仕様書は、ふわっとした「こうしたい」を、作れる言葉に直した書類なんです。
システムの機能仕様書は誰が読むのか
『書くのは自分でも、読むのは誰？』と考えておくと、書く量が決めやすくなります。
| 読む人 | 機能仕様書で知りたいこと |
|---|---|
| 発注側・業務の担当者 | 頼んだとおりの動きになっているか |
| 設計・プログラムを書く人 | 何を受け取り、何を返せばいいか |
| テストをする人 | どうなれば正しいと言えるか |
| 保守・運用の担当者 | あとで直す時に、元の決めごとは何だったか |
この4者が同じ書類を見て、同じ動きを思い浮かべられれば合格です。逆に、誰か1人でも「どっちの意味？」と聞き返すなら、まだ書き足りない所があります。
「機能」と呼ぶ単位の目安
機能の単位は、「利用者や他のシステムから見て、1回の操作でひとまとまりの結果が出るもの」くらいで考えると分かりやすいです。
例えば受注システムなら、「注文を登録する」「注文を取り消す」「注文の一覧を出す」がそれぞれ1つの機能です。「注文管理」とまとめてしまうと、中身が多すぎて書きにくくなります。
「機能仕様書」「機能設計書」「機能定義書」など、似た名前の書類が現場ごとに使われています。名前より「この書類で何を決めるのか」を最初にチームで合わせておくと、迷いが減りますよ。
要件定義書・設計仕様書との違い
要件定義書は「何を実現したいか」、機能仕様書は「機能が何をするか」、設計仕様書は「それをどう作るか」を書きます。上から順に、決めることが細かくなっていきます。
『機能仕様書と設計仕様書の違いがよく分からない』という声は、とても多いです。並べてみると、それぞれの役目が見えてきます。
| 書類 | 主に決めること | 主な読み手 | 書く時期の目安 |
|---|---|---|---|
| 要件定義書 | 業務の目的、必要な機能の一覧、性能などの条件 | 発注側と開発側の両方 | 開発のはじめ |
| 機能仕様書 | 機能ごとの入力・処理・出力・例外 | 開発側、テスト担当、業務の担当者 | 要件が固まった後 |
| 設計仕様書（設計書） | 画面やデータの作り、プログラムの分け方 | 開発側 | 機能仕様が固まった後 |
デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）では、要件定義書の機能要件として「機能」「画面」「帳票」「データ」「外部インタフェース」に関する事項を挙げています。機能仕様書は、このうち「機能」を一つずつ深く書いたもの、と考えるとつながりが分かりやすいです。
同じガイドラインでは、画面や帳票など利用者が直接分かる基本設計を行い、その後に機能を実現するための詳細設計を行う、としています。現場によっては、機能仕様書を基本設計の一部として書くこともあります。
- 利用者から見た機能の動き
- 受け取る値と返す結果
- エラーや例外の時の動き
- プログラムやデータの作り
- 処理の順番や部品の分け方
- 使う技術や画面の部品
要件定義書の中身は要件定義書とは？目的・書く内容・作る流れで、画面や帳票を含めた設計は基本設計書の書く項目と書き方で詳しく紹介しています。
英語だとどう呼ぶ？
先ほどの用語規格では、design specification は design description（設計を記述した文書）の同義語として扱われています。英語の資料を読む時は、functional specification が機能仕様書、design specification が設計仕様書に当たると考えておけば迷いません。
1つの機能を「入力・処理・出力・例外」の4枠で書く
機能仕様書の中身は、1機能ごとに「入力」「処理」「出力」「例外」の4枠を埋めると形になります。特に「例外」の枠を空けたまま渡さないのが、手戻りを減らすコツです。
『白紙から書こうとすると手が止まる…』という方も多いはずです。そこで編集部では、1つの機能を4つの枠に分けて書く記入表を作りました。
| 枠 | 書くこと | 書き方のコツ |
|---|---|---|
| 入力 | 誰が・何を・どこから渡すか | 項目名、必須か任意か、受け付ける文字や桁 |
| 処理 | 受け取った値で何をするか | 条件ごとに「〜の時は〜する」で書く |
| 出力 | 何を・どこへ返すか | 画面、帳票、ファイル、他のシステムへの連携 |
| 例外 | うまくいかない時どうするか | 入力の誤り、データが無い時、つながらない時 |
機能仕様書の例：注文を登録する機能
編集部が作った架空の例で、4枠を埋めてみますね。社内の受注システムで「注文を登録する」機能を書く場合です。
| 枠 | 記入例 |
|---|---|
| 入力 | 担当者が注文画面で、取引先、商品、数量、希望納期を入れる。取引先・商品・数量は必須 |
| 処理 | 在庫が足りる時は、注文を「受付済み」で登録する。足りない時は「入荷待ち」で登録する |
| 出力 | 画面に注文番号を出す。注文確認書の帳票を作り、出荷の担当者へ一覧で知らせる |
| 例外 | 数量が空欄や0の時は、入力欄の横に理由を出して登録しない。取引先が取引停止中の時は登録しない |
こうして書くと、テストをする人も「在庫が足りない時の動き」を確かめればいい、とすぐ分かります。
「例外」の枠は特に念入りに
ふだんの動きは、頼む人も作る人も頭に浮かびやすいものです。ところが、失敗した時の動きは誰も決めていないことがよくあるんです。
例えば、こんな会話が起きがちです。
「数量に0が入った時、どうなる仕様でしたっけ？」
「えっ、そこは決めていませんでした」
例外の枠を書く時は、「空欄」「範囲外」「重複」「データが無い」「他のシステムにつながらない」の5つを順に思い浮かべてみてください。
- 空欄や未選択の時の動きを書いた
- 決めた範囲を外れた値の時の動きを書いた
- 同じ内容が二重に送られた時の動きを書いた
- 探したデータが見つからない時の動きを書いた
- 他のシステムにつながらない時の動きを書いた
機能仕様書に書く項目と目次、テンプレートの使い方
機能仕様書の目次は、「全体の説明」「機能の一覧」「機能ごとの4枠」「画面・帳票・データとの関係」「未決事項と変更履歴」の5つのまとまりで作ると抜けが出にくくなります。
機能仕様書の項目は、会社やチームのテンプレートによって違います。ここでは、どの現場でも使いやすい目次の例を紹介しますね。
| 章 | 主な項目 | 書く時の目安 |
|---|---|---|
| 1. はじめに | 目的、対象範囲、用語の意味、関係する書類 | 1ページ程度 |
| 2. 機能一覧 | 機能の番号、機能名、使う人、優先度 | 表1枚 |
| 3. 機能ごとの仕様 | 入力・処理・出力・例外の4枠 | 1機能につき1〜2ページ |
| 4. 画面・帳票・データとの関係 | どの機能がどの画面・帳票・データを使うか | 対応表 |
| 5. 未決事項・変更履歴 | まだ決まっていない事、版と変更の内容 | 随時更新 |
表紙には、システム名、書類名、版、作成日、作成者、承認者を入れておきましょう。どの版を見ているかが分からないと、話がかみ合わなくなります。
機能仕様書のテンプレートはExcelとWordどちらがいい？
『機能仕様書のテンプレートはExcelとWordのどちらで作るべき？』と迷う方もいますよね。結論から言うと、機能の数が多いならExcel、説明の文章が多いならWordが向いています。
| 形式 | 向いている使い方 | 気をつけたいこと |
|---|---|---|
| Excel | 機能一覧や4枠の記入表を、1機能1行やシートごとに並べる | セルに長い文章を詰め込むと読みにくい |
| Word | 処理の流れや業務の説明を、文章と図で書く | 機能の数が増えると一覧で見にくい |
| Markdown | 文章で書き、変更の差分をチームで追いたい | 書き方の決まりをチームでそろえる |
機能仕様書テンプレートをExcelで作るなら、「機能一覧」シートと「機能ごとの4枠」シートを分けると見やすくなります。Markdownで書く方法は仕様書・設計書をMarkdownで書くで紹介しています。
機能仕様書のサンプルは「形」だけ借りる
機能仕様書サンプルをExcel形式で探したり、Wordのひな形を探したりしている方も多いはずです。サンプルは、目次の並びや表の作りを知るのには役立ちます。
ただ、中身の言葉までそのまま使うのはおすすめしません。業務も利用者も違うので、サンプルの文をなぞると、自分のシステムに無い動きが混ざってしまうんです。
サンプルの項目をすべて埋めようとして、関係の無い欄まで「該当なし」で埋めてしまうことがあります。使わない章は消して、自分のシステムで決めるべき事に時間を使いましょう。
IPAの資料で機能仕様書の考え方を探すなら
IPAの資料で機能仕様書の考え方を知りたい時は、「共通フレーム2013」が手がかりになります。開発の作業を、ソフトウェア要件定義、方式設計、詳細設計のように段階ごとに並べた共通の枠組みです。
発注側の目線で要件をまとめる時は、IPAの「ユーザのための要件定義ガイド 第2版」も参考になります。どちらも、書類の名前より「その段階で何を決めるか」を考える助けになりますよ。
機能仕様書の書き方：伝わる文にする5つのコツ
機能仕様書の書き方のコツは、「1文に1つの動き」「条件と結果をセットで書く」「あいまいな言葉を数や状態に直す」の3つが土台です。未決の事は隠さず、未決と書いて残しましょう。
同じ4枠でも、書き方ひとつで伝わり方は大きく変わります。読み手が迷わない文にするコツを、手順にしてみました。
- 機能一覧を作り、機能ごとに番号を振る
- 1機能ずつ、入力・処理・出力・例外の4枠を埋める
- 「適切に」「なるべく」などのあいまいな言葉を、数や状態に直す
- 決まっていない事は「未決」と書き、誰がいつまでに決めるかを添える
- 業務の担当者とテスト担当に読んでもらい、聞き返された所を直す
あいまいな言葉を直す例
『分かりやすく書いたつもりなのに、伝わっていなかった…』ということ、ありますよね。原因の多くは、読み手によって意味が変わる言葉です。
| 書きがちな文 | 直した文 |
|---|---|
| 入力に誤りがあれば適切にエラーを出す | 数量が空欄の時は、入力欄の横に「数量を入れてください」と出す |
| 一覧はなるべく早く表示する | 一覧は、検索ボタンを押してから待たずに表示されることを目安にする（数値は非機能要件で決める） |
| 必要に応じて担当者に通知する | 「入荷待ち」で登録された時だけ、出荷の担当者に一覧で知らせる |
速さなど「どのくらいの質で動くか」は、機能仕様ではなく非機能要件の話になります。決め方は非機能要件とは？要件定義書に書く項目と決め方で紹介しています。
「こうなったらこうなる」を全部書く必要はある？
条件の組み合わせが多い機能は、文章で全部書こうとすると読みにくくなります。そんな時は、条件を列に、結果を行に並べた表にしてみてください。
例えば「在庫が足りるか」「取引先が取引中か」の2つの条件なら、組み合わせは4通りです。4通りそれぞれの結果を表で書けば、抜けがあるとすぐ気づけます。
未決の事は「TBD」と書いて残す
まだ決まっていない所を、空欄のまま渡すのはやめておきましょう。英語の資料でよく見る「TBD」は To Be Determined の略で、「後で決める」という意味です。
TBDと書く時は、何を、誰が、いつまでに決めるかを添えておきます。デジタル庁のDS-100でも、未確定な要件はリスクの要因になり得るので、その旨を要件定義書で明らかにすることとされています。
レビューを頼む時は「全部見てください」より、「例外の枠に抜けが無いか見てください」と見てほしい所を伝えると、返事が具体的になります。見る観点は設計書・仕様書のレビュー観点も参考にしてみてください。
機能仕様書でよくある相談
知恵袋では「機能仕様書と機能設計書の違い」「仕様書の書き方を身につけたい」「仕様書の書き方がうまくなりたい」という相談がよく読まれています。どれも、決めることの段階をそろえれば答えが見えてきます。
知恵袋で多く読まれている相談を、内容を要約して答えてみますね。
相談1：機能仕様書と機能設計書は何が違う？
『システム開発の仕事で、機能仕様書と機能設計書という2つの書類が出てきて、違いが分からない』という相談です。
結論から言うと、名前の決まりは現場ごとに違います。そのうえで多いのは、機能仕様書が「機能が何をするか」、機能設計書が「それをどう作るか」を書く、という分け方です。
迷った時は、書類の目次を見比べてみてください。入力や出力の決めごとが中心なら仕様、プログラムの部品やデータの作りが中心なら設計、と見分けがつきます。
相談2：仕事を探している最中に、仕様書の書き方を身につけたい
『求職中で、仕様書の書き方を学んでおきたい。何から始めればいい？』という相談です。
おすすめは、身近な仕組みを1つ選んで、4枠で書いてみることです。例えば「会員登録」なら、入力は名前とメールアドレス、出力は登録完了の画面、例外は同じメールアドレスがすでにある時、と書き出せます。
書いた物を人に読んでもらい、聞き返された所を直す。この繰り返しが、いちばんの練習になります。
相談3：長く働いているのに、仕様書の書き方がうまくならない
『SEとして長く働いているけれど、仕様書の質に自信が持てない』という相談です。
経験が長い方ほど、自分には当たり前の前提を書き落としやすいものです。新しく入った人やテスト担当に読んでもらうと、書き足りない所が見つかりやすくなります。
- 1文に動きが1つだけになっている
- 条件と結果がセットで書かれている
- 例外の枠が空いていない
- 未決の事に、決める人と期限が書いてある
- 版と変更の履歴が残っている
機能仕様書を書けるようになると、テスト仕様書も書きやすくなります。機能ごとの4枠が、そのままテストの確かめどころになるからです。テストとのつなぎ方はテスト仕様書とは？書き方・項目とテンプレートの使い方で紹介しています。
書けるようになった力は、仕事の幅にもつながる
機能の動きを言葉にして、関係者の認識を合わせる力は、要件定義や設計などの上流工程で求められる力そのものです。今の職場で担当を少しずつ広げるのも、資格を取ってから動くのも、どちらもよい道です。
今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると、どんな経験が評価されるかが見えてきます。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
上流工程に進む道筋は上流工程とは？要件定義・設計ができるエンジニアになる道筋で紹介しています。
よくある質問
機能仕様書とは、ひと言でいうと何ですか？
システムの1つ1つの機能が「何を受け取り、何をして、何を返すか」を決めた書類です。作る人、テストする人、使う人が同じ動きを思い浮かべられるようにするために書きます。
機能仕様書と設計仕様書の違いは何ですか？
機能仕様書は機能が何をするかを、設計仕様書はそれをどう作るかを書きます。現場によって呼び方や分け方が違うので、書類で何を決めるかをチームで合わせておきましょう。
機能仕様書のテンプレートはExcelとWordのどちらがいいですか？
機能の数が多く一覧で管理したいならExcel、処理の説明の文章が多いならWordが向いています。機能一覧と、機能ごとの記入表を分けて作ると見やすくなります。
機能仕様書のサンプルはそのまま使えますか？
目次や表の作りを参考にするのには役立ちます。ただ、中身の言葉は業務や利用者によって違うので、自分のシステムに合わせて書き直してみてください。
機能仕様書はどのくらい細かく書けばいいですか？
テストをする人が、その書類だけで「どうなれば正しいか」を判断できるくらいが目安です。入力・処理・出力・例外の4枠がすべて埋まっていれば、大きな抜けは防げます。
まとめ
- 機能仕様書は、機能ごとに何を受け取り、何をして、何を返すかを決める書類
- 要件定義書は何を実現したいか、設計仕様書はどう作るかを書く
- 1機能を入力・処理・出力・例外の4枠で書くと形になる
- テンプレートは機能が多ければExcel、文章が多ければWordが向く
- サンプルは形だけ借り、未決の事はTBDとして決める人と期限を添える
コメント