「内容は間違っていないはずなのに、なぜか読み手に伝わらない」。仕様書や要件定義書を書く立場になった人の多くが、一度はこの壁にぶつかります。レビューで「ここはどういう意味ですか？」と質問が返ってきたり、開発側との認識がずれて手戻りが発生したり。原因が自分の「文章力」にある気がするものの、何をどう直せばいいのか分からず、文書を提出するたびに不安を感じている方も少なくないはずです。
仕様書が伝わらないのは、書いた人の能力が低いからではありません。多くの場合、「分かりやすく書く技術」を体系的に学ばないまま、我流で書いていることが原因です。業務知識やシステムの中身を理解していても、それを誤解なく文章に落とし込む技術は、また別のスキルだからです。
この「誤解されない文章を書く技術」こそが、テクニカルライティングです。テクニカルライティングは才能ではなく、原則とコツを知れば誰でも習得できる技術です。一文一義や読み手の定義、曖昧表現の排除といった具体的なルールを押さえれば、「これなら伝わる」という手応えを持って仕様書を提出できるようになります。
本記事では、テクニカルライティングとは何かをわかりやすく解説したうえで、認識のズレや手戻りを防ぐ仕様書の書き方を、基本原則・実務の手順・やりがちなNG例の改善・提出前のセルフチェックリストという順で具体的に紹介します。読み終えたとき、ご自身の書いた仕様文をその場で直せる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
テクニカルライティングとは？仕様書が「伝わらない」原因を解く技術
まずは、テクニカルライティングとは何かを整理しましょう。言葉の意味を押さえることで、「自分の仕様書が伝わらない」という悩みの正体が見えてきます。
テクニカルライティングの定義と目的
テクニカルライティングとは、技術的・専門的な内容を、読み手に正確・明瞭・簡潔に伝えるための文章技術です。仕様書・要件定義書・設計書・手順書・マニュアルなど、業務で使う実用的な文書を書くときに用いられます。
テクニカルライティングが目指すのは、おもに次の4つです。
- 正確さ: 書かれた内容が事実と一致し、解釈の余地がないこと
- 明瞭さ: 読み手が一度読んで意味を取り違えないこと
- 簡潔さ: 必要なことだけを、無駄なく短く伝えること
- 一貫性: 用語・表記・書式が文書全体で統一されていること
テクニカルコミュニケーター協会が編集する『日本語スタイルガイド』でも「一文一義で書く」ことが基礎技術の一つとして挙げられており、こうした原則はテクニカルライティングの土台となっています（参考: テクニカルコミュニケーター協会『日本語スタイルガイド（第3版）』）。
普通の文章との違いは「読み手の行動」にある
エッセイや小説のような文章は、読み手に何かを感じさせたり、楽しませたりすることが目的です。表現に幅があり、解釈が分かれてもかまいません。
一方、仕様書のような技術文書では、読み手は文章を「鑑賞」しません。読み手は文書をもとに、設計をしたり、コードを書いたり、テストをしたり、判断を下したりします。つまり、読み手は文章を読むのではなく、文章を使って何かを「探し」「実行する」のです。
この違いは決定的です。情緒的に良い文章でも、開発者が「どの条件のときに何をすればよいか」を一読で判断できなければ、技術文書としては失敗です。テクニカルライティングでは、上手い文章よりも「迷わせない文章」が評価されます。
仕様書が伝わらないと、何が起こるか
仕様書が伝わらないことの怖さは、ただ「読みにくい」で済まないところにあります。文章の曖昧さは、次のような連鎖を引き起こします。
- 仕様文の解釈が、書き手と読み手（開発者・テスター）でずれる
- 開発者が自分なりの解釈で実装を進める
- レビューやテストの段階で「想定と違う」が発覚する
- 手戻りが発生し、修正・再テストにコストと時間がかかる
- スケジュールが圧迫され、関係者の信頼関係にも影響する
つまり、仕様書の一文の曖昧さが、後工程で何倍ものコストになって返ってくるのです。「自分の文章力の問題かもしれない」と感じている不安は、裏を返せば「テクニカルライティングという技術を身につければ防げる問題」だということでもあります。次の章からは、その具体的な技術を見ていきます。
なお、仕様書に「何を書くか（記載項目）」を整理したい場合は、システム開発の仕様書とはもあわせてご覧ください。本記事では「どう書くか（伝わる表現）」に焦点を当てて解説します。
伝わる仕様書を書くテクニカルライティングの基本原則
ここからは、明日から仕様書に使えるテクニカルライティングの基本原則を紹介します。それぞれ「悪い例（Before）」と「良い例（After）」をセットで示すので、ご自身の文章を直すイメージを持ちながら読み進めてください。
原則1: 読み手を定義してから書く
文章を書く前に、「誰が、何を知るためにこの文書を読むのか」を決めます。読み手が変われば、書くべき内容も粒度も変わるからです。
仕様書の読み手は、たとえば次のように複数います。
- 開発者: どの機能を、どんな条件で、どう動かすかを知りたい
- テスター: 何が「正しい動作」で、何を確認すればよいかを知りたい
- 発注者・業務担当者: 業務要件が満たされているか、認識通りかを確認したい
読み手を意識しないまま書くと、開発者には説明不足、業務担当者には専門的すぎる、という「誰にも刺さらない文書」になりがちです。書き始める前に「この文書のおもな読み手は開発者」と決めるだけでも、文章の方向性が定まります。
原則2: 一文一義で書く（1つの文に1つの情報）
一文一義とは、1つの文には1つの情報だけを入れる、という原則です。テクニカルライティングのもっとも基本的なルールの一つで、これを守るだけで仕様書の伝わりやすさは大きく変わります。
Before（悪い例） ユーザーがログインボタンを押すとIDとパスワードを検証し、正しければトップ画面に遷移し、間違っていればエラーを表示するが、3回失敗した場合はアカウントをロックする。
一文に「検証」「遷移」「エラー表示」「ロック」という4つの動作が詰め込まれており、条件の組み合わせも読み取りづらくなっています。
After（良い例）
- ユーザーがログインボタンを押すと、IDとパスワードを検証する。
- 検証に成功した場合、トップ画面に遷移する。
- 検証に失敗した場合、エラーメッセージを表示する。
- 検証の失敗が連続3回に達した場合、アカウントをロックする。
1文1動作に分け、条件ごとに行を分けました。開発者はそのまま処理の分岐として読み取れ、テスターは各行をそのままテスト項目にできます。
原則3: 結論・要点を先に書く
技術文書では、結論や要点を先に書き、その後に理由や補足を続けます。読み手は冒頭で全体像をつかんでから詳細を読めるため、理解が早くなります。
Before（悪い例） 現行システムでは夜間バッチの処理時間が年々増加しており、ピーク時には翌朝の業務開始に間に合わないことがあるため、処理方式の見直しが必要であり、本機能では並列処理を導入する。
After（良い例） 本機能では、夜間バッチに並列処理を導入する。 理由は、現行の処理時間が業務開始に間に合わないケースがあるためである。
結論（並列処理を導入する）を先に置き、理由を後に回しました。結論を先に書く「PREP（結論→理由→具体例→結論）」や、重要な情報から書く「逆三角形」の構成は、仕様書だけでなく報告書や提案書でも有効です。
原則4: 曖昧表現を具体化する
「など」「適宜」「速やかに」「高速に」といった曖昧な言葉は、読み手によって解釈が分かれ、認識ズレの最大の原因になります。数値や条件に置き換えて具体化しましょう。
曖昧な表現（Before） | 具体化した表現（After） |
|---|---|
速やかにエラーを通知する | エラー発生から3秒以内に通知する |
適宜ログを出力する | 処理開始時・終了時・例外発生時にログを出力する |
大量のデータでも高速に動作する | 100万件のデータを5秒以内に表示する |
必要に応じて項目を追加できる | 管理者権限を持つユーザーが項目を追加できる |
「速やか」「適宜」が悪いのではなく、技術文書では「測れる基準」に落とし込むことが大切だということです。書いた本人は意味が分かっていても、読み手には伝わらないという前提で見直すのがコツです。
原則5: 情報を階層化する（概要から詳細へ）
仕様書は、いきなり細部に入るのではなく、「概要 → 機能 → 詳細」の順に情報を階層化します。読み手はまず全体像を把握し、必要な階層まで掘り下げて読めます。
たとえば、ある機能を説明するなら次の順序です。
- 概要: この機能が何のためにあるか（例: ユーザーが注文をキャンセルできる機能）
- 機能の振る舞い: どんな操作で何が起こるか（例: 注文一覧からキャンセルを選択すると確認画面を表示する）
- 詳細・制約: 例外や条件（例: 発送済みの注文はキャンセルできない）
見出しや箇条書きで階層を視覚的に示すと、読み手は目的の情報まで最短でたどり着けます。
仕様書の書き方—テクニカルライティングを実務に落とす手順
原則を理解したら、次は実際の仕様書づくりに落とし込みます。ここでは「何を書くか」と「どう書くか」をつなげた実務の手順を紹介します。
手順の全体像と書くべき項目の整理
仕様書を書くときは、おおむね次の流れで進めると迷いにくくなります。
- 読み手と目的を確定する: 誰が読み、何を判断するための文書かを決める（原則1）
- 記載項目を洗い出す: 機能要件・非機能要件・業務フロー・入出力・制約などを列挙する
- 構成（骨組み）を作る: 項目を概要から詳細へ階層化して並べる（原則5）
- 原則を当てはめて記述する: 一文一義・結論先行・曖昧表現の排除で各項目を書く
- レビュー観点で見直す: 読み手の立場で「迷う箇所」がないか確認する
このうち手順2で洗い出す項目は、システム開発の仕様書では次のようなものが基本になります。
- 機能要件: システムが何をするか（画面・帳票・処理の内容）
- 非機能要件: 性能・セキュリティ・可用性など「どのくらい」の品質か
- 業務フロー: 誰が、いつ、どの順序で操作・処理するか
- 入出力: 入力データ・出力データの項目と形式
- 制約・前提条件: 動作環境・対象外範囲・例外ケース
図・表・箇条書きを使い分ける
すべてを文章で書こうとすると、かえって伝わりにくくなることがあります。情報の性質に合わせて、図・表・箇条書きを使い分けましょう。
- 業務フローや処理の流れ: フローチャートや図で示すと、順序と分岐が一目で分かる
- 項目と値の対応: 表にすると、入出力項目やパラメータの一覧が比較しやすい
- 条件や手順の列挙: 箇条書きにすると、一文一義が自然に保たれる
たとえば「Aの場合はX、Bの場合はY、Cの場合はZ」という条件分岐は、文章で続けるより表にしたほうが、開発者もテスターも漏れなく確認できます。文章・図・表のどれが一番速く正確に伝わるかを、項目ごとに考える習慣をつけましょう。
用語を統一し、定義する
同じものを指すのに「ユーザー」「利用者」「会員」と表記がばらつくと、読み手は「これは同じものか、別のものか」と迷います。表記揺れは認識ズレの隠れた原因です。
- 文書の冒頭または用語集で、主要な用語の定義を明記する
- 一度決めた表記は、文書全体で統一する（例:「ログイン」で統一し「サインイン」は使わない）
- 略語は初出時に正式名称を併記する（例: 単一障害点（SPOF: Single Point Of Failure））
用語の統一は地味ですが、文書全体の信頼性を底上げします。表記揺れのチェックには、後述するセルフチェックリストを活用すると漏れにくくなります。
やりがちなNG例とテクニカルライティングによる改善
ここでは、仕様書で頻繁に見られる「伝わらない書き方」を類型化し、Before/After で改善方法を示します。過去にレビューで指摘された経験のある方は、心当たりがあるかもしれません。それぞれ「どんな手戻りを招くか」もあわせて確認しましょう。
NG例1: 主語・主体が抜けている
「誰が（何が）その処理を行うのか」が書かれていないと、読み手は主体を推測するしかなく、実装が分かれます。日本語は主語を省略しても文が成立してしまうため、特に起こりやすいNGです。
Before（悪い例） 注文が確定したら、在庫を引き当て、確認メールを送信する。
「在庫を引き当てる」のも「メールを送信する」のもシステムなのか、別のバッチなのか、運用担当者の手作業なのかが分かりません。
After（良い例） 注文が確定すると、システムが自動的に在庫を引き当てる。 在庫の引き当て完了後、システムが注文者へ確認メールを送信する。
招く手戻り: 主体の解釈違いにより、本来自動化すべき処理が手作業として実装される、あるいは逆のケースが起こり、設計のやり直しにつながります。
NG例2: 一文に複数の要件を詰め込む
原則2（一文一義）の逆で、1つの文に複数の要件や条件を詰め込むと、条件の組み合わせや優先順位が読み取れなくなります。
Before（悪い例） 管理者は全ユーザーの情報を閲覧・編集でき、一般ユーザーは自分の情報のみ閲覧でき編集はできないが、退会済みユーザーは誰も閲覧できない。
権限の組み合わせが3者分入り組んでいて、確認に時間がかかります。
After（良い例）
ユーザー種別
閲覧
編集
管理者
全ユーザーの情報
全ユーザーの情報
一般ユーザー
自分の情報のみ
不可
退会済みユーザーの情報
誰も閲覧不可
—
SCROLL→
権限のような「組み合わせ情報」は、文章よりも表で整理したほうが正確に伝わります。
招く手戻り: 条件の見落としによる権限設定のミスや、テスト項目の漏れが発生します。
NG例3: 前提・条件・例外が書かれていない
正常系（うまくいく場合）だけを書いて、例外や前提条件を書き忘れると、開発者は例外時の挙動を独自に判断してしまいます。
Before（悪い例） ユーザーはファイルをアップロードできる。
After（良い例）
- ユーザーはファイルをアップロードできる。
- アップロード可能な形式は、PDF・JPEG・PNGとする。
- 1ファイルあたりの上限サイズは10MBとする。
- 上限を超えた場合、「ファイルサイズが大きすぎます」というエラーを表示する。
- 対応形式以外のファイルが選択された場合、アップロードを受け付けない。
正常系の一文に、形式・サイズ・例外時の挙動という前提と条件を加えました。
招く手戻り: 例外処理が実装されず、想定外のファイルでエラーが発生したり、リリース後に不具合として報告されたりします。仕様書の段階で例外を書ききっておくことが、後工程の手戻りをもっとも効果的に防ぎます。
提出前に使うテクニカルライティング・セルフチェックリスト
ここまで紹介した原則とNG回避を、仕様書を提出する前の確認リストとしてまとめました。書き終えた文書を、このリストで一度セルフチェックする習慣をつけると、「これなら誤解されない」という手応えを持って提出できるようになります。
提出前セルフチェックリスト
- 読み手は明確か: この文書の主な読み手（開発者・テスター・発注者など）を意識して書いたか
- 一文一義になっているか: 1つの文に複数の情報・動作を詰め込んでいないか
- 結論・要点が先にあるか: 各項目で、結論より先に長い前置きを書いていないか
- 曖昧表現はないか: 「適宜」「速やかに」「高速に」「など」を数値・条件に置き換えたか
- 主語・主体はあるか: 「誰が（何が）その処理を行うのか」が書かれているか
- 前提・条件・例外を書いたか: 正常系だけでなく、例外時の挙動や制約を明記したか
- 用語は統一されているか: 同じものを別の言葉で書いていないか（表記揺れ）
- 図・表・箇条書きを使い分けたか: 条件の組み合わせを文章で書いていないか
- 情報は階層化されているか: 概要から詳細への順序になっているか
- 読み手が一読で実行できるか: 開発者・テスターがそのまま作業に移れるか
すべてにチェックがつけば、認識ズレや手戻りのリスクは大きく下がります。最初はすべてを意識するのが大変でも、繰り返すうちに自然と身についていきます。
テクニカルライティング力を継続的に高める方法
テクニカルライティングは、一度学んで終わりではなく、書きながら磨いていく技術です。次のような取り組みが力を高めます。
- 社内レビューを活用する: 自分では気づけない「伝わらなさ」を、第三者の指摘から学ぶ
- 指摘の傾向を記録する: レビューで指摘されたパターンを蓄積し、自分専用のチェック観点にする
- スタイルガイドを参照する: 表記ルールを統一したいときは、JTF日本語標準スタイルガイドやテクニカルコミュニケーター協会の『日本語スタイルガイド』が参考になる
- 良い仕様書を読む: 「迷わず読めた」と感じた文書の構成や言い回しを真似る
文章は、書いた人の理解の深さがそのまま表れます。テクニカルライティングを意識して書くことは、仕様そのものへの理解を深める訓練にもなります。
よくある質問（FAQ）
テクニカルライティングとプログラミングの違いは何ですか？
プログラミングが「コンピューターに正しく指示する技術」なのに対して、テクニカルライティングは「人に正確に伝える技術」です。仕様書は人間（開発者・テスター・発注者）が読むため、コードと同じくらい正確でありながら、人が一読で理解できる明瞭さが求められます。両者は別のスキルですが、良い仕様書は良い実装の前提になるという点でつながっています。
仕様書はWord・Excelのどのツールで書くべきですか？
ツールに唯一の正解はありません。文章中心の要件定義書はWord、項目と値を一覧化する設計書はExcel、というように、書く内容に合わせて選ぶのが現実的です。近年はMarkdownや専用のドキュメント管理ツールで書くチームも増えています。重要なのはツールよりも中身です。本記事で紹介した原則は、どのツールで書く場合でも同じように有効です。
非エンジニアでも仕様書を書けますか？
書けます。むしろ、業務を一番よく知っている企画担当者や業務担当者が業務要件を書くケースは多くあります。技術的な実装の詳細は開発者に委ねるとしても、「何を実現したいか」「どんな業務フローか」を一文一義で曖昧さなく書くことは、専門知識がなくても実践できます。本記事の原則とチェックリストは、非エンジニアの方にもそのまま使えます。
要件定義書と仕様書で、テクニカルライティングの注意点は違いますか？
基本となる原則（一文一義・読み手定義・曖昧表現の排除）は共通です。ただし、要件定義書は発注者と認識を合わせる文書なので業務の言葉を意識し、設計書・仕様書は開発者が実装する文書なので技術的な精度を意識する、という重心の違いはあります。読み手が誰かを最初に定義する（原則1）ことで、この違いに自然と対応できます。
AIに仕様書を書かせてもよいですか？
下書きや構成案の作成、文章の推敲にAIを使うことは有効です。曖昧な表現の指摘や、表記揺れのチェックは特に得意な領域です。ただし、AIは業務の文脈や暗黙の前提までは知らないため、生成された文章をそのまま提出するのは危険です。本記事のセルフチェックリストで人が最終確認し、前提・例外・主体が正しく書かれているかを検証することが欠かせません。AIは「書く負担を減らす道具」として活用し、伝わるかどうかの判断は人が担うのが現時点での現実的な使い方です。
テクニカルライティングは、特別な才能ではなく、原則を知れば誰でも身につけられる技術です。読み手を定義し、一文一義で書き、曖昧な表現を具体的な条件に置き換える。この積み重ねが、認識のズレや手戻りを防ぎ、「これなら伝わる」という自信につながります。まずは次に書く仕様書で、提出前セルフチェックリストを一度通してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
