ドキュメントを書くときに

成功しなかったソフトウェアや、ソフトウェア開発の中から、その失敗に至る原凶となった悪質な共通パターンを

カタログ化して、共有する活動も行われています。これは、良質なパターンとは分けて、

「アンチパターン」と呼ばれています。

「アンチパターン」の用途は、「反面教師」であり、「転ばぬ先の杖」です。

アンチパターンは「陥りやすい罠」の定義集となっています。

これらを知っておけば、早めに兆候をつかんで、トラブルを未然に防ぐことができます。

また、仮にトラブルに陥っても、それを現認できれば、適切な対策を打つことができます。

2.全角・半角、正式名称・略称全部バラバラ

同一人物が作成しているにも関わらず、その日の気分なのか統一しないパターン。

...

半角・全角、正式名称・略称が混在すると、以下のデメリットがあるので、統一すること。

・ 単純に見づらい

・ 同一のものを指しているのか判別しづらい

・ 検索・置換にヒットせずに漏れる

5. 見てもらいたい箇所を強調していない

該当箇所を自分で探せパターン

文章が短ければそれでも良いが、ログのバックトレースなどをノーヒントで探せと言われると厳しい。

11. 結論を最初に言わない

自分の苦労話を聞いてパターン

障害報告では、原因・影響・対策などの優先度が高い（＝知りたい）ので、そういったものから先に書くべき。

見る人は、調査者の苦労話を聞きたいのではなく、結論を知りたい。

結論が分からない状態で読み進めるのは苦痛。また、後日見たときもまた、最初から読まなければならず、苦痛。

13. 否定文を多用する

結局、どっちなの？パターン

否定文を使うと、以下のデメリットがあるので、肯定文を使用するようにする。

・ 頭の中でその反対を考えないといけない

・ 最後まで読まないと分からない。最後で逆転するので分かりにくい。

とかとか...個人的に耳が痛いものも多いです :confounded: