ITエンジニアが仕事で書く文章は、障害の発生から現在までの対応状況を時系列で説明するものや用語解説のような「事実を記述した文章」と、何らかの判断を示したり、主張や提案をしたりするための「論述的な文章」の2種類に大別できる。一般には、後者の論述的な文章のほうが圧倒的に多い。特に職位が上がると、事実だけの文章を書く機会はほとんどなくなる。部下の人事考課で書くコメント一つとっても、れっきとした論述的文章である。

 ただし、論述的な文章といえども、論述を支える「事実の記述」は必要である。事実だからといって、1から100まで漏れなく書けばよいということではなく、ここまで説明してきた「読み手はどういう人か」および「読み手の期待・関心ごと」を鮮明にして、情報を取捨選択する必要がある。事実の記述で大事なのは、個人の意見や評価を入れないことだ。事実の記述の中に、個人の意見や評価が入り込むと、意図的に事実を歪曲しているように見られがちだからだ。

 ここまではまず、システム機能の説明(事実の記述)を書く場合を例に、物事を「正確に、分かりやすく」書くコツを三つ紹介する。

物事を「正確に、分かりやすく」書くコツ
物事を「正確に、分かりやすく」書くコツ
[画像のクリックで拡大表示]

(a)相手が理解できる言葉を使う

 読み手が意味を知っていて、定義が明確な言葉を使うことを心がけよう。もし、一般的な意味と、その文脈の中で使っている意味が異なるなら、その言葉には注釈や説明書きを付ける必要がある。

 ユーザー企業向けの文章では、専門用語や、アルファベットを3~4文字連ねた略語を使ってはいけないと誤解している人がいる。しかし、定義がはっきりしている専門用語や略語なら、むしろ積極的に使ったほうがよいこともある。例えば、「標的型攻撃」という専門用語を使わずに「サイバー攻撃の一種」、「DHCP」(Dynamic Host Configuration Protocol)という略語を使わずに「LAN内のPCに対してネットワーク関連情報を自動的に割り当てるプロトコル」などと書くと、かえって内容が不明瞭になってしまう。もし読み手が「標的型攻撃」や「DHCP」を知らないようなら、用語解説を付け加えればよい。

 一方、バズワード(BUZZWORD)のような、なんとなく意味が分かるとはいえ、明確な定義が合意されていない(慣用が定着していない)用語や言葉は、読み手によって解釈が変わる恐れがあるので、よほどの必要性がない限り使用を避けよう。

 なお、略語については、身内の間でしか通用しないローカル用語が意外と多いので注意が必要だ。使う場合は、必ず何の略なのかを記すことを習慣付けておきたい。

(b)他との違い、境界を明確に

 システムの機能名称では、似たようなものが出てくることがある。例えば、「顧客登録機能」と「顧客情報入力機能」といった具合である。名前が違うのだから機能の内容も違うのだが、次のように説明したのでは、その違いが全く伝わらない。

ダメな例
 「顧客登録機能」は、顧客を登録する機能。
 「顧客情報入力機能」は、顧客の情報を入力する機能。

 この場合は、違いが分かるように、あるいは両者の境界が分かるように書くべきである。

修正例
 「顧客登録機能」は、新規顧客に関する情報を登録する機能。
 「顧客情報入力機能」は、登録済み顧客に関する情報を追加または修正する機能。