Web制作の仕様書とは。要件定義書との違いと、実際に必要な場面

Web制作の仕様書とは、「どう作るか」を書いた資料です。

要件定義書が「何を作るか」を決めるものなので、その次にくるものだと考えていただければ間違いありません。

ただ、コーポレートサイトや採用サイトで仕様書が必要になる場面は、限られます。

---

Web制作の仕様書と要件定義書の違い

まず、並べて整理します。

	要件定義書	仕様書
書くこと	何を作るか	どう作るか
粒度	目的・ページ構成・必要な機能	画面ごとの項目、動作、条件分岐
読む人	発注側と制作側の両方	主に作る人
作る人	発注する側／または一緒に	制作会社が中心

たとえば「問い合わせフォームが必要」と決めるのが要件定義書です。

そのフォームに何の項目を置くか、必須はどれか、入力を間違えたときに何を表示するか、送信後にどこへ移動するか——ここまで書くのが仕様書です。

教科書的には、要件定義書 → 仕様書 → 制作、という順番になります。要件定義そのものについてはWebサイトの要件定義とは何かに書いています。

---

実際には、Web制作の仕様書を作らない案件のほうが多いです

正直に書きます。

私たちは年間40本ほどのサイトを作っていますが、独立した仕様書を作る案件は多くありません。

手を抜いているわけではなく、必要がないからです。会社案内、サービス紹介、施工事例、採用ページ——こうしたページは、画面ごとの動作条件が複雑になりません。フォームも、項目が決まればそれ以上書くことがあまりない。

書くことがほとんどない書類を、形式のために作っても、誰も読みません。

---

Web制作の仕様書が、本当に必要になる場面

では、どういうときに必要なのか。私たちの経験では、次のような条件が入ってきたときです。

場面	なぜ必要か
既存システムとつなぐ	予約システム、顧客管理、基幹システムなど。相手側にも仕様があるため、突き合わせる必要がある
複数の会社が関わる	デザインと実装が別会社、システム部分だけ別会社など。間に書類がないと、認識が揃わない
保守を別の会社が引き継ぐ	作った人がいなくなったあとに読む人がいる
手続き上、提出が必要	稟議・入札など。中身より、承認のために要る

逆に言うと、1社が一貫して作り、外部システムとつながないサイトでは、仕様書はほとんど出番がありません。 実装側の書類がなぜ薄くなるのかはコーディング仕様書に、書くことがほとんどない理由に書きました。

もし今、仕様書のテンプレートを探して埋めようとされているなら、まずこの4つに当てはまるかどうかを確認されるといいと思います。何を書いて何を書かないかは要件定義書の34項目を「書く／書かない」で仕分けしましたが参考になります。当てはまらなければ、その時間は別のことに使えます。

---

仕様書は「全部書く」ものではありません

もうひとつ、誤解されやすいところがあります。

仕様書というと、漏れなく網羅した分厚い書類を思い浮かべる方が多いのですが、実務上の目的は網羅ではありません。

目的は、認識がずれそうな場所を、先に潰しておくことです。

ずれない場所を丁寧に書いても、何も起きません。ずれそうな一点が書いていなければ、あとで揉めます。分量と効果は、比例しません。

では、どこがずれそうか

ここが、この記事でいちばんお伝えしたいところかもしれません。

どこがずれそうかは、書類を眺めていても分かりません。

私たちが見ているのは、打ち合わせでの2か所です。

1. 1. お客さまが最初に口に出した項目
2. 2. 説明が急に長くなった項目

この2つが、その会社にとって本当に重要な項目です。そして、重要な項目ほど、こだわりがあり、こだわりがある場所ほど、認識がずれると困ります。

面白いのは、これが書類の構成順と一致しないことです。1ページ目に大きく書かれた項目が最初に語られるとは限りません。逆に、表の一番下に小さく書かれた項目で、急に説明が5分続くことがあります。

そこだけ、はっきりさせておけばいい。 私たちが仕様として書き残すのは、たいていそういう箇所です。

---

「揺れる場所」は、減らせます

もうひとつ、仕様書の分量が減る理由があります。

仕様書は、作り方が案件ごとにバラバラだと分厚くなります。毎回違う作り方をするなら、毎回説明が要るからです。

私たちは、固定ページもブロックエディタで編集できる仕組みを自社で開発して使っています。作り方が揃っているので、案件ごとに説明することがほとんどありません。

そして、この仕組みには副産物があります。納品時の操作説明で、こう言われることがあります。

「え？　このへんも更新できるんですか？」

公開後に自分で直せる範囲は、作り方で決まります。お知らせだけは自分で更新できて、他のページは制作会社に頼む——そういう形になっていることは、よくあります。その前提でいらっしゃるので、驚かれます。

会社案内もサービス紹介も採用ページも、同じ仕組みの上に乗っています。書くことが減るのは、揺れる余地を先になくしてあるからです。

このあたりは、コーディング仕様書の話として別の記事に書いています。

---

仕様書を求められている方へ

「制作会社から仕様書の提出を求められた」という状況で、この記事に来られた方もいるかもしれません。

その場合、確認していただきたいことが1つあります。

それは、発注側が書くべきものですか。

仕様書は本来、作る側が中心になって書くものです。もし「どう作るか」を発注側に書いてくださいと言われているなら、そこは相談されていいところだと思います。

私たちは、その形ではお願いしていません。要件定義書も仕様書も、必要な場合はヒアリングのあとにこちらで下書きをお作りします。書類が要る場合でも、宿題としてはお渡ししません。

---

向くケース・向かないケース

仕様書を作ったほうがいいケース

• – 既存システムや外部サービスと連携する
• – デザイン・実装・システムが別の会社に分かれている
• – 公開後の保守を、別の会社が引き継ぐ予定がある
• – 稟議や入札で、提出が必要

作らなくていいケース

• – 1社が一貫して制作する
• – 外部システムとの連携がない
• – 会社案内・サービス紹介・採用など、一般的なページ構成

2つ目の「連携がない」だけは、ご自身で判断しにくいかもしれません。その場合は、「今使っている業務システムがあるか、ないか」だけ教えていただければ、こちらで確認します。

---

締め

仕様書は「どう作るか」を書いた資料です。要件定義書の次にくるもので、必要な場面は限られます。

そして必要な場合も、網羅することが目的ではありません。ずれそうな一点を先に潰しておくことが目的です。その一点は、書類ではなく、打ち合わせでの話し方から見つかります。

書式を探して手が止まっているなら、そこで止まっている必要はありません。

そのままの状態でご相談ください。

要件定義書は、書かなくて大丈夫です。