GWの割引に乗じて購入した書籍をガッと読んでみた。
社内に素晴らしい技術文書を書く人がいて、自分の文書と何が違うのかずっと気になっていた。課題感を持ちつつも具体的なアクションをとっていなかったのだが、たまたま目についたLINEの勉強会でテクニカルライティングという分野を知り、そのスキルにすごく興味を持った。
開発者として働いてきて非エンジニアが普通に身につけていそうな事務的スキルを磨いてこなかったので、ここ何日かでテクニカルライティングのスキルは明らかに変わった感覚がある。
この書籍は特別新しかったり難しい内容が書かれているわけではないと思う。しかし一度学んでしまえば取り入れやすいTipsばかりなので、すぐ成果に繋がりそう。今までこういう本を読んだことがない人は試しに読んでみるのが良さそう。
良い文書の判断基準
文章が簡潔
一文が短い方が良い。長いと何が重要なのか把握しにくい。
読み手がどんな行動をすれば良いのか明確
- 書き手視点ではなく読み手視点で書く
- 読み手がどの様な人か考える。提出相手だけが読み手だとは限らない
- 例 提出先の部門関係者、経営者
- 思いついた相手から広げる意識をもつ
- その人が何をすべきかわかる様にする。それを判断する根拠も理解できる様にする。
論理的で理解しやすい
情報を整理してロジックツリーを組み立てる。ツリーの階層は3階層までにしておくと理解しやすい
校正時のテクニック
- 書くべき情報を整理する。読み手に必要なキーワードが足りているか考える
- 5W2Hを盛り込む。Hはどの様に(How)とコスト(How Much)
- 文書をリファクタリングする
- 重要な内容を先に書く
- タイトルや概要を有効に活用する
- 文章の構造がもつコンテキストも読み手の理解のフォローに役立てる
- 文章をリファクタリングする
- 接続詞を減らす。文の順序を入れ替えることで改善できることがある
- 箇条書きを効果的に使う
- 7項目以内にする。人が把握できる項目数は7つが平均
- 見出しと箇条書きのセットで一つの情報
- 手順のステップは10項目以内に抑える
- 操作と結果は文章を分ける
- 文をリファクタリングする
- 一文40字が目安
- 主題は一つに絞る
- 行動してもらうことが目的の文は動詞で表現する
- OK 〇〇してください
- NG 〇〇が必要です
- 否定表現は減らす。肯定系で書けないか検討する
- ユーザを主語にして、能動態と受動態を使い分ける
- 「など」は使わない
- 選択肢は全て書く。あるいは必要なものを書く。
- 同様の表現は英語に存在しない。英訳で誤訳に繋がる
- カッコは丸括弧（）と鉤括弧「」の二種類を基本にする
- 丸括弧は言い換えや製品名
- 鉤括弧は固有名詞や強調
- 補足情報を括弧書きするのはNG
- 一文が長くなる、冗長
