当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
仕様書を任されたものの、『文章が苦手だから向いていないかも』と感じている方は多いはずです。先輩の仕様書はすっきり読めるのに、自分が書くとなぜか伝わらないんですよね。
結論から言うと、仕様書のスキルは「聞く」「整理する」「言い切る」「確かめる」の4つの力に分けると、伸ばし方が見えてきます。生まれつきの文才ではなく、毎日の仕事の中で練習できる力なんです。
この記事を読めば、4つの力それぞれの意味と、明日から試せる練習方法が分かります。
仕様書を書くスキルとは？
仕様書を書くスキルは、きれいな文章を書く力というより、「相手の考えを正しく受け取り、誰が読んでも同じ意味になる形で残す力」です。そのために聞く・整理する・言い切る・確かめるの4つの力が要ります。
仕様書は、作る人と頼む人の間で「何を作るか」をそろえるための文書です。読む人によって意味が変わってしまう文章は、仕様書としては困るんです。
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という一文があります。迷った時に立ち返る文書だからこそ、書く人のスキルが大事になります。
仕様書そのものの意味や役割は仕様書とは？意味と目的、設計書・要件定義書との違いで紹介しています。
文章力より先に要る力がある
『文章力を鍛えなきゃ』と考える方は多いですよね。ただ、仕様書で困るのは、言い回しより「何を書くかが決まっていない」ことの方が多いんです。
| つまずく所 | 足りない力 |
|---|---|
| 何を書けばいいか分からない | 聞く力 |
| 書いたけれどまとまりがない | 整理する力 |
| 読む人によって意味が変わる | 言い切る力 |
| 後で抜けや食い違いが見つかる | 確かめる力 |
4つの力と日々の練習方法
4つの力は、どれも日々の仕事の中で練習できます。特別な勉強時間を取るより、打合せのメモやメールの書き方を少し変える方が身に付きやすいです。
ここが大事なところです。編集部で、4つの力と練習方法を表にしてみました。
| 力 | 何ができる力か | 日々の練習方法 |
|---|---|---|
| 聞く | 相手の困りごとや本当の目的をつかむ | 打合せで「なぜそうしたいか」を1回は聞き返す |
| 整理する | 聞いたことを項目に分け、順番に並べる | 打合せのメモを、終わった後に見出しを付けて書き直す |
| 言い切る | 誰が読んでも同じ意味になる文で書く | メールの「なるべく」「適宜」を具体的な言葉に置き換える |
| 確かめる | 抜けや食い違いを見つけて直す | 書いた文書を、読む人の立場で読み返す |
聞く力
仕様書の材料は、相手の話の中にあります。「どんな機能がほしいか」だけ聞くと、相手が思いついたことしか集まりません。
例えば、こんなふうに聞き返してみてください。
「それができると、どんな作業が楽になりますか？」
「今は、その作業をどうやっていますか？」
目的まで聞けると、相手が言葉にしていなかった要件にも気づけますよ。
整理する力
聞いた話は、思いついた順に出てきます。それを「目的」「やること」「条件」「決まっていないこと」のように項目に分けて並べるのが、整理する力です。
打合せのメモを、終わった後に見出しを付けて書き直してみてください。それだけで、何が決まって何が決まっていないかがはっきりします。
言い切る力
仕様書では、読む人によって意味が変わる言葉を避けます。
JIS Z 8301:2019（規格票の様式及び作成方法）の考え方を、日本規格協会が資料で紹介しています。要求事項は客観的に検証できるものだけを書き、「十分に強い」のような表現を用いない、という考え方です。規格の書き方ですが、仕様書にもそのまま使える考え方です。
| 言い切れていない書き方 | 言い切った書き方の例 |
|---|---|
| なるべく早く表示する | 一覧は何秒以内に表示する（数値は関係者で決める） |
| 適宜バックアップを取る | 毎日決まった時刻にバックアップを取る |
| 必要に応じて通知する | 承認待ちが出たら承認者にメールで知らせる |
| 十分な強度をもたせる | どの基準のどの値を満たすかを書く |
同じ資料では、「しなければならない」「してはならない」「することが望ましい」「してもよい」のように、要求の強さで言い方を分けることも紹介されています。どの文が「守ること」で、どの文が「できればやること」なのかが一目で分かるようになります。
一方で、「すべきである」「すべきでない」は使わないとしています。仕様書でも、文末の言い方を職場でそろえておくと、読む人が迷いにくくなりますよ。
確かめる力
書き終えたら、自分ではなく読む人の立場で読み返します。作る人なら「これで作れるか」、テストする人なら「これで確かめられるか」と考えてみるんです。
- 同じものを違う名前で呼んでいないか
- 数字や条件が書かれずに残っていないか
- 決まっていないことに「未定」と書いてあるか
- 前の版から変わった所が分かるか
書いた直後は、自分の頭の中の情報で行間を埋めて読んでしまいがちです。少し時間をおいてから読み返すと、抜けに気づきやすくなります。
立場ごとに伸ばしたい力
『全部を一度に伸ばすのは大変そう』と感じますよね。立場によって、先に伸ばしたい力は少し違います。
| 立場 | 先に伸ばしたい力 | 理由 |
|---|---|---|
| 初めて仕様書を書く会社員 | 整理する | 項目に分けるだけで読みやすさが大きく変わる |
| 開発のSE | 言い切る・確かめる | 作る人やテストする人が迷わない文書が求められる |
| 社内SE・発注担当 | 聞く・整理する | 社内の声を集めて要件にまとめる場面が多い |
| 施工管理・設計の担当 | 確かめる | 図面と仕様書の食い違いを見つける力がそのまま活きる |
書く前と書いた後のセルフチェック
仕様書は、書く前に「誰が読むか」「何を決めるか」をそろえ、書いた後に「読む人の立場で読み返す」と、ぐっと伝わりやすくなります。毎回同じチェックを通すのが、スキルを伸ばす近道です。
『毎回、何を確かめればいいか分からない』という方のために、書く前と書いた後のチェックを分けてみました。
- 読む人を決める（作る人、テストする人、頼む人のだれに向けるか）
- 目的と範囲を1文で書く
- 聞いたことを項目に分けて並べる
- あいまいな言葉を具体的な言葉に置き換える
- 読む人の立場で読み返し、直した所を版として残す
よくある失敗
全部を一人で抱えて、完成してから初めて人に見せてしまうことがあります。目次と各項目の見出しができた所で一度見てもらうと、大きな書き直しを防げます。
途中で見せるのは、恥ずかしいことではありません。早めに食い違いが見つかるほど、直す手間は小さく済みますよ。
書き方のコツは仕様書の書き方｜誰が読んでも同じに伝わる7つのコツでくわしく紹介しています。
仕様書のスキルでよくある相談
知恵袋でよく読まれているのは「要件定義書ってどう書くの？」「設計書通りに作ったのに怒られた」「設計書の書き方をどう勉強すればいい？」といった相談です。どれも4つの力のどこが足りないかで考えると答えが見えてきます。
ここからは、知恵袋でよく読まれている相談を要約して答えてみますね。
相談1：要件定義書ってどんなふうに書くの？
『プログラムを書く上で要件定義が大事だと聞いた。要件定義書ってどう書くの？』という相談です。
最初の一歩は、聞く力と整理する力です。
何のためのシステムかを聞き、「業務」「機能」「機能以外の条件」「決まっていないこと」に分けて書き出してみてください。中身の考え方は要件定義書とは？目的・書く内容・作る流れで紹介しています。
相談2：設計書通りに作ったのに怒られた
『設計書のとおりに作ったのに、思っていたのと違うと怒られた』という相談です。
これは、書いた側の言い切る力と、読んだ側の確かめる力の両方が関わる話です。設計書の書き方があいまいだった可能性もありますし、読む側が「これはどういう意味？」と聞き返す機会がなかったのかもしれません。
読む側に回った時は、気になった所を一覧にして質問するのがおすすめです。質問の一覧は、そのまま次の版を直す材料にもなります。
相談3：設計書の書き方を勉強したい
『システム設計書の書き方を勉強したい。おすすめの勉強方法は？』という相談です。
公的な手引きを読むのが近道です。
IPAの「ユーザのための要件定義ガイド 第2版」は、要件定義を成功に導く128の勘どころをまとめています。デジタル庁のDS-100には、要件定義書に書く項目が並んでいます。
あわせて、職場の良い仕様書を一つ選び、どんな順番で何を書いているかを書き写してみるのも効果があります。
相談4：要件定義書からテスト仕様書を作れと言われた
『要件定義書から、テスト仕様書とテストデータを作れと言われた。そんなやり方、普通あるの？』という相談です。
要件定義書をもとに「何を確かめれば要件を満たしたと言えるか」を考えるのは、確かめる力そのものの練習になります。書かれていない条件に気づいたら、それを質問として残しておきましょう。
その質問の一覧が、次に要件定義書を直す時の材料になります。読む側に回った経験は、自分が書く側になった時にも活きてきますよ。
スキルを仕事につなげる
仕様書を書く4つの力は、要件定義や設計を任される上流工程の仕事で特に求められます。今の職場で小さな文書から練習を重ねることが、次のキャリアにもつながります。
『この力は、仕事の評価につながるの？』と思う方もいますよね。
要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。上流工程の全体像は上流工程とは？要件定義・設計ができるエンジニアになる道筋で、仕事の中身は仕様書を書く仕事とは？SE・PM・社内SEの仕事内容と違いで紹介しています。
- 要件定義、基本設計、詳細設計など、担当する工程の名前
- 顧客折衝、社内調整など、聞く力を使う場面
- 設計書やテスト仕様書の作成など、書く文書の種類
- レビューや品質管理など、確かめる力を使う場面
職務経歴書では、「仕様書を書いた」だけでなく、どの力をどう使ったかまで書くと伝わりやすくなります。例えば「利用部門への聞き取りをもとに画面一覧を作り、あいまいな要件を数値に置き換えて合意した」のように書いてみてください。
今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると、どんな力を求められているかが見えてきます。今の職場で小さな仕様書から任せてもらう道も、もちろんありです。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
仕様書を書くスキルは、文章が苦手でも身に付きますか？
身に付きます。仕様書で大事なのは、きれいな文章より、聞いたことを項目に分けて、誰が読んでも同じ意味になる形で書くことです。打合せのメモの書き直しなど、毎日の仕事の中で練習できます。
仕様書のスキルを伸ばすのに、おすすめの手引きはありますか？
IPAの「ユーザのための要件定義ガイド 第2版」や、デジタル庁のDS-100が参考になります。言葉の選び方は、JIS Z 8301の考え方を紹介した日本規格協会の資料も役に立ちます。
仕様書であいまいな言葉を避けるにはどうすればいいですか？
「なるべく」「適宜」「必要に応じて」などの言葉を見つけたら、いつ・何を・どのくらいかに置き換えてみてください。数値が決まっていない時は「数値は関係者で決める」と書いておくと、決め漏れを防げます。
仕様書のスキルは、どのくらいで身に付きますか？
人や職場によって違います。厚生労働省の job tag の「システムエンジニア（受託開発）」では、一般的には3年目頃に一人で詳細設計を書けるようになると紹介されています。焦らず、小さな文書から積み重ねていきましょう。
まとめ
- 仕様書のスキルは聞く・整理する・言い切る・確かめるの4つの力
- 4つの力は打合せのメモやメールなど毎日の仕事で練習できる
- 客観的に確かめられる言葉で書き、あいまいな表現を避ける
- 書く前に読む人を決め、書いた後は読む人の立場で読み返す
- 仕様書を書く力は上流工程の仕事で評価されやすい
コメント