仕様書が「読みにくい」と言われる理由｜クライアントと齟齬を生まない書き方

こんにちは！
今日は「クライアントから『これ読みづらい』と言われない仕様書の書き方」について解説します。

仕様書が読みにくくなる現場あるある

僕も昔、仕様書を作った直後にクライアントから「これ、どう読むんですか？」と言われて、めっちゃ落ち込んだことがあります。
その時は「要件をちゃんと書いたのに、なぜ？」って思ってたんですけど、実際は「書き手と読み手の理解ギャップ」が原因やったんですよ。

現場でよく見るのは、こんなパターンです。

• エンジニアが読むことを想定して、専門用語を多用してしまう
• クライアントが読むことを忘れて、図解や説明がない
• 「重要な部分」と「補足」が区別されていない
• 同じ概念を複数の書き方で説明してしまう
• 実装の細かい話と要件の話が混在している

これらは「全部書いてある」のに「読みづらい」んです。
だから今回お伝えしたいのは、「情報の見せ方」と「受け手を意識した構成」の大切さなんですよ。

「誰が読むのか」を意識した構成設計

仕様書って、実は1種類ではなくて、読み手によって内容を変えるべきなんです。

僕のチームでは、仕様書をこんな風に分けて考えるようにしています。

• 要件書：クライアント向け。「何ができるようになるのか」を優先
• 設計書：エンジニア向け。「どう実装するのか」の詳細
• 確認シート：全員で使う。チェックリスト形式で齟齬がないか確認

ほんまに大事なのは「1つの仕様書を頑張って読みやすくする」より「読み手ごとに必要な情報を整理する」ことなんです。

特にクライアント向けの部分は、こんな工夫をするといいですよ。

• 目次を最初に必ず置く。見出しは階層を明確に
• 難しい専門用語は使わない（もし必須なら、最初に用語集を作る）
• 「画面イメージ」や「フロー図」を絶対に入れる
• 重要度を「必須」「推奨」「検討」で分ける

僕の失敗ですが、以前は全部が「必須」みたいな書き方をしてて、後からクライアントが「これは優先度低いと思ってました」って言われたことあります。
それからは優先度を明確にするようにしましたね。

ビジュアルと数値で曖昧さを消す工夫

「読みやすい」仕様書の共通点は、言葉だけじゃなくて「図」と「数字」をめっちゃ活用してるんです。

例えば、こんな説明だけでは曖昧やん。

• 「ユーザーが画面上部からスクロールしたときに、ヘッダーが固定される」

これを仕様書に書くなら。

• 画面キャプチャで「固定される時点」を矢印で示す
• position: fixedのtop値（例：0）を明記する
• スクロール位置が100px以上の時に発動、といった具体値を書く

あと、よくやる工夫としては、仕様書に「ビフォーアフター図」を入れることですね。
左側が現在の状態、右側が実装後の状態、みたいな。
これだけで「何が変わるのか」が一目瞭然になります。

数値も重要です。
「大きい」じゃなくて32px、「少し間隔を開ける」じゃなくてmargin-top: 16pxみたいに、必ず数値で示すといいですよ。

クライアント確認フローを最初に設計する

これは仕様書の書き方そのものじゃなくて、「仕様書をどう使うか」の話ですが、めっちゃ大事です。

クライアントに仕様書を共有する前に、こんなことを決めておくといいですよ。

• いつまでに確認してもらうのか
• 質問や修正は、どのフォーマットで返してもらうのか
• 確認が完了した証拠（メール、署名、etc）は何か
• 修正指示が出た時の対応プロセス

僕も以前は「とりあえず仕様書を送ります」ってスタイルやったんですが、後から「あ、この部分は別の仕様だった」って言われたりしてました。
今は最初に「この仕様書のどの部分をどう確認してほしいのか」を明確に伝えるようにしてるんです。

また、仕様書を送った時に「質問があればこの様式で返してください」って確認シートを一緒に渡すのもいいですよ。
そうするとクライアント側も「何を確認すればいいのか」が分かりやすくなります。

まとめ

仕様書が「読みにくい」って言われるのは、実は「書き方の問題」じゃなくて「相手のことを想像できてなかった」ってことがほとんどです。

大事なポイントをまとめると。

• 読み手ごとに情報を整理する（クライアント向け、エンジニア向け、確認用）
• 図やビジュアルを活用して、言葉の曖昧さを消す
• 優先度や重要度を明確に分ける
• 数値や具体値で、解釈の幅を狭める
• 仕様書の「使い方」もあらかじめ設計する

仕様書って、それ自体が「コミュニケーションツール」なんです。
だからこそ、相手が読みやすく、理解しやすいものを心がけるといいですよ。