技術文書を書くときに知っておいて欲しいこと
はじめに
筆者は、人の書いた技術的な報告書を確認、添削することが多いので、技術文書を書く上で重要なことをまとめてみました。私自身、決して文書を書くのは得意なほうではないのですが、恥は書くべきものとして公開します。
想定はメーカーに入社したての新入社員
新卒でメーカーに入社して、大学であまり文章を書く機会に恵まれなかった人で、報告書の作成に困っている方、文章を書くのが苦手でそのせいで生産性が落ちている方、そんな方の一助になればと思います。なお、テクニカルライティングには優れた書籍がいっぱいありますので、本当はこの記事よりも、本を読むことを推奨します。
文書はキャリアのための最強の武器
組織で偉くなるとは、一言でいえば、「影響力」が大きくなることです。影響力とは、人の行動を変えることで、偉い人はそれを付加価値に変えることができる人と、考えます。影響力を強くするには、あなたのメッセージが強力であるか(質)か、そのメッセージがより広く届くか(量)しかありません。メッセージを伝えるには、さまざまな手段がありますが、文書は長期間のこり、さらに、容易に複製可能なものです。スケールするコミュニケーション手段として、文書は最強の手段なのです。将来、あなたが強い影響力を持つことができれば、それはきっと、よりよいキャリアにつながるのだと、筆者は思います。
ルール1 文書の目的を明確にする
まずは文書の目的を明確にしましょう。
- 読者(target)は誰であるか
- 何を伝えたいのか
これらを明確したうえで、執筆にとりかかりましょう。執筆が進むにつれて、考えが変わることもあります。そのときは一度、振り返ってみて、「私は何を伝えたいのか?」しっかり考えてみましょう。
アンチパターン
- 紙面が余っていたor文書量が少ないので、何か書かなきゃいけないと思って、なんとなく書いてみました。
- なんか難しいことを書いてみて、賢さアピールしてみたい。(※ こんな人はほとんどいませんが、そういう誘惑はあるかもしれませんね。)
対策
- 読み返す。「何を伝えたいのか」という観点をもって、読み返してみましょう。
- 文書単位での目的と、一文一文単位での目的(メッセージ)があります。文書の目的が達成されるよう、細かい一文単位でのメッセージを練り上げるわけです。
ルール2 複雑に書かない
技術文書は、過去の事実と筆者の考えを伝えることに重きが置かれていますので、他の文書と違って目的がシンプルです。何らかの事実または考えを伝えることが目的です。つまり、ちゃんとそれらが伝わればOKです。印象的にすることも、スマートに見せることも、売れる記事にすること、どれも必要ありません。つまりは、シンプルな文体で構わないのです。
目安としては、次のとおりです。
- 小学校高学年から中学校レベルの文章
- 長い文章よりも短い文章
- 語尾の繰り返しがあってカッコ悪かったとしても良い
[!ちゃんと伝わる例]
試験装置の温度制御部に異常があった。おそらく、温度センサーに異常があったと考える。温度センサーの異常は、付着した塩分よるものと推測される。なお、塩分の付着は、実地調査にて確認した。
抑えておきたいコツとしては、次のとおりです。
- ワンセンテンス-ワンメッセージ
- 読点が一文に3以上含まれていれば、黄色信号、4つ以上であれば、赤信号
- 主語、修飾語(上記例の2文目でいう”温度センサーに”)に抜けがないこと
コツの反対を試してみます。
[!伝わりにくい例]
試験装置の温度制御部に異常があり、おそらく、温度センサーに異常があったと考えるが、この異常は、実地調査で確認した塩分よるものと推測される。
いかがでしょうか。ちょっと極端に書いてしまっているかもしれません。ですが、往々にしてありうる文章の例ではないかと思います。
ルール3 事実とデータを使いメッセージをわかってもらえるようにする
文書は批判的に読まれます。「それって、本当?」という、読者の批判を乗り越えて、メッセージを伝えないといけません。メッセージを伝える手段は、事実、データ、そして論理しかありえません。考えや感想をいくら重ねたとしても、それを支えるものがなければ、「それってあなたの、、、よね?」と言われてしまえば、おしまいです。
繰り返しますが、事実か、あるいはデータを使って、メッセージをわからせます。
[!事実を使って説明する例]
温度センサー部に塩分が付着していた。その他の異常は確認されなかった。以上のことから、塩分が故障原因であったと推測する。
[!データを使って説明する例]
故障品を調査したところ、温度センサー部に塩分が付着していた装置は、15台中14台であった。そのため、塩分が故障原因であったと推測する。
以上の例は、極めて簡単な構成での文章例になります。しかし、実際の場合では、背後の事実関係や論理構成が複雑になっていることが頻繁にあります。そんなケースを口語で書いてみます。
- 「データを散布図でプロットしてみて、相関がありそうだったから、たぶんここに因果があるんじゃないかなぁ」
- 「仮説をいくつかたててみました。そのなかで、仮説Aは実験により否定されましたが、仮説BとCはどっちつかずです。でも過去のデータからすると、仮説Bのほうがよりしっくりくるんです。」
口語で言えば簡単です。口頭で質問されれば適切に答えることができるが、でもそれを、ちゃんとした文章にしようとすると、詰まってしまう、そのような方がそこそこいるのではないかと思います。
そこで、そういった場合の対処法についてです。もちろん文書で複雑なことを書ければベターですが、”目的”が達成されればそれでよいのが、技術文書です。つまり、
- 図やチャートを使って説明する
- なぜなぜ分析やQC7つ道具など、ポピュラーなフレームワークを使う
- 文書の上手な人に相談する
という文章以外のスキルを使っても良いのです。なお、最後の対処法は、ある意味高度ですが、知恵を貸してくれる人を持つことも組織で働くには一つのスキルであったりします。
少し脱線しますが、PowerPointを使って資料を作ることについては、賛否があります。
Pros
- 見た目がよく、スマートに見せられる。
- わかったようになりやすい。(これは、論理関係をページ間で切れるので)
Cons
- 論理的な整合性が破綻しやすい。
- 読者の立場からして、何がいいたいのかわからなくなりやすい。
- 情報に不足があっても気付きにくい。そのせいで再利用性が悪くなる。
筆者の立場からすると、社外向けの資料はPowerPointで、社内向けの文書はWord, Excelなどで作るのが良いのではないかと思います。顧客資料はだいたいのケースで、プレゼンや説明がともないますし、再利用性を高くする必要がないからです。
おわりに
ここで紹介した内容は、筆者のこれまでの経験によりますが、多くの書籍で紹介されているものとそう遠くない内容かと思います。感覚を頼りに、まとめてみましたが、もう一度教科書を読んだうえで、もっとわかりやすい記事にできればよいなと思っています。
Discussion