コーディング仕様書に、書くことがほとんどない理由
要件定義と発注の実務｜書類そのものの話 2本目 全6本
目 次
コーディング仕様書とは、Webページをどう実装するかを決めた資料です。
私たちの案件では、ここに書くことがほとんどありません。丁寧に確認しているからではなく、揺れる余地を先になくしてあるからです。
そして、そのことは公開後にもっと大きく効いてきます。
コーディング仕様書とは
デザインができたあと、それを実際のWebページとして組み立てる工程がコーディングです。上位にあたるWeb制作の仕様書については別の記事に書いています。その進め方を決めておく資料が、コーディング仕様書です。
一般的には、こういったことが書かれます。
- 使用する技術やフレームワーク
- ファイルの構成、命名のルール
- 見出し・本文・ボタンなどの書き方の統一ルール
- 対応するブラウザ、画面幅ごとの表示
- 画像の書き出しルール
読むのは、基本的に作る人です。発注する側が書くものではありません。
何のために書くのか
目的はひとつで、認識のズレを防ぐことです。
複数人で作るとき、あるいは作った人と直す人が違うとき、ルールが決まっていないとバラバラになります。同じ見出しなのにページによって余白が違う、似たボタンが5種類ある、といった状態です。
見た目の問題だけではありません。あとから直すときに、どこを触ればいいのか分からなくなります。
だから、先にルールを決めて書き残しておく。理にかなった話だと思います。
コーディング仕様書に、書くことがない理由
私たちも、この問題が起きないようにしています。ただし、書類で防いでいません。
理由は単純で、コーディング仕様書が厚くなるのは、作り方が案件ごとに違うからです。毎回違う作り方をするなら、毎回説明が要ります。
私たちは、固定ページもブロックエディタ（Gutenberg）で編集できるように、独自のCSSの仕組みを自社で開発して使っています。 案件ごとに実装の方法を考え直していないので、説明することがほとんどありません。
ルールを書き残して守るのではなく、そもそも外れられない形にしてある、という言い方が近いと思います。
制作の一部にはAIも使っていますが、認識のズレが起きにくいのは、この仕組みによるところが大きいです。AIで浮いた時間は、文章や構成といった中身のほうに回しています（AIで浮いた時間を、中身に使う）。
本当に効いてくるのは、公開後です
正直に言うと、コーディング仕様書が薄いこと自体は、発注される方にとってどうでもいい話だと思います。
大事なのは、その副産物のほうです。
納品時に操作の説明をしていると、こう言われることがあります。
「え？ このへんも更新できるんですか？」
「このへん」というのは、会社案内やサービス紹介、採用ページのことです。お知らせの投稿画面ではなく、いわゆる固定ページを指して、そうおっしゃいます。
驚かれるということは、それまでのサイトでは触れなかったということです。
「お知らせだけ自分で更新できるサイト」の話
更新できる範囲は、作り方で決まります。
| 誰が更新するか | |
|---|---|
| お知らせ・ブログ | 自社で更新できる |
| 会社案内・サービス・採用など | 制作会社に依頼 |
下の行が、あとから効いてきます。
初回のご相談で、前のサイトについて伺うと、いちばんよく聞くのがこれです。
「更新のたびに費用がかかる」
責める話ではありません。作りがそうなっていれば、依頼するしかありませんし、依頼を受けた側も作業をしているので、費用が発生するのは当然です。
問題は、そのうちに更新しなくなることです。
「文章を少し直したい」「新しいサービスを1つ足したい」——そのたびに見積もりが要るなら、だんだん後回しになります。そして数年経つと、情報が古いままのサイトが残ります。
公開後に、サイトが止まらないこと
私たちの作り方では、会社案内もサービス紹介も採用ページも、お知らせと同じように編集できます。同じ仕組みの上に乗っているからです。
すると、こういうことが起きます。
採用サイトの要件定義にも書いていますが、採用サイトを公開したお客さまから、しばらくして言われたことがあります。
「社員インタビューをどんどん増やしたい」
効いたから、もっと欲しくなった、という話です。
ここで大事なのは、この要望が公開後に出てきたことです。要件定義の段階で「社員インタビューを何本載せるか」を決めるのは、無理があります。作って、反応を見て、初めて「もっと欲しい」になります。
そして、増やせる作りだったから、増やせました。
同じ時期に、別のお客さまからはこういう連絡をいただいています。
「問い合わせが増えました。顧客からも好評です」
公開したあとに手が入るサイトと、入らないサイト。差が出るのは、たいてい公開してからです。
コーディング仕様書が、それでも必要になる場面
私たちの案件で書くことが少ないというだけで、不要な書類だとは思っていません。
次のような場合は、必要です。
| 場面 | なぜ |
|---|---|
| デザインと実装が別の会社 | 間に書類がないと、認識が揃いません |
| 保守を別の会社が引き継ぐ | 作った人がいなくなったあとに読む人がいます |
| 既存システムと連携する | 相手側の仕様と突き合わせる必要があります |
| 社内に開発チームがある | あとから自社で手を入れる前提なら、必須です |
いずれも、関わる人が増える場合です。1社が一貫して作るなら、書類の出番は減ります。
発注する側がコーディング仕様書を書く必要は、ありません
もし「コーディング仕様書を提出してください」と言われて、この記事に来られたのでしたら、確認していただきたいことがあります。
それは、発注側が書くべきものですか。
コーディング仕様書は、実装する側が書くものです。発注する側が用意するのは、通常ありません。書類そのものがなくても進む理由は要件定義書がなくても、Web制作は進みますに書いています。
私たちの場合は、必要な案件であればこちらで作成してお渡しします。 書類が要る場合も、宿題としてはお渡ししません。
公開後にご自身で触れる作りにしておくと、月々にかかる費用にも効いてきます。内訳はホームページの維持費にまとめました。
向くケース・向かないケース
この作り方が合うケース
- 公開後、自分たちで文章や写真を直したい
- 前のサイトで、更新のたびに依頼が必要だった
- 情報が古いまま放置されているページがある
- 少しずつ育てていきたい
合わないケース
- ページごとにまったく違う構造・表現を作りたい
- すでに社内に開発チームがあり、自社のルールに合わせて実装してほしい
1つ目について補足すると、揃った仕組みの上に乗せる作り方なので、1ページごとに設計を変える方向とは相性がよくありません。 表現の自由度を最優先されるなら、別の作り方のほうが合うと思います。
コーディング仕様書に書くことがほとんどないのは、丁寧に確認しているからではありません。揺れる余地を先になくしてあるからです。
そして、そのことがいちばん効いてくるのは、公開してからです。会社案内も、サービス紹介も、採用ページも、ご自身で直せます。
「え？ このへんも更新できるんですか？」——毎回この質問が出るということは、そうでないサイトが多いということだと思っています。
書類のことは、こちらで引き受けます。
そのままの状態でご相談ください。
要件定義書は、書かなくて大丈夫です。
