仕様書の書き方｜誰が読んでも同じに伝わる7つのコツ

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

仕様書の書き方は「読む人が迷わないか」で決まる

仕様書そのものの意味や、設計書・要件定義書との違いは仕様書とは？意味と目的、設計書・要件定義書との違いでまとめています。ここでは「どう書くか」に絞ってお話ししますね。

『文章が苦手だから、仕様書もうまく書けない』と心配する方もいますよね。実は、仕様書は名文である必要はまったくないんです。

求められるのは、読んだ人が迷わないことだけです。だからこそ、コツさえ押さえれば誰でも書けるようになります。

仕様書を読むのはどんな人？

書き始める前に、誰がこの仕様書を読むのかを思い浮かべてみてください。読む人によって、どこを詳しく書くべきかが変わります。

この4者が同じ文書を読みます。どの人が読んでも同じ答えにたどり着ける書き方が、いい仕様書の条件なんです。

仕様書の作り方：書き始める前の準備と手順

仕様書の作成方法は、業界や会社でいろいろあります。ただ、どの分野でも通じる手順は次のとおりです。

目次はひな形を借りてもいい

『目次をゼロから考えるのは大変そう』と感じますよね。目次は、社内の過去の仕様書や公的な手引きの項目を借りて作って大丈夫です。

項目の並べ方や表紙の作り方は仕様書に書く項目と目次・表紙の作り方、ExcelやWordのひな形の使い方は仕様書のテンプレートで紹介しています。

決まっていない事は「未定」と書いて残す

書いている途中で、まだ決まっていない事が出てくるのは普通のことです。そんな時は空欄にせず、「未定（〇月の打合せで決める）」と書いておきましょう。

デジタル庁のデジタル・ガバメント推進標準ガイドラインでも、未確定な要件はリスクになり得るので、その旨を要件定義書で明らかにするよう求めています。決まっていない事が見えている仕様書のほうが、後から揉めにくいんです。

誰が読んでも同じに伝わる7つのコツ

ここからが本題です。日本の規格の書き方を定めたJIS Z 8301:2019の考え方も参考にしながら、7つにまとめました。

コツ1：一文に一つのことだけを書く

「登録したら一覧に表示し、担当者に通知して、ログも残す」のように1文に3つの動きを入れると、どれか1つが抜けても気づきにくくなります。動きごとに文を分けておきましょう。

文を分けると、テストや検査の項目にもそのまま使えます。1文が1つの確認項目になるイメージです。

コツ2：主語をはっきり書く

「入力内容を確認する」と書くと、確認するのがシステムなのか担当者なのか分かりませんよね。「システムが」「受付担当が」と主語を入れるだけで、誤解はかなり減ります。

コツ3：あいまいな量は数字にする

「大きめの文字」「すばやく」「十分な強度」は、人によって思い浮かべる物が違います。JIS Z 8301:2019の一般原則でも、要求事項は客観的に検証できるものだけを書き、「十分に強い」のような表現は使わないとされています。

コツ4：場合分けは条件として書く

「必要に応じて」「場合によっては」は、どんな場合なのかが書いてありません。「〇〇の時は」「〇〇でなければ」と条件をはっきり書きましょう。

コツ5：迷いそうな所には例を付ける

ルールだけでは伝わりにくい所は、具体例を1つ添えると一気に分かりやすくなります。例えば「全角10文字まで」と書いたら、「例：仕様書ドットコム編集部（11文字なので入力できない）」のように添える形です。

記入例をたくさん見たい方は、仕様書のサンプル・記入例も参考にしてみてください。

コツ6：同じ物は同じ言葉で呼ぶ

ある所では「顧客」、別の所では「お客様」「利用者」と書くと、読む人は別の物だと受け取ってしまいます。最初に出てくる所で言葉を決めて、最後まで同じ言葉を使いましょう。

コツ7：「どう確かめるか」まで書く

仕様書の文は、読んだ人が「できている・できていない」を判断できる形にしておきます。確かめ方が書けない文は、まだあいまいさが残っているサインなんです。

語尾をそろえると読み違いが減る

JIS Z 8301:2019では、要求は「…しなければならない」「…する」、推奨は「…することが望ましい」、許容は「…してもよい」のように表現の形を決めています。「…すべきである」は使わないとされているのも特徴です。

社内の仕様書でここまで厳密にする必要はありません。ただ、「守ってほしい事」と「できればでいい事」の語尾を分けておくだけで、読む人の迷いはかなり減ります。

あいまいな言葉を「数字・条件・例」に置き換える書き換え表

『どこがあいまいなのか、自分では気づけない』という方も多いですよね。そこで編集部では、よく見かけるあいまいな言葉を3つの置き換え方で分けた表を作ってみました。

表の数字はあくまで書き方の例です。実際の値は、使う人や発注者と相談して決めてくださいね。

数字が決められない時はどうする？

『何秒なら妥当なのか、そもそも分からない』という時もありますよね。そんな時は無理に数字を作らず、「今の業務で何秒かかっているか測ってから決める」と未定事項に入れておきましょう。

根拠のない数字を書くと、後で「なぜこの数字なの？」と聞かれた時に答えられません。決めた理由を一言添えておくのがおすすめです。

書く物別の書き方：プログラム・関数・制御盤・業者に出す仕様書

プログラム・ソフトウェアの仕様書の書き方

プログラムの仕様書は、「何を受け取って、何を返すか、うまくいかない時はどうするか」が中心です。ソフトウェアの仕様書の書き方で迷ったら、まずこの3つを表にしてみてください。

画面からボタンを押した時に、どのテーブルのどの項目が更新されるかも書いておくと、後から直す人がとても助かります。画面や機能の書き方は機能仕様書とは？で詳しく紹介しています。

関数の仕様書の書き方

関数の仕様書は、1つの関数につき「名前・役割・引数・戻り値・前提・例外」をそろえて書くのが基本です。役割は1文で言える長さに収めましょう。

例えば「税込金額を計算する」関数なら、引数に「税抜金額（0以上の整数）」、戻り値に「税込金額（整数・端数の扱いは〇〇）」と書きます。端数の扱いのような、人によって答えが変わる所を書いておくのがポイントです。

制御盤の仕様書の書き方

制御盤の仕様書は、盤の中身よりも「どんな条件で、何を動かし、何を止めるか」が肝心です。設置場所の環境や、異常の時にどう止まるかも、作る側が一番知りたい所になります。

具体的な値や規格は、発注者や設計者の基準によって変わります。社内の基準書や過去の盤の資料と照らし合わせて決めてください。

業者が作成する仕様書と、発注者が書く仕様書

『仕様書って、業者が作成するものじゃないの？』という声もよく聞きます。実際、細かい仕様を業者が作成して、発注者が確認する進め方も多いんです。

ただ、何を頼みたいか、何ができていれば合格かは、頼む側にしか決められません。IPAの「超上流から攻めるIT化の原理原則17ヶ条」にも「要件定義は発注者の責任である」という条があります。

業者が作った案を受け取ったら、そのまま承認せずに「自分たちの目的に合っているか」を確かめておきましょう。発注の仕様書の書き方は発注仕様書とは？で詳しく紹介しています。

「同等品」の書き方

物品を調達する仕様書では、特定のメーカーの製品名だけを書くと、他の製品が参加できなくなってしまいます。総務省行政管理局の「情報システムに係る政府調達の基本指針」実務手引書（2007年）でも、原則として特定の商標名等を用いた要求要件を定めないこととされています。

JIS Z 8301:2019の一般原則でも、性能で決めるのが難しく材料などを指定する時は「…又はこれと同等以上の材料」のように書くのが望ましいとされています。同等品の書き方で迷ったら、製品名ではなく「必要な性能」を並べるのが基本です。

仕様書を変更する時の書き方

仕様は、作っている途中でも変わるものです。困るのは変更そのものより、「変わったことが伝わっていない」ことなんですよね。

表は架空の記入例です。小さな直しは小数点以下、大きな変更は先頭の数字を上げる、のように版の付け方のルールを決めておくと分かりやすくなります。

版の付け方や、変更をどう関係者に伝えるかは仕様書の変更管理で詳しく紹介しています。

仕様書の書き方でよくある相談

Q&Aサイトでよく見かける仕様書の書き方の相談を、内容を要約して紹介しますね。

相談1：システムに詳しくないのに、仕様書と画面の設計を任された

『開発は外注業者がやるけど、仕様書作成と画面レイアウトまでは自分の役目になった。手順が分からない』という相談です。システムに詳しくない担当の方からよく出ます。

この場合は、まず「今の業務の流れ」と「困っている事」を書き出すところから始めましょう。システムの専門用語で書く必要はありません。

画面は、手書きでも表計算ソフトでもいいので、置きたい項目を並べた絵を描いてみてください。それを外注先に見せて質問をもらうと、仕様書の抜けがどんどん見えてきます。

相談2：ボタンを押した時に何が更新されるかまで書くべき？

『画面で登録ボタンを押した時、どのテーブルのどの項目が更新されるか分かる仕様書はあった方がいいのか』という相談もあります。

結論から言うと、あった方がいいです。特に、後から別の人が直す時や、データがおかしくなった時の原因探しで大きく役立ちます。

ただ、全部の画面で細かく書くと時間がかかります。お金や在庫など、間違うと影響が大きいデータから優先して書いてみてください。

相談3：長く書いてきたのに、仕様書の文章に自信が持てない

『プログラマとして長く働いているが、仕様書の文章の書き方を改めて教わったことがない』という相談も目立ちます。経験が長い方ほど、自己流のまま来ていることが多いんです。

そんな時は、7つのコツのうち「数字・条件・例」の3つだけを意識して、過去の仕様書を1本書き直してみてください。書き直した前後を同僚に読んでもらうと、違いがはっきり分かります。

仕様書を書く力は、システム開発の上流工程を任される時にとても評価されやすい力です。今の職場で書く機会を増やすのも、今の担当工程から一歩進める職場を探すのも、どちらも正当な道です。

よくある質問

まとめ

生成AIを使って下書きを速く作る方法は仕様書をAIで作るで紹介しています。

あわせて読みたい

仕様書とは？意味と目的、設計書・要件定義書との違い

仕様書に書く項目と目次・表紙の作り方｜共通の骨組みと業界別の項目

仕様書のテンプレート｜Excel・Wordで作る時のひな形と使い方