テクニカルライティングとは——正確さと分かりやすさを対立させない

製品担当から、データ記録装置の社内メモが届く。「CSV形式で出力可能です。ただし、旧版では対応していません」。内容は事実かもしれない。だが顧客は、どの画面を開き、どの版なら使え、旧版なら誰に頼むのかを決められない。

テクニカルライティングとは、技術情報の事実や条件を変えず、読む人が必要な判断や作業を終えられる言葉と順番へ書き換える技術である。誰が何をするか、どの条件で成り立つかを迷わず確かめられるようにする。

正確さを優先して社内語を残すか、分かりやすさを優先して条件を省くか。この二択にする必要はない。元資料へ戻れる形で事実を保ち、初見の読者が行動する順へ説明を移せば、二つは同じ工程で高められる。

冒頭の装置、版、画面、動作は説明用の架空例であり、実在製品の操作やデータ保持を示さない。本稿では日本の専門団体と、Google、Microsoft、GOV.UKの公開資料を照合し、書く前の準備から読者テストまでをたどる。

テクニカルライティングは、技術情報を正しい行動へつなぐ書き方である

一般財団法人テクニカルコミュニケーター協会（JTCA）は、テクニカルライティングを、元情報を集めて整理し、目的と対象者に合わせて書き換える技術と説明する。[S1]

難しい語を短い語へ置き換えるだけではない。複数の段落をつなぎ、読者が使える一つの文書へまとめるところまで含む。

対象は取扱説明書だけではない。製品ヘルプ、操作手順、仕様の説明、API文書、エラーメッセージ、技術記事も候補になる。

共通するのは、読者が技術を理解して使うための文章である。専門職のテクニカルライターだけでなく、技術者、編集者、サポート担当者もこの技術を使える。

ただし、文章が短く、言葉が易しければよいわけではない。「旧版は非対応」を削れば読みやすく見えるが、使えない人が手順を始める。

反対に、社内の仕様書をそのまま載せても不十分である。顧客が必要な一文を見つけられなければ、作業は止まる。

JTCAが説明する、より広いテクニカルコミュニケーションは、正確さ、参照元をたどれる状態、理解される伝え方を同時に扱う。[S2]

正確さは情報の出所と条件で守り、分かりやすさは読者が使う順番で高める。

技術広報とは何かでは、技術を企業への信頼や対話につなぐ活動を扱った。テクニカルライティングは、その活動に使う一つの文章技術である。

関心を集める表現と、使用条件や手順の正しさは両立できる。ただし、前者で後者を置き換えてはいけない。

では、元の事実を動かさずに、読む順番だけをどう変えるのか。冒頭の社内メモを使って確かめる。

正確さは条件を残し、分かりやすさは読む順番を変えて守る

文章を直す前に、元資料から変えてはいけない事実を抜き出す。架空例では、操作を始める場所、対応する版、更新できる人、出力後の元データの扱いである。数値や用語だけでなく、成立条件、対象外、完了した状態も確認する。

元の一文は「出力可能」と結論だけを示す。読者が実際に動く順へ変えると、次のようになる。

• 1. 装置の版を確認する。CSV出力を使えるのは、架空の版3.2以降である。
• 2. 版3.2以降なら、設定画面の「データ」を開き、「CSV出力」を選ぶ。
• 3. ファイルが保存されたことを確認する。出力しても、装置内の元データは削除されない。
• 4. 版3.1以前なら操作を止め、更新権限を持つ管理者へ依頼する。

この書き換えでは、機能も対応版も変えていない。条件を最初へ移し、一文に一つの行動を置き、操作場所と完了状態を足した。読者が自分で更新してよいとは推測せず、元資料で確認した担当者へ戻している。

Microsoft Learnの公開ガイドは、読者の目的と作業を先に定める。日常語を使いながら、技術内容は薄めないよう案内する。[S5]

手順のガイドでは、操作を一つずつ分け、必要なら場所を先に示す。原則として動詞から始め、作業を終える操作まで書く。[S6]

短文化は手段の一つにすぎない。短くした結果、対象、条件、例外、危険、確認方法が消えるなら不正確である。

長文を残す場合も、主語、行動、条件の関係が一度で取れないなら、文や手順を分ける。削る対象は、重複や読者の作業に不要な脇道である。

ただし、何が脇道かは文章だけを見ても決められない。書き始める前に、読む人と扱う範囲を定める必要がある。

書く前に、誰が何を終えるかと扱わない範囲を決める

「顧客向け」「全社員向け」では、読者を決めたことにならない。同じ顧客でも、初めて候補を比べる人、導入を承認する人、毎日操作する人、異常から戻す人では、知っている語も必要な答えも違う。

Googleの技術文書講座は、読者が作業に必要とする知識から、すでに持つ知識を引いた差を文書で補うと説明する。[S3]

肩書だけでなく、対象技術にどれだけ近いか、以前に学んだ知識が今も使えるかまで見る。専門職だから社内略語を知っているとは限らない。

同じ講座は、文書が扱う範囲、扱わない範囲、対象読者、前提知識、読後にできることを先に示す。[S4]

「CSV出力の手順」を書くなら、版の確認からファイル保存までを扱う。装置の初期設定や、表計算ソフトでの集計まで同じページへ詰める必要はない。

書く前の制作票には、最低限、次を一文ずつ置く。

• 読者：誰が読むか。対象について何を知り、何を知らないか。
• 目的：読み終えた人が、どの判断や作業を終えられればよいか。
• 範囲：どこからどこまでを説明し、何を別の文書へ渡すか。
• 元資料：仕様、試験記録、画面、担当者のうち、どれを正本とするか。
• 条件：対応版、対象、権限、例外、危険、助けを求める境界は何か。
• 更新：製品、画面、制度、問い合わせのどの変化で見直すか。

材料は新製品の発表だけではない。技術広報のネタを探す方法で扱った開発記録、顧客質問、失敗からも選べる。

同じ説明で人が止まる箇所を探し、質問を一件に絞る。すると、読者と完了状態も具体化しやすい。

制作票だけで正しさが保証されるわけではない。専門家には当たり前すぎて書き忘れる条件があり、初見読者には読んでも進めない順番がある。二種類の失敗は、同じ人の自己校正だけでは見つけにくい。

一つの語を一つの意味にそろえ、条件を行動より先に置く

同じ操作を「保存」「書き出し」「エクスポート」と呼び分けると、読者は別の機能だと受け取るかもしれない。製品画面の表示が「CSV出力」なら、手順でもその語を使う。検索に必要な別名は最初に対応を示し、その後は呼び方をそろえる。

専門語をすべて日常語へ変える必要もない。画面名、部品名、規格名を別の語へ変えると、現物や参照資料と一致しなくなる。正しい語を残し、初出で「何をするものか」を普通の言葉で説明する。

条件は、読者が操作した後ではなく、動く前に置く。「CSV出力を選びます。版3.1以前では使えません」では遅い。「版3.2以降なら」と先に示せば、対象外の読者はそこで止まれる。

「旧版の場合は更新してください」では、誰が更新するかが分からない。利用者に権限がないなら、「操作を止め、管理者へ依頼する」と主語と行動を分ける。書き手が知っている担当範囲を、読者も知っているとみなさない。

• 誰が：利用者、管理者、保守担当者の誰が行うか。
• いつ：どの版、状態、条件なら始めてよいか。
• 何を：どの画面、部品、値に何をするか。
• 完了：何が見えたら終わり、どこで止まるか。

否定や警告も、禁止だけで終えない。止める条件、避ける理由、代わりに誰へ何を依頼するかを、公開できる範囲で示す。ただし、安全や法令に関わる表現は、読みやすさだけで判断せず、製品ごとの要求と専門担当者の確認を優先する。

語、主語、条件、完了をそろえても、書き手自身は欠けた前提に気づきにくい。公開前には、事実を知る人と、説明を初めて使う人が別の失敗を確かめる。

技術担当は事実を、初見読者は行動を確かめる

技術担当者は、値、用語、対応版、成立条件、対象外、危険、参照元が正しいかを確認する。原稿の事実を一つずつ元資料へ戻し、推測で補った箇所がないかを見る。

公開できない情報があるなら、黙って削らない。誰へ何を添えて確認するかを示す。

初見読者は、開始点を見つけられるか、同じ物を同じ語で呼んでいるか、行動の順番を追えるか、終わった状態が分かるかを見る。つまずきは知識不足ではなく、前提や説明が欠けた可能性も示す。

編集担当者は、どちらかの指摘を好みで採用しない。技術担当者の指摘なら元資料、初見読者の指摘なら止まった行動へ戻す。

小さな組織なら一人が担当してもよい。その場合は時間を空けて二つの確認を分け、別の人に作業だけ試してもらう。

技術広報を始めるときの役割分担でも、目的、読者、題材、確認者を先に決める必要がある。

テクニカルライティングでは、さらに元資料の版、確認者、変更理由を残す。担当者が替わっても、なぜその条件を書いたかをたどれるようにするためである。

校正を終えても、読者が実際に動けるとは限らない。最後は感想を聞くだけでなく、文章を使って一つの作業をしてもらう。

「分かりやすかったですか」と聞けば、肯定的な感想は得られるかもしれない。しかし、条件に合わない版で操作を始めたり、保存できていないのに終わったと思ったりすれば、文書の目的は達成していない。

GOV.UKのユーザビリティテストは、実際または想定する利用者が具体的な作業を試す様子を観察する。理解して完了できるか、言葉や配置に問題がないかを確かめる。[S7]

これは英国政府サービス向けの方法である。民間企業へ同じ人数や手順を義務づけるものではない。

架空例なら、「手元の装置でCSV出力を使えるか判断し、使える場合はファイルを保存する」と作業を渡す。テスト中は答えを教えず、開始点、版の確認、操作、完了、管理者へ戻る境界のどこで止まったかを記録する。

• 正しい開始点を見つけられたか。
• 条件に合う場合だけ操作を始めたか。
• 保存の完了を正しく確認できたか。
• 対象外なら止まり、誰へ頼むか分かったか。
• 同じ語を別の意味に受け取らなかったか。

失敗が見つかったら、原稿だけを直すとは限らない。仕様が曖昧なら技術担当へ戻し、画面名が製品内で揺れているなら製品側も確認する。

問い合わせ先が不明なら運用を決める。文書のつまずきが、製品や社内手順の問題を見つける場合もある。

PV、滞在時間、検索順位は、文書を見つけてもらえたかを知る手掛かりになる。それだけでは、正しい作業を終えたかは分からない。

技術広報のKPIで扱った媒体全体の成果と分け、まず一つの文書が一つの作業を助けたかを見る。

公開後は、同じ質問がサポートへ戻った箇所、サイト内検索で答えが出なかった語、途中で離れた手順、誤って完了した場面を集める。製品の版、画面、法令、担当窓口が変わったときは、元資料と公開文を一緒に更新する。

テクニカルライティングを始めるなら、まず社内で繰り返し説明している一つのメモを選ぶ。誰が何を終えたいかを決め、事実、条件、対象外、参照元を抜き出す。その後で、読者が動く順に一文ずつ置く。

技術担当者が事実を、初見読者が行動を確かめ、同じ原稿へ指摘を戻す。正確さのために難しくする必要も、分かりやすさのために条件を薄める必要もない。読者が正しいところで進み、正しいところで止まれる文章が、二つを両立させる。