技術文書の品質管理（その２）技術文書を確認する人の視点から

2024-02-09

【目次】

今回は、自分以外の人が技術文書の品質管理をする場合（自分が書いた技術文書を自分以外の人が確認する）に関する解説です。前回と異なり、自分以外の人の視点つまり技術文書を確認する人の視点で解説します。具体的な例として、部下が書いた技術文書を確認するとき（チェックするとき）を考えます。

1.「部下が書いた技術文書をチェックするときに必要なこと」とは

部下が書いた技術文書をチェックするときに必要なこととは「内容が明確に伝わらない書き方（わかりにくい書き方）の基準を持っていること」と「その具体的な修正方法の指示ができること」です。

「〇〇君の書いたこの打ち合わせ資料は内容が明確に伝わらない（わかりにくい）ので修正してくれ」のような指示を部下が受けたとします。

このように指示されれば「どこがわかりにくいのだろう？」と考え、部下は打ち合わせ資料を読み返す必要があります。この打ち合わせ資料を書いた部下は“書き手”なので“知っている人”です^注１）。書き手の立場（知っている人の立場）で書いているので内容が明確に伝わらない箇所がすぐにわからないかもしれません。あるいは、内容が明確に伝わらない箇所を見つけることができないかもしれません。

^注1）：「内容が明確に伝わる技術文書の書き方（その２）」を参照

2. 具体的な修正方法の指示を出す

上司が、内容が明確に伝わらない書き方の基準を持ちさらにその修正方法がわかれば、上司は、部下に対して具体的な修正方法の指示ができます。具体的な修正方法の指示を出すことで、部下も「内容が明確に伝わらない」の意味を理解したうえで自分が書いた技術文書を修正することができます。例えば、以下のような指示です。

①結論がわかりにくいので結論を打ち合わせ資料の冒頭に書いたほうがよい。
＊「６つのルールと18の書き方^注2）」の中の「書き方1：要点を冒頭に書く」に対応します。
②決定事項に対して明確な根拠が書いてないので決定事項が明確に伝わる根拠を書いたほうがよい。
＊「６つのルールと18の書き方」の中の「書き方4：根拠を書く」に対応します。
③この箇所は文の羅列で書いてあるので見出しを付けてかたまりに分けて書いたほうがよい。
＊「６つのルールと18の書き方」の中の「書き方6：かたまりに分けて書く」に対応します。
④この文は長いため内容がわかりにくいので一文一義の考え方で書いたほうがよい。
＊「６つのルールと18の書き方」の中の「書き方16：短い文を書く」に対応します。