テクニカルライティングの3C
さて、今やソフトウェア開発に携わっていれば逃れられなくなったといえるテクニカルライティング。どうせなら良いものを書きたいですよね。テクニカルライティングの良し悪しはなんで決まるんでしょうか？
科学論文もプログラム仕様書も同じテクニカルライティングという括りでいいのかという疑問はありますけど、しかし、共通して要求される性質があります。「Clear（明確）・Correct（正確）・Concise（簡潔）」の3Cです。
- Clear：明確に伝わること
- Correct：内容も文法も正確であること
- Concise：簡潔に書かれていること
テクニカルな文書を評価する特性は、3C以外にもあります。設計書なら網羅性とか、報告書なら5W1Hとか、論文なら投稿基準を満たしているかとか。雑誌記事やプレゼンテーションでは、感動（「そうだったのか！」という気付き体験）なんて評価軸さえあります。ですが、全てのテクニカルな文書を評価する基準としては、まずこの3Cが挙げられるでしょう。
3Cは昔から
Clear・Correct・Conciseの3C、あるいは、それにComplete（完全）・Convincing（説得力）を加えた5Cは、ずいぶん昔から言われていることです。最初に誰が言い出したのかは、もはやちょっと分かりません。例えば、70年ほど昔の本にも次のように出てきます。
"Technical and Business Report Preparation" (Robley Winfrey, 1948) p.150
The writer needs to practice the design of sentences for the correct, complete, concise, clear, and convincing expression of his thoughts.
（ライターは、自分の考えを正しく、完全、簡潔、明瞭、そして説得力を持たせて表現するために文章の設計を練習する必要があります。）
3Cの評価基準は読者
このテクニカルライティングの3Cは、誰が評価できるんでしょうか？ それは読者です。読む人のための「Clear・Correct・Concise」なんです。
ある文章に対する3Cの評価は、読者によって違ってきます。同じ1つのテクニカルな文章を読んで、ある読者は「よく分かった」と感心し、別の読者は「分かるけど、説明がくどすぎる」（＝簡潔じゃない）と嘆き、また別の読者は「さっぱり分からなかった」（＝明確じゃない）と文句をいうかもしれません。例えば、次の文はどうでしょう？
- 「高速ハーシュネス評価値が1.0向上した。」
私は自動車会社で足回りの開発をやっていたことがあります。その組織内では、上の1文は十分に明確・正確・簡潔なんです。でも、自動車にちょっと関心があるくらいの人にとっては意味不明でしょう。そのような読者に対しては、次のような文にします。
- 「高速道路を走行中に継ぎ目を越えるときのガタピシ感が改善された（既定の走行テストでテストドライバーによる5段階評価の点数が1.0向上した）」
前の文に比べると、簡潔ではなくなりました。正確性を補おうとカッコ書きを加えていますが、組織内の人間には自明である「既定の走行テスト」の内容が一般の読者には分かりませんから、正確性でも劣っています。でも、前の文よりは意味が分かるようになった、明確になったと思います。
もう1つ例をあげましょうか。C#でのプログラミングの話題です。
- 「awaitを含むコードブロックを排他ロックするには、スレッドアフィニティがないSemaphoreSlimクラスなどを使う。」
この文は、awaitキーワードを使い慣れているC#プログラマーでも、たぶん戸惑うでしょう。マルチスレッドに精通していない読者には「スレッドアフィニティ」が意味不明だからです。「スレッドアフィニティがない」という部分を、ここの文脈に合った簡単な説明に置き換えてみましょう。
- 「awaitを含むコードブロックを排他ロックするには、別スレッドからロックを解放しても問題のないSemaphoreSlimクラスなどを使う。」
この文なら、awaitキーワードを使い慣れているC#プログラマーにとってはClear・Correct・Conciseになったと思います。しかし、awaitキーワードに不慣れなプログラマーが読者なら、さらに次のような説明が必要になります。
- 「awaitした後のコードは、別スレッドで実行される可能性がある。awaitを含むコードブロックを排他ロックするには、別スレッドからロックを解放しても問題のないSemaphoreSlimクラスなどを使う。」
ずいぶんと長い文章になってしまいました。でもこの文なら、.NET Frameworkのマルチスレッドとawaitキーワードにそれほど詳しくないC#プログラマーにも明確でしょう。
このように、読者の知識やスキルによって3Cの評価基準が変わってくるんです。
読者を想定することがテクニカルライティングの第1歩
テクニカルな文書の良し悪しは、読者の知識やスキルによって変わります。いくら良いドキュメントが書けたと思っても、読者の想定を間違えていたらテクニカルライティングとしては失格です。情報を読者に伝えるという肝心なことが上手くできていないのですから。あるいは、読者を想定しなかったり、書いているうちに想定がブレてしまうと、説明不足になって明確性が欠けたり、無用な説明を冗長にしてしまって簡潔性が失われたりしてしまいます。
「これから書く文書の読者は、どんな知識やスキルを持った人たちだろうか？」という想定を固めるのが、テクニカルライティングで最初にやるべきことなんです。
読者にも想定読者を伝える
テクニカルな文書は、読者に対しても想定読者が分かるように作ります。設計書や報告書のように、あらかじめ読者が決まっている文書もあります。そうでない文書は、想定外の読者が手に取ってしまったら「これを読むのは苦労するよ！」（あるいは「退屈するよ！」）と知らせるために、文書の早い段階で想定読者が分かるようにします。
書籍だと、タイトルや表紙の雰囲気、それと前書きあたりを使って、想定読者を表現します。雑誌やWebマガジンでは、そのメディアが狙っている読者層があります。メディアの読者層よりも狭い範囲の読者を想定する場合には、記事の冒頭でそれが分かるように書きます。このサイト（CodeZine）の記事で1ページ目に「対象読者」を記載しているものには、そういう意味があるんです。
まとめ
- テクニカルライティングには3C「Clear（明確）・Correct（正確）・Concise（簡潔）」が求められる
- 3Cの評価基準は読者の知識やスキルによって変わる
- 書き始める前に読者を想定することが大切
想定する読者によって、どのように説明すれば明確になるか、また、簡潔にするためにどれだけ説明を削れるかが決まります。書いているうちにどこまで説明すればいいのか分からなくなったら、想定読者を再確認しましょう。
